dc13 - 1.0
DebConf13
| Speakers | |
|---|---|
|
Ben Hutchings |
| Schedule | |
|---|---|
| Day | DebConf day 3 (2013-08-13) |
| Room | Second talk room |
| Start time | 14:30 |
| Duration | 00:45 |
| Info | |
| ID | 1039 |
| Event type | meeting |
| Track | Debian boot |
| Language | en |
| Feedback | |
|---|---|
|
Did you attend this event? Give Feedback |
Secure Boot for Debian Linux
Debian 7 cannot be installed on new PC desktops and laptops without reconfiguring the firmware to disable Secure Boot. Installation of Debian should be as easy as possible, so it is important that we provide images that are compatible with Secure Boot as deployed. This would also provide a defence against some kinds of rootkit. How do we get there?
Most PC desktops and laptops are 'designed for Windows' which means Secure Boot is enabled by default. The only KEK (trusted key) we can rely on being installed is Microsoft's. The MS logo requirements do require that the firmware allows editing key stores and disabling Secure Boot, but the UI and key formats will vary between systems which makes them practically impossible to document. Over the next few years, Secure Boot will also be introduced on PC servers, though vendors are much more concerned about Linux support on servers.
There are several free boot loaders for which MS-signed binaries are available (Shim, efilinux, and the LF loader) with varying mechanisms for establishing trust in the second-stage boot loader or kernel. Potentially we could support several of them, but practically we would have to choose just one for installation media. It seems preferable to use the same boot loader for both installation media and the installed system, if possible.
We may have to sign the second-stage boot loader and/or kernel as well, and disable kernel features that allow inserting untrusted code into the kernel if it is booted through Secure Boot. (And this would provide a real security benefit, though there are enough kernel bugs that there will still often be ways to compromise the kernel code.) But we must always give users the option to override this, either by disabling Secure Boot or through explicit interaction with the trusted boot loader.
Which components do we use and who's going to work on them?