Forgot your password?
typodupeerror
DRM Operating Systems Your Rights Online

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

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Gothmolly (148874) on Sunday December 30, 2012 @02:24PM (#42427475)

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

    • by Great Big Bird (1751616) on Sunday December 30, 2012 @02:27PM (#42427489)
      In days gone by a 'boot sector virus' was a real danger. This would seemingly prevent that.
      • by macemoneta (154740) on Sunday December 30, 2012 @02:30PM (#42427507) Homepage

        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.

        • by Anonymous Coward on Sunday December 30, 2012 @02:46PM (#42427593)

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

          • by mjg59 (864833)

            It's not DRM. You can turn it off in the firmware and there's no way for the OS to know that you did.

            • Re: (Score:2, Informative)

              by Anonymous Coward

              Wrong.

              1. You can turn it off on x86 - not on ARM

              and the biggy:

              2, Windows can tell if it was booted in secure mode or legacy mode.

              So basically you couldn't be more wrong. Congratulations.

              • by mjg59 (864833)

                How does Windows know whether it was booted in secure mode? It makes the EFI GetVariable() call. Which is a function pointer handed to it by the firmware. Which you can modify if you're running untrusted code. So, no, Windows can't tell.

                • by spitzak (4019)

                  The GetVariable() call returns a decryption key that the hardware calculated. If secure boot is turned off then it returns the wrong value. Your patched version cannot return the correct value because you do not know it.

                  Actually the "value" is the state of the decryption chip, not anything that can be read. Either you have to get the decryption chip into the same state (supposedly impossible unless you know the master key, which would just let you sign a bad copy of Windows anyway), or you would have to fin

                  • by mjg59 (864833)

                    "The GetVariable() call returns a decryption key that the hardware calculated"

                    No it doesn't. It returns a 1 if the firmware claims to have booted securely, and a 0 if not. You're thinking of Measured Boot, not Secure Boot.

        • by AmiMoJo (196126) * <mojo@NOspAm.world3.net> on Sunday December 30, 2012 @02:50PM (#42427611) Homepage

          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.

          • by Billly Gates (198444) on Sunday December 30, 2012 @03:04PM (#42427681) Journal

            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.

            • by segedunum (883035) on Sunday December 30, 2012 @03:29PM (#42427791)

              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's not a case of being afraid to upgrade. It's the fact that users, companies and organisations have software and infrastructure that runs and is tested on XP and there is zero benefit to them changing it. Kind of like how a great deal of mainframe code is still written in COBOL. There is no benefit to rewriting it and people do not have the time or the resources. You might not like that but that's the real world.

              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.

              Anything can be deemed to be untrusted, that's the problem. I'm afraid the rootkit/virus/security angle to this stuff is just an excuse, plain and simple.

              It is great for corporate customers.

              It's a disaster for corporate customers. They face a future of new hardware refusing to boot existing versions of Windows or any other operating systems, enforced upgrades and a spiralling in costs, licensing and otherwise. A rootkit is the least of their worries.

              • by AmiMoJo (196126) *

                It's not a case of being afraid to upgrade. It's the fact that users, companies and organisations have software and infrastructure that runs and is tested on XP and there is zero benefit to them changing it. Kind of like how a great deal of mainframe code is still written in COBOL. There is no benefit to rewriting it and people do not have the time or the resources. You might not like that but that's the real world.

                The key difference is that people tend not to use their mainframe running COBOL code to browser the internet at lunch time. Software for XP tends to be end-user software, on vulnerable workstations.

                Windows 7 does provide a full XP virtual machine as well.

                • by segedunum (883035)

                  The key difference is that people tend not to use their mainframe running COBOL code to browser the internet at lunch time. Software for XP tends to be end-user software, on vulnerable workstations.

                  You're missing the point. Corporations have desktop software that they completely rely on that was written for the NT4/Windows 2000/Windows XP era as the desktop market expanded within business through the 90s and early 00s. That reached a critical mass some years ago. I hate to burst peoples' bubbles on this but companies do not spend vast sums on having dedicated teams of people continually upgrading Microsoft software and rewriting their own software to run on new platforms nor do they care about people

            • by betterunixthanunix (980855) on Sunday December 30, 2012 @10:37PM (#42430285)

              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.

              ...and that is a case in point. If this could be used for GNU/Linux it would be great for security; it cannot be, because this is not about the security of the user, but rather the security of privileged "media partners" and other companies. The security that "Secure Boot" is meant to provide is security against secret keys being copied out of RAM by some teenager using a debugger, or cheating in MMOs by people who modified their kernels to defeat anti-cheating technologies, or people who might try to use their computers in ways they were supposed to pay extra to do, and so forth. The adversary in the "Secure Boot" security model is the user of the computer , and that is the problem.

          • by VortexCortex (1117377) <VortexCortexNO@S ... t-retrograde.com> on Sunday December 30, 2012 @04:17PM (#42428059)

            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

            • by BitZtream (692029)

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

              FYI, EFI is more than capable of presenting a BIOS environment to the next stage of the boot process, ask any mac owner.

            • by Rockoon (1252108)

              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.

              You speak later about booting from read only media, but thats part of the problem. Even if you prevent a specific boot sector from being written to, that doesn't tell you or the kernel anything about which bootsector was loaded and executed... and therefore the kernel cannot know that it has, or ever had, full control.

            • There's nothing preventing EFI from having an option one could enable to prevent changes to the bootable sectors while the system is running.

              Well except that you make way too many assumptions. Like EFI will intrinsically (magically) know how all bootable devices past, present, and future work. And it has, and can maintain complete control over all known and unknown interfaces to those devices at all times, and scrub all the calls to those interfaces to prevent any attempts to write to the boot sector. Also, it would magically retain that control whether attached or unattached to the machine (USB stick, Sata Dock). Many of those are either im

            • by AmiMoJo (196126) * <mojo@NOspAm.world3.net> on Monday December 31, 2012 @04:57AM (#42431395) Homepage

              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.

          • Re: (Score:3, Interesting)

            by Gaygirlie (1657131)

            I haven't seen a virus or other malware in YEARS that modified the kernel, bootloader or drivers. The ones I have seen have just attached themselves to the system once the kernel and its drivers are already loaded, and thereby Secure Boot wouldn't do a diddly good against those, and these kinds of viruses/malware packages are a dime a dozen.

        • Anything in a computer that calls itself 'Secure' isn't. Secure Boot is a false sense of security that will lead people to think they are safe. Secure Boot is Microsoft's Security against competition.
        • Re: (Score:3, Informative)

          by mjg59 (864833)

          BIOS boot sector protection has never prevented writes to the MBR unless you're running DOS - any actual OS uses direct hardware access instead of using the BIOS, and so it can't be blocked. It'd be possible for the BIOS to complain that the MBR's been modified, but it has no way of verifying that the partition boot code or the actual bootloader are still secure. Unsurprisingly, malware authors take advantage of this - https://support.kaspersky.com/viruses/solutions?qid=208280748 [kaspersky.com] has a list of modern bootki

        • by BitZtream (692029)

          And then the tiny ass bootsector loads another unchecked block of code that can easily be tampered with.

          The boot sector is .... 512 bytes. That is bearly enough code to do anything useful, it is infact NOT enough space for the code required to boot my FreeBSD machine which has its root on ZFS, as such that process is two stage (well more than that in actuality) and the boot sector really just points to another boot block in an known location that the bios doesnt' give a flying fuck about.

          There isn't enough

          • by BitZtream (692029)

            I posted too soon :/

            It should also be noted that 'boot sector protection' as implemented doesn't work unless you're using BIOS calls to do the write. Once you're using direct hardware access like every OS on the planet does, BIOS doesn't have any part in the process and thus is a non-starter.

    • by segedunum (883035) on Sunday December 30, 2012 @03:22PM (#42427761)

      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.

      • #4 is false. How do propose that Windows will detect that it's not being virtualized if the host doesn't want it to know? Did you think that somehow there is magic dust that makes it so that VMs can't virtualize a UEFI boot environment, secure boot and all?

      • I don't know whether Microsoft realises it but we'll all look back on this as the beginning of the end for them.

        It's the continuation of the end. The beginning of the end was when Minimsft [blogspot.com] was captured and lobotomized.

    • The most important one is that it can gaurantee that the software you're running is the software you THINK you're running.

      Simple example: Someone nasty gets access to your Linux box and installs a rootkit. This includes a modified version of "ps" that won't show the rootkit process(es), making it harder for you to notice it's there.

      If you use a Linux machine that's set up to take advantage of the hardware, you could have it set to, say, only allow software that was signed by Canonical to run on it. This wou

      • You have the right idea, but you're mistaken about the details.

        A rootkit doesn't install a modified version of ps, it modifies the system calls that ps uses. That way the rootkit is able to hide its processes from any program that enumerates processes. (There's much more to it of course.)

        That also makes it easier to defend against. There's no need to prevent the user from running whatever userland code they want. All you need to do is ensure that the kernel you are running is the one you THINK you're ru
    • What problem does Secure Boot solve, other than Microsoft's "other OS" problem?

      Actually, it doesn't even "solve" that problem. Secure Boot is only a potential problem on computers running Windows 8. Once you buy that computer, Microsoft has already collected their "Windows Tax" so even if you install some other OS, it has no effect on Microsoft. They already got their money. This is one of Microsoft's biggest problems. The monopolist mentality is so deeply entrenched that they spend an enormous amount of time and money on stupid crap that is of absolutely no benefit to them.

      More

    • It prevents rootkits from hijacking the OS at bootup. For example malware acting as a hypervisor with your real OS running under it.

    • by hairyfeet (841228)

      Rootkits and the ability to use the built in VM capabilities of modern chips to put malware in a hypervisor? Might want to look up some of the recent black hats, "blue pill" would be a good place to start, where a researcher created malware that using the VM features of the chips made it pretty much impossible to detect or remove since while the OS thought it was running on the chip itself it was actually running on a VM.

      People seem to act like its still the early 90s and most malware is just geeks being do

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

      Secure Boot satisfies Steve Ballmer's compulsive need to piss on the shoes of antitrust regulators.

  • They may say they're committed, but let's hope they put their money where their mouth is the next time a machine they really want comes to market.
  • by Missing.Matter (1845576) on Sunday December 30, 2012 @02:36PM (#42427537)
    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.
    • by Microlith (54737) on Sunday December 30, 2012 @02:40PM (#42427565)

      Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.

      • FSF did complain [fsf.org] about iPad, but it seems they were focused on the DRM aspect of the store. Did they also start a campaign about the locked bootloader? I'm just looking at the practicality of their campaign... if they were really concerned about the practice, perhaps they should have started this campaign before Apple sold 100 million locked down iPads, and turned locking down tablets into an industry standard. Microsoft has carte blanche to lock down Windows RT because they can point any government agency
      • by tuppe666 (904118) on Sunday December 30, 2012 @03:02PM (#42427665)

        Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.

        Well to be fair both the FSF and EFF have been heavily involved after Apple demonised their customers calling them criminals for for jailbreaking Apples Phones(not theirs). Ignoring the fact that those are *electronic* devices and Apple is nowhere near a monopoly (I now its not a good answer for apple users), but again the same groups are not just focused on Microsoft. As for the FSF a quick Google gives this http://www.defectivebydesign.org/blog/1256 [defectivebydesign.org], although the jailbreak DMCA exemption for the iPhone...and not the tablet, have been big news on most technology sites.

      • by segedunum (883035)

        Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.

        Because secure boot is about locking down the PC platform. It's on a whole different level. People can actually chose not to use iOS. They don't exactly get a choice these days not to use a PC.

    • by rekoil (168689) on Sunday December 30, 2012 @02:44PM (#42427585)

      The FSF has been knocking Apple over iOS since its release. http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix [fsf.org]

      • They seem to be more focused on the DRM aspect in your link, and again here [fsf.org]. What I'm saying is that this campaign against one single implementation of a locked bootloader means absolutely nothing if the leader in the marketplace has sold 100 millino locked down units and you've done nothing to stop that. If the FSF succeeds with their campaign, most tablets sold will *still* be locked down. What will they gain by this?

        Think of it like a boss battle, where the boss is supported by many little nuisance h
        • by amiga3D (567632)

          That's one hardware vendor versus dozens. Restricted-Boot will cover all the other hardware vendors. Apple gets to cheat because they make the software for their hardware. All the people that buy Apple know this and in fact it's one of the reasons some of them buy Apple. I own a Mac computer but I bought an Android phone because I don't like the total lock down they have on the iOS devices. I pretty much run anything I want on my Mac so they haven't taken the process to the Computer side of the busines

    • by Xtifr (1323)

      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.

      Only on x86. The MS requirement for user-control over UEFI only applies to x86 systems. Arm based systems (phones, pads, etc.) have no such requirement.

      But yes, I was surprised and pleased that MS included those requirements, even if it was just for x86, and I'm sure the FSF was as well.

      • by segedunum (883035)

        But yes, I was surprised and pleased that MS included those requirements, even if it was just for x86, and I'm sure the FSF was as well.

        I wasn't surprised. On x86 they had to because of the stink that would be created if corporations couldn't install existing Windows versions on new hardware or run their ghosting and imaging tools. On ARM they have no such problems and all they want to do is ensure Android cannot run.

        • That's the real question. Is the ability to disable secure boot on X86 just a temporary concession to corporations that would refuse to buy new computers without it? Once XP and Windows 7 work their way out of the corporate infrastructure, will Windows certified X86 machines still be required (or even allowed) to support disabling secure boot. If there's some promise to that effect, then fine. But I don't know of any.

          Also, if ARM ever supplants X86 in corporate settings, then all bets are off. There is

        • That, and just because those requirements are there today doesn't mean they'll be there tomorrow.
    • by segedunum (883035)

      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

      The difficulty is that OEMs will not lose any Windows 8 certification if they do not implement a user configurable key database. If it boots Windows 8 Microsoft won't care. Microsoft tacked that on to their 'mandatory requirements' knowing full well it won't be implemented in just about any case. In another 'mandatory requirement' they specify that the key database contents are to be determined by the OEM.

      As for disabling secure boot, that was done so that existing versions of Windows and other platforms

      • by mjg59 (864833)

        Microsoft have told me that they'll revoke certification for any vendor who doesn't provide the appropriate options. If you have examples of machines that have certification and which don't allow any modification of the key database, let me know so we can find out if they were telling the truth.

    • by amiga3D (567632)

      If I buy a computer from Dell I don't want Microsoft telling me what I can use it for.

  • by Todd Knarr (15451) on Sunday December 30, 2012 @02:49PM (#42427607) Homepage

    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: (Score:3, Interesting)

      by Billly Gates (198444)

      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: (Score:2, Informative)

        by Anonymous Coward

        The problem regarding the "Secure Boot"-key are a bit different:

        Because they are built into the UEFI-firmware they cannot be easily replaced. You have to upgrade your firmware to get a new key. And then there is some kind of chicken&egg problem:

        When the built-in key is compromised what should be updated first? The boot-loader (Signed with the non-compromised key) ? Or the key? If you replace the boot-loader first, the firmware refuses to load this boat-loader. And if you first replace the key, you have

        • Wrong (Score:5, Insightful)

          by scheme (19778) on Sunday December 30, 2012 @03:44PM (#42427869)

          To replace the key and the boot-loader you have to disable "Secure Boot" in the firmware (Disabling by software is not allowed), then update the key (Means flashing a new version of the firmware) and the boot-loader and then reactivate "Secure Boot".

          Now think of Average Joe or your grand mother and tell me how someone like them will accomplish this.

          Replacing the keys doesn't require reflashing the firmware, you just need go into the UEFI setup screen and add or delete the keys you're interested in. If the key gets compromised, you just go to the setup, add the new key, boot and update the bootloader and go into the setup and remove the old key. Or, even easier, you update the boot-loader on a working system, then go into the UEFI setup and remove the old key and add the new key. The procedure you outlined is unnecessarily complex even assuming that you have to reflash the firmware to get new keys.

          • Cool. So if you're *right*, where's Linux running on the surface?
          • by DrJimbo (594231)

            No. You are wrong. You said:

            Replacing the keys doesn't require reflashing the firmware, you just need go into the UEFI setup screen and add or delete the keys you're interested in. If the key gets compromised, you just go to the setup, add the new key, boot and update the bootloader and go into the setup and remove the old key ...

            This is true for Secure Boot where the user/owner has control of the keys but it is untrue of Restricted Boot which is what the OP was talking about. In fact their subject line (which you overwrote) was:

            Restricted Boot by definition insecure

            Their point, of course, is that with Restricted Boot the user, by definition, does not have control of the keys so has no access to the setup screens you talk about. This is the essence of the problem with Restricted Boot they were pointing out. Your response makes no sense.

      • by segedunum (883035)

        The master key in both situations are still secure.

        They are not guaranteed to stay that way, that's the OP's point. If I was a serious virus writer this system is a potential boon. If you can find a way of compromising the system so that things appear to be trusted when they're actually not and you can lock out other software as a result you can create a hell of a lot of damage before anyone even notices.

        • by mjg59 (864833)

          If you were a serious virus writer you'd already want to use the Microsoft CA to sign your rootkit so you can install it as a signed driver in Windows. Secure Boot moves the vulnerability down the stack, but even now a compromised Microsoft signing key is still massively desirable to virus authors.

    • by Dunbal (464142) *
      Yup I agree completely. Ultimately I am responsible for my computer, not my OS vendor, and the "trust" model has already proven to be flawed. When the hackers have obtained certificates from the certificate issuing authorities themselves like say, VeriSign, there is no one left to trust. It's a mere marketing term that has no real value. Therefore I must have the keys to my own machine since ultimately I am the only one worthy of my trust.
  • by scheme (19778) on Sunday December 30, 2012 @02:54PM (#42427625)

    So the FSF is basically asking people to sign a petition that asks manufacturers to do what they are already doing and plan on doing ? The current requirements for windows 8 is that users must be able to disable secure boot in the bios and do key management (addition/removal) of keys as well. I don't know of any manufacturer that is planning on doing anything different since that would mean that their systems would not be windows 8 certified.

    In fact, I don't think microsoft bans having other keys besides their key in the bios by default.If, for example, the FSF or some coalition (e.g. RedHat, Ubuntu, Debian, etc.) were to come up with some workable way key signing infrastructure, they could petition UEFI/mobo developers to include their keys in shipped products as well. The question is how do you freely allow people to get bootloaders signed without making it easily for malware authors to do the same.

    • by spitzak (4019)

      The unsigned or differently-signed bootloader is not able to load Windows, because it will leave the machine in a different state that Windows will refuse to load from (ie wrong keys produced by the hardware). So such bootloaders are pretty limited. I could imagine a *huge* piece of Malware that is an entire copy of Windows but the user will lose any personal data stored on the disk in secure encrypted directories so this may be easily noticed, especially if Microsoft defaults to this encryption (which perv

    • by westlake (615356)

      So the FSF is basically asking people to sign a petition that asks manufacturers to do what they are already doing and plan on doing ?

      That is pretty much it.

      Secure Boot is part of the UEFI 2.2 spec. Published in 2008. The geek has had four years to prepare for this.

    • by andrew3 (2250992)

      In fact, I don't think microsoft bans having other keys besides their key in the bios by default.

      Windows RT has Restricted Boot on it.

  • by DrJimbo (594231) on Sunday December 30, 2012 @03:43PM (#42427859)
    The essence of DRM is that user is considered to be the attacker. The FSF endorses Secure Boot only when the user has control of the keys so the user is obviously not the attacker in that case. Secure Boot is only a form of DRM when the user/owner does not have control of the keys. This is what we should fight against. Categorizing all forms of Secure Boot as "DRM" is wrong both technically and politically.

    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.

    • Yep. And Linux systems are potentially better able to take advantage of the security than current versions of Windows. Many Linux systems are already configured to only install signed packages from the distro repository, Secure Boot allows the boot process to be secured as well. Combined with SELinux some very secure setups can be realized.
  • If you don't like the secureboot idea, THEN DON'T BUY PRODUCTS THAT INCLUDE IT. Seriously, not that difficult of a concept to understand.
  • I believe the real story here is the fact that slashdot managed to correct the extremely exaggerated story they presented yesterday.

    Writting "it's more complicated" is nice, but hardly a good apology.


    Nevertheless, in days like these, let's take a moment to congratulate slashdot on a summary that's actually correct.

    It's too often, that I find a different story, if I read beyond the summary.
  • Knowing most "users" out there, any option which exists to let a 'user' configure something will most likely result in a virus configuring it on behalf of the ignorant user. Disabling Restricted Boot should require some physical action to prevent software from doing it.
    • by spitzak (4019)

      When you turn off secure boot, Windows DOES NOT BOOT! It cannot because it will not see correct decoding keys read from the hardware. The virus cannot do much other than brick the machine, which it can do already in a much worse way by modifying a file so Windows refuses to boot whether or not secure boot is on.

      The more useful feature that RMS really should insist on is that the user can add their own keys. But all this means is that you can boot either Windows or Linux without having to change the bios set

  • What happens when the Master key is found/hacked/whatever?

    I mean, the big hacking groups, you know, the real criminal ones with the money, are probably salivating at the idea of finding an exploit or getting their hands on the master key. Its really only a function of time, and even money that it happens in the next few years. Hell, they could probably throw enough money at someone within MS with access to the master key and have it within a few days if they knew who would be open to taking a bribe.

    Still,

    • by recoiledsnake (879048) on Monday December 31, 2012 @12:05AM (#42430635)

      Just because you haven't seen one doesn't mean they aren't prevalent.

      If you(and others here) really want to educate yourself instead of spreading karmawhoring FUD, please read on.

      Here are some references about boot malware which UEFI secure boot will prevent.

      http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection [chmag.in] [chmag.in]

      http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ [theregister.co.uk] [theregister.co.uk]

      http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft [computerworld.com] [computerworld.com]

      I recommend reading atleast the first link.

      Here's one juicy bit:

      TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

      When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

      The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

      The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original dataThe bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

      TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

      All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

      Another bit:

      The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products

      The OEMs offered to add Red Hat and Ubuntu etc.'s keys but they refused since they didn't want to have an exclusive solution and neither did they want to be in the position of signing keys. If the Linux foundation stepped up, the OEMs will gladly add their master key to U

  • by monkeyhybrid (1677192) on Sunday December 30, 2012 @08:46PM (#42429665)

    Direct link to the petition / statement referred to in the summary: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/ [fsf.org]

    Only takes a few seconds to sign it!

Things equal to nothing else are equal to each other.

Working...