Re: EFI BoF at DebConf
Hi Steve,
Thanks for the summary of the EFI BoF. If you don't mind, I'm going to
piggy-back on this to provide a bit more info about Secure Boot. Some of
this is just expanding on your notes with clarifications; other bits are new
information I've gleaned while attending the UEFI Summer Summit this week.
But don't ask me to remember which parts are which, as it's all run a bit
together in my head. ;)
With many of my comments, I may be giving the impression that I think things
aren't that bad and that everything will be ok with Secure Boot. I am in
fact very concerned about Secure Boot; we have some significant challenges
ahead for continued after-market compatibility with commodity machines as a
result of this change. But to meet those challenges, we need to be focused
on the issues that are actually going to cause a problem. For instance, I
*don't* think we should be worried that machines will go out the door with
the Windows 8 logo on them while failing to correctly implement SB
(including the disable and customization capabilities). The Microsoft team
working on this are quite serious about getting it right, and they do have
a compliance testing process that exercises the SB aspect of the
requirements. So while there may be a machine or two slipping through to
market that don't support SB in the required manner, these would be bugs -
and I have every reason to believe Microsoft will be open to bug reports
about them.
The things that are worrying me, and that I therefore think we need to focus
on, are the areas where the Win8 requirements *don't* cover us.
On Fri, Jul 20, 2012 at 11:34:13PM +0100, Steve McIntyre wrote:
> There is also a second part to this puzzle: Microsoft's Secure Boot
> specification.
Nitpick: Secure Boot is part of the UEFI specification; the part here that's
Microsoft's is the policy around how SB is to be used.
> System vendors wanting MS certification for their hardware (i.e. just
> about all vendors) will be required to ship their hardware with Secure
> Boot enabled by default
Bearing in mind that they're only required to do this for Windows 8
certification. Some machines may ship with Windows 8 preinstalled, but not
have SB enabled and thus not be certified; some may continue to ship with
Windows 7; some server machines may (at least in the short term) come with
firmware that doesn't implement Secure Boot.
And some vendors may ship with Windows 8 preinstalled but fail the Win8
certification requirements because they've managed to not actually support
disabling SB and/or updating keys. Small comfort that this will result in
them not being able to use the Windows 8 logo if it means we won't be able
to use the machines at all.
Ironically this last bit means that the Windows 8 logo may wind up being the
*best* indicator of Linux compatibility for UEFI hardware. Only time will
tell what we see in the market.
> Future UEFI SB changes
> ======================
> Comes down to MS certification requirements as to what actually ships.
> Must be possible to disable SecureBoot but will practically be done via
> access to the firmware: usability obstacle.
More than just a practical implementation detail, it's by design that you
will only be able to disable SecureBoot via the firmware. To allow a UEFI
application to disable SecureBoot for you noninteractively would almost
completely undermine the security model. Now, I can't actually think of a
way that a UEFI application that *only* disabled SB could be used to
compromise a machine remotely; but it's in the Windows 8 reqs that the
firmware must not allow SB to be disabled programmatically.
(System.Fundamentals.Firmware.UEFISecureBoot 18)
> No clarity on how users can install their own keys, down to particular
> vendor variability.
James Bottomley appears to be addressing this:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git
Provided you can get the machine into setup mode or custom mode in the first
place (which is supposed to be guaranteed by the Win8 reqs), the tools here
should allow you to non-interactively install your own keys without
resorting to the vendor's firmware UI.
> Part of the spec but not necessarily implemented by vendors - best effort
> only and might not work for all.
FWIW, my understanding is that MS's logo compliance testing is expected to
catch this case.
> It is quite possible that one or more OEM's will simply not bother to
> implement the option to disable SecureBoot or put it in but not adequately
> test it. Current certification requires a switch to be available but no
> requirement for this to be obvious. Turned off, the machine cannot or may
> not be able dual-boot Windows8 depending if turning it off means switching
> firmware to BIOS compatibility mode or just not cheching the signature
> from EFI.
Hmm, I don't remember this being discussed during the BoF. I think it's
clear from context that when the Win8 requirements speak of disabling Secure
Boot, they mean not enforcing Secure Boot /while still providing an EFI
environment/.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: