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~A(c)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.
I think the larger problem is, how do you verify that the firmware code is actually compiled from that particular source? If you cannot load your own firmware (I know, a pipe dream) how is this different than the current situation? Not just that, if a vulnerability in the current code is found, can you actually update it yourself?
I used to have a Samsung Galaxy Nexus, and know all too well what happens when support is arbitrarily dropped. I would probably still have that phone were I able to load the latest version of Android. But since TI dropped support for the OMAP SoC, I could not upgrade beyond 3.4.
Hi,
The other problem is that if you want to do something else (e.g. boot Haiku from USB, boot MS-DOS from CD-ROM, boot FreeBSD from hard drive, etc) you’re screwed because they stripped out all of the “non essential” functionality, and if you want to change your hardware (e.g. upgrade the video card) you’re also screwed because that’d require a little extensibility.
Mostly it sounds like they’re using “open source” as yet another form of vendor lock-in; to make sure the computer will only ever be able to run one specific OS and nothing else (e.g. maybe a special Linux distro created by Google, for Google’s benefit and not yours).
– Brendan
Trammel is involved with the NERF project
and the project probably use HEADS firmware as a payload:
https://media.ccc.de/v/33c3-8314-bootstraping_a_slightly_more_secure…
HEADS firmware (Linux) can boot any os via kexec
min 39:00s to min 40:30s
Hi,
So you can use kexec to boot Windows, and OS X, and Haiku, and MS-DOS, and FreeBSD, and Solaris, and …?
– Brendan
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
Hi,
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
That is the exact reason why Google has the new project treble. If the bulk of the software can be updated without the hardware drivers needing to change devices can stay useful longer.
But thats oreo and beyond so maybe the nexus 5x will be a long lived device? One can dream anyways.
and the hardware driver security holes (intentional or not) will remain there for longer.
Since there’s no firmware upgrade after a while, the holes will remains anyway. Without the system upgrade either in the old case.
coreboot, libreboot, openbios…
there are alternatives already… auditable alternatives….
And none of those seem to address the Intel IME/AMD PSP security coprocessor issue. This one at least plans to, though how successful it can be I don’t know.
Edited 2017-10-29 22:01 UTC
Why wouldn’t you just put that into one of the existing (shipping) solutions, like Coreboot?
Why wouldn’t one put effort into improving an existing OS instead of worrying about that minor hobby one? Cos they can?
Also there seems to be a hardware purist streak amongst some of the existing projects and they might not be accepting of code handling the PSP/IME for political reasons.
The purism Librem laptops also disable the IME, and they use Coreboot, if I recall, so it’s not just a Google thing, for sure.
I’m partial to the Open Firmware (of which openbios, which you mention, seems to be an implementation) – used in many ~alternative systems (like Pegasos for MorphOS) or in the One Laptop Per Child XO-1 …not chosen over UEFI seemingly because it just wasn’t done by Intel.
And written in Forth… (one day I’ll learn it, I promise
)
Edited 2017-11-01 00:06 UTC
I might be confusing it with something else, but isn’t it possible to disable UEFI in the CMOS setup?
You’re thinking of Secure Boot. UEFI is what’s used these days instead of BIOS.
(The UEFI is responsible for things like initializing your RAM and bringing your motherboard into a state where an OS can recognize it. “The CMOS setup” just configures a very small portion of it.)
Edited 2017-10-31 10:05 UTC
Not to mention you don’t really disable it, it’s more like BIOS emulation mode.
Replacing one buggy nightmare with another…