

More information on Linux and the UEFI secure boot feature. - thristian
http://mjg59.dreamwidth.org/6503.html

======
sp332
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

------
mbreese
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: _
"

~~~
sounds
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

------
CoffeeDregs
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.

~~~
nknight
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.

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

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

------
Andys
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.

~~~
hollerith
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.

------
shareme
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?

~~~
etherealG
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.

