U-Root: firmware solution written in Go

From 2015, something I missed because I didn’t know Go then. ;-(

U-root: A Go-based, Firmware Embeddable Root File System with On-demand Compilation
Ronald G. Minnich, Google; Andrey Mirtchovski, Cisco

U-root is an embeddable root file system intended to be placed in a FLASH device as part of the firmware image, along with a Linux kernel. The program source code is installed in the root file system contained in the firmware FLASH part and compiled on demand. All the u-root utilities, roughly corresponding to standard Unix utilities, are written in Go, a modern, type-safe language with garbage collection and language-level support for concurrency and inter-process communication. Unlike most embedded root file systems, which consist largely of binaries, U-root has only five: an init program and 4 Go compiler binaries. When a program is first run, it and any not-yet-built packages it uses are compiled to a RAM-based file system. The first invocation of a program takes a fraction of a second, as it is compiled. Packages are only compiled once, so the slowest build is always the first one, on boot, which takes about 3 seconds. Subsequent invocations are very fast, usually a millisecond or so. U-root blurs the line between script-based distros such as Perl Linux and binary-based distros such as BusyBox; it has the flexibility of Perl Linux and the performance of BusyBox. Scripts and builtins are written in Go, not a shell scripting language. U-root is a new way to package and distribute file systems for embedded systems, and the use of Go promises a dramatic improvement in their security.

Video and audio on first URL.






I missed this blog post from SuSE from last year:

[…]One UEFI topic that I noticeably did not address in this blog is secure boot. This was actually covered extensively in three previous blogs. To read those blogs do a search for “Secure Boot” at suse.com. I also did not address the comparison of UEFI and BIOS from the operating systems perspective in this blog. That is a separate blog that was released at the same time as this one (Comparison of UEFI and BIOS – from an operating system perspective). Please read it too. Hopefully this gives you some helpful information about the transition from BIOS to UEFI, on the hardware side. You can find more information about SUSE YES Certification at https://www.suse.com/partners/ihv/yes/ or search for YES CERTIFIED hardware at https://www.suse.com/yessearch/. You can also review previous YES Certification blogs at YES Certification blog post[…]



UEFI-D: D language bindings for UEFI

D bindings for UEFI specifications, based on the headers from EDK II 2015. They allow to compile fully functional EFI executables without assembly or C bootstrapping, it boots directly to D 🙂 They can be used to build UEFI-compatible applications and drivers in the D Programming Language. Sample “Hello, world” program is provided, with source and a linux script to compile[…]







Intel MPX Explained


Intel MPX Explained: An Empirical Study of Intel MPX and Software-based Bounds Checking Approaches

Oleksii Oleksenko, Dmitrii Kuvaiskii, Pramod Bhatotia, Pascal Felber, Christof Fetzer

(Submitted on 2 Feb 2017)

    Memory-safety violations are a prevalent cause of both reliability and security vulnerabilities in systems software written in unsafe languages like C/C++. Unfortunately, all the existing software-based solutions to this problem exhibit high performance overheads preventing them from wide adoption in production runs. To address this issue, Intel recently released a new ISA extension – Memory Protection Extensions (Intel MPX), a hardware-assisted full-stack solution to protect against memory safety violations. In this work, we perform an exhaustive study of the Intel MPX architecture to understand its advantages and caveats. We base our study along three dimensions: (a) performance overheads, (b) security guarantees, and (c) usability issues. To put our results in perspective, we compare Intel MPX with three prominent software-based approaches: (1) trip-wire – AddressSanitizer, (2) object-based – SAFECode, and (3) pointer-based – SoftBound. Our main conclusion is that Intel MPX is a promising technique that is not yet practical for widespread adoption. Intel MPX’s performance overheads are still high (roughly 50% on average), and the supporting infrastructure has bugs which may cause compilation or runtime errors. Moreover, we showcase the design limitations of Intel MPX: it cannot detect temporal errors, may have false positives and false negatives in multithreaded code, and its restrictions on memory layout require substantial code changes for some programs.


See also:



tg165-tools: FLIR TG165 thermal camera firmware hacking tools

TG165 Tools: This repostiory contains tools for extending the functionality of the low-end FLIR TG165 thermal camera. With these tools, you can add alternate functionality to your TG165 without having to replace its original firmware.
* A simple utility (fwutil.py) and python module (tg165) that can pack and unpack FLIR Upgrade.bin firmware images.
* A simple utility (compose-fw.py) that can be used to build firmware-upgrade files that contain multiple programs.
* A simple assembly bootstrap (boot_select) that allows you to select between multiple programs on device startup.
* A DFU “alternate-bootloader” (alt_bootloader) that allows you to upload custom programs via USB without distruping the main one. This should enable rapid development!
* An (example) firmware payload that allows you to dump the TG165’s FLIR-provided bootloader.



Verified Boot

Marc Kleine-Budde of Pengutronix gives a talk at the Embedded Linux Conference Europe (ELCE), on using Verified Boot.