[gghh]

These slides are from the talk given at the Open Source Summit (formerly known as LinuxCon) last week in Prague. The abstract given at the talk page https://osseu17.sched.com/event/ByYt/replace-your-exploit-ri... is

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.

[grx]

Because the schedule does not provide it, here's the direct link to the talk: https://youtu.be/iffTJ1vPCSo

[bogomipz]

>"UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel"

Does anyone know how they were able to compare the size of the codebase given that UEFI is proprietary/closed-source?

[tyingq]

UEFI is just a spec. Intel did release an open source implementation: http://www.tianocore.org

[josteink]

My understanding is that most of the UEFI implementations out in the wild is based on this one, since the spec is pretty big and definitely not something a random mobo vendor would like to implement.

[microcolonel]

Most UEFI in the wild is based on Tianocore/EDK-II, which has about 1.5 million SLOC, plus about 400,000 source lines in header files. Some subset of this would actually be running on the device, but this doesn't include the drivers and the very base of the firmware. Let's say maybe two million SLOC is running on a typical UEFI firmware blob.

Linux also lacks the most basic level of the firmware (which is most likely handled Coreboot? I'm not fully clear on what NERF is overall). A much smaller proportion of Linux codebase would be running on a given device, as compared to the EDK-II, though. Who knows. /kernel and /arch/x86 together make about 440k SLOC.

Funnily enough, this is actually the second time a "Linux BIOS" has been tried. The first time was called LinuxBIOS (later renamed to Coreboot), and the idea was quite literally to put a kernel on ROM and have as little firmware as possible to get to a booted system.

[jacobush]

Non disclosure agreement? Or just asked the UEFI vendor(s)?

[jstanley]

Compare the size of the binary, perhaps?

[482794793792894]

While that would also be a somewhat useful measure in this context, there's very little correlation between the size of the codebase and the size of the binary.

Programming languages and styles can vary in verbosity a lot. For example, if UEFI is written in some form of assembler code, then you quickly get a lot of lines of code while the binary doesn't grow particularly. On the other hand, high-level programming languages like Java, or even moreso functional and logic programming languages like Haskell and Prolog respectively, can generate huge binaries out of even just a few lines of code.

[JumpCrisscross]

What is Apple’s privacy reasoning for accepting UEFI?

[gcb0]

Cost.

[bringtheaction]

dotTK, now there is a TLD I haven't seen in a loong while

[retox]

The last time I saw them with any regularity they were mostly spam and guild/clan pages.

[feelin_googley]

Video of the talk was posted yesterday: https://news.ycombinator.com/item?id=15572978