That was exactly my motivation: there are tons of guides for setting up UEFI SecureBoot platform keys, yubikey tokens, TPM disk encryption, dmverity, etc, but all of them seemed to involve "type hundreds of commands with no mistakes and hope that your system still boots afterwards". It felt to me that each program represented a low-level library function that needed to be linked into a high-level tool to handle the common cases for most users.
Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.
One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.
If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.
There's a way to encrypt the boot partition and have GRUB ask you for the boot partition key, but you're limited to LUKS1, and the decryption process is slow as molasses, since it's implemented inefficiency directly in the GRUB code, because the Kernel's faster code isn't loaded yet. It's also probably full of side channel leaks. Signing the kernel and ramdisk is probably the better option...
It's pretty typical boot time for most UEFI server platforms with network cards and RAID controllers. The Dell R630 takes about six minutes, the HP DL3x0 is about eight and the Lenovo x3550 takes over ten. Of the ones I've tested only the Intel s2600wf is under two minutes in a stock configuration, but with LinuxBoot it is less than twenty seconds to a Unix shell despite the PEI and DXE serial debugging messages: https://www.youtube.com/watch?v=0HISDFXZvSI
The threat model that LinuxBoot is addressing is different form SecureBoot and it can use the well known, normal Linux tools rather than the unconventional UEFI ones.
The Heads runtime can do things like use TPMTOTP to attest to the user that the firmware is unaltered and includes gnupg to verify the kernel and root filesystem signatures with the user's own key.
For cloud systems a LinuxBoot runtime can use the TPM or other trusted hardware to remotely attest to the client's own provisioning server that the configuration is unchanged, and since it is reproducibly built, that the firmware is what the user expects. This is significantly more trustworthy than the binary blobs and non-reproducible UEFI firmware on most servers.
The LinuxBoot kernel establishes a hardware root of trust with the TPM and measures the ROM before bringing up any IO devices, so when it connects to the network it is able to perform a remote attestation as to its state. This way the hosting provider or customer can decide to not provision a node that has somehow been modified by a prior tenant.
For a network booting scenario the LinuxBoot server can use GPG to validate the signature on the kernel that it receives over the network. Additionally, secrets can be sealed in the TPM and only unlocked if the received kernel matches the expected one (and if the local firmware is unmodified).
You're probably getting downvoted because you did not follow up with "...because $reasons", so your post comes off as petty Linux hate (is there such word as "anti-fanboyism"?).
In the context, most other posts here contain no technical detail whatsoever either and are nothing more than unsubstantiated opinions (same as mine); they just really dislike that there is someone out there who doesn’t think that Linux is phenomenal. In the days of Microsoft dominance, we called that monoculture.
Volumes have been written and videos filmed on all the inadequacies of the GNU/Linux kernel, far more than I could cram into one “Hacker News” post. I for example get a painful reminder of just how unfit the Linux kernel is as firmware every time I turn on my television set which runs it (ARM V7 Linux for the curious). After that, I don’t want any more. That is not an isolated scenario.
Because people have been doing it since the 90s. Google use this on their Chromebook. Some of the people working on Coreboot, Heads, NERF have been doing it for a long time and they all seem to agree with each other.
Also, please tell me why the Linux kernel is so bad, but the BSDs are not? They are not that different and its hard to argue that they are much saver in terms of bugs (just look at the BSD talk at 34C3).
How long "people have been doing it" has nothing to do with the quality, it's a fallacy. They can't code if they can't even get the basics like polling or startup / shutdown correctly.
While both might be true, it does not change the fact that Linux is not a good choice for firmware because the product is simply bad. And asking for links (I did originally write videos and I meant those exact ones) and then complaining about having to watch through them is exactly what’s wrong with our industry. That kind of mentality spills over into code quality or lack thereof. It is high time to start owning up to it and change course.
You also mentioned volumes that have been written. And those would be greatly preferable to podcast or videos, which are some of the worst forms of information sharing, with low density, inability to process it at one's own pace and several other reasons.
Unless you want to discuss something visual where showing things on camera helps greatly with delivering the subject matter, you're much better off writing an article or two. But if the video is mostly about looking at people's faces as they talk and flashy intro animations, then you're just wasting people's time and attention. Again, why not just write an article and include photos of people involved?
Have you ever wondered why you’re always so angry? I looked at your comment history and your bio... sheesh man, please seek out a mental health professional. It’s not normal. I’m gonna take a wild guess that you have had lower back pain for years too. Not trying to be a prick, just a wake up.
Had you had grown up on something so cool and elegant as a Commodore Amiga or an sgi Origin 3800 and IRIX and now you find yourself stuck on a PC bucket server forced by someone else to run Linux, by knowitalls who’ve never known anything else, you’d be pissed off too. People tend to become resentful when they have to regress to something worse and it was not their choice.
So Linux (there is no GNU/Linux kernel, but a GNU/Linux OS) is more popular than how much you'd like it to be, and is that the problem? I for one am glad GPL-licenced free software is running on as much platforms as possible. In those cases Linux is basically a library they pick for their work. You can well say the same thing for glibc, gcc, apache, nginx etc. But in the end-user space nobody is forcing you to use Linux, and that's what monoculture is, not the choices regarding firmware with which the end user is not meant to ever interact.
So Linux (there is no GNU/Linux kernel, but a GNU/Linux OS) is more popular than how much you'd like it to be, and is that the problem?
That's a huge problem for me, because I get stuck dealing with problems solved in traditional UNIX operating systems anywhere from 30 to 20 years ago. It's extremely depressing to have to regress. If the future is Linux, then I want no part of such future.
But in the end-user space nobody is forcing you to use Linux
No? Then why do most companies today force me to work on Linux by insisting on running it? Why am I told in interviews "nah, they don't want to try ZFS or SmartOS... they're Linux people".
The delivery medium is irrelevant. And yes, this particular video is a good source, since the person in the video is an authority on kernel engineering; his teams have managed to deliver a fully functional storage appliance, a volume manager/filesystem from the future, infinitely extensible kernel and userspace debuggers, a dynamic tracing framework, a very high performance operating system which for more than two decades was the textbook on large scale symmetric multiprocessing, and a large scale cloud solution which mops the competition in efficiency and design of use. Oh, and a parallel startup/shutdown mechanism as part of a larger self-healing framework. I have a sneaking suspicion that this person might know what he’s talking about after having written and debugged a good portion of that code. I’m not putting in Linux as firmware because I already have it in the products and infrastructure I use and not only is it piss poor slow and inefficient and crashes all of the time, but greenhorns who think they know best keep introducing compatibility-breaking changes. Out of the question, no more. And polishing a piss poor solution is no solution either. Start with a solid foundation, which excludes Linux immediately from the consideration.
Oh, the delivery medium and medium are relevant. Not to you, that much is clear. But we've already established your viewpoint is an outlier. The person you're referring to is Bryan Cantrill [1]. For each expert like him, there are also Linux kernel experts, so I am not buying that one [2], sorry. He's been able to rant successfully in text, as you can read on the Wikipedia page. No idea why we'd have to see extremely long videos of him. I'm sure a shorter, to the point argument can be made by him. So if Cantrill (& friends) could sum it up in 10 min read in a 2018 sauce, that'd be great.
Literally nobody cares that you don't wanna do that with Linux. That's like your problem. The world needs practical solutions; not *NIX wars or zealotry.
There are practical solutions: FreeBSD, OpenBSD, SmartOS. Linux for firmware is not one of those, but if you think it is, good luck with using it for that. Don't bother to let me know how it worked out for you.
tl;dr: Xeno Kovah, Corey Kallenberg and I ported several previously disclosed vulnerabilities from Windows UEFI systems to Apple's EFI firmware. Using the 2014 Darth Venamis ("Dark Jedi") vulnerability we were able to unlock the motherboard boot flash, write our proof of concept to it, then scan the bus for PCIe Option ROMs and copy the worm to them as well. This allowed it to spread to other systems via shared Thunderbolt devices, possibly across air-gap security perimeters or via evil-maid attacks.
Like the original Thunderstrike vulnerability presented at CCC last year[0], firmware passwords and FileVault encryption don't prevent infection, reinstalling OSX won't remove it and it changes the RSA keys in the ROM so that Apple's firmware update routines can't remove it either. The only way to remove it is with a hardware in-system programming device connected to the SPI flash chip.
This is a transcript of our hour long presentation at DefCon 23 / Blackhat 2015 last week, which is why it is too long to read... Here is a shorter overview[1] and a demo video[2].
What about firmware updates? The usual way that Apple distributes Thunderbolt Display updates is using the OSX update mechanism. That has to be able to write to the firmware somehow.
Potentially, yes. However, if you want to have the ability to write firmware, etc, you're going to want some way of toggling that pin, leaving us right back where we started.
You connect that pin to a small switch in a not-so-easily-accessible place and tell the user to connect it whenever firmware updating is required. Something as simple as pushing a paperclip into a hole would be sufficient.
Firmware updates should not be "transparent", "seamless", "one click", or whatever other terms are used today to describe silent or little-noticed changes. They are modifying a very important part of the system, and the user has to be aware of that.
Being in control of so much of your hardware of course some hardwired logic could be included e.g. in the keyboard matrix that would make some physical interaction necessary during firmware upgrades, but not require a hidden button.
Nevertheless, as long as such a button or switch is easily accessible, and not able to be covered by a seal, the system stays vulnerable to evil maids. And such a thing definitely wouldn't be the Apple Way™
No, the vulnerability is in the firmware doing nothing to ensure that the code it's executing is unmodified. This part of the attack isn't possible on systems that have UEFI Secure Boot enabled - once the option ROM is modified, the firmware will simply refuse to execute it.
Does Apple's firmware support Secure Boot? I've always heard of it in connection with Windows 8+. If they support it, is it enabled by default? If either answer is "no", it seems like the Option ROM vuln is pretty severe for Macs.
question for you - Secure Boot basically screws up the ability to boot Linux OSes. From this article, it seems Secure Boot is a good thing.
How do you see this working out in the longer term - is there a Secure Boot alternative that allows freedom to boot Linux, yet protects against vulnerabilities like these ?
SecureBoot implementations often let a user, via some means, add additional keys that they trust.
Any user can simply create their own key, sign their own firmware, linux, and what have you with it, and then boot away.
Unfortunately, Microsoft mandates secure boot but doesn't require the feature of adding keys to be present... so the reality is a bit more grim.
The reality is that most distros have managed to get a signing key from microsoft (and those that haven't, there's a grub shim signed by such a key) that is included by default in microsoft certified secureboots. This has been working, but is not as ideal.
> Secure Boot basically screws up the ability to boot Linux OSes
Not really. The barrier to obtaining a signed bootloader isn't that large, and if you're unwilling or unable to do that you can use http://mjg59.dreamwidth.org/20303.html and just oblige your users to jump through an additional (easily documented) hoop. We had legitimate concerns over the impact of Secure Boot on free operating systems, and for the most part we were able to reach some reasonable solutions.
The problem is that most models on thingiverse produce designs that are very, very difficult to fold up. Even low-poly things (like the Stanford Bunny) are almost impossible.
Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.
One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.
If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.