[kwlug-disc] Windows 8 OEM specs may block Linux booting

[Chris Irwin]

On Sat, Sep 24, 2011 at 11:04:59AM -0400, L.D. Paniak wrote:
> Here is a de-FUD-ded version of the Windows 8 boot system from MS
> themselves:
> 
> http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx
> 
> Bottom line:  Windows 8 won't work without secure boot enabled. And
> secure boot will not let anything else boot unless UEFI has a
> certificate for it. The question of dealing with other OSes (disable
> option, user management of boot certs, ??) is left to the motherboard
> vendors.
> 
> [...]
> 
> The good news is that (almost) the entire installed base of PC hardware
> will not be qualified to run Windows 8.

The article doesn't say Windows 8 won't work without secure boot, only
that they require it to be present and enabled by default for the
windows sticker certification ("Windows 8 compatible", or whatever the
phrase will be).

They actually specifically mention that disabling the function must
*not* be programatically accessible from within the OS to prevent
malware from bypassing secure boot. That suggests that Windows 8 would
still boot without secure boot (which matches with the other reading
I've been doing), otherwise it would a very silly, overly high-profile,
and short-lived malware.

> It is a very nice play by Redmond. They can attempt to patch the
> vulnerabilities  of their poor security architecture *and* make it more
> difficult for PCs to run alternative operating systems at the same time.
> All the while leaving the motherboard vendors holding the bag.

This won't affect Windows security. Once booted, Windows itself can run
unsigned applications. This is simply to ensure that the system is
booting a known-good operating system (and once it gets past the
bootloader, the whole EFI part is done).

If you can actually enter your own keys into the motherboard, then I
could definitely see benefit: I have an encrypted hard disk, except my
boot loader and /boot partition are not protected. Theoretically, my
initrd could be modified to log my passphrase provided you have physical
access. It would take about five minutes assuming you know how the
initrd is structured.

However, if I could ensure that only my *verified* grub was loading, and
GRUB could be modified verify my kernel and initrd (separately, that
would not be a UEFI feature after GRUB has started), then I would have a
significant security gain at boot time. Again, none of this affects the
security of the system while running (in my example, you could get a
keylogger in the initrd when it rebuilds after updates. However, if you
already have root on the running machine, bypassing secure boot is
unnecessary).

Much like TPM, it is a technology that has the potential to actually
make our computing environment more secure. The real issue is not
whether the technology is good or bad (it is a tool and can be used for
both). The issue is trust and ownership ('Secure' relative to whom?)

> We should have a pool on how long it takes for this system to be hacked
> and turned into yet another Windows vulnerability.

Suppose that the "hack" was simply a release of Microsoft's private
signing certificate through whatever means (poor random numbers like
sony, leaked, whatever). There would have to be a method to invalidate
the old key and authorize a new one, which would probably be a bootable
(manufacturer signed) firmware update.

Most users won't update their firmware, and Microsoft probably won't
sign new updates with a compromised key. Furthermore, if you *did*
update firmware and needed to use the original restore disks which only
had the old signatures, you would be in a similar predicament. Logically
there needs to be a way to boot in non-secure mode as a fallback, at
least until you can install & update. Due to the points above, it would
be very short sighted to disable that functionality.

There is plenty of common non-microsoft software that needs to run (Disk
imaging, SSD firmware updates, hard disk data recovery tools, etc).
Matthew Garrett's concern that some fly-by-night manufacturers will not
ship sufficient functionality is justified. However, I'd imagine there
would be extremely few UEFI implementations. Wikipedia lists four:

    https://secure.wikimedia.org/wikipedia/en/wiki/Unified_Extensible_Firmware_Interface#Implementation_and_adoption

If it was up to me, I'd probably make it work with a USB dongle &
passphrase. To enable/disable secure boot or add or disable keys, the
system-unique dongle must be physically connected, and the passphrase be
entered. The passphrase is sent to the UEFI system, and it interacts
with the dongle directly. This prevents rogue access, would allow
programatic access with user confirmation ("System requests key
0xDEADBEEF be added to secure boot" along with some method for seeing
who signed the key, chain of trust, etc.). Maybe I should send a
resumé to Intel or American Megatrends.

Now, there was one point in the linked post that did cause some
concern:

    "and that OEMs prevent unauthorized attempts at updating firmware
     that could compromise system integrity."

This would probably have a serious effect on the coreboot project if
firmware updates must be signed by the OEM.

-- 
Chris Irwin
e:  chris at chrisirwin.ca
w: http://chrisirwin.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20110925/86328f95/attachment.sig>