| 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 |
Archives