|| ||Alan Cox <alan-AT-lxorguk.ukuu.org.uk> |
|| ||Community support for Fedora users <users-AT-lists.fedoraproject.org> |
|| ||Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions |
|| ||Fri, 1 Jun 2012 08:46:06 +0100|
|| ||Article, Thread
> We're told that Fedora's bootloader is going to get signed – and by that,
> that must mean "grub", right?
No. A tiny loader before grub with the Microsoft key is the plan. That's
actually technically quite smart as it means you don't have to keep going
back to Microsoft. Of course in reality because EFI is buggy and full of
work arounds you will. And since it's probably a revenue stream I can
imagine Microsoft will be keen to revoke keys and charge lots of $99
whenever it can as well.
> And, grub can boot an arbitrary Linux kernel, right?
The signed loader would load a signed grub which would load a signed
kernel which would load only signed modules (no vmware, no nvidia. no
virtualbox, no 3rd party downloaded GPL kernel modules, no security
patches applied by hand, no custom reconfigurations, no board
workarounds, no tmapi on thinkpad). In practice in many cases it will
also have to sign all the firmware that is loaded into the drivers so you
won't be able to update the firmware.
You'd also have to turn off the kernel debugger features, much of
firewire, some X features, uvesafb, lrmi, dosemu (but not dosbox),
systemtap, setserial, and a whole host of other things. You probably have
to mandate SELinux as well and prevent anyone from setting certain
attributes on packages that are not signed etc.
There are some really non-obvious ones and I'm keeping them under my
(free) hat until after Red Hat try this including a couple of gems I
think I'll sit on until a RHEL with this "feature" is released.
Also every time a hole is found Fedora will have to revoke that kernel,
force everyone to upgrade or if they have an older unsupported kernel
leave them stranded.
Out of support releases are also an interesting problem. If a hole is
found they need to revoke the key. If they do that the users machine is
crippled. It's potentially a criminal matter in many EU states as well so
whoever issues the revocation could end up in jail. Nobody is really too
sure. This is all untested waters.
> So, a virus that wants to compromise a signed, secure bootload chain, can't
> it simply install Fedora's signed grub, configured to boot a bare-bones
> Linux kernel, nothing will prevent that, right?
Not it would just use a kernel hole and if it was targetting windows it
would use the early bit of the kernel boot up, compromise itself at init
(very early very quiet so basically invisible), and then bootstrap
windows 8 either directly or virtualised while lying that the secure boot
> Red Hat's private key. The kernel will be configured to load only kernel
> modules that are also signed by Red Hat's private key. OEMs that supply OEM
> binary blobs, for stuff like RAID cards, etc, that are certified with RHEL,
> will get Red Hat to sign their kernel modules for them, also for a token
> certification key. That's the hood, welded shut, that's absolutely mandatory
> for a secured bootloader to have any logical purpose, whatsoever.
Correct - and you need to lock it down way more than that. Also I can't
see Red Hat directly signing third party binary blobs. If it does that it
implicitly believes they are lawful and also acquires some liability for
them in they malfuction.
> Fedora is not going to be a part of this. In order to boot Fedora, it will
> be necessary to disable the secure bootload, on the hardware.
It will be up to the Fedora Board to stop Red Hat corrupting the goals of
the Fedora project in this way - or if they won't for people who dislike
it to dump Fedora - particularly package maintainers.
users mailing list
To unsubscribe or change subscription options:
Have a question? Ask away: http://ask.fedoraproject.org
to post comments)