Uncategorized

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.

https://www.usenix.org/conference/atc15/technical-session/presentation/minnich

https://github.com/u-root/u-root

http://u-root.tk/

Standard
Uncategorized

Android Things

Supported hardware: Intel® Edison, Intel® Joule, NXP Pico i.MX6UL, Raspberry Pi

https://github.com/androidthings
https://developer.android.com/things/hardware/index.html
https://developer.android.com/things/index.html
https://developer.android.com/things/preview/index.html
https://developer.android.com/things/hardware/developer-kits.html
https://android-developers.googleblog.com/2017/02/android-things-developer-preview-2.html

 

 

Standard
Uncategorized

Google on fuzzing PCIe

Fuzzing PCI express: security in plaintext
By Julia Hansbrough, Software Engineer

Google recently launched GPUs on Google Cloud Platform (GCP), which will allow customers to leverage this hardware for highly parallel workloads. These GPUs are connected to our cloud machines via a variety of PCIe switches, and that required us to have a deep understanding of PCIe security. Securing PCIe devices requires overcoming some inherent challenges. For instance, GPUs have become far more complex in the past few decades, opening up new avenues for attack. Since GPUs are designed to directly access system memory, and since hardware has historically been considered trusted, it’s difficult to ensure all the settings to keep it contained are set accurately, and difficult to ensure whether such settings even work. And since GPU manufacturers don’t make the source code or binaries available for the GPU’s main processes, we can’t examine those to gain more confidence. You can read more about the challenges presented by the PCI and PCIe specs here. With the risk of malicious behavior from compromised PCIe devices, Google needed to have a plan for combating these types of attacks, especially in a world of cloud services and publicly available virtual machines. Our approach has been to focus on mitigation: ensuring that compromised PCIe devices can’t jeopardize the security of the rest of the computer. Fuzzing to the rescue[…]

https://cloudplatform.googleblog.com/2017/02/fuzzing-PCI-Express-security-in-plaintext.html

Standard
Uncategorized

Matthew Garrett leaves CoreOS, joins Google

Matthew Garrett is leaving CoreOS and has gone to Google!

https://coreos.com/blog/working-on-container-linux.html

 

Standard
Uncategorized

Google documents internals firmware usage

Worth reading:

[…]
Secure Boot Stack and Machine Identity

Google server machines use a variety of technologies to ensure that they are booting the correct software stack. We use cryptographic signatures over low-level components like the BIOS, bootloader, kernel, and base operating system image. These signatures can be validated during each boot or update. The components are all Google-controlled, built, and hardened. With each new generation of hardware we strive to continually improve security: for example, depending on the generation of server design, we root the trust of the boot chain in either a lockable firmware chip, a microcontroller running Google-written security code, or the above mentioned Google-designed security chip. Each server machine in the data center has its own specific identity that can be tied to the hardware root of trust and the software with which the machine booted. This identity is used to authenticate API calls to and from low-level management services on the machine. Google has authored automated systems to ensure servers run up-to-date versions of their software stacks (including security patches), to detect and diagnose hardware and software problems, and to remove machines from service if necessary.
[…]

https://cloud.google.com/security/security-design/

http://www.theregister.co.uk/2017/01/16/google_reveals_its_servers_all_contain_custom_security_silicon/

 

Standard
Uncategorized

IBM on attacking Android Custom Boot Modes

IBM’s SecurityIntelligence has a story on attacking Android’s Custom Boot Modes.

Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes
By Roee Hay
Co-authored by Michael Goberman.

In recent months, the X-Force Application Security Research Team has discovered several previously undisclosed Android vulnerabilities. The November 2016 and January 2017 Android Security Bulletins included patches to one high-severity vulnerability, CVE-2016-8467, in Nexus 6 and 6P. Our new paper, “Attacking Nexus 6 & 6P Custom Bootmodes,” discusses this vulnerability as well as CVE-2016-6678.[…]

https://securityintelligence.com/android-vulnerabilities-attacking-nexus-6-and-6p-custom-boot-modes/

Standard