Linked by Thom Holwerda on Sun 29th Oct 2017 17:44 UTC
Google

Two weeks ago, security researchers managed to disable the Intel Management Engine, and last week, Google held a talk at the Open Source Summit (née LinuxCon) in which they unveiled their plans to completely (well, almost completely) replace every bit of code between the operating system you know about (Windows, Linux, BSD, whatever) and the bare metal x86 processor (Intel-only, for now).

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a "Ring -2 hypervisor"). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs.

Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

Both the slides from the talk and the video are available.

Thread beginning with comment 650435
To view parent comment, click here.
To read all comments associated with this story, please click here.
jing
Member since:
2017-08-19

Don't know for MacOS and Windows but those can be virtualized via kvm or xen :-)
for the rest of the list I think so, they should boot.

https://en.wikipedia.org/wiki/Multiboot_Specification

anyway...someone did implement a kexec syscall in a freebsd derivative... and used it to boot linux...
https://github.com/fail0verflow/ps4-kexec

https://www.youtube.com/watch?v=2A7V3GLWF6U

Reply Parent Score: 1

Brendan Member since:
2005-11-16

Hi,

Don't know for MacOS and Windows but those can be virtualized via kvm or xen :-)


Awesome - destroy the capabilities the firmware needed to work properly in an attempt to reduce the attack surface; and then increase the attack surface by multiple orders of magnitude more than it ever was to work around the fact that you've destroyed all the capabilities the firmware needs to work properly!


for the rest of the list I think so, they should boot.

https://en.wikipedia.org/wiki/Multiboot_Specification


The only OS (that I know of) that uses Multiboot was Solaris.

Linux (and its "kexec()") have never officially used or supported Multiboot. Note: if I remember correctly, once upon a time there was a patch written by GRUB developers to add Multiboot support to Linux that was rejected by Linux developers and then died.

anyway...someone did implement a kexec syscall in a freebsd derivative... and used it to boot linux...
https://github.com/fail0verflow/ps4-kexec


Sounds great until Linux updates/improves/changes "kexec()" (or more correctly, the Linux Boot Protocol) and both new versions of Linux and that one "FreeBSD derivative" no longer boot (preventing you from running the firmware update tool/s needed to fix/update the firmware).

Note: The original "kexec()" on Linux was exploitable (allowed unsigned kernels to be booted, so a hacker could use a signed Linux kernel followed by "kexec()" to bypass UEFI Secure Boot); and this was eventually fixed. The patch you linked to has the same exploit without the fix.

- Brendan

Reply Parent Score: 3