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
Uncategorized

video of Brian’s Tianocore Linaro Connect presentation

Brian Richardson of Intel recently gave a presentation at ARM Ltd’s Linaro Connect on the subject of UEFI. Intel started UEFI but in recent years ARM is also using UEFI.

Standard
Uncategorized

Linaro Connect

ARM’s Linaro Connect is happening. Click on their web page for live streaming.
In addition to all of the ARM topics, Brian Richardson, an Intel evangelist will be speaking about UEFI at this event. 🙂

 

Linaro Connect LAS16

Standard