U-Boot ported to Intel64

Simon Glass of Chromium posted a *82-part* patch to the U-Boot list, with a port of U-Boot from 32-bit x86 to 64-bit x64 support. Quoting Simon’s initial message:

[PATCH 00/82] x86: Add initial support for 64-bit U-Boot

At present U-Boot runs entirely in 32-bit mode on x86, except for the initial switch from 16-bit mode. On 64-bit machines it is possible to run in 64-bit mode. This series starts the process of adding this support. The main benefit of 64-bit mode for a boot loader is direct access to all available memory. There are also more registers, but this makes very little difference. This feature is implemented by putting all of the 32-bit code in an SPL build. SPL then runs through all the init that has to be done in 32-bit mode, changes to 64-bit mode and then jumps to U-Boot proper. Typically the total code size increases slightly. For example, on link in 32-bit mode, U-Boot has around 480KB of code (admittedly with a large number of features enabled). In 64-bit mode, U-Boot falls to around 460KB, but SPL adds another 60KB, for a net increase of 40KB. Partly this is due to code duplication and partly it is due to the worse code density of 64-bit code on x86. Many major features are not implemented yet, for example:
  – SDRAM sizing
  – Booting linux
  – FSP support
  – EFI support
  – SCSI device init
  – Running video ROMs
Still, this is a big step forward towards full 64-bit support. To enable it, select CONFIG_X86_RUN_64BIT. This series is available at u-boot-x86/64-working.

91 files changed, 1796 insertions(+), 705 deletions(-)
See full description in the post:
http://lists.denx.de/pipermail/u-boot/2016-September/267925.html

U-Boot v2016.09 released

Tom Rini of Konsulko announced the latest release of U-Boot on the u-boot list @lists.denx.de.

Highlights:
– More DM work (MMC, of-platdata for size constrained instances, etc)
– Lots and lots of architecture / SoC / Platform updates: x86, rockchip,
  sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
– mkimage cleanups
– More test.py updates, vboot now a testcase
– Secure boot work on both ARM and PowerPC.
– PSCI updates
– MAKEALL is gone, buildman is for use by all
– We now have xtensa support
– DT overlays
– More Kconfig migration
– Some NFS fixes

Read the full announcement if you’re able to help U-Boot with testing, they’re looking for some help with their new automated test framework.
https://github.com/swarren/uboot-test-hooks
https://github.com/trini/uboot-test-hooks
http://www.denx.de/wiki/U-Boot

U-Boot v2016.09-rc2 released

Tom Rini of Konsulko announced the v2016.09-rc2 release of U-Boot. Excerpting most of his announcement:

It’s release day and v2016.09-rc2 is out now.  […]

A short list of changes to come in now are:
– More and various SoC and architecture updates
– Various DM updates and conversions
– PSCI updates
– MAKEALL is gone, buildman is for use by all
– We now have xtensa support
– DT overlays

A non-code change is that now I have Jenkins setup to automatically poll my WIP branches and run test/py/test.py on a few real boards along with sandbox.  I still have some more configuring and cabling to do, and a few more boards I can get setup.

For more info, see the announcement on the u-boot mailing list.

U-Boot v2016.09-rc1 released

Tom Rini of Konsulko announced the v2016.09-rc1 release of U-Boot, his announcement to the U-Boot list is excerpted below:

It’s release day and v2016.09-rc1 is out and the merge window is closed. I’ve updated git and the tarballs are also up now.  I’ve made an attempt at keeping track of what updated as things went along this time:
– DM / MMC block device clean up, patman improvements
– DM now supports of-platdata for cases where we are very much size constrained.
– Various SPI fixes / improvements
– Arch / SoC / Platform updates: x86, rockchip, sunxi, TI, NXP/FSL, Tegra, Zynq, uniphier
– First round of updates to the PSCI code to make it easier to use.
– mkimage cleanups
– More test.py updates, vboot now a testcase
– Secure boot on MPC85xx.

And of course, other things as well.  Please feel free to chime in if there’s something important I forgot to call out. If you notice any problems with the release, please speak out and thanks all!

binman: new U-Boot firmware image creation tool

Simon Glass of Chromium submitted “binman”, a new firmware image creation tool, to the U-Boot project. Below is the intro from Simon’s patch 0/30:

binman: A tool for creating firmware images

This series introduces binman, a tool designed to create firmware images. It provides a way to bring together various binaries and place them in an image, at particular positions and with configurable alignment.

Packaging of firmware is quite a different task from building the various parts. In many cases the various binaries which go into the image come from separate build systems. For example, ARM Trusted Firmware is used on ARMv8 devices but is not built in the U-Boot tree. If a Linux kernel is included in the firmware image, it is built elsewhere.

It is of course possible to add more and more build rules to the U-Boot build system to cover these cases. It can shell out to other Makefiles and build scripts. But it seems better to create a clear divide between building software and packaging it.

U-Boot supports a very large number of boards. Many of these have their own specific rules for how an image should be put together so that it boots correctly. At present these rules are described by manual instructions, different for each board. By turning these instructions into a standard format, we can support making valid images for any board without manual effort, lots of READMEs, etc.

Images consist of a number of entries which are combined to make up the final image. The image is described in the device tree for the board, meaning that it can be accessed at run-time if desired.

Binman is an extensible tool. A set of standard entries is provides, but new entries can be created fairly easily. Entries can be as simple as providing the name of a file to include. They can also handle more complex requirements, such as adjusting the input file or reading header information from one entry to control the position of another.

U-Boot’s mkimage builds FIT images and various other binaries. Binman augments this by allowing these binaries to be packed together. While FIT should be used where possible, it cannot be used everywhere. For example, many devices require executable code at a particular offset in the image. X86 machines require lots of binary blobs at particular places, and a microcode collection easily accessible at boot.

So far binman has enough functionality to be useful, but apart from a few RFC patches, no attempt is made to switch boards over to use it. There should be enough material to permit review and comments.

The series is available at u-boot-dm/binman-working

Future work and missing features are documented in the README.

For more info, see the patch on the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot

U-Boot v2016.07 released

Tom Rini of Konsulko announced U-Boot v2016.07. Excerpting his announcement:

[…] I’ve released v2016.07 and it’s now live on git and FTP and ACD.  As a possible bonus, the tarball is now signed with my PGP key. Looking over the changes in this release, I would say it’s another good, solid, iterative improvement over the last.  MMC has moved to DM, we have more tests for DM now too.  ARM (32 and 64bit), MIPS, x86 have all seen improvements.  We’ve also switched to mirroring what the Linux Kernel does for “libgcc” type functionality now which should help with supporting the compilers that most distributions ship while still catching the types of errors we want caught.  We’ve moved a few more options over to Kconfig (caught some problems in our tools too) and are once again ready for more.  I think we have enough tests available now (thanks to tbot) that really even the complicated things can be moved over now and verified as correct, it’s just a matter of doing it.  We also have the ability for SPL to load FIT images and thus pick the right DT to pass along to the main U-Boot binary. […]

Full announcement:
http://lists.denx.de/pipermail/u-boot/2016-July/260149.html
More info:
http://www.denx.de/wiki/U-Boot

U-Boot: Secure Boot by Authenticating/Decrypting SPL FIT blobs

Andreas Dannenberg of TI submitted a patch to the U-Boot list, with an update to an earlier Secure Boot patch. Here’s the intro comment from the patch:

This patch series is derived from an earlier RFC [1] with (most of the) feedback implemented that was provided by Simon, Tom, and Lokesh (see change log at the end). There are still some loose ends namely affecting the make process (see discussion here [2], maybe Yamada-san has some inputs?) as well as the conversion of the “weak” post-process function call to a Kconfig option. We did experiment with a few options regarding the Kconfig conversion but couldn’t really settle on a good way. Simon or Tom- if you could provide a tiny bit of additional direction here we will be happy to re-visit this and change the current implementation.

Here’s again the high-level summary of what we are trying to achieve:

A method is introduced that uses a “weak” post-process function call that’s injected into the SPL FIT loading process after each blob has been extracted (U-Boot firmware, selected DTB) which is populated with a platform specific function. In case of TI high-security (HS) device variants a ROM API call is performed (via SMC) that transparently handles authentication and optional decryption. This essentially allows authenticating (and optionally decrypting) U-Boot from SPL. The post-processing injection is implemented such to enable a more universal use of this feature by other platforms or for other purposes.

Furthermore the build process has been modified to automatically invoke a TI blob signing/encryption tool through the $TI_SECURE_DEV_PKG env variable already introduced into U-Boot. This singing/encryption step happens for each artifact that gets bundled into the final u-boot.img FIT blob.

Why do we need this for our platforms if some generic form of verified boot already exists in U-Boot? The approach proposed here provides support for decryption which is currently not available in U-Boot (and may not be easily implementable generically for example due to the need for keeping symmetric keys secure). Furthermore it allows for a consistent build as well as runtime flow no matter authentication and/or decryption is used (as opposed to using existing U-Boot verified boot for authentication and an additional TI-specific ROM API call for decryption for example). It also allows for a faster and more efficient boot process (auth and decryption can be performed in a single step by the ROM APIs also utilizing crypto HW accelerators in a completely transparent fashion). However anyone can still use the standard U-Boot verified boot scheme from U-Boot onwards if they so chose and only need authentication.

I also just re-rested the patch series on actual AM437x HS, DRA7 HS, DRA72 HS, and AM57 HS device variants by building and running SPL/U-Boot. I’ve also build-tested the corresponding non-HS device variant configurations to make sure nothing is broken there.

Changes RFC->PATCH:
– Update of README.ti-secure
– Unification of some of the secure ROM API call stuff between AM43xx and
  OMAP5-based platforms by moving those into common files
– Replacement of puts() with printf()
– Minor build simplification/cleanup
– Addition of “Reviewed-by:” comments for files that were pretty much carried
  over from the RFC as-is
– Addition of AM437x HS device build support (was missing in RFC)
– Removal of some redundant conditional compile directives
– Rebased on upstream U-Boot commit “Prepare v2016.07-rc2”

Regards,
Andreas Dannenberg

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg216299.html
[2] https://www.mail-archive.com/u-boot@lists.denx.de/msg216298.html

Andreas Dannenberg (4):
  arm: omap-common: add secure rom call API for secure devices
  arm: omap-common: secure ROM signature verify API
  arm: omap-common: Update to generate secure U-Boot FIT blob
  arm: omap5: add U-Boot FIT signing and SPL image post-processing

Daniel Allred (4):
  arm: cache: add missing dummy functions for when dcache disabled
  spl: fit: add support for post-processing of images
  arm: omap-common: add secure smc entry
  doc: Update info on using secure devices from TI

Madan Srinivas (1):
  arm: am4x: add U-Boot FIT signing and SPL image post-processing

See the patch email thread on the U-Boot list for more details.
http://lists.denx.de/mailman/listinfo/u-boot

U-Boot Secure Boot

Sumit Garg of NXY has submitted a 4-part patch to U-Boot to add Secure Boot support to U-Boot’s SPL framework. Sumit’s patch announcements follow.
(No, I didn’t edit out step 2 in next paragraph, there were only two steps, 1 and 3.)

The patch-set does the following :
1. Enable chain of trust in SPL framework for ARM based platforms.
3. Add SD secure boot target for ls1021atwr platform.

Sumit Garg (4):
  DM: crypto/fsl: Enable rsa DM driver usage before relocation
  SECURE_BOOT: Enable chain of trust in SPL framework
  SECURE_BOOT: Enable SD as a source for bootscript
  arm: ls1021atwr: Add SD secure boot target

[PATCH 1/4] DM: crypto/fsl: Enable rsa DM driver usage before relocation

Enable rsa signature verification in SPL framework before relocation for verification of main u-boot.

[PATCH 2/4] SECURE_BOOT: Enable chain of trust in SPL framework

Override jump_to_image_no_args function to include validation of u-boot image using spl_validate_uboot before jumping to u-boot image.
Also define macros in SPL framework to enable crypto operations.

[PATCH 3/4] SECURE_BOOT: Enable SD as a source for bootscript

Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash.

[PATCH 4/4] arm: ls1021atwr: Add SD secure boot target

Add SD secure boot target for ls1021atwr.
Implement board specific spl_board_init() to setup CAAM stream ID and corresponding stream ID in SMMU. Change the u-boot size defined by a macro for copying the main U-Boot by SPL to also include the u-boot Secure Boot header size as header is appended to u-boot image. So header will also be copied from SD to DDR.

For more information, see the full patch on the list:
http://lists.denx.de/mailman/listinfo/u-boot

U-Boot Secure Boot

Andreas Dannenberg of TI has submitted a 9-part patch to the U-Boot project, adding LOTS more security to the boot process. It includes and depends on some other recent patches by Madan Srinivas, Daniel Allred, and others I think (sorry for lack of attribution).

[RFC 0/9] Secure Boot by Authenticating/Decrypting SPL FIT blobs

This is an RFC for a method that uses a “weak” post-process function call that’s injected into the SPL FIT loading process after each blob has been extracted (U-Boot firmware, selected DTB) which is populated with a platform specific function. In case of TI high-security (HS) device variants a ROM API call is performed (via SMC) that transparently handles authentication and optional decryption. This essentially allows authenticating (and optionally decrypting) U-Boot from SPL. The post-processing injection is implemented such to enable a more universal use of this feature by other platforms or for other purposes.

Furthermore the build process has been modified to automatically invoke a TI blob signing/encryption tool through the $TI_SECURE_DEV_PKG env variable already introduced into U-Boot. This singing/encryption step happens for each artifact that gets bundled into the final u-boot.img FIT blob.

Why do we need this for our platforms if some generic form of verified boot already exists in U-Boot? The approach proposed here provides support for decryption which is currently not available in U-Boot (and may not be easily implementable generically for example due to the need for keeping symmetric keys secure). Furthermore it allows for a consistent build as well as runtime flow no matter authentication and/or decryption is used (as opposed to using existing U-Boot verified boot for authentication and an additional TI-specific ROM API call for decryption for example). It also allows for a faster and more efficient boot process (auth and decryption can be performed in a single step by the ROM APIs also utilizing crypto HW accelerators in a completely transparent fashion). However anyone can still use the standard U-Boot verified boot scheme from U-Boot onwards if they so chose and only need authentication.

The patch series has been tested on DRA7 HS, DRA72 HS, and AM57 HS device variants. The AM43 HS support is still missing some Makefile changes but the principle in the final implementation will be similar what’s implemented for the other devices.

  spl: fit: add support for post-processing of images
  arm: cache: add missing dummy functions for when dcache disabled
  arm: omap-common: add secure smc entry
  arm: omap-common: add secure rom call API for secure devices
  arm: omap5: add secure ROM signature verify API
  arm: omap5: add FIT image post process function
  ti: omap-common: Update to generate secure FIT

  arm: am4x: add secure ROM signature verify API
  arm: am4x: add FIT image post process function

[RFC 1/9] spl: fit: add support for post-processing of images
The next stage boot loader image and the selected FDT can be post-processed by board/platform/device-specific code, which can include modifying the size and altering the starting source address before copying these binary blobs to their final desitination. This might be desired to do things like strip headers or footers attached to the images before they were packeaged into the FIT, or to perform operations such as decryption or authentication.

[RFC 2/9] arm: cache: add missing dummy functions for when dcache disabled
Adds missing flush_dcache_range and invalidate_dcache_range dummy (empty) placeholder functions to the #else portion of the #ifndef CONFIG_SYS_DCACHE_OFF, where full implementations of these functions are defined.

[RFC 3/9] arm: omap-common: add secure smc entry
Adds an interface for calling secure ROM APIs across a range of OMAP and OMAP compatible devices.

[RFC 4/9] arm: omap-common: add secure rom call API for secure devices Adds a generic C-callable API for making secure ROM calls on OMAP and OMAP-compatible devices. This API provides the important function of flushing the ROM call arguments to memory from the cache, so that the secure world will have a coherent view of those arguments. Then is simply calls the omap_smc_sec routine.

[RFC 5/9] arm: omap5: add secure ROM signature verify API
Adds an API that verifies a signature attached to an image (binary blob). This API is basically a entry to a secure ROM service provided by the device and accessed via an SMC call, using a particular calling convention.

[RFC 6/9] arm: omap5: add FIT image post process function
Adds a board specific FIT image post processing function for when CONFIG_SECURE_BOOT is defined.  Also update the omap common config header to enable CONFIG_SECURE_BOOT always for secure TI devices (CONFIG_TI_SECURE_DEVICE is defined).

[RFC 7/9] arm: am4x: add secure ROM signature verify API
Adds an API that verifies a signature attached to an image (binary blob). This API is basically a entry to a secure ROM service provided by the device and accessed via an SMC call, using a particular calling convention. This API is common across AM3x HS and AM4x HS devices.

[RFC 8/9] arm: am4x: add FIT image post process function
Adds a board specific FIT image post processing function when u-boot is compiled for the high-secure (HS) device variant.

[RFC 9/9] ti: omap-common: Update to generate secure FIT
Adds commands so that when a secure device is in use and the SPL is built to load a FIT image (with combined u-boot binary and various DTBs), these components that get fed into the FIT are all processed to be signed/encrypted/etc. as per the operations performed by the secure-binary-image script of the TI SECDEV package.

For more information, see the full patch on the list:
http://lists.denx.de/mailman/listinfo/u-boot

U-Boot v2016.07-rc1 released

Tom Rini announced the latest release of U-Boot.

(Usually U-Boot releases are pretty terse, presuming you’re a U-Boot developer and already understand what is in each release. This announcement has more info!)

Excerpting announcement:

Some highlights include more DM support (both in general such as block) and specific (FSL I2C).  Freescale ARMv8 platform support has been updated with new platforms and MIPS has seen a number of new / updated platforms as well.  And on that note, x86, Zynq, sunxi, TI, rockchip and socfpga also saw big updates.  Finally, we’ve pulled in patches that bring in “lib1funcs” from the Linux kernel rather than rely on gcc’s libgcc.  This will make building on a number of distributions much easier.

Full announcement:
http://lists.denx.de/pipermail/u-boot/2016-June/257121.html

SeaBIOS ACPI patch fixing Ubuntu/Windows installs

Bin Meng posted an 18-part patch to the SeaBIOS list, fixing multiple issues that may impact the installation of Ubuntu (only Ubuntu and no other Linux distros??) and Windows:

[PATCH v2 00/18] x86: acpi: Support installation of Ubuntu/Windows and boot Windows

SeaBIOS can be loaded by U-Boot to aid the installation of Ubuntu and Windows to a SATA drive and boot from there. But till now this is broken. The installation either hangs forever or just crashes. This series fixed a bunch of issues that affect the installation of Ubuntu and Windows, and booting Windows.

Testing was performed on MinnowMax by:
– Install Ubuntu 14.04 and boot
– Install Windows 8.1 and boot
– Install Windows 10 and boot

This series is available at u-boot-x86/acpi2-working.

Changes in v2:
– New patch to remove the unnecessary checksum calculation of DSDT
– New patch to remove header length check when writing tables
– New patch to enable SeaBIOS on all boards
– New patch to add GPIO ASL description

Bin Meng (18):
  x86: minnowmax: Adjust U-Boot environment address in SPI flash
  x86: Call board_final_cleanup() in last_stage_init()
  x86: Fix up PIRQ routing table checksum earlier
  x86: Compile coreboot_table.c only for SeaBIOS
  x86: Prepare configuration tables in dedicated high memory region
  x86: Unify reserve_arch() for all x86 boards
  x86: Reserve configuration tables in high memory
  x86: Use high_table_malloc() for tables passing to SeaBIOS
  x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM
  x86: acpi: Remove the unnecessary checksum calculation of DSDT
  x86: acpi: Remove header length check when writing tables
  x86: doc: Update information about IGD with SeaBIOS
  x86: baytrail: Enable SeaBIOS on all boards
  x86: doc: Mention Ubuntu/Windows installation and boot support
  acpi: Quieten IASL output when ‘make -s’ is used
  x86: baytrail: Add internal UART ASL description
  x86: baytrail: Add GPIO ASL description
  x86: doc: Add porting hints for ACPI with Windows

For more information, see the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot

PXE boot support added to U-Boot’s EFI payload

Alexander Graf of SuSE has submitted a new patch to his EFI payload for U-Boot, adding PXE boot support!

[PATCH 0/4] efi_loader: PXE boot support

One of the most common boot cases with EFI on arm64 is to boot from the network using PXE boot. While TianoCore implements that just fine, we were lacking support for it in U-Boot so far. But no longer! Here is a patch set, enabling PXE booting of EFI payloads. With this patch set, I was successfully able to automatically boot our normal (usually used with TianoCore based systems) environment to boot and run grub2 and a kernel from there with U-Boot.

* efi_loader: Add network access support
* bootp: Move vendor class identifier set to function
* net: Move the VCI and client arch values to Kconfig
* distro: Add efi pxe boot code

For more information, see the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot

coreboot 4.4 released!

coreboot version 4.4 has been released, which includes 850 commits by 90 authors added 59000 lines to the codebase since their last quarterly release. This release includes OpenPOWER support and experimental U-Boot payload support. It also has an Intel ME tool which is new (at least to me). There are many other changes, excerpting their announcement:

Significant changes:
* Build system (30 commits) – Add postcar stage, ‘timeless’ builds, extend site-local, test toolchain by version string, update dependencies, catch ACPI errors, l add additional macros.
* Toolchain updates (40+ patches) – Update IASL to v20160318 , LLVM to v3.7.1, add GNU make, add nds32le GCC compiler
* Lint tools (30 patches) – Update existing lint utilities, add lint tests for executable bit, make sure site-local isn’t committed, add test to break all lint tests.
* Payloads (60 commits) – Fixes for libpayload, coreinfo and nvramcui, add new payloads, see below.
* Maintainers file – (8 patches) – continue adding maintainers for various areas.
* Documentation for adding Intel FSP-based platforms (20 commits)

New architectures:
* power8
* qemu-power8

New payloads:
* depthcharge: For ChromeOS verified boot
* iPXE: For network booting
* Memtest86+: Updated with fixes for correctly testing coreboot with payloads
* U-Boot (Experimental): Alternate payload for booting an OS

New/updated mainboards:
* asus/kcma-d8
* emulation/qemu-power8
* google/auron_paine
* google/gru
* intel/amenia
* intel/apollolake_rvp
* intel/camelbackmountain_fsp
* intel/galileo
* lenovo/t420
* asus/kgpe-d16
* google/oak
* google/chell
* intel/kunimitsu

New/updated socs:
* intel/apollolake
* intel/fsp_broadwell_de
* intel/quark
* marvell/armada38x
* rockchip/rk3399
* cpuamd/mct_ddr3
* drivers/intel/fsp2_0
* northbridge/intel/sandybridge/raminit
* soc/intel/apollolake
* soc/intel/fsp_baytrail
* soc/intel/skylake
* soc/mediatek/mt8173

New vendorcode directories:
* siemens

New/updated submodules:
* chromeec
* 3rdparty/arm-trusted-firmware (329 commits)
* 3rdparty/vboot (28 commits)
* util/nvidia/cbootimage (13 commits)

New/updated Utilities:
* archive – Concatenates files into a single blob with an indexed header
* chromeos – Download and extract blobs from a ChromeOS image
* futility – vboot Firmware utility
* intelmetool – Shows information about the Intel ME on a platform.
* marvell/doimage_mv – No usage notes
* post – Simple utility to test post cards

Full announcement:
http://blogs.coreboot.org/blog/2016/05/02/announcing-coreboot-4-4/
https://www.coreboot.org/releases/

Reversing Huawei router part 2: U-Boot’s CLI

Juan Carlos Jiménez has written the 2nd part of his series on reversing a Huawei router! The first part was excellent, this one is just as good.

Practical Reverse Engineering Part 2 – Scouting the Firmware

In part 1 we found a debug UART port that gave us access to a linux shell. At this point we’ve got the same access to the router that a developer would use to debug issues, control the system, etc. This first overview of the system is easy to access, doesn’t require expensive tools and will often yield very interesting results. If you want to do some hardware hacking but don’t have the time to get your hands too dirty, this is often the point where you stop digging into the hardware and start working on the higher level interfaces: network vulnerabilities, ISP configuration protocols, etc. […]

Part 2:
http://jcjc-dev.com/2016/04/29/reversing-huawei-router-2-scouting-firmware/

Part 1:
https://firmwaresecurity.com/2016/04/09/huawei-hg533-reversing-part-i/
http://jcjc-dev.com/2016/04/08/reversing-huawei-router-1-find-uart/

U-Boot Verified Boot to get security improvements

Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.

I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.

P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.

Full post/thread:
http://lists.denx.de/mailman/listinfo/u-boot

U-Boot’s EFI loader gets El Torito ISO support

Alexander Graf of SuSE has updated his EFI patch for U-Boot, adding the ability to boot from El Torito-style ISOs:

efi_loader: Support loading from El Torito isos

Some distributions still provide .iso files for installation media. To give us greatest flexibility, this patch set adds support for El Torito booting with EFI payloads.

  iso: Make little endian and 64bit safe
  iso: Start with partition 1
  iso: Allow 512 byte sector size
  efi_loader: Split drive add into function
  efi_loader: Add el torito support
  efi_loader: Pass file path to payload
  efi_loader: Increase path string to 32 characters
  distro: Enable iso partition code

For more information, see the full patch:
http://lists.denx.de/mailman/listinfo/u-boot

U-Boot: EFI patches applied, and new bootefi command

Alexander Graf of SuSE has been adding EFI support to U-Boot.  He also just added a new boot loader command, ‘bootefi’, as well:

[PATCH v6 19/30] efi_loader: Add “bootefi” command

In order to execute an EFI application, we need to bridge the gap between U-Boot’s notion of executing images and EFI’s notion of doing the same. The best path forward IMHO here is to stick completely to the way U-Boot deals with payloads. You manually load them using whatever method to RAM and then have a simple boot command to execute them. So in our case, you would do

  # load mmc 0:1 $loadaddr grub.efi
  # bootefi $loadaddr

which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload.

Tom Rini of the U-Boot project also just posted a message saying that the EFI patches have been mostly applied:

EFI loader support largely enabled

What I mean by the subject is that with the EFI loader patches enabled U-Boot itself (not SPL) now includes the EFI loader and required bits on ARM/aarch64.  This is in general I think a good thing.  I’ve however disabled it on a few boards due to size constraints.  This is an average gain of ~12KiB in U-Boot proper.  I fully expect a number of platform patches opting out of this support due to it just not being a real usecase and I am agreeable to talking about making it not enabled by default.  So, lets kick things off.

For more information, see the U-Boot sources or mailing list archives:

http://lists.denx.de/mailman/listinfo/u-boot

Coreboot adds U-Boot as a Payload

Michael Larabel of Phoronix reports that Coreboot now supports U-Boot as another payload option:

Coreboot users have generally relied upon the SeaBIOS or TianoCore payloads for booting up into a Linux distribution, but now a U-Boot payload is supported as another option. Intel-based Chromebooks have long been using U-Boot as a payload for Coreboot while now all of that support is going upstream. A commit today adds U-Boot as a possible payload for x86 systems when configured via the new Kconfig options. The commit by Google’s Martin Roth explains, “Graphics worked in U-Boot correctly by initializing the VBIOS and setting up a console mode. Tested in QEMU and on Minnowboard Max.”

More information:

http://www.phoronix.com/scan.php?page=news_item&px=Coreboot-U-Boot-Payload

http://anzwix.com/a/Coreboot/PayloadsAddUBootAsACorebootpayload

Exploiting D-Link webcams

Vectra Labs has a blog post on how easy it is to attack U-Boot-based D-Link webcams, using simple tools like BusPirate, FlashROM, and BinView. I wonder if the U-Boot in question was using U-Boot Verified Boot or not? At a higher level, this blog seems to be a good example of how insecure the current generation of IoT devices are, and how much (or little) you should rely on such devices.

[…] Conclusion

So does all this mean that D-Link’s web camera has a major security issue? Not necessarily – we get what we pay for, and asking a vendor who sells a webcam on Amazon for $30 to provide safe firmware update features which would require a TPM or a specialized chip to verify the content and signature of a software update is not very realistic. Rather the point of this demonstration is to highlight the real impact that IoT devices pose to the attack surface of a network. As we’ve shown, the barriers to hacking these devices are relatively low, and even the most basic devices can provide the plumbing for a persistent command-and-control channel. While these devices are low-value in terms of hard costs, they still matter to the security of the network, and teams need to keep an eye on them to reveal any signs of malicious behavior.

*Vectra disclosed the issue to D-LInk in early December 2015. As of January 7, 2016, the company has not provided a fix.

Full post:
http://blog.vectranetworks.com/blog/turning-a-webcam-into-a-backdoor

https://threatpost.com/inexpensive-webcam-turned-into-backdoor/115854/
https://www.grahamcluley.com/2016/01/easy-convert-cheap-webcam-network-backdoor/
http://www.techworm.net/2016/01/heres-how-a-cheap-webcam-can-be-converted-into-network-backdoor.html

Bill of Materials for Things

As Dyngnosis says:

“Bill of Materials for embedded devices could/should include a list of included 3rd party libraries. (Think heartbleed on an infusion pump)”

Consumers should know a lot more about the details of what is included in firmware. U-Boot has SPDX metadata.