Uncategorized

LAVA 2017.11 released

Neil Williams of Linaro announced the 2017.11 release of LAVA.

2017.11 is the second release on the roadmap to the removal of V1. This is the single largest change ever made to the LAVA packages.
* All dashboard URLs are permanently disabled in lava-server.
* All devices which were not enabled for V2 are now hidden and unusable.
* All V1 code has been removed from lava-dispatcher.
* All V1 documentation has been removed from lava-server-doc.

2017.11 also includes large changes to the packaging of both lava-server and lava-dispatcher. The prompts formerly used to configure a V1 remote worker have been removed.

https://lists.linaro.org/pipermail/lava-announce/2017-November/000040.html
https://lists.linaro.org/pipermail/lava-announce/2017-September/000037.html
https://github.com/Linaro/pkg-lava-server
https://github.com/Linaro/pkg-lava-dispatcher
https://www.linaro.org/initiatives/lava/
https://validation.linaro.org/
https://wiki.linaro.org/LAVA
https://wiki.linaro.org/QA/AutomatedTestingFramework
https://wiki.debian.org/LAVA

Standard
Uncategorized

Fall UEFI Plugfest agenda

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

http://www.uefi.org/events/upcoming

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.

Standard
Uncategorized

Tianocore patch to increase memory protection

Ard Biesheuvel of Linaro submitted a V2 5-part patch to the EDK2 project, to harden UEFI more!

This is a proof of concept implementation that removes all executable permissions from writable memory regions, which greatly enhances security. It is based on Jiewen’s recent work, which is a step in the right direction, but still leaves most of memory exploitable due to the default R+W+X permissions. The idea is that the implementation of the CPU arch protocol goes over the memory map and removes exec permissions from all regions that are not already marked as ‘code. This requires some preparatory work to ensure that the DxeCore itself is covered by a BootServicesCode region, not a BootServicesData region. Exec permissions are re-granted selectively, when the PE/COFF loader allocates the space for it. Combined with Jiewen’s code/data split, this removes all RWX mapped regions.

Changes since v1:
– allocate code pages for PE/COFF images in PeiCore, so that DxeCore pages have the expected memory type (as suggested by Jiewen)
– add patch to inhibit page table updates while syncing the GCD memory space map with the page tables
– add PCD to set memory protection policy, which allows the policy for reserved and ACPI/NVS memory to be configured separately
– move attribute manipulation into DxeCore page allocation code: this way, we should be able to solve the EBC case by allocating BootServicesCode pool memory explicitly.

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

Standard
Uncategorized

Linaro Binary Toolchain Release GCC 6.3-2017.02

Linaro does regular drops of core tools, and these days they’re using GCC v6.x, and GCC has a few new language features and target architecture features recently. Excerpting the Linaro announcement:

The Linaro GCC 6.3-2017.02 Release is now available. […]  The Linaro binary toolchain is a collection of x86-hosted GNU cross-toolchains targeting a variety of ARM architecture targets. Linaro TCWG provides these toolchains as a service to our members. Due to hardware availability, system-image availability, validation complexity, and user-base size, not all host and target toolchain combinations can be validated by Linaro with the same rigor. The most rigorously validated targets are little-endian and hardfloat implementations of the 32-bit ARMv7 (arm), 32-bit ARMv8 (armv8), and 64-bit ARMv8 (aarch64) architectures.  Linaro recommends those targets to our members. […] The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc’s memcpy API. Linaro recommends using the 64-bit x86_64 host toolchains as the 32-bit i686 host toolchains and the 32-bit mingw host toolchains will only be provided as long as there is sufficient member interest to justify their continued availability. […] The GCC 6 Release series has significant changes from the GCC 5 release series.  For an explanation of the changes please see the following website[1]. For help in porting to GCC 6 please see the following explanation[2]. […]

[1] https://gcc.gnu.org/gcc-6/changes.html
[2] https://gcc.gnu.org/gcc-6/porting_to.html
https://gcc.gnu.org/onlinedocs/

http://releases.linaro.org/components/toolchain/gcc-linaro/6.3-2017.02/
http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/
http://snapshots.linaro.org/components/toolchain/binaries/

See the full announcement for more details:
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Standard
Uncategorized

Tianocore patch to harden UEFI executables

Ard Biesheuvel of Linaro has posted a V2 patch to the Linux-EFI list, which includes some UEFI image hardening.

[PATCH v2 00/14] arm64+ARM: efi: PE/COFF cleanup/hardening

This cleans up the PE/COFF EFI header, by taking some of Mark’s patches and use them to replace open coded constants with symbolic ones, and remove incorrect values or unused sections. Finally, it updates the section layout so that the kernel Image can be mapped in a way that does not require setting RWX permissions anywhere. Note that this is currently not a huge win, given that most current UEFI implementations map all of RAM RWX by default, but this is finally gaining some attention, and work is underway to make the PE/COFF loader in EDK2 adhere to the section permissions, which would also allow the RAM mapping to default to non-executable. Work in progress nonetheless…

Changes since v1:
– added missing secondary SOB on Mark’s patches
– leave Image header as before, only move the PE header to a separate file
– put PE header fixes in a separate patch
– add acks from Mark and Peter (#6)
– give ARM the same treatment as arm64 (#10 – #13)
– add NB10 PE debuglink entry to ARM PE/COFF header as well (#9, #14)

Full announcement/patch:
http://vger.kernel.org/majordomo-info.html

Standard
Uncategorized

Leif on QEMU and USB host device pass-through

Leif has a new blog post on using UEFI with USB pass-through.

[…]”One thing that is unsurprising, but very cool and useful, is that this works well cross-architecture. So you can test that your drivers are truly portable by building (and testing) them for AARCH64, EBC and X64 without having to move around between physical machines.

http://blog.eciton.net/uefi/qemu-usb-passthrough.html

Checkout his previous blog post, on UEFI driver development, as well as older posts on Linaro/ARM/UEFI history.

 

Standard
Uncategorized

new AArch64 vm-spec validation tools

Riku Voipio of Linaro has announced the release of some new tools that validate the VM to the Linux cross-distro list.

Some time ago we drafted a specification[1] for AArch64 virtual machines. Now we are launching verification tools that let everyone verify that the whole stack (host hypervisor, guest firmware and guest OS image) implements the spec 2[]. For some extra background see the blog post on vmspec [3]. From the cross-distro point of view, we are interested in finding out if
– QEMU shipped is new enough (2.6+)
– a compatible EFI for arm64 guests is available
– a vmspec compatible cloud guest image is available

If the image comes with cloud-init, vmspec-boot can be used directly to verify compliance. Without cloud-init, one can run vmspec-verify inside the guest to verify manually. The tools are still under development, for example the ACPI test returns a failure even if the guest would support ACPI if forced. Feedback and patches are always welcome. The README.md lists a handful of guest images that have been used in testing. I’d be most happy to add more links to the list!

[1] http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf
[2] https://github.com/linaro/vmspec-tools
[3] http://www.linaro.org/blog/core-dump/ensuring-bootable-arm-vm-images/
Full message:
https://lists.linaro.org/mailman/listinfo/cross-distro

Standard