1 |
On Fri, Jun 15, 2012 at 8:18 AM, Luca Barbato <lu_zero@g.o> wrote: |
2 |
> On 06/15/2012 06:57 AM, Chí-Thanh Christopher Nguyễn wrote: |
3 |
>> If you have influence on UEFI secure boot spec, you could suggest that |
4 |
>> they mandate a UI which lists all boot images known to the EFI boot |
5 |
>> manager, and the user can easily whitelist both individual loaders and |
6 |
>> the keys used to sign them. |
7 |
>> |
8 |
> |
9 |
> That would be a good compromise. |
10 |
> |
11 |
|
12 |
Agreed, though MS is likely to be sensitive about how this is done. |
13 |
One of their requirements: |
14 |
System.Fundamentals.Firmware.UEFISecureBoot / 14: |
15 |
Mandatory. No in-line mechanism is provided whereby a user can bypass |
16 |
Secure Boot failures and boot anyway Signature verification override |
17 |
during boot when Secure Boot is enabled is not allowed. A physically |
18 |
present user override is not permitted for UEFI images that fail |
19 |
signature verification during boot. If a user wants to boot an image |
20 |
that does not pass signature verification, they must explicitly |
21 |
disable Secure Boot on the target system. |
22 |
|
23 |
Sounds like they want to make getting around signature issues a fairly |
24 |
technical exercise. This of course raises the barrier to loading |
25 |
another OS, though to be fair the "Stuxnet wants to access your boot |
26 |
sector - hit OK to allow or Cancel to not display the cute video your |
27 |
friend sent you" options that are typical these days hasn't really |
28 |
been very effective in keeping out malware. |
29 |
|
30 |
Rich |