On 06/02/2012 03:28 PM, Gregory Maxwell wrote:
On Sat, Jun 2, 2012 at 12:36 PM, Matthew Garrett<mjg59@xxxxxxxxxxxxx> wrote:
Per spec the machine simply falls back to attempting to execute the next
entry in the boot list. An implementation may provide some feedback that
that's the case, but there's no requirement for it to do so, so it's
perfectly valid for it to just fall back to booting Windows with no
notification.
If the issue were just the opaque and unpredictable behavior on
failure this could be addressed without signing any of the
distribution proper.
Create a pre-bootloder. If secureboot is enabled only permitting this
boot because it's signed with the msft key, then display the most
helpful instructions WRT secureboot we can display and then halt. If
secureboot is not enabled, pass control to grub.
This should meet the signing requirements and it removes the opacity
without locking down any of Fedora. Such a bootloader should meet
whatever requirements to get signed, since if secureboot is turned on
it wont boot anything at all.
So let me get this straight. Your solution is to write a shim bootloader
that differs from the one we've proposed in that instead executing the kernel,
if Efi:SecureBoot is set to 1 in the firmware, it tells the user to fumble
around in the firmware menus, which don't necessarily even exist, until they
find the switch that tells them to disable security, to turn that and
probably anything similar they find before finding the right switch off,
and then to try again. And maybe you want to explain to them that the system
was somehow configured wrong from the factory even though windows worked and
the system manufacturer probably did have some reason for flipping the switch
labeled "security" to the "enabled" position.
And you want us to get that signed, and just have it not bother to boot the
system. For freedom.
You've just drawn the higher barrier for freedom-to-modify line at a different
point in Fedora, but it's still there. But in your version it also tells the
user to expose themselves to a legitimate security problem so that they're
free-er to do something they could already do, if only they had the will to
do it. It may also be telling them to do something they cannot, with any
reasonable amount of effort, do, depending on if apple decide to ship with SB
enabled and the MS keys installed in DB, since they certainly won't be shipping
windows logos, and they're not too keen on bootloader menus.
Do I even need to explain why I don't think this is better than our plan?
--
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
