More information on Linux and the UEFI secure boot feature. | Hacker News Reader

More information on Linux and the UEFI secure boot feature.

mjg59.dreamwidth.org

50 pointsthristian17 comments

Don't miss this in the footnotes:

Hilariously, Microsoft's signing tool gets this wrong by also adding the contents of gaps between sections in direct contravention of their own specification. This is fine for binaries generated by Microsoft's toolchain because they don't have any gaps, but since our binaries do contain gaps[2] and since the standard firmware implementation[3] does implement the specification correctly, any Linux-generated binaries signed with the Microsoft tool fail validation. Go team. [2] Something that is, as far as we can tell, permitted by the PE-COFF specification [3] Written by Intel, not Microsoft

I'm trying to figure out the order of operations here for a custom kernel. I have no doubt vendor supported Linux (Redhat, Ubuntu, etc...) will be able to work around this. But what will the steps be for a custom kernel? It seems to be something like this:

    1) Build kernel
    2) Generate key
    3) Sign kernel with key
    4) Install key in UEFI key manager

But the question I have is, what do we do with the key now? Is it kept on disk? If so, does that open up a new vector for attack? A Linux virus/worm that finds the signing key, generates a new hacked kernel, signs it, and then installs itself?

I know that's a lot of steps, but then again, if a malevolent program gains root on a box, you can't really trust anything on it anymore. So I guess there isn't really anything too different about this approach, except that it may give you a false sense of security.

I'd hope that there could be some warning about booting a new kernel. Maybe something like "You are booting a new operating system 'OSName v3.1.021b' with fingerprint: AB AD C0 DE AA ..., do you wish to continue? Yes / No / Always: _ "

If I compile the kernel from source, I'd hope to have the choice to disable Secure Boot. (But I'll probably get a hand-me-down sony laptop and that won't be a choice.)

Hopefully, the spec will require that I can install a new key. If I'm going to the effort to generate a public/private keypair, I should really save the private key on, oh, a removable drive. Then on a separate removable drive (Matthew Garrett's suggestion) I create the UEFI bootable kernel and add the public key.

1. The BIOS asks me if I want to install the new public key on the removable drive - I say yes

2. I tell the BIOS to boot from the kernel on the removable drive

3. I install the kernel and OS to the internal drive

4. Each time I reboot, the BIOS already has the new key saved, so it accepts the kernel

5. If I build a new kernel and sign it with the same key, I can install it on the internal drive or on a removable drive, and the BIOS will boot it

I'm worried because I run Debian on my laptop and I'm not certain that I'll be able to just pull-and-push my HD into my next laptop.

But what I'm more worried about: "the growing threat of pre-OS malware". I'm a saavy nerd, but I don't really know what this means. I'm sure that I could Google it, but it feels like we've missed the boat on security: I don't need Fort Knox, but, even as a geek, I need something that isn't confusing and restrictive.

I'm guessing you're either a very young savvy nerd, or you've forgotten about boot sector viruses.

This has been a problem for 25+ years.

He says he uses Debian, so yeah, he's forgotten about boot sector viruses.

Mainly it means lower-than-OS, such as firmware, hypervisor layers, hardware backdoors/leaks, etc. Things that are guaranteed to be invisible to the guest layers.

The other pre-OS-malware meaning is HDs and flash devices shipped with viruses on them.

What are the chances of Microsoft allowing their vendors to implement installing secure-boot keys from removable media?

Summary: Secure boot will be turned on by default and will prevent booting alternative operating systems.

But you will be able to turn it off if you know how to use a BIOS, unless your hardware vendor has disabled the ability to turn it off in order to reduce their support burden.

That's a misleading summary! Under the OP's proposal, you will be able to boot any OS from removable media. Furthermore, if the vendor of the OS follows some simple instructions (involving placing a key in a certain file), the BIOS will ask you if you want to permit future boots -- from removable and non-removable media -- of that OS. So for example once you have booted Ubuntu from removal media and answered yes to the question, from then on you will be able boot any version of Ubuntu from any (removable or non-removable) volume without being peppered with any more secure-boot-related questions.

Although some PC vendors might not implement the proposal, you can say that of any proposal.

Very good proposal IMHO.

Deleted comment

We gain if there are any OEMs that do implement the proposal.

Deleted comment

You ... have gained the ability to use secure boot?

Validating the integrity of the operating system using code stored as part of the operating system doesn't buy you anything - a prospective virus writer would just make sure to patch that checking code as well. You need to check integrity from outside that sandbox for it to be meaningful.

While the bios code does run on the same CPU as everything else, the important part is that it runs first - and the correct way of handling the keystore is to prevent it from being written to once non-bios code has started executing.

hmmm Imagine this...

I am an Airman at a secret facility in Nevada and want to install a new secure OS to experiment so I download this new OS and install to removable media and answer yes boot the alternative OS....

But the whole alternative OS was infected with virus as the new malware rootkit so now we have keyloggers on all computers controlling US drone fleets..

Pretty picture is it not?

I would expect the OS to be checked for safety before an attempt to install it in a place it had access to infect other machines. Anyone with the ability to install an alternate OS working in such an environment should have the knowledge to not do something that stupid. The fault here is with the person, not the software. Protecting users from themselves so much that they have no control of the software on their machines as an alternative to your scenario seems like giving up too much.

The point of secure boot is that it protects the environment before the operating system starts. If the operating system you're installing is untrusted then you've lost regardless.

Reply on news.ycombinator.com