Slashdot Mirror

← Back to Stories (view on slashdot.org)

FSF Does Want Secure Boot; They Just Want It Under User Control

Posted by timothy on from the where-the-devil-is dept.

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."

10 of 210 comments (clear)

  1. What problem does it solve? by Gothmolly · · Score: 5, Interesting

    What problem does Secure Boot solve, other than Microsoft's "other OS" problem?

    --
    I want to delete my account but Slashdot doesn't allow it.
    1. Re:What problem does it solve? by Anonymous Coward · · 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).

    2. Re:What problem does it solve? by AmiMoJo · · Score: 5, Informative

      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.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    3. Re:What problem does it solve? by Billly+Gates · · 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.

      --
      http://saveie6.com/
    4. Re:What problem does it solve? by VortexCortex · · 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

  2. So then they're fine with Windows 8 by Missing.Matter · · Score: 5, Insightful

    So then they're fine with the way Windows 8 handles it? Because that's exactly what Microsoft demands of computer manufacturers who want to be certified for Windows 8.

    Windows RT is a whole different matter, but Windows RT also accounts for about 0% of the tablet market right now. Why is the FSF making all this noise now, when Apple has been happily locking down the iPad since 2010? Microsoft is just joining the party, and it seems a little late for FSF to get self-righteous about it.

    But more power to them I guess. It seems like a tough fight, however, when users have a great deal of choice between tablets (both locked and unlocked), even with the locking down of certain hardware.

  3. Re:Its all in the language by cwebster · · Score: 5, Insightful

    'Jailed' is the popular nomenclature. What do you think 'jailbreaking' means on your mobile device? It means unlocking the bootloader so it will boot unsigned or differently signed kernels. Doesnt sound patronizing to me, it sounds descriptive.

  4. Re:Its all in the language by Anonymous Coward · · Score: 5, Insightful

    Weaslly words? The lockdown in the name of "Secure Boot" is a weasel word. Calling it what it is in its implementation on ARM, "Restricted Boot" is not weasely--it's correct (cf. "Digital Rights Management" vs. "Digital Restrictions Management")

  5. Restricted Boot by definition insecure by Todd+Knarr · · 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 were only some of the most recent. And I'd note this older bulletin 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.

  6. Re:Its all in the language by PolygamousRanchKid+ · · Score: 5, Insightful

    Most people buying a computer will hear "Secure Boot", and yell, "Good! Secure! War on Terror!"

    When they hear "Restricted Boot", they will scream, "Bad! Restricted! War against my freedom!"

    It's those folks who this wording is for, not Slashdot folks.

    --
    Schroedinger's Brexit: The UK is both in and out of the EU at the same time!