Uncategorized

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

 

https://jobs.qualcomm.com/public/jobDetails.xhtml?requisitionId=1960693

Standard
Uncategorized

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.

https://careers.microsoft.com/jobdetails.aspx?jid=321602&job_id=1070761

https://azure.microsoft.com/en-us/blog/ecosystem-momentum-positions-microsoft-s-project-olympus-as-de-facto-open-compute-standard/

Standard
Uncategorized

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:

https://lists.denx.de/pipermail/u-boot/2017-September/305340.html

 

Standard
Uncategorized

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:

https://lists.denx.de/pipermail/u-boot/2017-September/305181.html

Standard
Uncategorized

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.[…]

http://www.kb.cert.org/vuls/id/166743

Standard
Uncategorized

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:
https://lists.denx.de/pipermail/u-boot/2017-August/301203.html

 

Standard
Uncategorized

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:
https://lists.denx.de/listinfo/u-boot

 

Standard