Tag: Linaro

Zephyr Project: MCUboot Security Part 1

~ hucktech ~ 1 Comment

MCUboot Security Part 1
By Zephyr Project
November 28, 2018

Zephyr Project member David Brown, a Senior Engineer with Linaro Ltd., shares the best practices for security in this blog post, which first ran on Brownian Motion.

This is the first in what I hope to be a series of posts about the MCUboot bootloader from a security perspective. Please note that although I work in security, I am by no means a cryptographer. I appreciate any feedback on any and all flaws in my analysis. The MCUboot Project is a secure bootloader for 32-bit MCUs. The goal of MCUboot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade. The essential problem that MCUboot seeks to solve is how to allow firmware updates, while still maintaining some kind of integrity and control over what firmware can be run on the device. The easiest way to prevent unauthorized firmware from running on a device is to configure the flash to be immutable. Unfortunately, this prevents potential security updates (as well as functionality improvements). MCUboot solves this by itself being a small amount of code that can be placed in an immutable section of flash. It then can verify the main code before allowing it to execute, as well as control updates to that code. MCUboot is configurable, and these configuration choices affect the security promises that MCUboot is able to make.[…]

https://www.zephyrproject.org/mcuboot-security-part-1/

https://www.davidb.org/post/mcuboot-security-1/

https://mcuboot.com/

 

ARM releases EBBR 0.7 spec

~ hucktech ~ Leave a comment

The Embedded Base Boot Requirements (EBBR) specification defines requirements for embedded systems to enable inter-operability between SoCs, hardware platforms, firmware implementations, and operating system distributions. The aim is to establish consistent boot ABIs and behaviour so that supporting new hardware platforms does not require custom engineering work.

https://github.com/ARM-software/ebbr/releases/tag/v0.7

https://github.com/ARM-software/ebbr
https://github.com/ARM-software/ebbr/wiki

see-also:

Click to access Dong_Wei_ARM_Final.pdf

https://www.linaro.org/blog/the-boot-problem/

Linaro announces the Trusted Firmware open project

~ hucktech ~ Leave a comment

Linaro Community Projects Division announces the Trusted Firmware open project
San Jose – WEBWIRE – Tuesday, October 16, 2018

The Trusted Firmware project promises to provide an important software foundation to further security development for both Cortex-A and Cortex-M/R processors. Linaro Community Projects Division, the division of Linaro managing open source community projects with open governance, today announced that Trusted Firmware is available as a Linaro Community Projects Division open project. Trusted Firmware provides a reference implementation of Secure World software for Armv7, Armv8-A and Armv8-M architectures. It provides SoC developers and OEMs with a reference trusted code base complying with the relevant Arm specifications. This forms the foundations of a Trusted Execution Environment (TEE) on application processors, or the Secure Processing Environment (SPE) on microcontrollers.[…]

https://www.webwire.com/ViewPressRel.asp?aId=230084

https://www.trustedfirmware.org/

 

Linaro Connect Vancouver BC: CfP open

~ hucktech ~ Leave a comment

 

Call for Proposals: opened 8 May 2018
Deadline to submit proposals: ends 23 July 2018

 

http://connect.linaro.org/cfp/
http://connect.linaro.org/

PS: Resources from last Linaro Connect:

http://connect.linaro.org/hkg18/resources/

U-Boot gets Android Verified Boot (AVB) 2.0

~ hucktech ~ Leave a comment

Igor Opaniuk of Linaro posted a patch to the U-Boot list, adding Android Verified Boot 2.0 support:

This series of patches introduces support of Android Verified B oot 2.0,which provides integrity checking of Android partitions on MMC. It integrates libavb/libavb_ab into the U-boot, provides implementation of AvbOps, subset of `avb` commands to run verification chain (and for debugging purposes), and it enables AVB2.0 verification on AM57xx HS SoC by default. Currently, there is still no support for verification of A/B boot slots and no rollback protection (for storing rollback indexes there are plans to use eMMC RPMB). Libavb/libavb_ab will be deviated from AOSP upstream in the future, that’s why minimal amount of changes were introduced into the lib sources, so checkpatch may fail. For additional details check [1] AVB 2.0 README and doc/README.avb2, which is a part of this patchset.[…]

https://lists.denx.de/pipermail/u-boot/2018-April/326562.html

 

LAVA 2018.2 released

~ hucktech ~ Leave a comment

Neil Williams of Linaro announced the 2018.2 release of LAVA. Here’s 3 changes excerpted from the announcement below:

* Bootloader support changes: Better detect errors in the bootloader – this adds support to distinguish between a bootloader failure and a kernel failure to detect problems when the bootloader tries to start the kernel. This has an important effect on how some test jobs run – see Quiet Kernels below. The parallel change (7a2b3a68 Change the flow of bootloader commands so they are executed individually) supports detecting failures to download artifacts as distinct from failures to execute once downloaded.

* Bootloader action optimisations: To support the better error detection, several bootloader actions have been optimised. This means that different actions may be used, changing the names you may be using for timeouts. e.g.
https://staging.validation.linaro.org/scheduler/job/209814/definition#defline10
The timeout name was u-boot-interrupt – now it is bootloader-interrupt. The UI shows you which actions have been assembled into the pipeline.
e.g.: bootloader-interrupt: Wait for prompt Hit any key to stop autoboot (timeout 00:02:00)

* Quiet Kernels: The bootloader support changes wait for an indication that the bootloader has completed and that the kernel has started, by watching for a kernel_start_message. If your kernel is configured to be quiet, then each test job using that kernel *must* clear the kernel_start_message:
   context:
   kernel_start_message: ”
In most cases, the test job should not use ‘quiet’ as this hides important debugging information from the kernel boot process.
[…]

https://lists.linaro.org/pipermail/lava-announce/2018-February/000048.html
https://www.linaro.org/initiatives/lava
https://validation.linaro.org/
https://wiki.linaro.org/LAVA
https://github.com/search?q=org%3ALinaro+lava

David Brown at Linaro Connect: Digital signatures and the beginning of the world (on ARM bootloaders)

~ hucktech ~ Leave a comment

From Linaro Connect 2017 in San Francisco:

Digital signatures and the beginning of the world – SFO17-306
David Brown
The bootloader is where it all begins. This session sums up our experiences with various signature types, data formats, implementations and how to choose.

http://connect.linaro.org/resource/sfo17/sfo17-306/

 

ARM (Linaro) on Meltdown and Spectre

~ hucktech ~ 1 Comment

Spoiler alert:

[…]This is the first part in a series of blog posts about Meltdown and Spectre. The intention here was to penetrate the whitepapers and give an easy to grasp overview of the attacks. In the upcoming blog post we will talk more about individual components, like OP-TEE, Linux kernel and other firmware.

https://www.linaro.org/blog/meltdown-spectre/

Linaro releases Enterprise Reference Platform 17.12

~ hucktech ~ Leave a comment

ERP 17.12 has been released!

The goal of the Linaro Enterprise Reference Platform is to provide a fully tested, end to end, documented, open source implementation for ARM based Enterprise servers. The Reference Platform includes kernel, a community supported userspace and additional relevant open source projects, and is validated against existing firmware releases. The Linaro Enterprise Reference Platform is built and tested on Linaro Enterprise Group members hardware and the Linaro Developer Cloud. It is intended to be a reference example for use as a foundation for members and partners for their products based on open source technologies. The members and partners to include distribution, hyperscaler or OEM/ODM vendors, can leverage the reference for ARM in the datacenter.
[…]
– Focused on ACPI and UEFI use-cases.
[…]

http://releases.linaro.org/reference-platform/enterprise/17.12/
https://platforms.linaro.org/documentation/Reference-Platform/Platforms/Enterprise/ReleaseNotes-17.12.md/

More info: linaro-announce@lists.linaro.org list archives:
https://lists.linaro.org/mailman/listinfo/linaro-announce

LAVA 2017.11 released

~ hucktech ~ Leave a comment

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

Fall UEFI Plugfest agenda

~ hucktech ~ Leave a comment

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.

Tianocore patch to increase memory protection

~ hucktech ~ Leave a comment

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

Linaro Binary Toolchain Release GCC 6.3-2017.02

~ hucktech ~ Leave a comment

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

Tianocore patch to harden UEFI executables

~ hucktech ~ Leave a comment

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

Leif on QEMU and USB host device pass-through

~ hucktech ~ 1 Comment

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.

 

new AArch64 vm-spec validation tools

~ hucktech ~ Leave a comment

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

video of Brian’s Tianocore Linaro Connect presentation

~ hucktech ~ Leave a comment

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.