linux/LinuxUEFISecBootNotes written at 15:35:07; Add Comment
Some things that strike me about Linux and UEFI secure booting
When I read Matthew Garrett's Implementing UEFI Secure Boot in Fedora, a number of things struck me about the situation (for his background on UEFI secure boot, see part 1, part 2, more, and especially this). The basic setup is that Microsoft is requiring that any hardware that wants to carry a 'Windows 8 ready' logo must support UEFI secure boot and must have it turned on.
(Actually, when I read Garrett carefully the last bit is not clear. He says that if Windows 8 is preinstalled UEFI secure boot must be enabled, but he doesn't say that a motherboard merely marked with the Windows 8 logo program must have secure boot turned on. It's possible that this is not a Microsoft requirement and that motherboard and system vendors may thus ship bare machines with UEFI secure boot turned off. We probably won't know until Windows 8 logo hardware starts shipping.)
First, something that's worth noting explicitly:
This hits both install media and 'live CDs' (these days as likely to be a USB stick as a physical CD or DVD), and also PXE netbooting. Signed media can boot automatically, but not unsigned media. Among other things, this is a real usability hit for unsigned installers; you can't even boot the installer to an instruction screen about the need to disable secure boot in the BIOS. And as Garrett notes in his series, Microsoft has not mandated a specific UI for disabling secure boot in the BIOS so everyone is going to do it differently.
In the short term I'm more optimistic than Garrett is about how easy it will be to turn UEFI secure boot off. Since (as far as I know) older versions of Windows will not boot on UEFI secure boot machines, as long as a significant number of people will want to install them the BIOS vendors have a strong motivation to make this as easy as possible. The absolutely easiest way would be a boot-time popup that says 'you are trying to boot an unsigned thing; continue anyways?'
(This may wind up be disallowed by Microsoft's Windows 8 requirements, of course. Just like all other security warnings, the easier it is for users to disable secure boot the less effective it is at preventing boot time malware because almost all users will just reflexively override the warning if they can. BIOS vendors don't care about this, but Microsoft does and they may put their foot down.)
tech/SecureBootProblem written at 11:42:32; Add Comment
The secure boot problem
In theory, UEFI secure booting has the straightforward goal of stopping boot time malware, malware that compromises your machine before Windows boots and thus before any of its protections can kick in (such malware already exists, although it's not very common). In practice, secure boot requires that all privileged code your machine ever runs be signed. Your bootloader must be signed, your operating system (Windows or otherwise) must be signed, your hardware drivers must be signed. Wait, what? How did 'prevent boot time malware' turn into 'only run signed code'?
The core problem with all secure boot schemes and with this general goal of blocking boot time malware is that the OS has no way to be sure that it was booted securely. There is no way for Windows (or any other OS) to reliably detect that it was booted in a compromised environment or by something other than the official boot system and throw up a big warning when it starts to the effect that you're in trouble. If an attacker has control of the machine, they can construct a fake boot environment that lies to the target OS and says 'honest, you were booted securely, everything is fine, I am not boot time malware'. At that point it is game over.
(I'm not convinced that you can get around this in practice even with hardware support.)
This means that secure boot can never allow the attacker to gain control of the machine through any path, even a long one. A bootloader allows control of the machine, so you can only run approved, presumed secure bootloaders. An operating system allows control of the machine, so bootloaders can only run approved operating systems. Kernel level drivers allow control of the machine (if you abuse them), so operating systems can only allow approved drivers. Direct hardware access to some hardware allows you to take control of the machine (for example by programming DMA to overwrite bits of the OS), so operating systems can only allow that access to approved programs. And so on. Thus we wind up with secure boot requiring that all privileged code be signed, all the way down the line from the bootloader to graphics drivers.
Any opening in this chain of trust allows an attacker to slip in, intercept the process, take over the machine, and boot the target OS in a malware infected environment. If they can slip in early enough, you're unlikely to notice that your machine takes a few seconds longer to boot than before because it is actually booting a carefully configured minimal OS install for something that is willing to run an unsigned driver and the 'driver' is then taking the machine over to start your real OS.
Of course, the corollary of this is that signing things is not really good enough to keep attackers out. It would only be good enough if the signed things had no vulnerabilities that attackers could exploit, but of course they are going to have vulnerabilities and they're going to get compromised. In theory signing things allows things to be de-approved after the fact when they are found to be vulnerable; in practice, well, there's all sorts of potentially explosive issues.
PS: how this interacts with virtualization makes my brain hurt. In theory I think that all virtualization systems (whether or not they require special hardware privileges) are part of the trust chain and so have to be signed. I have no idea how you enforce that.
Sidebar: the theoretical way around this with hardware support
What you need is a piece of hardware that cannot be faked, can be irreversibly disabled by the system, and is essential to boot your OS. The obvious implementation is to have a crypto processor with preloaded keys that is used to decrypt some portion of your OS. At the point where the boot system transitions out of secure booting, it tells the crypto processor to flush the preloaded keys; if your OS is booted after that point, it will be unable to decrypt portions of itself and won't run. Malware is presumed to not have the keys, so it cannot reload them into the crypto processor.
(I'm engaging in a certain amount of handwaving here about how the keys would work.)
One pragmatic difficulty with this is the question of what prevents the malware from simply providing the necessary decrypted material directly. Almost all of your OS's code and data is not system dependent and cannot be tied to a particular machine so the malware can simply carry around a generic copy of the decrypted, live version of anything that normally comes encrypted. My instinct is that it's hard to have system dependent material that is really crucial and cannot be quietly substituted or patched.
* * *
Atom feeds are available; see the bottom of most pages.