12 ms·
Replacing exploit-ridden firmware with a Linux kernel [pdf]
- onkdinlsi 9y agoPanthers vs Buccaneers Live Stream Free https://weheartit.com/articles/300359447-watch-online-panthers-vs-buccaneers-2017-live-stream-free-29-oct-metlife-stadium-nfl-game-preview https://weheartit.com/articles/300359447-watch-online-panthe...
- jabl 9y agoNitpick: NERF isn't coreboot, not even "coreboot 2". It's a separate project. Nice project though, and sad that it's needed in the first place. Oh well.
- gghh 9y agoThese 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-ridden-firmware-with-linux-ronald-minnich-google 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/ http://u-root.tk/), which are written in the Go language.
- grx 9y agoBecause the schedule does not provide it, here's the direct link to the talk: https://youtu.be/iffTJ1vPCSo https://youtu.be/iffTJ1vPCSo
- bogomipz 9y ago>"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?
- jacobush 9y agoNon disclosure agreement? Or just asked the UEFI vendor(s)?
- jstanley 9y agoCompare the size of the binary, perhaps?
- 482794793792894 9y agoWhile 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.
- tyingq 9y agoUEFI is just a spec. Intel did release an open source implementation: http://www.tianocore.org http://www.tianocore.org
- josteink 9y agoMy 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 9y ago
- feelin_googley 9y agoVideo of the talk was posted yesterday: https://news.ycombinator.com/item?id=15572978 https://news.ycombinator.com/item?id=15572978
- bringtheaction 9y agodotTK, now there is a TLD I haven't seen in a loong while
- retox 9y agoThe last time I saw them with any regularity they were mostly spam and guild/clan pages.
- JumpCrisscross 9y agoWhat is Apple’s privacy reasoning for accepting UEFI?
- gcb0 9y agoCost.
- hugelgupf 9y agoMods, please change title to replace Coreboot with "Linux kernel". This is not Coreboot and doesn't involve Coreboot at all :)
- dchest 9y agoI watched the talk video and I don't remember it was stated anywhere that Google will replace UEFI/Intel ME. The correct title is "Replace your exploit-ridden firmware with a Linux kernel".
- Dunedan 9y agoEver since I read that Intels UEFI reference implementation has a comparable complexity to the Linux kernel[1] I thought it's absolut nuts to have something with such a complexity just to set up the hardware for another operation system. And that's just UEFI and not even touching ME and other stuff. [1]: https://mjg59.dreamwidth.org/10014.html https://mjg59.dreamwidth.org/10014.html
- ptaipale 9y agoOn the other hand, isn't quite a lot of the code in Linux kernel for the same thing, handling hardware complexity?
- andrewflnr 9y agoEven if it is, that still means you're doing it again.
- frik 9y ago> The problem > ● Linux no longer controls the x86 platform > ● Between Linux and the hardware are at least 2 ½ kernel Please release it for general public, so that everyone has the choice (for Intel+AMD CPUs). > code you don't know about: Kernel -3, Minix 3 Wtf "Minix 3" running invisible behind the scene
- corkraider 9y agoParts of Intel ME are probably derived from Minix 3. http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-an...
- userbinator 9y agoDoesn't Coreboot implement UEFI? I suppose a more accurate title is "replace proprietary UEFI implementation"... nonetheless, the idea of putting a full Linux kernel in the firmware (if I'm reading the article correctly), presumably just to boot another one in the actual OS, despite the openness, sounds like it would increase complexity even more. I think Linus' opinion remains relevant over a decade later: http://yarchive.net/comp/linux/efi.html http://yarchive.net/comp/linux/efi.html https://plus.google.com/+LinusTorvalds/posts/QLe3tSmtSM4 https://plus.google.com/+LinusTorvalds/posts/QLe3tSmtSM4 I'd actually love to see a "replace UEFI with regular BIOS" project ;-)
- jabl 9y ago> Doesn't Coreboot implement UEFI? No. Though I think there is some work to allow people to build a coreboot + upper layers of UEFI (presumably using the open source tianocore UEFI implementation) combination in order to boot operating systems that require UEFI. Just like it's possible to build a coreboot + seabios combination in order to boot OS's that require BIOS services (such as DOS). > nonetheless, the idea of putting a full Linux kernel in the firmware (if I'm reading the article correctly), presumably just to boot another one in the actual OS, despite the openness, sounds like it would increase complexity even more. UEFI is very complex. I.e. it contains a TCP/IP stack (v4 & v6), and whatnot. The Linux IP stack is certainly a lot more battle tested than the UEFI one. And further, the idea is to allow the owner of the hardware to update the boot Linux kernel and not be beholden to the whims of the Intel & the HW manufacturer, who may not have the owners interest as a primary concern.
- josteink 9y ago> UEFI is very complex. I.e. it contains a TCP/IP stack (v4 & v6), and whatnot. For better or worse. Most regular BIOSes contains IPv4 for PXE anyway. UEFI just allows you to do PXE a little more cleanly directly from firmware without needing a disk to bootstrap the process with other stuff like iPXE.
- jabl 9y ago> Most regular BIOSes contains IPv4 for PXE anyway. Indeed. But that's UDP only, not TCP which is a lot more complex. UEFI contains TCP as well (IIRC recent versions of UEFI support boot over HTTP, similar to iPXE). > UEFI just allows you to do PXE a little more cleanly directly from firmware without needing a disk to bootstrap the process with other stuff like iPXE. That's correct. OTOH when your firmware + bootloader stuff requires a TCP/IP stack, HTTP, support for booting from all kinds of software RAID setups, filesystem support in order to be able to find and load the kernel, and whatnot, replacing all of that with a minimal Linux kernel + userspace doesn't sound so crazy anymore.
- mtgx 9y agoSo far AMD has ignored fixing this pretty much because "only privacy nerds" care about it. Well, some of those privacy and security nerds happen to work for companies like Google and even have influence over those companies' hardware purchases. So now AMD has just lost a big chuck of potential Google business, and who knows what kind of other potential contracts, because it continues to ignore this issue instead of actually showing some leadership on it. Maybe it's time for AMD to actually differentiate from Intel on this issue?
- paulmd 9y agoDevil's advocate: if large customers care, AMD can easily give them a "special" microcode image with it disabled. Intel does the same thing with the "High-Assurance Platform" for the intelligence community, which is effectively a ME killswitch. However, these fixes are generally not offered to the public even when they already exist (again, see: Intel HAP). The rules of the game are different when you're one of the Super 7 instead of just some random pleb. And increasingly those guys are no longer interested in leaving this threat vector open, which says something.
- bogomipz 9y ago>" Intel does the same thing with the "High-Assurance Platform" for the intelligence community, which is effectively a ME killswitch." Do you have any links or documentation you could share regarding these exceptions? Thanks.
- GranPC 9y agoHere you go: http://blog.ptsecurity.com/2017/08/disabling-intel-me.html http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
- PuffinBlue 9y agoTo see the Int community have a special mode to disable ME simply confirms that the ME is exploited, if any further proof was needed.
- deleted 9y ago[deleted]
- politelemon 9y agoDoes this indicate us end-users can apply it too to our own gaming PCs for example?
- jabl 9y agoAFAIU at this point it's quite early, and the way they're working on it at the moment is to remove the ROM flash chip (which, depending on the motherboard, may require desoldering the chip) and flash it with a SPI programmer. If you're up to that stuff, I think they'd be happy to have your help. Otherwise maybe you should wait and hope they'll figure out how to flash it from Linux, and make it robust enough that there's a relatively low risk of bricking your system.
- fulafel 9y agoThey confuse exploit with vulnerability. Exploit = ready made program to take advantage of a security hole.
- da_chicken 9y agoYeah, but it's also extremely common to conflate those two. It's not as bad as how everything was somehow a "zero day" for a few years there.
- nialv7 9y agoHow I read the title: replacing a exploit-ridden software, with another exploit-ridden software (but this one is open source)
- azernik 9y agoLinux has undergone a lot more (hostile and friendly) penetration testing and bug-fixing than UEFI.
- ryanlol 9y agoLinux is still certainly more "bug-ridden" than UEFI, because of size alone.
- azernik 9y agoFrom the abstract: > UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel... And this kernel build is a trimmed-down one, removing functionality that isn't necessary to initialize the hardware and boot the full kernel.
- hawski 9y agoThe other one is also open source (maybe a bit less). However Linux should be a bit less exploit-ridden
- nialv7 9y agoSo there is the Intel reference implementation. But vendors are free to make changes, and their versions are not open source.
- deleted 9y ago[deleted]
- ksec 9y agoThe question is, Why Linux? You already have Linux for OS, why the same on firmware? Why not Minix? ( Used in Intel Me Already ) Why not OpenBSD? ( Very Secure ) Why not NetBSD? ( Extremely Portable ) Why not FreeBSD? Why not Coreboot? Why not the OpenSource UEFI implmentation? Why not switch back to simple and easy BIOS?
- wmf 9y agoIt sounds like the whole point of this project is to not have two separate OSes. Linux+Linux is much simpler than Linux+Minix or whatever.
- eeZah7Ux 9y agoIf you are going to use a Linux kernel (on layer 0) anyways it reduces the attack surface by half!
- jabl 9y ago> Why Linux? You already have Linux for OS, why the same on firmware? The Linux they're flashing to the firmware ROM is a custom minimal build. Using that, they can then boot a standard distro kernel. And depending on your threat model, you might not need to update the firmware kernel as often as the distro kernel, as it's only used for booting. Note that this is for servers; for an embedded system you might as well boot directly to the final kernel. > Why not Minix? ( Used in Intel Me Already ) Why not OpenBSD? ( Very Secure ) Why not NetBSD? ( Extremely Portable ) Why not FreeBSD? A few guesses: - Linux is the one most familiar to the developers of this. And to the Google sysadmins, presumably. - Compatibility: If the distro kernel resides on, say, an XFS filesystem on an MD-RAID device, the firmware boot kernel needs drivers for that. - It uses kexec which is a quick and easy way to boot a Linux kernel from another Linux kernel. If you want to boot from another OS you'd have to figure out something else. > Why not Coreboot? Coreboot is preferable, but since the low-level firmware on modern x86 server platforms is tightly controlled with hardware signing keys, no data sheets released etc., coreboot hasn't been able to run on an Intel x86 server platform for the past decade. This project (NERF) is a pragmatic compromise, by replacing only the upper parts of the firmware stack and removing/disabling the ME as much as possible. > Why not the OpenSource UEFI implmentation? It's designed-by-committee crap which is far less battle tested than Linux. > Why not switch back to simple and easy BIOS? It's less evil than UEFI sure, but I guess it's unfortunately only a question of time until it's removed from PC firmwares (Apple already did it many years ago, AFAIU). Besides, AFAIK switching to BIOS mode does nothing to disable the ME. And if you're going to do something from scratch, you might as well use something sane like coreboot.
- madez 9y agoWhat are the reasons the hardware the microcode is running on isn't directly exposed to the user? Why shouldn't we teach our compilers to generate code for the lowest level possible?
- wmf 9y agoBackwards compatibility is a big reason. If the OS handles everything then you can only use an OS that has the latest drivers. Driver bugs could also brick your hardware in some cases.
- dfox 9y agoThere is actually an significant technical issue with user-supplied microcode on modern fast CPUs: the control store is not fully writable and only small parts of it can be patched in the field. Reason for that is that the control store is probably the fastest block of memory in modern PC as it has to have latency on the same order as CPU clock period and usually has very wide data bus. Implementing this as entirely writable RAM would be uneconomical.
- vinkelhake 9y ago64x
- deleted 9y ago[deleted]
- forapurpose 9y agoSlide 3 refers to "ISH" and "IE" among "X86 CPU(s) you don’t know about". What are they referring to?
- wmf 9y agoISH: Integrated Sensor Hub IE: Innovation Engine There's also the PCU Package/Power Control Unit that no one talks about.
- sscarduzio 9y agoFrom the presentation, looks like that - as of today - a ChromeBook are way more secure than a MacBook. Is that right?
- wmf 9y agoI don't think much is publicly known about Apple's UEFI implementation; what if it's already stripped down?
- listic 9y agoCompiling on demand is cool, but why is it needed?
- hawski 9y agoIf I understand correctly to make it more auditable. Still: tool-chain remains prebuilt and trusting trust issues. More auditable is better than less auditable.
- listic 9y agoWhy is compiling on demand more auditable than just having open source BIOS?
- hawski 9y agoUEFI is open source to some extent. There is an Intel project [1] that every company's UEFI is based upon. Even having fully open source BIOS is not enough by itself. The binary that is on your system can be anything. You can somewhat trust it if you can verify it, only if the project would use reproducible builds. But the hardware can still lie to you. What I also have in mind is the trusting trust issues [2]. [1] https://github.com/tianocore/edk2 https://github.com/tianocore/edk2 [2] http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack
- btbuilder 9y agoI find the use of Go for the userland pretty cool. It makes sense in this case considering if you disable cgo the only external dependency you have is the Linux syscall table. I've implemented a number of system tools in Go and it is pretty well suited to this sort of job IMHO. One particular case that I've struggled with however, is when I've needed to modify some characteristic of my running thread using an OS mechanism. For instance, say I have a number of go-routines running and then I want to make sure a filesystem is unmounted from all mount namespaces the kernel has. My only pure-Go option right now, is to execute another go program (or re-execute the same program with some arguments) that will enter the namespace via syscall, do the work in that namespace and then quit. If you have a bunch of namespaces this seems wasteful. This is because you don't have complete control over what Go does with the OS-thread you are working in. Yes, you can lock your go-routine to a particular OS thread but you can't stop Go from using that somewhat special and potentially more privileged thread, to create other OS threads to service go-routines. Thereby potentially sprinkling your go-routines with different capabilities and/or namespaces. I ended up using cgo, which was a shame. Perhaps someone knows some neat trick to work around this?
- zyga 9y agoHey there. In snapd (which is implemented in mostly go) we have this problem a lot. The real issue is that certain system calls fail if more than one thread exists in the calling process. One of those is setns(2), as is documented in the manual page. What I ended up doing is to use a small C preamble that parses command line arguments, figures out where to go and uses setns before the go code even begins initializing. This solved the particular case we were working on but in my opinion golang's opinionated approach to threading is not suitable for writing many system tools in it. My wishlist item for golang 2.x is a build mode where threading is 100% under developer control but this seems to be at odds with the design for non-blocking IO.
- btbuilder 9y agoInteresting. I don't have access to the code I was talking about anymore, but I'm pretty sure that I did have different threads in different mount namespaces. Looking at the man-page briefly it looks like the restriction you are talking about applies only to user namespaces. Interesting to know that there are even more situations to be considered.
- suihkulokki 9y agoPower9 servers appear already do this. They have minimal firmware to load the on-rom linux, which then uses userland application (petitboot) to figure out which installer media or already installed linux system you want to kexec() into: https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petitboot/ https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petit... This seems logical, if you are going to run linux, why reimplment all the drivers in UEFI.
- slim 9y agoIs'n't GRUB supposed to play that role? Why a full kernel?
- bwindels 9y agoI think grub would usually be called after the boot firmware (like UEFI, or coreboot, or a traditional BIOS) has already initialized the hardware. Some of these systems can also directly load your operating system, and I would guess the one of the few thing missing from the boot firmware would be the filesystem support, and not much more
- reacweb 9y agoSo many layers with a single goal: preventing the user from owning the hardware.