FSF Does Want Secure Boot; They Just Want It Under User Control 210
Yesterday, we ran a story with the headline "Free Software Foundation Campaigning To Stop UEFI SecureBoot." It's more complicated than that, though, writes gnujoshua: "We want computer manufacturers to implement Secure Boot in a way that is secure. If a user can't disable Secure Boot and they are unable to sign their own software (e.g., bootloader, OS, etc), then we call that particular implementation 'Restricted Boot.' We don't want computer makers to implement Restricted Boot. We want them to implement Secure Boot and to provide a way for individuals to install a fully free OS on their computers. Many computer makers are implementing UEFI Secure Boot in this way, and we want to continue encouraging them to do so." The complete text of the statement they'd like people to sign reads: "We, the undersigned, urge all computer makers implementing UEFI's so-called "Secure Boot" to do it in a way that allows free software operating systems to be installed. To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice. We commit that we will neither purchase nor recommend computers that strip users of this critical freedom, and we will actively urge people in our communities to avoid such jailed systems."
What problem does it solve? (Score:5, Interesting)
What problem does Secure Boot solve, other than Microsoft's "other OS" problem?
Re:What problem does it solve? (Score:5, Interesting)
Re:What problem does it solve? (Score:5, Interesting)
The boot sector issue has already been solved by most BIOS by (optionally, under user control in the BIOS configuration) preventing writes to the sector. The only time you need to unlock it is when you want to update the bootloader (relatively rare). I'm still at a loss for the value-add presented by secure boot.
Re:What problem does it solve? (Score:5, Interesting)
The value is that it's DRM. Obviously this has no value to any computer user, but it has value to the people who try to force the proprietary OS on you (Microsoft).
Restricted Boot by definition insecure (Score:5, Interesting)
Think about it a moment. The ultimate piece of malware would be one that can make your computer run software of someone else's choice, prevent you from running software other than the malware, and block you from removing the malware from the system or preventing it from running. Every piece of malware out there tries to do this, with varying degrees of success. Look at the malware that tries to disable anti-virus/anti-malware software.
Now, Restricted Boot would give someone else control over what software could boot on the machine, and prevent you from changing that list of authorized software. You cannot authorize software you want to run to run, nor can you remove authorization from software you do not want to run. You can't influence what runs at boot, you can't alter it's operation. In short, you've bought into every malware author's wet dream: a system where they can do anything they want and the user can't do a thing about it.
And if you think "Oh, but all the system software would be signed by Microsoft, so how would the malware authors get the keys to authorize their software?", think about this: Microsoft certificates have already been compromised. The bad guys have already gotten access to what they need to sign software with legitimate Microsoft keys. The certificates used by the Flame malware [sans.edu] were only some of the most recent. And I'd note this older bulletin [microsoft.com] describing a situation where Verisign issued legitimate certificates issued to Microsoft to black-hats with no association with Microsoft. The bad guys obtaining the private keys to sign software isn't a theoretical discussion, it's already actually happened.
Re:Restricted Boot by definition insecure (Score:3, Interesting)
The master keys have not been compromised. Only one of the older ones which are derived from the master for signing software under XP. MS has revoked that particular key and replaced it with another one. The bad guys also forged one of Adobe's for running signed flash applets as well but Adobe has replaced it. The master key in both situations are still secure.
Re:What problem does it solve? (Score:5, Interesting)
Many viruses modify either the OS bootloader or low level drivers (SATA, PCI bus etc). By loading so early in the boot process they have full and unrestricted access to the entire machine, making them excellent and difficult to remove rootkits.
This isn't just a Windows problem either, all operating systems are vulnerable to the modification of core boot files.
One of the only cool things about Windows 7/8 do is have protected kernel paths combined with signed drivers in x64. This makes the job of a rootkit much harder and is one of the only arguments to give for die hard XP users who are chaining their old systems by their ankles for life afraid to upgrade.
It is not about DRM at all and is not used. A signed bootloader with the kernel path and device drivers prevent the next aulurion worm/rootkit from taking shape as nothing untrusted can run from the kernel.
It is great for corporate customers. If this could be used for gnu/Linux the situation would be great for security.
Re:What problem does it solve? (Score:5, Interesting)
1. It heads off anything else that is good enough being installed on to PC hardware that Microsoft deems threatening.
2. It's a lovely form of DRM Microsoft is probably salivating at. It means that future hardware can explcitly refuse to install previous versions of Windows even if it is possible.
3. Manufacturers will probably love it because there is the possibility that they can enforce what hardware can or can't be installed in the system. The net result is that hardware will have an artificially shorter life from now on and things will get a whole lot more expensive for users and for any prospective entrants into the hardware business. In fact, it will be downright impossible. Expect this to turn into one God-awful mess.
4. Everyone talks about Linux and other operating systems, but it will have an interesting effect on virtualisation. Microsoft has long been deeply uncomfortable about non-Microsoft systems running Windows virtual machines. The net effect is that these days you can run NT, Windows 2000 or Windows 2003 and prolong their life on new hardware by virtualising. With 'Secure' Boot Microsoft gets to dictate what hypervisors will run on hardware in future and they'll be able to control the life of their current and future operating systems. Expect to install Windows 8 on Windows Server 2015 with Hyper-V? Nope, sorry. Windows will probably also end up refusing to run as a guest on any hardware it doesn't like.
Basically, it's the end of the PC platform. I don't know whether Microsoft realises it but we'll all look back on this as the beginning of the end for them.
Secure Boot is *not* (necessarily) DRM (Score:4, Interesting)
Being categorically against Secure Boot is akin to be categorically against digital encryption and signing in general just because they are tools that are sometimes used to create DRM. DRM is bad. Secure Boot without user/owner key control can make it worse. The FOSS community should embrace Secure Boot but fight for key control.
Used properly, Secure Boot will make FOSS systems more secure. It is much better to add security measures *before* they are needed rather than after. We have generally been ahead of the curve security-wise for decades. Embracing Secure Boot (with user key control) will help us stay ahead of the curve. If we instead shun Secure Boot there is a very real danger that we will lag behind.
Re:So they want the status quo then? (Score:4, Interesting)
Can you boot whatever you want on Windows RT thingy? No. RMS and FSF are right, you are wrong.
Re:What problem does it solve? (Score:5, Interesting)
The BIOS exists in the mother board's firmware. When you turn on the computer the BIOS is what is first executed. BIOS is what searches for drives that are bootable by looking for a first sector with 0x55 0xAA @ byte positions 510 & 511 (offset from pos 0, the first byte). If you tell the BIOS not to allow writes to any boot sectors then there can be no writing to the OS bootloader which starts off in that boot sector. That sector's 512 bytes (minimum) get loaded at seg:off 0000:07C0h on x86 systems, and the code begins executing in 16 bit real mode. In that 466 bytes of data (512 - 2 - 64 for partition table) it's a pretty tight fight, but I've managed to squeeze in a hash algorithm and a fingerprint along with the loader code for my own OS. If my boot sector is write protected, then it can't be modified, and it can verify the early environment kernel it loads hasn't been tampered with as well. From my early kernel I can perform signature verification of all other code loaded -- From drivers and applications to even other OS's sectors (for multi-boot). Signatures are either embedded in the executable as part of my extension to ELF or in a separate table in the case of the multi-boot OS sectors. Furthermore, the /boot/ system can be stored on read only media, such as a CD ROM, to prevent any tampering when the OS isn't running (you can do this with Linux too). This is how I secure even x86 systems w/o the option to disable boot sector writes -- Boot a CD that boots the OS.
EFI requires a FAT 32 file system to store your boot data within. Other FATs like FAT16 are supposed to be supported, but in my experience only FAT32 works reliably. This is nice because the BIOS can load your whole early kernel image into memory, set up protected mode and begin executing the kernel image at its desired memory location without requiring you to write bootstrap loader that does this. EFI sucks a bit because I'll miss the old real mode and the ability to install old OSs like DR DOS & DOS 3.1, and miss all those classic graphics modes, but that's a lot of baggage (service interrupts) for BIOS to have to support, and it's all a bit buggy anyway from BIOS to BIOS...
UEFI, SecureBoot, adds the requirement that the boot image be cryptographically signed with a key stored in the firmware. However, what good does it do to cryptographically sign the kernel image and verify it at boot if the OS doesn't take over and cryptographically verify all the low level drivers, etc? It's not any good, that's what. So, the OS has to support that same sort of signature system that I can achieve on an x86 without UEFI's help, given that BIOS lets me disable writing to the boot sector, or I boot from a read only media (CD/DVD).
There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running. Drives would have to support a "mark read only" standard for sectors that the EFI or the OS itself could use to prevent changes to data on disk. The point is that the same exact benefits UEFI provides can be provided by simply setting sectors "read only" at boot -- No signature chains required in the damn BIOS at all. OS code will be responsible for verifying its own signature chains anyway, so the OS could be written in such a way that it's early kernel doesn't ever need to be modified -- Public Key Crypto could be used in the 1st stage kernel to allow any 2nd stage to be verified once the 1st stage is loaded, and different signed 2nd stages could be created for kernel upgrades. To keep the whole system secure only the 1st stage would need hardware write only protection. Additionally, the write-only method would allow any OS be installed without requiring clumsy crypto-key management -- End users could set a BIOS flag: Allow new OS Installation During Next Boot: [ON | OFF] much easier than looking up and entering a huge hex key -- What are the chances you'll mistype one char? Ugh, THAT's going to raise the bar to i
Comment removed (Score:3, Interesting)
Re:Headline is disingenuous (Score:4, Interesting)
Problem with secure boot is it creates a whole new attack vector. Attempts to solve one problem by creating a new one. When the purpose of attack is to deny access to the machine, what better way than to trip secure boot into action and prevent the machine from running. So you attack software doesn't have to do much of anything at all, just be difficult to remove without a full reinstall and it can leave the rest of the attack to secure boot.
Re:What problem does it solve? (Score:4, Interesting)
It is not about DRM at all
Not at all you say? Not at all about DRM...then what happened here:
https://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/ [softwarefreedom.org]
A signed bootloader with the kernel path and device drivers prevent the next aulurion worm/rootkit from taking shape as nothing untrusted can run from the kernel.
It also ensures that users cannot do this sort of thing:
http://www.evilavatar.com/forums/showthread.php?t=7650 [evilavatar.com]
Or even something as simple as this:
https://en.wikipedia.org/wiki/Decss [wikipedia.org]
See, the distinction here is subtle. If the user can modify their kernel, but only when their computer is a special "modify the bootloader" mode (or if the user can sign their own bootloader etc.), then the security argument makes sense. If the user cannot, then there is no security argument, because forbidding the user to modify their own system has nothing to do with security -- unless by "security" you mean "DRM."
If this could be used for gnu/Linux the situation would be great for security.
Re:What problem does it solve? (Score:4, Interesting)
If you tell the BIOS not to allow writes to any boot sectors then there can be no writing to the OS bootloader which starts off in that boot sector.
Not true I'm afraid, modern operating systems that talk to the hardware directly rather than using BIOS calls will ignore this setting.
There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running. Drives would have to support a "mark read only" standard for sectors that the EFI or the OS itself could use to prevent changes to data on disk.
So nothing but a change a to the SATA standard and the requirement of having a new HDD that supports the feature. Plus the whole point about rootkits is that they have equal power to the BIOS/EFI/OS, and besides which they don't always target the bootloader anyway. Many variants of the fake anti-virus scam that was rife a few years ago targeted the legacy IDE driver, for example, so protecting the bootloader wouldn't help.
OS code will be responsible for verifying its own signature chains anyway
Wouldn't help. One of the tricks rootkits use is to present the OS with a valid signature when verifying a driver, but then let it load an infected copy or replace the code with their own in memory. That is one reason why they are hard to detect - when an antivirus scanner reads the driver file from disk it gets the clean copy and does not see an infection.
However, what good does it do to cryptographically sign the kernel image and verify it at boot if the OS doesn't take over and cryptographically verify all the low level drivers, etc?
Fortunately they thought of that and SecureBoot will verify bundles of low level driver files as well. Otherwise, as you point out, it would be useless for any OS that doesn't use a huge monolithic kernel.
I mean, FAT32 is Microsoft's Proprietary File System, and parts of it are patented: Short to Long name mapping, for example.
Which is why no long file names are required, and everything that needs to be implemented can be done so with patent-free open source code. That is why FAT32 is so common in embedded systems and consumer products - widespread compatibility, free implementations and no patents to worry about.