Booting a Self-signed Linux Kernel | Hacker News Reader

Booting a Self-signed Linux Kernel

kroah.com

74 pointstanglesome20 comments

I'm confused, but maybe you can enlighten me: This article talks about using a tool called KeyTool to manipulate the keys stored on the machine. But if software is capable of doing that, wouldn't that defeat the whole purpose of UEFI to begin with? How is it ensured that it's the user operating KeyTool and not $MALWARE?

Why does KeyTool even run on a locked-down-by-MS machine? Have they signed it as part of the Linux Foundation bootloader? Why would they do such a thing? I don't mean for protecting-the-monopoly-reasons, but for straight security reasons as this clearly circumvents anything they were trying to accomplish.

I seem to be missing a piece of information here.

You have to disable the Secure Boot protection before you can run KeyTool - from the article:

  Traverse the BIOS settings and find the place where UEFI boot mode is specified, and turn it the “Secure Boot” option OFF."

This is an example of what I love about the open source community. Some argue that signed boot was an attempt to force the open source community out by holding the keys to the ability to boot, as it were. Some think it's just relentless advancement of the forces of centralization and the establishment's view on security. Regardless of all of that, we can now take advantage of it to ensure our machines can only boot our trusted, linux/bsd/home-built OSes. I'm reminded of the car dealer crossroads from "In the beginning was the command line".

Open Source FTW.

Unfortunately, the fact that you have to go through such an elaborate procedure will deter many people from going open-source. Before secure boot, installing Linux was relatively straightforward, and that is one of the reasons for its success. Those days are drawing to a close.

Why can't this procedure be standardized and made straightforward? It's hard now, but hopefully in the future it will just be a typical part of installing the operating system.

Because the procedure requires making changes to the BIOS, and that can't be automated, or even standardized because different manufacturer's BIOSes are different. Recall this passage from the post:

"Reboot the machine, and go into the BIOS. Usually this means pounding on the F2 key as the boot starts up, but all machines are different, so it might take some experimentation to determine which key your BIOS needs."

That will be a show-stopper for most people.

Really? I think that's a pretty normal part of choosing to boot from external media, which is a pretty normal part of choosing to install an aftermarket operating system.

You think that because you're a geek. Normal people, if they run Linux at all, install it by booting from a CD. And even that is too scary for most people.

That procedure was only needed in order to show how booting a non-signed kernel was made possible and later how that was turned off again.

The magic is in KeyTool and that doesn't require the user to alter the BIOS in any way. You boot from that USB drive (sb-usb.img linked in the article) by the usual methods of booting from an external drive. It will boot because its bootloader is the Linux Foundation one that was signed by MS. Then you launch keytool and change the key config.

At this point, your bios will boot a kernel you have signed.

The only BIOS intervention in the article was to first allow booting unsigned kernels (not needed with that sb-usb thing) and then to turn it off again. At least that was my impression.

Ah. Well, it's possible I misunderstood that. I hope you're right.

Ah, hold on.

Doesn't running keytool require you to turn off security in the bios first?

> its bootloader is the Linux Foundation one that was signed by MS.

sounds like abomination. Even in the early 1998 our web browser had 4 or 5 root certificates. Why only one in the case of secure boot?

This article reminds me of the hassle it took to dualboot my new laptop with Win8/Linux. Although this self-signed-do-it-yourself approach sounds very interesting - and by all means I will try it as well - it's complex enough to stop loads of people from even trying.

As some have put it in this comment section, regular people only want to install from a CD. This will be too much for them, unfortunately.

Nice! It'd be good to pair this with some instructions on how to do safe key management by yourself, because you'll only ever be as safe as you keep your keys.

I would link to some here, but I don't even know of any best practices for keeping personal keys safe. (Use smartcard/physical-backed keys?)

The conventional wisdom I've been given has indeed be using smart cards for key management. Id love to know if this idea is still the best way.

> Use smartcard/physical-backed keys?

Basically, yes.

I'd be happy to share details of how I generated/store/backup my keys but be forewarned that I went the "extremely paranoid" route.

Please do. I haven't been able to find a vendor for smart cards in the US nor do I know exactly what to buy.

I have to ask but I am not optimistic - would this get Linux booted on a Surface RT?

so.... why exactly does UEFI exist again....? seems useless

It is a replacement for BIOS that first showed up on Itanium platforms. It adds quite a bit of complexity but also opens the door for new features like secure boot.

I won't argue whether it is useful but it is in nearly all new desktop hardware including all Apple x86 hardware. It is here to stay.

Reply on news.ycombinator.com