Sure, it seems like an interpreter would be required here, but I was more concerned about the logic surrounding the interpreter to create the secure sandbox, rather than the interpreter itself. If security wasn't a goal, it doesn't sound too hard. Maybe even if made people specifically write their option ROMs to run in this interpreter it wouldn't be so bad. But, without having any experience in this area at all, it seems like it would be difficult to set up a sandbox to run any old option ROMs that people wrote expecting to be executed directly. If you could do it, it seems like it would take a non-trivial amount of code. I doubt OEMs would want to spend system flash space on it, given this is a problem that goes away once people switch to signed UEFI device drivers.
Somewhat interestingly, UEFI BIOS already has an interpreter. The UEFI specs created something called EFI Byte Code to allow people to create architecture-independent UEFI device drivers. But, they were just trying to prevent add-in cards from having multiple copies of device drivers- they weren't trying to execute each driver in a sandbox.
Anyways, this is just a thought experiment (albeit a somewhat interesting one- I kind of like the sandbox idea, I just don't think it will happen). As I said, OEMs are explicitly forbidden from executing unsigned UEFI device drivers and/or legacy option ROMs when secure boot is enabled.
I think we're just having a terminology/interpretation difference. You're saying SMI handlers are "in" the BIOS, I'm saying SMI handlers are "set up" by the BIOS. I'm not quite sure what you mean by saying they're "in" the BIOS itself. As I said, SMI handlers are certainly loaded by the BIOS during boot. The BIOS is the only entity that can load SMI handlers, and its supposed to lock SMI code prior to executing untrusted option ROMs or bootloaders (otherwise you have a pretty nasty vulnerability on your hands).
But, I wouldn't call SMI handlers "part of" the BIOS, partly because they don't perform the same function as BIOS, but perhaps more importantly because they run in a logically separate execution environment from the BIOS (i.e., System Management Mode).
But, the distinction between "in" versus "set up by" the BIOS isn't particularly important. I'm still curious about your previous claim that you could use SMI to do code signing checks after you've passed control to untrusted code outside BIOS/boot firmware. As I said in my previous message, its not clear to me how that would work. What would trigger the SMI handler to perform the check?
I'm pretty sure it will be a problem for the tiny number of people that will attempt to do this on a new OEM-purchased Win8 box.
I have to admit, I have no idea what you're talking about when referring to some sort of sandboxed environment in BIOS. Nobody does that now, nor is it clear from me that it's even be possible to secure up a secure sandbox to execute opROMs in. Even if it is possible, it seems like it would be rather difficult to implement, so OEMs wouldn't be interested in wasting their precious system flash space on it.
While I'm skeptical of any sort of secure sandbox, you can have compatibility layers. In UEFI BIOS, you can load Compatibility Support Modules (CSM) to execute legacy option ROMs. But, this isn't a secure way to execute untrusted code- its just there for compatibility with legacy hardware/firmware. So, OEMs are explicitly prohibited from loading CSMs when secure boot is enabled.
My point is that your video card isn't going to work in the preboot environment if you don't have a signed UEFI device driver. Could an OS potentially work around that and get the video card working under the OS? Maybe, but even then you're still not going to be able to go into the BIOS settings in preboot to turn off UEFI secure boot, because video isn't going to work there. I don't know for sure, but I suspect Windows would have hard time using a video card if its option ROM wasn't executed during boot.
So, the moral of the story is just if you buy a Dell Windows 8 system, and want to toss in an old video card, make sure you turn off secure boot *before* you take out the video card the system came with (that is, if it has a discrete video card at all).
UEFI secure boot isn't incompatible with your idea. You'd still need some standardized interfaces for signing code and verifying that code at boot. The main differences would be trust anchor management and the signing process. But, the architecture of UEFI secure boot is absolutely compatible with the idea that the device owner can determine what code should run. Microsoft's requirement for x86 systems pretty much mandates it. It's Microsoft's requirements for ARM systems that are incompatible.
But, your proposed solution is awful for the vast majority of people. How are novice users going to sign the boot code on their systems? Your saying every single person is going to have to securely manage a private signing key for every device they have. To update code, that user is going to have to pull out that private signing key, sign the code they want to update their system to run, and then update the code. For home users, that sounds incredibly complicated. For corporations, it doesn't lend itself well to automation. It's only good for enthusiasts.
What's the alternative? For the vast majority of people, its much, much better to have a small set of trusted third parties that will sign boot code. I know I don't want to have to keep a signing key in a protected place, and have to take it out and use it to sign code whenever I want to update an option ROM or bootloader.
The compromise on x86 systems seems like a good approach. Microsoft will run a signing service, but if people want to swap out the trust anchors and stand up their own signing service, they can. That's not going to be easy for people to do, but I really don't see an alternative. What am I missing?
I fully intend to keep UEFI secure boot turned on whenever possible. It's a very useful security feature. We're already seeing some malware that modifies the Windows bootloader to get around 64-bit Windows code signing checks.
I'm saying my systems run a video card option ROM (which is the legacy equivalent to UEFI device drivers) that is stored in flash memory on the video card. It's not running a generic video card driver that is stored on the motherboard flash. To the best of my knowledge, all systems today run a video card specific option ROM at boot.
OK, but that's more of an OS driver thing, isn't it? I'm still a little concerned that you might need to run a card-specific device driver to help the card itself boot up while the computer is booting up. If a generic video driver would work to give BIOS basic video functionality in preboot, why wouldn't we be using those now? In the legacy BIOS world you only have 640x480 resolution with 16 colors even with card-specific option ROMs.
What do you mean in secure boot the "option of booting alternative bootloaders is impossible?" It's not. Secure boot just says that alternative bootloader needs to be signed. Now, you're right that there would be a security problem for Windows if an alternative bootloader tried to load Windows without checking its signature. But, there are other ways to deal with that potential problem other than simply forbidding alternative bootloaders. Things like GRUB can't boot Windows directly anyway- it just starts the Windows bootloader, whose signature would be checked by the UEFI BIOS as part of secure boot.
Exactly. I don't know how this transition will go, because it really hasn't started yet. I think the only UEFI device drivers are drivers which are embedded in the BIOS (e.g., like a UEFI device driver for integrated video on a motherboard). So, we really don't know yet how aggressive video card vendors will be at moving to UEFI device drivers, and, just as importantly, signed UEFI device drivers. I'm guessing video cards will ship with signed UEFI device drivers well before Win8 starts shipping, but I know I've put in cards that are several years old in some of my systems, either as a temporary measure if a card goes bad or just to use spare parts in systems that don't need fast video.
First, we just have a terminology difference. I use "BIOS" as a fairly generic term for the boot firmware on the motherboard that executes at power-on. UEFI isn't really the right term for that, because UEFI is just a standard set of interfaces that UEFI-compatible boot firmware can implement. If its important to distinguish between old and new, I'll usually write "legacy BIOS" or "UEFI BIOS".
Second, there definitely are drivers for BIOS. In the legacy BIOS world they're called Option ROMs. In the UEFI world, they're called device drivers. You need those if you want to use a device in the preboot environment. Not every device needs an option ROM. You're not going to need to use, say, a TV tuner in preboot. But, you do want to use SATA/IDE controllers do you can boot of a drive, or maybe you want to use a network card to boot off a network server using PXE. Video is certainly important in preboot too, since you might want to go into the configuration settings and change stuff around. The only question is if you can use some sort of generic UEFI device driver, or if you need a card-specific one.
Third, secure boot ENDS when Windows starts booting. Mainly, UEFI secure boot verifies signatures on UEFI device drivers and the bootloader. Once the bootloader runs, UEFI secure boot is essentially over. The UEFI BIOS is no longer in control of the system, and its up to the bootloader and the OS to check signatures at that point.
Sure, but all that is tangential. UEFI secure boot itself doesn't say anything about how non-EFI executables are handled during boot. If a signed OS loader doesn't want to verify a signature on the OS kernel, it doesn't have to. It might want to, so it can't be used as part of malware, but that's not a part of UEFI secure boot.
Liability is a potential problem with UEFI secure boot, although a problem for whoever is signing UEFI executables (i.e., Microsoft). That's probably why no one else has offered to set up a signing service.
SMI handlers aren't really part of the BIOS. They're set up by the BIOS, but they're not really BIOS code. SMI handlers either have to be invoked by whatever software is controlling the system or by certain hardware-driven mechanisms that don't seem to apply here. There might be a some weird way to jerry-rig SMI handlers to do what you're describing, but its far from clear to me that that's possible.
Interestingly enough, in the UEFI world there is some BIOS code that lives on after the OS takes control. UEFI provides a set of run time services to the OS. Again, these have to be called from the OS. But, there really isn't anything comparable in the legacy BIOS world. As I said, SMI handlers aren't really BIOS code. ACPI code is slightly more comparable, but still not quite the same thing,
By the way, there is something interesting research into the nasty kinds of malware you can create if you can load malicious SMI handlers. One way an attacker could do that would be to flash a malicious BIOS which loads malicious SMI code. But, the Windows 8 requirements include some protections on the BIOS, including requiring signed BIOS updates.
Honestly, I think you have it backwards. I think its less that UEFI secure boot is most advantageous to Microsoft and more that it happens to be inconvenient to Linux. The open source community, for both good and bad reasons, has made a series of decisions that make a signed code model difficult to implement (and stomach).
Forgetting about who runs the signing service for a moment, do you have a better idea of how to solve security problems with boot firmware? It's one thing if you don't like the implementation of UEFI secure boot, but you seem to be suggesting that the entire concept behind UEFI secure boot benefits Microsoft. If that's true, what is the alternative?
I don't think Microsoft particularly wanted to run the signing service. It has already given them headaches, and it opens the door for a lot of potential problems with liability. But who else was going to run it? The UEFI Forum never gave any indication they were willing to run it when the specification was being written. Given they were the natural choice, I think it's pretty clear that means they explicitly didn't want to run it. Who else was going to run it? Verisign? I'm sure that would have gone over much better... Even if things did go that route, who was going to pay for it? If Microsoft funded it, which they probably would have had to, people would have just assumed Verisign was going to do whatever Microsoft told them to.
Red Hat and Canonical have never given any indication they were willing to run a signing service either. And people in the industry did ask them to. I'm not sure they ever explicitly said no, but they certainly never said yes either.
I don't think there are any discrete video cards with UEFI device drivers. Certainly there are none with signed UEFI device drivers, seeing as there isn't anyone signing those yet, and that's really what you need in a UEFI secure boot system. That will presumably quickly change as we approach the release of Windows 8, but there's still the problem of new systems running old video cards. That's exactly the situation I was imagining when I initially rose this issue.
RAID cards aren't really an issue. If you want to boot off an old RAID card, but it doesn't have a signed UEFI device driver, you're going to be able to go into the BIOS settings and turn off secure boot. I don't think there's a way around that. But, Microsoft's requirements for x86 systems say that users have to be able to do that. But, the idea is that there are some UEFI device drivers that you're going to need to even turn off UEFI secure boot. Some things, like the keyboard controller, are already embedded in the BIOS, so they're not problematic. But the video card might be a special case. If you want to muck with BIOS settings, you're going to need video working. But, if video cards need device-specific UEFI device drivers to function, it creates a problem. To get video working, you may need to run an unsigned video card UEFI device driver (or to run a legacy option ROM), you need to turn off secure boot. But, to turn off secure boot you'll need video working.
I figure there are two possibilities: either 1) you're right and you can have generic UEFI device drivers for video cards, or 2) there's going to be a slightly painful transition process. It might be that people that want to swap in an old video card in a new Win8 system will need to disable secure boot before removing the video card that same with their new Win8 system. Retail motherboards will probably ship with UEFI secure boot turned off by default (if they support it at all), since the Win8 requirements don't apply to them. In the end, I doubt it would impact very many people. How many people are buying new desktops at retail and putting in old video cards?
The threat you identified isn't special to GRUB or even bootloaders. Any EFI executable could potentially be "hiding" a malicious bootloader, or some other malicious payload that mucks with the way Windows boots up. I think you'll deal with this potential threat exactly one way: if you find out a previously-signed EFI executable is doing bad things, you'll add the signature associated with that executable to the "forbidden list" (essentially revoking the signature), and you'll go after whoever submitted that executable for signing.
That doesn't necessarily help you if OS-present malware modifies the loaders and the kernel. On the next boot you could load a modified kernel, which isn't going to be detected because you'll also have modified loaders. But, a lesser-known fact about UEFI secure boot with Windows8 is that Microsoft's OS loader is going to be signed with a different key than all other EFI executables. While I don't know exactly how its intended to work, its presumably intended to help block the sort of attack I think you are imagining. But, at the very least, GRUB can't directly load Windows. Instead it would launch the Windows 8 loader, and the UEFI BIOS should verify the signature at that stage. Presumably a bootloader like GRUB could be modified to directly load Windows, but that might be enough to land you on the forbidden list if someone catches you.
I don't know. All that's basically just a guess on my part.
I think you're absolutely right though that there's a tension between security and flexibility here.
You make an interesting point about service processors. Generally speaking, it should be difficult for malware to use that vector, since service processors (should) authenticate any requests (using a digital certificate, or at least a password). Still, a strict interpretation of Microsoft's requirements say that physical presence is required, and remotely changing a BIOS setting via a service processor isn't physical presence. Will OEMs write their BIOS so you can't change that setting via something like AMT? Maybe. I don't really know. I honestly don't see a compelling need to be able to turn it off remotely, so it seems like a bad idea to let it be remotely accessible by any mechanism, including a service processor. If you're running Windows, the only reason you might want to turn off secure boot is to use an old add-in card, in which case you're already physically at the box. If you're running Linux, and they don't get their act together to play nicely with secure boot, then you're just going to turn off secure boot when you initially set up the system.
I really don't know what Windows recovery tools use. It seems like those wouldn't be executing in the EFI environment and would instead load their own generic device drivers. I know MS wants to be able to use UEFI interfaces to display stuff on screen, but I think that's primarily for their bootloader (which is an EFI executable).
There's certain a handful of things you might want to do in the preboot environment. Things like BIOS or card flashing are generally initiated from OSes these days, although a lot of products can probably do it in preboot, or at least DOS. You'd certainly be able to do those things on a UEFI secure boot system if you had UEFI-compatible cards. The question is can you do those things easily on a UEFI secure boot system when you don't have UEFI-compatible cards. This is a potential problem that would only impact a small percentage of users. How many people go out and buy a new computer, and then toss in an old add-in card that is used during boot (like a SATA/RAID controller or video card)? Some do, but not a lot.
Part of me is tempted to say that you must be right, and that there's got to be a generic video UEFI device driver to fall back on. But, if that were true, why wouldn't we just use generic video card option ROMs today? As you said, there's really no need for full-fledged video in the preboot environment anyway. But I know my systems all execute a video card-specific option ROM during boot. Many of the other boot-critical devices on a system are on the motherboard and have option ROMs that are embedded in the BIOS (e.g., keyboard controller, USB, SATA, etc.). Things like mice are different sorts of devices. Those don't have option ROMs that execute on the host CPU. They have their own firmware running on microcontrollers inside the mice, but no option ROMs read out during boot and executed on the host. USB controllers, on the other hand, definitely have option ROMs (but again, they're usually embedded in the BIOS).
By the way, these devices don't need secure chips. The signature verification is done by the host CPU, not anything on the card/device. The card/device just needs to have flash memory that contains a signed UEFI executable. The BIOS will find that during the boot process, verify the signature, and execute it.
Maybe this is a stupid question, by why would every distribution have to get their GRUB build signed? Is GRUB distribution-specific now? If so, then I don't see any way around signing every build. For something like UEFI secure boot to work, you need to sign all code that executes during boot. But, if you're saying that because of some idea that GRUB has to verify the OS, I don't see where that comes from. There's no requirement to do that.
And, by the way, of course the signing key wouldn't be distributed. That would completely invalidate the security of UEFI secure boot. There's only one signing key per trust anchor. UEFI secure boot doesn't have a way to do certificate chaining. That's why Microsoft has to sign everything- there's no mechanism to give other entities signing keys rooted in Microsoft's trust anchor.
I agree the entire UEFI secure boot is slanted in Microsoft's favor, but that's only because they're the only player in town. No one else has offered to set up a UEFI executable signing service.
RAID cards were usually the thing I pointed to when people were worried you weren't going to be able to turn off UEFI secure boot. I fully expect you'll need a signed UEFI device driver for your RAID card if you want to boot off of it.
Hopefully you're right about a basic UEFI device driver, otherwise I think people will have problems before UEFI-compatible add-in cards become pervasive. But, in a UEFI world I don't think you have the same concerns about no video until OS boot. UEFI systems running Windows 8 will boot much faster than today's systems, making the time before the OS device driver kicks in much less.
I doubt that. There's a lot less code in boot firmware than in most OS-level software, meaning fewer opportunities for vulnerabilities in that code. And, probably more importantly, a lot fewer ways to inject code and try to run it. There's actually a paper from a couple years ago that found a vulnerability in the way that Intel signs their BIOS updates. That's essentially the sort of vulnerability you'd need to find. But, Intel did something sort of stupid: they signed all the BIOS code, but they didn't sign the graphics that appeared on-screen during boot. Someone found a vulnerability in the code that processed the graphics during boot which allowed for a buffer overflow exploit. Now they know better. I'm sure there's many more ways to get things wrong, but I think the code will be locked down pretty well. I don't expect to see very many exploitable vulnerabilities in UEFI BIOS that would compromise the security of UEFI secure boot.
Microsoft wants UEFI secure boot so people can securely boot into Windows. If you're using a different bootloader to load Linux, Microsoft doesn't care if your system gets infected with a rootkit. But, the preboot environment doesn't know what OS is going to be loaded, so it has to check signatures on anything. Right now the only entity that has stepped up to the plate to sign UEFI executables is Microsoft. No one else has they would set up an alternative signing service. If Red Hat and Canonical joined together to create one, they might actually be able to get the major OEMs to install the trust anchor on their products.
I've only seen the mid-December draft of the Windows 8 requirements, but it's my understanding that that draft significantly loosened the requirements for UEFI secure boot. Or, perhaps more accurately, is significantly strengthened the requirement for user-control of the secure boot setting and the trust anchors on x86 systems. That might indicate some reluctance to accept third party trust anchors. Or maybe they didn't expect any other UEFI executable signing services, since nobody else said they would do it. Or maybe at first they thought it was more appropriate to leave the decision on configuring secure boot to OEMs (a position they obviously don't hold now, given the strict requirements on both x86 and ARM systems).
UEFI secure boot is a perfectly legitimate mechanism to secure the boot process. That's really important, because any code that executes before the OS can insert a rootkit that would be very difficult to detect. I haven't heard of an equally good alternative that is suitable for the mass market. So, I really think people should be applauding Microsoft for what they're demanding on x86 systems. I agree the situation on ARMs isn't ideal. It's really not any worse than the policies of the competition, but I do generally agree people should be able to do whatever they want on the hardware they buy.
But, it seems like GRUB really should be able to get their code signed. They aren't the ones distributing the device that does the signature checking. Matthew Garrett basically said the same thing, although basically called that a legal loophole.
Retail motherboards and graphics cards don't need to meet these requirements. Only complete systems from OEMs do. I think the Windows logo for those products only means they've gone through WHQL testing.
Thank you. I don't know where Matthew Garrett that crazy idea either. Once the BIOS passes control to the bootloader, and the bootloader passes control the OS, the BIOS no longer dictates what runs on the system.
Slashdot Mirror
Sure, it seems like an interpreter would be required here, but I was more concerned about the logic surrounding the interpreter to create the secure sandbox, rather than the interpreter itself. If security wasn't a goal, it doesn't sound too hard. Maybe even if made people specifically write their option ROMs to run in this interpreter it wouldn't be so bad. But, without having any experience in this area at all, it seems like it would be difficult to set up a sandbox to run any old option ROMs that people wrote expecting to be executed directly. If you could do it, it seems like it would take a non-trivial amount of code. I doubt OEMs would want to spend system flash space on it, given this is a problem that goes away once people switch to signed UEFI device drivers.
Somewhat interestingly, UEFI BIOS already has an interpreter. The UEFI specs created something called EFI Byte Code to allow people to create architecture-independent UEFI device drivers. But, they were just trying to prevent add-in cards from having multiple copies of device drivers- they weren't trying to execute each driver in a sandbox.
Anyways, this is just a thought experiment (albeit a somewhat interesting one- I kind of like the sandbox idea, I just don't think it will happen). As I said, OEMs are explicitly forbidden from executing unsigned UEFI device drivers and/or legacy option ROMs when secure boot is enabled.
I think we're just having a terminology/interpretation difference. You're saying SMI handlers are "in" the BIOS, I'm saying SMI handlers are "set up" by the BIOS. I'm not quite sure what you mean by saying they're "in" the BIOS itself. As I said, SMI handlers are certainly loaded by the BIOS during boot. The BIOS is the only entity that can load SMI handlers, and its supposed to lock SMI code prior to executing untrusted option ROMs or bootloaders (otherwise you have a pretty nasty vulnerability on your hands).
But, I wouldn't call SMI handlers "part of" the BIOS, partly because they don't perform the same function as BIOS, but perhaps more importantly because they run in a logically separate execution environment from the BIOS (i.e., System Management Mode).
But, the distinction between "in" versus "set up by" the BIOS isn't particularly important. I'm still curious about your previous claim that you could use SMI to do code signing checks after you've passed control to untrusted code outside BIOS/boot firmware. As I said in my previous message, its not clear to me how that would work. What would trigger the SMI handler to perform the check?
I'm pretty sure it will be a problem for the tiny number of people that will attempt to do this on a new OEM-purchased Win8 box.
I have to admit, I have no idea what you're talking about when referring to some sort of sandboxed environment in BIOS. Nobody does that now, nor is it clear from me that it's even be possible to secure up a secure sandbox to execute opROMs in. Even if it is possible, it seems like it would be rather difficult to implement, so OEMs wouldn't be interested in wasting their precious system flash space on it.
While I'm skeptical of any sort of secure sandbox, you can have compatibility layers. In UEFI BIOS, you can load Compatibility Support Modules (CSM) to execute legacy option ROMs. But, this isn't a secure way to execute untrusted code- its just there for compatibility with legacy hardware/firmware. So, OEMs are explicitly prohibited from loading CSMs when secure boot is enabled.
My point is that your video card isn't going to work in the preboot environment if you don't have a signed UEFI device driver. Could an OS potentially work around that and get the video card working under the OS? Maybe, but even then you're still not going to be able to go into the BIOS settings in preboot to turn off UEFI secure boot, because video isn't going to work there. I don't know for sure, but I suspect Windows would have hard time using a video card if its option ROM wasn't executed during boot.
So, the moral of the story is just if you buy a Dell Windows 8 system, and want to toss in an old video card, make sure you turn off secure boot *before* you take out the video card the system came with (that is, if it has a discrete video card at all).
UEFI secure boot isn't incompatible with your idea. You'd still need some standardized interfaces for signing code and verifying that code at boot. The main differences would be trust anchor management and the signing process. But, the architecture of UEFI secure boot is absolutely compatible with the idea that the device owner can determine what code should run. Microsoft's requirement for x86 systems pretty much mandates it. It's Microsoft's requirements for ARM systems that are incompatible.
But, your proposed solution is awful for the vast majority of people. How are novice users going to sign the boot code on their systems? Your saying every single person is going to have to securely manage a private signing key for every device they have. To update code, that user is going to have to pull out that private signing key, sign the code they want to update their system to run, and then update the code. For home users, that sounds incredibly complicated. For corporations, it doesn't lend itself well to automation. It's only good for enthusiasts.
What's the alternative? For the vast majority of people, its much, much better to have a small set of trusted third parties that will sign boot code. I know I don't want to have to keep a signing key in a protected place, and have to take it out and use it to sign code whenever I want to update an option ROM or bootloader.
The compromise on x86 systems seems like a good approach. Microsoft will run a signing service, but if people want to swap out the trust anchors and stand up their own signing service, they can. That's not going to be easy for people to do, but I really don't see an alternative. What am I missing?
I fully intend to keep UEFI secure boot turned on whenever possible. It's a very useful security feature. We're already seeing some malware that modifies the Windows bootloader to get around 64-bit Windows code signing checks.
I'm saying my systems run a video card option ROM (which is the legacy equivalent to UEFI device drivers) that is stored in flash memory on the video card. It's not running a generic video card driver that is stored on the motherboard flash. To the best of my knowledge, all systems today run a video card specific option ROM at boot.
OK, but that's more of an OS driver thing, isn't it? I'm still a little concerned that you might need to run a card-specific device driver to help the card itself boot up while the computer is booting up. If a generic video driver would work to give BIOS basic video functionality in preboot, why wouldn't we be using those now? In the legacy BIOS world you only have 640x480 resolution with 16 colors even with card-specific option ROMs.
What do you mean in secure boot the "option of booting alternative bootloaders is impossible?" It's not. Secure boot just says that alternative bootloader needs to be signed. Now, you're right that there would be a security problem for Windows if an alternative bootloader tried to load Windows without checking its signature. But, there are other ways to deal with that potential problem other than simply forbidding alternative bootloaders. Things like GRUB can't boot Windows directly anyway- it just starts the Windows bootloader, whose signature would be checked by the UEFI BIOS as part of secure boot.
Exactly. I don't know how this transition will go, because it really hasn't started yet. I think the only UEFI device drivers are drivers which are embedded in the BIOS (e.g., like a UEFI device driver for integrated video on a motherboard). So, we really don't know yet how aggressive video card vendors will be at moving to UEFI device drivers, and, just as importantly, signed UEFI device drivers. I'm guessing video cards will ship with signed UEFI device drivers well before Win8 starts shipping, but I know I've put in cards that are several years old in some of my systems, either as a temporary measure if a card goes bad or just to use spare parts in systems that don't need fast video.
First, we just have a terminology difference. I use "BIOS" as a fairly generic term for the boot firmware on the motherboard that executes at power-on. UEFI isn't really the right term for that, because UEFI is just a standard set of interfaces that UEFI-compatible boot firmware can implement. If its important to distinguish between old and new, I'll usually write "legacy BIOS" or "UEFI BIOS".
Second, there definitely are drivers for BIOS. In the legacy BIOS world they're called Option ROMs. In the UEFI world, they're called device drivers. You need those if you want to use a device in the preboot environment. Not every device needs an option ROM. You're not going to need to use, say, a TV tuner in preboot. But, you do want to use SATA/IDE controllers do you can boot of a drive, or maybe you want to use a network card to boot off a network server using PXE. Video is certainly important in preboot too, since you might want to go into the configuration settings and change stuff around. The only question is if you can use some sort of generic UEFI device driver, or if you need a card-specific one.
Third, secure boot ENDS when Windows starts booting. Mainly, UEFI secure boot verifies signatures on UEFI device drivers and the bootloader. Once the bootloader runs, UEFI secure boot is essentially over. The UEFI BIOS is no longer in control of the system, and its up to the bootloader and the OS to check signatures at that point.
Sure, but all that is tangential. UEFI secure boot itself doesn't say anything about how non-EFI executables are handled during boot. If a signed OS loader doesn't want to verify a signature on the OS kernel, it doesn't have to. It might want to, so it can't be used as part of malware, but that's not a part of UEFI secure boot.
Liability is a potential problem with UEFI secure boot, although a problem for whoever is signing UEFI executables (i.e., Microsoft). That's probably why no one else has offered to set up a signing service.
SMI handlers aren't really part of the BIOS. They're set up by the BIOS, but they're not really BIOS code. SMI handlers either have to be invoked by whatever software is controlling the system or by certain hardware-driven mechanisms that don't seem to apply here. There might be a some weird way to jerry-rig SMI handlers to do what you're describing, but its far from clear to me that that's possible.
Interestingly enough, in the UEFI world there is some BIOS code that lives on after the OS takes control. UEFI provides a set of run time services to the OS. Again, these have to be called from the OS. But, there really isn't anything comparable in the legacy BIOS world. As I said, SMI handlers aren't really BIOS code. ACPI code is slightly more comparable, but still not quite the same thing,
By the way, there is something interesting research into the nasty kinds of malware you can create if you can load malicious SMI handlers. One way an attacker could do that would be to flash a malicious BIOS which loads malicious SMI code. But, the Windows 8 requirements include some protections on the BIOS, including requiring signed BIOS updates.
Honestly, I think you have it backwards. I think its less that UEFI secure boot is most advantageous to Microsoft and more that it happens to be inconvenient to Linux. The open source community, for both good and bad reasons, has made a series of decisions that make a signed code model difficult to implement (and stomach).
Forgetting about who runs the signing service for a moment, do you have a better idea of how to solve security problems with boot firmware? It's one thing if you don't like the implementation of UEFI secure boot, but you seem to be suggesting that the entire concept behind UEFI secure boot benefits Microsoft. If that's true, what is the alternative?
I don't think Microsoft particularly wanted to run the signing service. It has already given them headaches, and it opens the door for a lot of potential problems with liability. But who else was going to run it? The UEFI Forum never gave any indication they were willing to run it when the specification was being written. Given they were the natural choice, I think it's pretty clear that means they explicitly didn't want to run it. Who else was going to run it? Verisign? I'm sure that would have gone over much better... Even if things did go that route, who was going to pay for it? If Microsoft funded it, which they probably would have had to, people would have just assumed Verisign was going to do whatever Microsoft told them to.
Red Hat and Canonical have never given any indication they were willing to run a signing service either. And people in the industry did ask them to. I'm not sure they ever explicitly said no, but they certainly never said yes either.
I don't think there are any discrete video cards with UEFI device drivers. Certainly there are none with signed UEFI device drivers, seeing as there isn't anyone signing those yet, and that's really what you need in a UEFI secure boot system. That will presumably quickly change as we approach the release of Windows 8, but there's still the problem of new systems running old video cards. That's exactly the situation I was imagining when I initially rose this issue.
RAID cards aren't really an issue. If you want to boot off an old RAID card, but it doesn't have a signed UEFI device driver, you're going to be able to go into the BIOS settings and turn off secure boot. I don't think there's a way around that. But, Microsoft's requirements for x86 systems say that users have to be able to do that. But, the idea is that there are some UEFI device drivers that you're going to need to even turn off UEFI secure boot. Some things, like the keyboard controller, are already embedded in the BIOS, so they're not problematic. But the video card might be a special case. If you want to muck with BIOS settings, you're going to need video working. But, if video cards need device-specific UEFI device drivers to function, it creates a problem. To get video working, you may need to run an unsigned video card UEFI device driver (or to run a legacy option ROM), you need to turn off secure boot. But, to turn off secure boot you'll need video working.
I figure there are two possibilities: either 1) you're right and you can have generic UEFI device drivers for video cards, or 2) there's going to be a slightly painful transition process. It might be that people that want to swap in an old video card in a new Win8 system will need to disable secure boot before removing the video card that same with their new Win8 system. Retail motherboards will probably ship with UEFI secure boot turned off by default (if they support it at all), since the Win8 requirements don't apply to them. In the end, I doubt it would impact very many people. How many people are buying new desktops at retail and putting in old video cards?
The threat you identified isn't special to GRUB or even bootloaders. Any EFI executable could potentially be "hiding" a malicious bootloader, or some other malicious payload that mucks with the way Windows boots up. I think you'll deal with this potential threat exactly one way: if you find out a previously-signed EFI executable is doing bad things, you'll add the signature associated with that executable to the "forbidden list" (essentially revoking the signature), and you'll go after whoever submitted that executable for signing.
That doesn't necessarily help you if OS-present malware modifies the loaders and the kernel. On the next boot you could load a modified kernel, which isn't going to be detected because you'll also have modified loaders. But, a lesser-known fact about UEFI secure boot with Windows8 is that Microsoft's OS loader is going to be signed with a different key than all other EFI executables. While I don't know exactly how its intended to work, its presumably intended to help block the sort of attack I think you are imagining. But, at the very least, GRUB can't directly load Windows. Instead it would launch the Windows 8 loader, and the UEFI BIOS should verify the signature at that stage. Presumably a bootloader like GRUB could be modified to directly load Windows, but that might be enough to land you on the forbidden list if someone catches you.
I don't know. All that's basically just a guess on my part.
I think you're absolutely right though that there's a tension between security and flexibility here.
You make an interesting point about service processors. Generally speaking, it should be difficult for malware to use that vector, since service processors (should) authenticate any requests (using a digital certificate, or at least a password). Still, a strict interpretation of Microsoft's requirements say that physical presence is required, and remotely changing a BIOS setting via a service processor isn't physical presence. Will OEMs write their BIOS so you can't change that setting via something like AMT? Maybe. I don't really know. I honestly don't see a compelling need to be able to turn it off remotely, so it seems like a bad idea to let it be remotely accessible by any mechanism, including a service processor. If you're running Windows, the only reason you might want to turn off secure boot is to use an old add-in card, in which case you're already physically at the box. If you're running Linux, and they don't get their act together to play nicely with secure boot, then you're just going to turn off secure boot when you initially set up the system.
I really don't know what Windows recovery tools use. It seems like those wouldn't be executing in the EFI environment and would instead load their own generic device drivers. I know MS wants to be able to use UEFI interfaces to display stuff on screen, but I think that's primarily for their bootloader (which is an EFI executable).
There's certain a handful of things you might want to do in the preboot environment. Things like BIOS or card flashing are generally initiated from OSes these days, although a lot of products can probably do it in preboot, or at least DOS. You'd certainly be able to do those things on a UEFI secure boot system if you had UEFI-compatible cards. The question is can you do those things easily on a UEFI secure boot system when you don't have UEFI-compatible cards. This is a potential problem that would only impact a small percentage of users. How many people go out and buy a new computer, and then toss in an old add-in card that is used during boot (like a SATA/RAID controller or video card)? Some do, but not a lot.
Part of me is tempted to say that you must be right, and that there's got to be a generic video UEFI device driver to fall back on. But, if that were true, why wouldn't we just use generic video card option ROMs today? As you said, there's really no need for full-fledged video in the preboot environment anyway. But I know my systems all execute a video card-specific option ROM during boot. Many of the other boot-critical devices on a system are on the motherboard and have option ROMs that are embedded in the BIOS (e.g., keyboard controller, USB, SATA, etc.). Things like mice are different sorts of devices. Those don't have option ROMs that execute on the host CPU. They have their own firmware running on microcontrollers inside the mice, but no option ROMs read out during boot and executed on the host. USB controllers, on the other hand, definitely have option ROMs (but again, they're usually embedded in the BIOS).
By the way, these devices don't need secure chips. The signature verification is done by the host CPU, not anything on the card/device. The card/device just needs to have flash memory that contains a signed UEFI executable. The BIOS will find that during the boot process, verify the signature, and execute it.
Maybe this is a stupid question, by why would every distribution have to get their GRUB build signed? Is GRUB distribution-specific now? If so, then I don't see any way around signing every build. For something like UEFI secure boot to work, you need to sign all code that executes during boot. But, if you're saying that because of some idea that GRUB has to verify the OS, I don't see where that comes from. There's no requirement to do that.
And, by the way, of course the signing key wouldn't be distributed. That would completely invalidate the security of UEFI secure boot. There's only one signing key per trust anchor. UEFI secure boot doesn't have a way to do certificate chaining. That's why Microsoft has to sign everything- there's no mechanism to give other entities signing keys rooted in Microsoft's trust anchor.
I agree the entire UEFI secure boot is slanted in Microsoft's favor, but that's only because they're the only player in town. No one else has offered to set up a UEFI executable signing service.
RAID cards were usually the thing I pointed to when people were worried you weren't going to be able to turn off UEFI secure boot. I fully expect you'll need a signed UEFI device driver for your RAID card if you want to boot off of it.
Hopefully you're right about a basic UEFI device driver, otherwise I think people will have problems before UEFI-compatible add-in cards become pervasive. But, in a UEFI world I don't think you have the same concerns about no video until OS boot. UEFI systems running Windows 8 will boot much faster than today's systems, making the time before the OS device driver kicks in much less.
I doubt that. There's a lot less code in boot firmware than in most OS-level software, meaning fewer opportunities for vulnerabilities in that code. And, probably more importantly, a lot fewer ways to inject code and try to run it. There's actually a paper from a couple years ago that found a vulnerability in the way that Intel signs their BIOS updates. That's essentially the sort of vulnerability you'd need to find. But, Intel did something sort of stupid: they signed all the BIOS code, but they didn't sign the graphics that appeared on-screen during boot. Someone found a vulnerability in the code that processed the graphics during boot which allowed for a buffer overflow exploit. Now they know better. I'm sure there's many more ways to get things wrong, but I think the code will be locked down pretty well. I don't expect to see very many exploitable vulnerabilities in UEFI BIOS that would compromise the security of UEFI secure boot.
Microsoft wants UEFI secure boot so people can securely boot into Windows. If you're using a different bootloader to load Linux, Microsoft doesn't care if your system gets infected with a rootkit. But, the preboot environment doesn't know what OS is going to be loaded, so it has to check signatures on anything. Right now the only entity that has stepped up to the plate to sign UEFI executables is Microsoft. No one else has they would set up an alternative signing service. If Red Hat and Canonical joined together to create one, they might actually be able to get the major OEMs to install the trust anchor on their products.
I've only seen the mid-December draft of the Windows 8 requirements, but it's my understanding that that draft significantly loosened the requirements for UEFI secure boot. Or, perhaps more accurately, is significantly strengthened the requirement for user-control of the secure boot setting and the trust anchors on x86 systems. That might indicate some reluctance to accept third party trust anchors. Or maybe they didn't expect any other UEFI executable signing services, since nobody else said they would do it. Or maybe at first they thought it was more appropriate to leave the decision on configuring secure boot to OEMs (a position they obviously don't hold now, given the strict requirements on both x86 and ARM systems).
UEFI secure boot is a perfectly legitimate mechanism to secure the boot process. That's really important, because any code that executes before the OS can insert a rootkit that would be very difficult to detect. I haven't heard of an equally good alternative that is suitable for the mass market. So, I really think people should be applauding Microsoft for what they're demanding on x86 systems. I agree the situation on ARMs isn't ideal. It's really not any worse than the policies of the competition, but I do generally agree people should be able to do whatever they want on the hardware they buy.
But, it seems like GRUB really should be able to get their code signed. They aren't the ones distributing the device that does the signature checking. Matthew Garrett basically said the same thing, although basically called that a legal loophole.
Retail motherboards and graphics cards don't need to meet these requirements. Only complete systems from OEMs do. I think the Windows logo for those products only means they've gone through WHQL testing.
Thank you. I don't know where Matthew Garrett that crazy idea either. Once the BIOS passes control to the bootloader, and the bootloader passes control the OS, the BIOS no longer dictates what runs on the system.