Embedded Linux Japan Technical Jamboree 63 slides/videos uploaded

Status of Embedded Linux, Tim Bird
Review of ELC Europe 2017, Tim Bird
mplementing state-of-the-art U-Boot port, 2017 edition, by Marek Vasut
Linux カーネルのメモリ管理の闇をめぐる戦い(協力者募集中, Tetsuo Handa (NTT Data)
Request for your suggestions: How to Protect Data in eMMC on Embedded Devices, Gou Nakatsuka (Daikin)
Fuego Status and Roadmap, Tim Bird
Multicast Video-Streaming on Embedded Linux environment, Daichi Fukui (TOSHIBA)
From 1 to many Implementing SMP on OpenRISC, Stafford Horne
Core Partitioning Technique on Multicore Linux systems, Kouta Okamoto (TOSHIBA)
Debian + YoctoProject Based Projects: Collaboration Status, Kazuhiro Hayashi (TOSHIBA)


See-also: Septemer 2017 Jamboree 62:

Status of Embedded Linux, Tim Bird
EdgeX Foundry: Introduction and demonstration of end to end IoT system, Victor Duan, Linaro
Lighting Talk: Integration between GitLab and Fuego, Tomohito Esaki, IGEL Co., Ltd.
DebConf17 Report, Kazuhiro Hayashi, TOSHIBA
Lightning Talk : About the LTS now, Shinsuke kato, Panasonic Corporation
Kernel Recipes 2015 – Linux Stable Release process, Greg KH
Lightning Talk: IPv6 Ready Logo Test for LTSI 4.9 and introduction about CVE-2016-5863 and CVE-2017-11164, Fan Xin, Fujitsu Computer Technologies Limited


Environment variable whitelisting patch for U-Boot

Quentin Schulz of Free Electrons submitted a patch to U-Boot, adding whitelisting of variables, based on a patch by Maxim Ripard of Free Electrons.

[PATCH 00/11] Introduce variables whitelisting in environment

This patch series is based on a patch series from Maxime. This is an RFC. It’s been only tested in a specific use case on a custom i.MX6 board. It’s known to break compilation on a few boards. I have a use case where we want some variables from a first environment to be overriden by variables from a second environment. For example, we want to load variables from the default env (ENV_IS_NOWHERE) and then load only a handful of other variables from, e.g., NAND. In our use case, we basically can be sure that the default env in the U-Boot binary is secure but we want only a few variables to be modified, thus keeping control over the overall behaviour of U-Boot in secure mode. It works in that way:
– from highest to lowest priority, the first environment that can be loaded (that has successfully init and whose load function has returned no errors) will be the main environment,
– then, all the following environment that could be successfully loaded (same conditions as the main environment) are secondary environment. The env variables that are defined both in CONFIG_ENV_VAR_WHITELIST_LIST and in the secondary environments override the ones in the main environment,
– for saving, we save the whole environment to all environments available, be they main or secondary (it does not matter to save the whole environment on secondary environments as only the whitelisted variables will be overriden in the loading process

[1] https://patchwork.ozlabs.org/cover/842057/

For more info, see full email/patch on:

bootloader_instrumentation_suite – for u-boot

This test suite helps you keep track of different versions of u-boot/build tools, static analysis of that build’s binaries, and runtime trace results of running that binary on a given hardware configuration. For each u-boot/build configuration it keeps a database of information it statically gathered for each boot stage, boot stage images/ELF files, a prepared SD card image, and test results of runtime trace analyses. If it detects changes in the u-boot source or build tools it will create a new set of test result directories with a new sdcard image and static analysis results.[…]





Qualcomm seeks bootloader engineer

Embedded Software Engineer – Bootloaders
Qualcomm processors provide integrated solutions for millions of diverse mobile and new emerging platforms across IoT, Automotive and Compute markets. It all starts with the Boot Firmware the first mission critical code to execute on our SoC(System on chip) and prepare the system for operation. We design and develop the software we put in mask boot ROM, along with system boot-loaders. Features we work on include image authentication, multicore setup, the UEFI pre-boot environment, configuration of next-generation DDR memories, ARM CPU and custom Qualcomm DSP/microprocessors, MMU/Cache memory management and advanced driver development for multiple boot/storage devices including eMMC, UFS, NAND, SPI-NOR, QSPI and flashless boot transport interfaces such as PCIe, SDIO, USB. Embedded Bootloader design & development involves architecting solutions to address different use cases and feature requirements in the early bootloader environment before the handoff to the High Level Operating System kernel. Engineer is expected to work with different Qualcomm build infrastructure tools and ARM compiler tool chains to enable different drivers and services for Bootloaders, optimizing them both for boot time, internal memory size constraints and power metrics.
* Design, development and integration of custom and/or open source Bootloaders for QCT mobile platforms.
* ThreadX, Linux, Android, Windows Boot process knowhow
* UEFI (Unified Extensible Firmware Interface) based bootloader and device driver model experience
* coreboot, uboot based bootloader experiences



Microsoft seeks senior embedded Linux firmware engineer

The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services.
This role will be for a highly-motivated Firmware Engineer with a solid background in embedded system design using embedded Linux.
* 5+ years professional experience in one or many of: designing, developing embedded solutions using ARM SoCs and Linux, extensive u-boot customization, Linux kernel internals and adding new hardware drivers.
* 2+ years proven and demonstrable programming skill in C/C++ for resource constrained embedded platforms.
* Experience with debugging tools such as JTAG, oscilloscopes and bus analyzers.



U-Boot v2017.09 released

Tom Rini has announced the v2017.09 release of U-Boot. And it clarifies status of VU166743/CVE-2017-3225/CVE-2017-3226, excerpt below:

I’ve released v2017.09 and it’s now live on git and FTP and ACD (along with PGP sig file). There’s a few things I need to headline in this release. First and foremost is https://www.kb.cert.org/vuls/id/166743 (aka CVE-2017-3225 and CVE-2017-3226). If you’re using CONFIG_ENV_AES in your project, you have security implications to worry about and decide the correct path forward in. With respect to the community, I marked it as deprecated for this release, and I plan to remove it for the next release unless someone with relevant background steps up and wants to rewrite the code in question (and make sure the rest of the environment code isn’t going to lead to other issues similar to CVE-2017-3226). Both of the issues in question here could be fixed but the worry is about it being the “tip of the iceberg” in the area. […]

Full announcement:



more on U-Boot encryption vulnerabilties

Re: https://firmwaresecurity.com/2017/09/08/u-boot-aes-cbc-encryption-multiple-vulnerabilities/

I asked on the U-Boot mailing list for more information on this issue. The response from Tom Rini of Konsulko:

So, I mentioned this in the patch that migrated the option to Kconfig and marked it deprecated, and I plan to mention it in the release notes on Monday. But, this option has no in-tree users and I plan to remove the code in the near term, if no one with the relevant background steps up to re-implement it. Thanks!

Full post:


U-Boot AES-CBC encryption multiple vulnerabilities

Vulnerability Note VU#166743
Das U-Boot AES-CBC encryption implementation contains multiple vulnerabilities

Das U-Boot is a device bootloader that can read its configuration from an AES encrypted file. For devices utilizing this environment encryption mode, U-Boot’s use of a zero initialization vector and improper handling of an error condition may allow attacks against the underlying cryptographic implementation and allow an attacker to decrypt the data.Das U-Boot’s AES-CBC encryption feature uses a zero (0) initialization vector. This allows an attacker to perform dictionary attacks on encrypted data produced by Das U-Boot to learn information about the encrypted data. Devices that make use of Das U-Boot’s AES-CBC encryption feature using environment encryption (i.e., setting the configuration parameter CONFIG_ENV_AES=y) read environment variables from disk as the encrypted disk image is processed. An attacker with physical access to the device can manipulate the encrypted environment data to include a crafted two-byte sequence which triggers an error in environment variable parsing. This error condition is improperly handled by Das U-Boot, resulting in an immediate process termination with a debugging message. The immediate failure can be used as an oracle for a Vaudenay-style timing attack on the cryptography, allowing a dedicated attacker to decrypt and potentially modify the contents of the device. An attacker with physical access to the device may be able to decrypt the device’s contents. The CERT/CC is currently unaware of a practical solution to this problem.[…]


U-Boot UEFI updates, for standard distro boot

Rob Clark has a new 20-part RFC patch to U-Boot to significantly improve U-Boot’s UEFI support. I’ve included most of Rob’s comments below, see the patch for the code.

[PATCH v0 00/20] enough UEFI for standard distro boot

This patchset fleshes out EFI_LOADER enough to support booting an upstream \EFI\BOOT\bootaa64.efi (which then loads fallback.efi and then eventually the per-distro shim.efi which loads the per-distro grubaa64.efi) without resorting to hacks to hard-code u-boot to load a particular distro’s grub, or other hacks like setting up the distro installation as live-media. The first seven patches add dependencies that will be needed later in the series. Patches 8-15 make u-boot work with upstream grub, without relying on distro patches. Patches 16-19 add missing bits of the UEFI implementation needed to support shim/fallback. And finally patch 20 adds bootmanager support to avoid shim/fallback after first boot.

Background: with a normal UEFI implementation, the boot process is:

a) firmware (u-boot) looks at BootOrder and the BootXXXX variables to try to determine what to boot.
b) the firmware will look at the BootXXXX variables (which contain an EFI_LOAD_OPTION “struct” in order specified by BootOrder, and will boot the first bootable option.
c) The EFI_LOAD_OPTION specifies a device-path which identifies the device and file path of the .efi payload to exectute.

If there are no bootable options the firmware falls back to loading \EFI\BOOT\bootaa64.efi (exact name varies depending on arch), which then loads fallback.efi which uses the EFI_SIMPLE_FILE_SYSTEM_PROTCOL and EFI_FILE_PROTOCOL to search for \EFI\*\boot.csv, and will then set BootOrder and BootXXXX EFI variables accordingly so that on next boot fallback.efi is not necessary.

(I’m ignoring secure boot, it is out of scope here.)

For example, if you had both fedora and opensuse installed on the same disk in different partitions, you would have both:

+ \EFI\fedora\boot.csv
+ \EFI\opensuse\boot.csv

The former would contain the filename of \EFI\fedora\shim.efi and the latter to \EFI\opensuse\shim.efi (each of which would know to load \EFI\fedora\grubaa64.efi or \EFI\opensuse\grubaa64.efi). Based on this, fallback.efi would setup EFI_LOAD_OPTION’s Boot0000 and Boot0001 (and BootOrder would control the order the load-options are considered).

With a real UEFI fw there would also be some sort of boot-order menu (ie. hold down f9 at boot, and get a menu to pick which of the Boot* load-options to try first). That is not part of this patchset but would be a useful next step to allow installing multiple operating systems on the same disk.

This patchset provides EFI variable support during bootservices, so viewing or modifying EFI variables after linux ExitBootServices()’s is not possible. If the board supports saveenv() this will be called in efi_exit_boot_services() to persist variables that where set during the boot process. Making variables available after EBS is tricky on hardware that does not have dedicated storage, as after EBS u-boot no longer controls the devices. An approach that Alexander Graf suggested, is that since reboot/halt is controlled via UEFI, is that on boards that can ensure memory is persisted across reboot, to store modified EFI variables in a special memory location and turn halt into reboot uboot -> appropriate setenv() calls -> saveenv() -> halt in order to persist modified variables. Which is also not part of this patchset, and will likely require some board-specific help.

There will be some updates to this patchset depending on whether we move to c11 as Heinrich suggested (ie s/L”string”/u”string” and some changeups in the vsprintf patch). But rather than calling this an RFC (which I figured was more likely to get ignored for review) I am calling this a v0.

Thanks to Peter Jones for a couple of the patches, and a bunch of help understanding what the things above the UEFI fw expect (and fixing a few shim and grub bugs that we found along the way).

32 files changed, 2508 insertions(+), 329 deletions(-)

Full announcement from Rob:


EFI variable support for U-Boot

Rob Clark has an RFC patch to U-Boot, with UEFI variable support:

[RFC] efi: variable support

Mapping from EFI variables to grub variables. Still almost as many TODOs as lines of code, but just figured I’d send out an early version for comments. I was thinking of it as a useful way for u-boot to pass values to grub (although grub is still missing a way for grub scripts to retrieve UEFI variables). The rough idea is to encode GUID + variable name plus “efi_” prefix (to avoid unintended u-boot variables leaking into the UEFI world). And then encode the type (and attributes?) in the string value of the variable. Ie. something like:

setenv efi_8be4df6193ca11d2aa0d00e098032b8c_OsIndicationsSupported (u64)0

Full patch/thread:


Hacking the Virgin Media Super Hub

By Jan Mitchell and Andy Monaghan, 12 June 2017
Context’s Research team have looked at a large number of off-the-shelf home routers in the past and found them to be almost universally dreadful in terms of security posture. However, flagship routers from large ISPs such as BT, Sky and Virgin Media are notably absent from the regular stream of router vulnerabilities in the press. We were curious to discover if these routers were significantly more secure than their off-the-shelf cousins, so we decided to dedicate some of our public research time into looking at one of these devices. […]
The output in Figure 1 suggested that U-Boot is executing a boot script, which was definitely something we wanted to investigate. The first step was to obtain a copy of the bootloader by reading the Flash memory. Given we didn’t have the ability to input characters this would be somewhat tricky via software, so we fired up the hot air gun and removed the Spansion (S25FL129P) NAND flash chip. There are a number of ways to read data from a flash chip, all of which we will be detailing in another blog shortly. In our case, as our preferred I2C/Serial Peripheral Interface (SPI) reader was in another office we used a BeagleBone Black and a bit of Python to manually drive the chip’s SPI bus[…]



Microsoft seeks U-Boot Linux firmware Engineer

Senior Software Engineer, Linux Firmware – CSI / Azure – Cloud Server Infrastructure
The Cloud Server Infrastructure Firmware Development (CSI-FW) team is responsible for server hardware definition, design and development of Server and Rack Infrastructure engineering for Microsoft’s online services. […] This role will be for a highly-motivated Firmware Engineer with a solid background in embedded system design using embedded Linux. […] Required Qualifications:
* Extensive knowledge of u-boot customization, Linux kernel internals and adding new hardware drivers



U-Boot gets NVMe support

Zhikang Zhang of NXP added NVMe driver support to U-Boot.

Add Support of devices that follow the NVM Express standard

 Basic functions:
    nvme init/scan
    nvme info – show the basic information of device
    nvme Read/Write

 Driver model:
    Use block device(CONFIG_BLK)’s structure to support nvme’s DM.
    Use UCLASS_PCI as a parent uclass.

The driver code heavily copy from the NVMe driver code in Linux Kernel.

Add nvme commands in U-Boot command line.

1. “nvme list” – show all available NVMe blk devices
2. “nvme info” – show current or a specific NVMe blk device
3. “nvme device” – show or set current device
4. “nvme part” – print partition table
5. “nvme read” – read data from NVMe blk device
6. “nvme write” – write data to NVMe blk device

More info: U-Boot mailing list.

Companies actively contributing to U-Boot

Here are some statistics on the U-Boot project, from a U-Boot list posting by Wolfgang Denk of DENX Software Engineering. The Full List is at the below URL. The subset list below are just the top contributing companies. The posting by Wolfgang also shows the top individuals.

Processed 664 csets from 126 developers
26 employers found
A total of 41330 lines added, 31385 removed (delta 9945)

Top changeset contributors by employer
(Unknown)                  170 (25.6%)
Socionext Inc.             105 (15.8%)
Google, Inc.                88 (13.3%)
NXP                         80 (12.0%)
Konsulko Group              42 (6.3%)
Texas Instruments           28 (4.2%)
Samsung                     26 (3.9%)
Xilinx                      26 (3.9%)
ARM                         20 (3.0%)
DENX Software Engineering   14 (2.1%)

Top lines changed by employer
Konsulko Group            21331 (35.5%)
(Unknown)                 8685 (14.4%)
Socionext Inc.            8227 (13.7%)
NXP                       8112 (13.5%)
Google, Inc.              5308 (8.8%)
DENX Software Engineering 1904 (3.2%)
ST Microelectronics       1801 (3.0%)
Openedev                  1105 (1.8%)
Samsung                    866 (1.4%)
CompuLab                   844 (1.4%)

Employers with the most signoffs (total 111)
NXP                         28 (25.2%)
Xilinx                      16 (14.4%)
DENX Software Engineering   15 (13.5%)
Samsung                     13 (11.7%)
(Unknown)                    9 (8.1%)
Google, Inc.                 9 (8.1%)
Collabora Ltd.               6 (5.4%)
ARM                          5 (4.5%)
Intel                        4 (3.6%)
Socionext Inc.               3 (2.7%)

Employers with the most hackers (total 128)
(Unknown)                   65 (50.8%)
NXP                         17 (13.3%)
Texas Instruments            7 (5.5%)
Xilinx                       4 (3.1%)
DENX Software Engineering    4 (3.1%)
Google, Inc.                 3 (2.3%)
Intel                        3 (2.3%)
Socionext Inc.               3 (2.3%)
Samsung                      2 (1.6%)
Collabora Ltd.               2 (1.6%)

More info:


proposed driver model for U-Boot init

Simon Glass of Chromium posted an 16-part patch to the U-Boot list, adding a driver model to the U-Boot init sequence.

[PATCH 00/16] RFC: Board init using driver model

At present we have a lot of ad-hoc init functions related to boards, for example board_early_init_f(), board_misc_init_f() and dram_init(). There are used in different ways by different boards as useful hooks to do the required init and sequence it correctly. Some functions are always enabled but have a __weak default. Some are controlled by the existence of a CONFIG. There are two main init sequences: board_init_f() (f for running from read-only flash) which runs before relocation and board_init_r() (r for relocated) which runs afterwards. One problem with the current sequence is that it has a lot of arch-specific #ifdefs around various functions. There are also #ifdefs for various features. There has been quite a bit of discussion about how to tidy this up and at least one RFC series[1].

Now that we have driver model we can use this to deal with the init sequences. This approach has several advantages:
– We have a path to remove the #ifdefs
– It is easy for multiple parts of the code to implement the same hook
– We can track what is called and what is not
– We don’t need weak functions
– We can eventually adjust the sequence to improve naming or to add new init phases
– It provides a model for how we might deal with ft_board_setup() and friends

This series starts the process of replacing the pre-relocation init sequence with a driver-model solution. It defines a uclass, adds tests and converts sandbox and a few x86 boards over to use this new setup. This series is not ready for use yet as the rest of the init sequence hooks need to be converted. But there is enough here to show the idea.

Comments welcome.

[1] https://lists.denx.de/pipermail/u-boot/2011-August/098718.html

37 files changed, 980 insertions(+), 45 deletions(-)
create mode 100644 doc/driver-model/board-info.txt

More information:

Alexander on U-Boot+UEFI+GRUB on ARM

Here’s one interesting presentation for the upcoming OpenIoT and Embedded Linux Conference:

Marrying U-Boot, uEFI and grub2 – Alexander Graf, SUSE

Booting is hard. Booting in the ARM world is even harder. State of the art are a dozen different boot loaders that may or may not deserve that name. Each gets configured differently and each has its own pros and cons. As a distribution this is a nightmare. Configuring each and every one of them complicates code that really should be very simple. To solve the problem, we can just add another layer of abstraction (grub2) on top of another layer of abstraction (uEFI) on top of another layer of abstraction (u-boot). Follow me on a journey on how all those layers can make life easier for the distribution and how much fun uEFI really is. After this talk, you will know how ARM systems boot, what uEFI really means, how uEFI binaries interact with firmware and how this enables convergence of the Enterprise and Embedded markets.

Alexander Graf, KVM Wizard, SUSE
Alexander started working for SUSE about 8 years ago. Since then he worked on fancy things like SUSE Studio, QEMU, KVM and openSUSE on ARM. Whenever something really useful comes to his mind, he tends to implement it. Among others he did Mac OS X virtualization using KVM, nested SVM, KVM on PowerPC and a lot of work in QEMU for openSUSE on ARM. He is the upstream maintainer of KVM for PowerPC, QEMU for PowerPC and QEMU for S390x.




U-Boot gets improved testing

Tom Rini of Konsulko posted an 8-part patch to the U-Boot list, improving their CI infrastrucute. It is nice to see firmware projects with improved testing!

[PATCH 0/8] Various travis-ci improvements

The following series does a few things with our existing travis-ci infrastructure.  We update to the latest Ubuntu release that is supported (there are only 2 Linux host choices) and make use of toolchains that are available that way when possible and fix building of x86.  I added in microblaze and sh4 and xtensa to the build loop (I left out blackfin and openrisc as they have compile problems currently in general). The biggest change here is that I’ve added support for test.py running on qemu-x86, qemu-ppce500, qemu-mips*, vexpress_ca15_tc2, vexpress_ca9x4, and integratorcp_cm926ejs along with sandbox.

This final part is I think the most important.  With this change all it now takes to have some build coverage and some test.py coverage is a github account.  You can then login to travis-ci.org that, click a few things and get build and test coverage with minimal effort now.  It takes about 2 hours in its current configuration but could easily be cut down in ones personal repository for quicker test cycles.  And for the record, in addition to email notifications by default one will have https://api.travis-ci.org/repos/USERNAME/u-boot/builds.atom available as an atom feed, in addition to the numerous other notification methods available.