1 |
Am 03.06.2012 08:57, schrieb Walter Dnes: |
2 |
> On Sat, Jun 02, 2012 at 07:36:51PM -0400, Michael Mol wrote |
3 |
> |
4 |
>> The BIOS will only load a signed bootloader. The signed bootloader |
5 |
>> will only load a signed kernel. |
6 |
> |
7 |
> OK, so I sign LILO. What code is in there that prevents LILO from |
8 |
> loading whatever kernel I've compiled? |
9 |
> |
10 |
|
11 |
Nothing. The point is, if you sign software that is used (or can be |
12 |
used) for malware, your key will be blacklisted. That's why Fedora takes |
13 |
the measures I've listed: They don't want to have their key revoked. |
14 |
|
15 |
>> The signed kernel will...do whatever you tell it to do. |
16 |
> |
17 |
> Define "kernel"... no... seriously. |
18 |
> 1) Could it actually be a hypervisor? |
19 |
> |
20 |
> 2) Or maybe another copy of LILO which proceeds to load the actual |
21 |
> kernel? |
22 |
> |
23 |
|
24 |
Sure, whatever floats your boat. UEFI only checks the boot loader |
25 |
directly. After that, it is the boot loader's responsibility to keep the |
26 |
next stage secure. But if you allow unchecked access to the hardware |
27 |
through whatever signed code you have, your key will be blacklisted. To |
28 |
quote Matthew again: |
29 |
|
30 |
> Secure boot is built on the idea that all code that can touch the |
31 |
> hardware directly is trusted, and any untrusted code must go through |
32 |
> the trusted code. This can be circumvented if users can execute |
33 |
> arbitrary code in the kernel. So, we'll be moving to requiring signed |
34 |
> kernel modules and locking down certain aspects of kernel |
35 |
> functionality. The most obvious example is that it won't be possible |
36 |
> to access PCI regions directly from userspace, which means all |
37 |
> graphics cards will need kernel drivers. Userspace modesetting will |
38 |
> be a thing of the past. Again, disabling secure boot will disable |
39 |
> these restrictions. |
40 |
|
41 |
Regards, |
42 |
Florian Philipp |