Forgot your password?
typodupeerror
DRM Microsoft Security Hardware

Free Software Foundation Campaigning To Stop UEFI SecureBoot 355

Posted by timothy
from the no-one-will-ever-name-a-child-uefi dept.
hypnosec writes "The Free Software Foundation is on an offensive against restricted boot systems and is busy appealing for donations and pledge in the form of signatures in a bid to stop systems such as the UEFI SecureBoot from being adopted on a large-scale basis and becoming a norm in the future. The FSF, through an appeal on its website, is requesting users to sign a pledge titled 'Stand up for your freedom to install free software' that they won't be purchasing or recommending for purchase any such system that is SecureBoot enabled or some other form of restricted boot techniques. The FSF has managed to receive, as of this writing, over 41,000 signatures. Organizations like the Debian, Edoceo, Zando, Wreathe and many others have also showed their support for the campaign."
This discussion has been archived. No new comments can be posted.

Free Software Foundation Campaigning To Stop UEFI SecureBoot

Comments Filter:
  • Grub? (Score:5, Interesting)

    by TheRealMindChild (743925) on Saturday December 29, 2012 @09:11PM (#42423315) Homepage Journal
    Hasn't Ubuntu made GRUB a SecureBoot [h-online.com] boot loader? How isn't this sufficient?
    • Re:Grub? (Score:5, Insightful)

      by Ynot_82 (1023749) on Saturday December 29, 2012 @09:28PM (#42423435)

      How isn't this sufficient?

      It's not sufficient, because it doesn't solve the problem.

      The problem is that MS's implementation of secure boot allows them to control what can and cannot boot on a device.
      It is entirely at their discretion.

      This is already in practice with the surface tablets
      See Mathew Garrett's recent blog post
      http://mjg59.dreamwidth.org/21189.html [dreamwidth.org]

      As you can see, locking out other OSs is already in place for the Surface tablet, which is unable to boot any other system (even with the boot-loader shims done by RedHat, Ubuntu and the Linux foundation.)

      • Re: (Score:3, Funny)

        by drankr (2796221)
        Irrelevant - this would be a problem if people were actually buying and using "surface tablets".
        • Re:Grub? (Score:5, Insightful)

          by Ynot_82 (1023749) on Saturday December 29, 2012 @10:00PM (#42423609)

          and when will it become relevant to you?

          When they push Windows-only "secure boot" on laptops?
          When they push Windows-only "secure boot" on servers?
          When they push Windows-only "secure boot" on desktop machines?

          When, exactly, will this obviously evil and anti-competitive move be of relevance to you?

          • Re:Grub? (Score:5, Funny)

            by Anonymous Coward on Saturday December 29, 2012 @10:15PM (#42423703)

            When they put Windows-only "secure boot" on Surfaces I didn't say anything because I didn't own a Surface.
            When they put Windows-only "secure boot" on laptops I didn't say anything because I didn't own a laptop.
            When they push Windows-only "secure boot" on servers I didn't say anything because I didn't own a server.
            When they push Windows-only "secure boot" on desktop machines I didn't say anything because I didn't own a Desktop.
            Boy, am I glad I own an iMac, iPad and iPhone ... um, wait ...

          • by Hentes (2461350)

            So how many laptops, servers and desktops does Microsoft produce?

          • Re:Grub? (Score:5, Insightful)

            by Bengie (1121981) on Sunday December 30, 2012 @01:02AM (#42424341)
            SecureBoot is a standard that allows the end user to limit their system to only booting signed code. Next thing you'll be complaining about SSL and how it can also limit the end user from working with untrusted sources.

            If you don't like it, disable it. You can also add your own certs. This applies to most motherboards and I can almost guarantee, all servers. Ever work in the real world? IT has A TON of custom boot code that won't work with default SecureBoot. Any hardware manufacturer that targets Servers/Enterprise/Enthusiast, WILL have at least a way to disable SecureBoot and at best a way to manage certs.

            Commonly used tools in IT that WILL break based on your flawed understanding:
            PXE Boot
            Memtest
            NSA Secure Erase Linux Distro
            Bart PE
            Norton Ghost
            Firmware Updates
            Win7
            WinXP

            Any hardware manufacturer that ruined the above would be committing business suicide.

            If IT needs to manage, test, or fix it, SecureBoot will have to be configurable.
            • Re:Grub? (Score:5, Informative)

              by Microlith (54737) on Sunday December 30, 2012 @01:40AM (#42424489)

              If you don't like it, disable it.

              On systems where you can. Microsoft is already leveraging it on ARM against the owner of the device. This is completely unlike SSL.

              You can also add your own certs.

              Through a painful and convoluted process.

              Ever work in the real world?

              I have, have you? I deal with UEFI and vendor-to-vendor, board-to-board inconsistencies daily. IT hardware also costs many thousands more than consumer level hardware.

              Any hardware manufacturer that ruined the above would be committing business suicide.

              That's fine. All this has to do is hinder the adoption of other platforms and force everything through Microsoft. That's what they've always wanted, really.

            • Adding to list: Checkpoint / Truecrypt / insert disk encryption solution.

            • Re:Grub? (Score:5, Informative)

              by Alsee (515537) on Sunday December 30, 2012 @08:07AM (#42425541) Homepage

              If you don't like it, disable it. You can also add your own certs.

              Oh really?

              Microsoft confirms UEFI fears, locks down ARM devices [softwarefreedom.org]

              On x86 systems Microsoft needs computers to be compatible with older versions of Windows. On x86 systems the Microsoft Hardware Certification says that manufacturers must include an option to disable UEFI SecureBoot, and must allow the owner to load his own keys. However on systems with an ARM processor Microsoft doesn't need to worry about hardware being compatible with versions of Windows because there are no versions of Windows for ARM. On ARM systems Microsoft has mandated that MANUFACTURERS ARE FORBIDDEN TO INCLUDE ANY OPTION TO DISABLE UEFI SECUREBOOT. On ARM systems Microsoft has mandated that MANUFACTURERS ARE FORBIDDEN TO INCLUDE ANY POSSIBILITY OF OWNERS LOADING THEIR OWN KEYS.

              Microsoft has made it crystal clear that they can and will use UEFI to lock computers AGAINST their owners and to anti-competively lock out any possibility to load alternate operating systems when they do not have to worry about compatibility with older versions of Windows.

              Currently ARM processors are primarily used in smartphones, however at least one manufacturer, Qualcomm, has announced they will be manufacturing ARM based PCs. Microsoft has mandated that owners of these PCs be denied any possibility of disabling the system and denied any possibility of loading your own keys.

              Microsoft has announced the Windows 7 End Of Life date to be January 14, 2020. On that date Microsoft is no longer concerned with x86 computers being compatible with pre-UEFI operating systems. On that date Microsoft can drop the "Disable SecureBoot" legacy support. On that date there is every reason to expect Microsoft take their ARM-style no-legacy-support terms and impose them on all PC manufacturers.

              Your "If you don't like it, disable it" is already false on some systems today, and there is good reason to suspect Microsoft may forbid it on all systems in a few years.

              -

              • Re:Grub? (Score:5, Insightful)

                by Missing.Matter (1845576) on Sunday December 30, 2012 @09:06AM (#42425679)
                Sounds like a lot of tinfoil you got there.

                Microsoft has made it crystal clear that they can and will use UEFI to lock computers AGAINST their owners and to anti-competively lock out any possibility to load alternate operating systems when they do not have to worry about compatibility with older versions of Windows.

                Why does this matter at all on ARM? Currently, the number one selling tablet manufacturer in the ARM space does this, and it aint Microsoft. Apple does everything in their power to prevent you from running Linux on iPad. And you know what? I have absolutely no problem with that, because if I want an unlocked tablet I can just go buy any of the dozens of varieties. Choice is good. Microsoft entering the space does not take that choice away, and it doesn't appear that it will any time soon.

                x86 is an entirely different land. I contend that Microsoft's requirement has less to do about backwards compatibility and much much more to do with not running afoul of antritrust regulations. Honestly, Microsoft has nothing to worry about in the x86 space. Their biggest competitor here won't even allow their OS to be installed on generic x86 hardware. Their second biggest competitor is so far removed, they're hardly worth considering. If Linux were gaining any traction before this whole thing started, I would say "yeah, maybe they are getting worried" but Desktop Linux is holding strong at
                So in fact, probably the *worst* thing Microsoft could do is lock down x86 bootloaders for anticompetitive reasons, because there is no real competition on the desktop to Windows. They would be inviting DOJ and EU oversight where this is no need to, as there is no credible threat. As it stands, Microsoft's biggest threat to their desktop marketshare is the dwindling PC market due to the locked down iPad.

                Apple has sold 100 million iPads so far. Microsoft has sold a mere fraction of that in ARM tablets. In that sense, your capslock-infused rage seems misdirected, as Apple is the one leading the charge in locked down bootloaders on ARM devices. I personally have no problem with it, but it seems strange to me all this rage wasn't abound in 2010. Where was the FSF campaign when Apple was getting started with iPad? Or in 2006 with locked down iPhone? Now this practice is commonplace, and the target isn't even the correct company; even if they get Microsoft to completely change their practice, 99% of ARM tablets sold will still be locked down.

    • Re: (Score:2, Insightful)

      by Anonymous Coward
      Why can't they use a hardware jumper for this instead of requiring signed code?
      • Re: (Score:3, Insightful)

        by Alex Belits (437) *

        Because then it won't keep those computers Windows-only.

      • Re:Grub? (Score:4, Interesting)

        by Sir_Sri (199544) on Saturday December 29, 2012 @10:36PM (#42423805)

        Probably because people may still want to update their MOBO firmware without opening the case, same with installing a new OS.

        It's one thing to do it on your machine at home. It's another to deploy 500 machines where you have to change a jumper on each one, and then change it back.

    • Re:Grub? (Score:5, Interesting)

      by cheesybagel (670288) on Saturday December 29, 2012 @10:04PM (#42423631)

      What Ubuntu did was very unsatisfactory. You still cannot easily compile your own kernel. What that ex-RedHat guy did was a lot better since you can load anything you want as long as you confirm your choice on boot.

      Here is what RMS should be doing instead of this petition which is going to get nowhere:

      1. Restart work on coreboot
      2. Make coreboot work with Windows and Linux as is
      3. Convince more motherboard manufacturers to support coreboot
      4. Ask Linux users on install if they want to backup their old BIOS and install coreboot as their default BIOS

    • Re:Grub? (Score:4, Insightful)

      by sjames (1099) on Saturday December 29, 2012 @10:48PM (#42423845) Homepage

      It's not sufficient because it leaves MS, a company known for it's extreme hatred of Free software, able to decide what will and will not boot on locked down SecureBoot devices. As a bonus, it sends a message to others who implement different lick-in schemes that they could be next on the boycott list.

      Even on SecureBoot systems that aren't completely locked down, it establishes a very definite class system where only MS OSes and those that pay tribute to the king are first class citizens.

      Not objecting suggests that it's OK for MS to further erode the meaning and value of property rights (other than their own, of course).

  • by Anonymous Coward

    I like the straight jacket clipart - It reminds me of how this is all just insanity.

    Secure Boot is a good thing people! It means I can actually lock out my machines so they'll only boot linux and never windows!

    • Good thing that the FSF isn't against Secure Boot, but against implementations of it that don't allow the user to install free software OSs.

      The threat is not the UEFI specification itself, but in how computer manufacturers choose to implement the boot restrictions.

  • Concealed defect (Score:3, Interesting)

    by jandar (304267) on Saturday December 29, 2012 @09:13PM (#42423337)

    It should be mandated that any restriction on a general purpose computer has to be stated clearly as such on the packing, otherwise it would a intentionally concealed defect.

    • by jbolden (176878)

      Microsoft has been pretty clear about where UEFI is and the spec. They've been publishing papers, having websites, publishing books, giving talks, having videos on channel 9 for over a dozen years. You may disagree with them, but you can't accuse them of lack of disclosure.

  • Not realistic (Score:5, Insightful)

    by girlintraining (1395911) on Saturday December 29, 2012 @09:20PM (#42423367)

    Richard, it's a nice sentiment, but what are the alternatives? Signing something saying I won't buy a UEFI-enabled system is basically saying I've doomed myself to the stone age. Every company is switching over. Nobody's going to go for that in the long term, anyone signing that is doing it just to make a statement. Eventually, their decrepit pre-UEFI system is going to fry, and they're going to go looking for a new one.

    Rather than do something useless like a petition, which have a very low success rate on the internet, why not give us something useful: Like a list of motherboards and builds that do not have UEFI and sport otherwise modern hardware and features?

    • Re: (Score:3, Insightful)

      by Microlith (54737)

      a list of motherboards and builds that do not have UEFI

      Which will trend to zero very rapidly. The problem, of course, is not UEFI but the Microsoft-centric architecture behind Secure Boot.

      • Re: (Score:3, Informative)

        by tftp (111690)

        Which will trend to zero very rapidly.

        If there is a demand there will be the offer. I will personally make m/boards for you that run whatever CPU you want and use whatever booting technology you want. If you insist I can use an entirely FPGA-based design that is 100% F/OSS. It may not be as good as an Intel CPU, but it will work.

        OpenCores Projects [opencores.org]

        The only way to block this is to make it illegal. But I cannot imagine how you can make microcontrollers illegal today. Would I need a license to own a debu

        • by Kjella (173770)

          I will personally make m/boards for you that run whatever CPU you want (...) It may not be as good as an Intel CPU, but it will work.

          So which is it, can you make me a LGA1155 socket motherboard or can't you? Or did you mean "any CPU you want, as long as it's an ancient and outdated one with open specs"?

          • Re:Not realistic (Score:4, Informative)

            by tftp (111690) on Saturday December 29, 2012 @11:41PM (#42424001) Homepage

            So which is it, can you make me a LGA1155 socket motherboard or can't you? Or did you mean "any CPU you want, as long as it's an ancient and outdated one with open specs"?

            I can make any motherboard, with LGA1155 or any other socket - or with direct attachment of a CPU that is packaged as a BGA. Why not? It's not rocket science. The pin grid is 0.91 mm [intel.com], which is pretty generous today. My last BGA design involved a part with a 0.5 mm pitch; that was expensive. You may want to have Intel's reference designs, but they are obtainable today, and I have some for Atom (because that's what I need.) The DDRx routing will have to be carefully done, but that's also not an impossible task. I built 20A, 0.9V polyphase power supplies before, for a PowerPC project. There is hardly anything else that is notable.

            But super-fast and super-hot motherboards of this kind are not what the digital rebel needs, IMO. He needs a small, lightweight, portable system - a tablet would be ideal, especially if it accepts external attachments like the monitor and USB. In reality all modern tablets are already suitable for the task. Communication, not data crunching, is the primary use of computers today - and any low-power system can do it just as well as a hot desktop.

            Another reason for a digital rebel to not depend on Intel is that Intel can be asked (or forced) to make sure that their CPUs don't even start until they authenticate with the BIOS. You can build such a system already. For example, the CPU will refuse to access most of its address space until it issues a challenge to the BIOS (or TPM) and receives a correct response. The pre-auth mode would be just good enough to boot up, but if you need to run an OS you need the CPU unlocked. The private key to the CPU is in the mask, and the chances of getting to it are nearly zero.

            In this situation it is essential to have an entirely free CPU design that is not constrained by artificial barriers. There are already lots of good CPUs that are ready for an FPGA. If there is a need, a SoC can be synthesized from existing RTL components and then manufactured as an ASIC. If that is illegal, use FPGA and program your own bitstream. Either way, computers are here to stay, and the only way to restrict access to them is not technical but social (like public beheading of underground engineers.)

        • Re:Not realistic (Score:5, Insightful)

          by mrchaotica (681592) * on Sunday December 30, 2012 @01:45AM (#42424509)

          The only way to block this is to make it illegal. But I cannot imagine how you can make microcontrollers illegal today. Would I need a license to own a debugger or a soldering iron?

          Maybe you can't imagine it, but RMS imagined it a decade and a half ago [gnu.org].

          Much like 1984, it was scary then, but scarier now.

    • I don't see your predictions with the same surety you do. Having MS in the control of what runs in all general purpose computers is not good for anybody but to Microsoft. Even if manages to push it at first, there will be enough interest from other companies to make systems outside their control.
      • there will be enough interest from other companies to make systems outside their control.

        Absolutely true. There is enough of a Linux presence in the server market to insure appropriate motherboards are available, and there will always be niche companies providing PC boards as well.

    • Re: (Score:2, Insightful)

      by DigiShaman (671371)

      What's wrong with supporting UEFI secureboot by default, but still providing users a BIOS option of disabling it for legacy/alternate OSes? Secureboot should be an added feature, not a forced requirement for motherboards. If Microsoft Windows X is require secureboot, the user can toggle secureboot on. Why does this have to be such a big deal?

      Is there really some conspiracy going on in which Microsoft will own the PC market with Intel as the -unofficial- official Microsoft hardware developer locking out all

      • MS, as all big companies, wants control, at least enough of it to eliminate any possibility of competition. It cannot force total control out of the blue, but it can try to erode resistance with time, pushing it bit by bit. The current UEFI implementation is just one more attempt to do exactly this.
      • by jbolden (176878)

        What you are describing is what Microsoft is doing on x86 systems, pretty much.

      • What's wrong with supporting UEFI secureboot by default, but still providing users a BIOS option of disabling it for legacy/alternate OSes?

        Because the definition of 'UEFI secureboot' is that you can't disable it. Disabling it would defeat the entire point of the Trusted Computing Module... which is to fuck you, the customer, over a barrel--er, I mean, provide the customer with the security and reliability they've come to expect in a modern operating system...

        • I'm not saying this topic isn't cause for some eyebrow raising, but it doesn't do anyone any good to be spreading FUD! If you actually spent some time researching this topic, you will find that what you said isn't entirely true. Take the Dell Latitude 6430u that comes with Windows 8. You can disable secure boot in BIOS. I refer you to page 44 of its owners manual (PDF format) [dell.com]. Not only that, but TPM can be disabled along with the options of booting via legacy ROM (BIOS).

          Basically here's the skinny. For x86

          • by waterbear (190559) on Sunday December 30, 2012 @06:55AM (#42425377)

            ....it doesn't do anyone any good to be spreading FUD! If you actually spent some time researching this topic, you will find that what you said isn't entirely true. Take the Dell Latitude 6430u that comes with Windows 8. You can disable secure boot in BIOS. I refer you to page 44 of its owners manual....

            Well, I don't have a 6430u, but I just looked at page 44 of the owner's manual. It's written in gobbledygook language with double negatives and obscurity about what exactly is being enabled/disabled.

            What's more, one of the controls 'described' on the page has a big warning that it's for one-time use only and "Activate and Disable options will permanently activate or disable the feature and no further changes will be allowed".

            Maybe I could navigate that path to freedom if I had plenty of information from elsewhere, but that 'owner's-manual' page looks like it's exploiting complexity and obscurity to hinder the use of freedom.

            It's unfair to call 'FUD' when information about available features has been obscured to the point of incomprehensibility.

            -wb-

      • Re:Not realistic (Score:4, Interesting)

        by SuricouRaven (1897204) on Sunday December 30, 2012 @05:14AM (#42425139)

        Conspiracy? Well, yes. This is *Microsoft* we're talking about here. The company convicted of antitrust violations by both US and EU regulators. The company which has a history of using every dirty trick in the book to get ahead, and which for many years waged a campaign against open source that seemed at times like some sort of personal vendetta. And the company which has now announced they are building a big 'Kill linux' button which they can press by revising a single clause in a contract. Based simply on the past actions of the company, it would seem a very bad idea to trust them with such power.

      • Is there really some conspiracy going on in which Microsoft will own the PC market with Intel as the -unofficial- official Microsoft hardware developer locking out all other OSes?

        Yeah, pretty much.

    • by sjames (1099)

      The pledge does NOT demand non-UEFI systems. It demands:

      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.

      Where in there do you see UEFI being rejected? It says the signers will not buy a system that doesn't allow SecureBoot to be disabled by the owner or offer a reasonable alternative for loading any Free Software OS of the owner's choice.

  • Antitrust in EU? (Score:5, Informative)

    by Anonymous Coward on Saturday December 29, 2012 @09:20PM (#42423371)

    The secure boot crap could be an antitrust issue.
    German goverment has spoken abit about it
    http://www.h-online.com/open/news/item/German-government-advocates-security-in-the-hands-of-users-1753715.html

  • by Microlith (54737) on Saturday December 29, 2012 @09:26PM (#42423411)

    If anything, the FSF should push to have how UEFI handles its signature database, and who handles signing, fixed so that it isn't so wholly Microsoft centric. You can tell because it puts key acquisition and installation in the hands of the system vendors, and the only one they'll independently acquire with any regularity is Microsoft's. And as a result everyone goes to them for signing.

    If key handling were decentralized and standardized across all vendors, and adding your own key wasn't mutually exclusive with other keys (as it effectively is now,) then it probably wouldn't be such a problem. Hell, if they included a system-specific key installed on each platform and a hardcopy of the key, that would probably eliminate most of the concerns expressed here.

    Unfortunately, doing this would likely require them becoming a promoter ($200,000) and contributing code out the ass to see it happen. As it stands the only OS vendor at that level in the UEFI Foundation is Microsoft. All the Linux vendors are Contributor or lower and can't possibly have a voice as loud as Microsoft. Net result a perfectly good security concept gets twisted into a Microsoft-specific hazard.

    • by EdZ (755139) on Saturday December 29, 2012 @10:36PM (#42423807)

      fixed so that it isn't so wholly Microsoft centric

      Good news, it's already fixed then!

      So who decides what keys can be added to the bootloader? The end user, in the case of every x86 board. Microsoft requires any system vendor to allow end users to add their own keys (either directly, or by wiping the existing keys and requiring the user to add their own and microsofts back in). No user-modifiable Secure Boot, no Windows 8 for you. No windwos 8 certification? The manufacturer can do whatever they want, from locking down the loader to only one key of their choice, or not implementing secure boot at all/ Basically, the current state of affairs.

      If key handling were decentralized

      It is decentralised. It's so decentralised, that it's handled on a per-end-device basis. Because you manage the keys on your device by entering them.

      and adding your own key wasn't mutually exclusive with other keys (as it effectively is now,)

      No, it isn't. If you can add your own keys, you can add any keys.

      The level of FUD over Secure Boot, and it's non-relation to Windows 8, is astounding.

      • by Microlith (54737) on Sunday December 30, 2012 @01:53AM (#42424543)

        Good news, it's already fixed then!

        No, it isn't!

        So who decides what keys can be added to the bootloader?

        Theoretically, the BIOS vendor. Or if you make a Windows RT device, Microsoft. In practice, Microsoft.

        The end user, in the case of every x86 board.

        Only through an irritating process that, in virtually every functional example is mutually exclusive with the Microsoft keys.

        Microsoft requires any system vendor to allow end users to add their own keys (either directly, or by wiping the existing keys and requiring the user to add their own and microsofts back in). No user-modifiable Secure Boot, no Windows 8 for you.

        Microsoft. So benevolent. We'll see how long this lasts.

        No windwos 8 certification? The manufacturer can do whatever they want, from locking down the loader to only one key of their choice, or not implementing secure boot at all/ Basically, the current state of affairs.

        Not a single vendor would dare omit Windows 8 certification.

        It is decentralised. It's so decentralised, that it's handled on a per-end-device basis. Because you manage the keys on your device by entering them.

        The "decentralization" is a joke. It's so decentralized that the only vendor with any guarantee of getting their key on the system is Microsoft. That's why EVERY LINUX VENDOR is going to Microsoft for a signature. Which, of course, such a supposedly vendor independent system shouldn't result in.

        It's totally biased in Microsoft's favor and they know it.

        No, it isn't. If you can add your own keys, you can add any keys.

        Go show me one system that lets you add one with out forcing you to clear the Microsoft key? Or without having to rebuild the entire key database from scratch and installing it? It puts a nice high, high bar on being able to leverage that security and even more so for any system not approved by Microsoft to use it.

        FUD

        Please. Why is it that every time this subject comes up we're told to just, y'know, shut the fuck up and trust Microsoft?

      • by mrchaotica (681592) * on Sunday December 30, 2012 @01:56AM (#42424555)

        So who decides what keys can be added to the bootloader? The end user, in the case of every x86 board.

        AND WHAT ABOUT ARM DEVICES?

        If such restrictions are allowed to happen everywhere, they will inevitably end up happening everywhere. The situation is already completely unacceptable!

      • Re: (Score:3, Informative)

        by segedunum (883035)
        I'm sorry, but this load of bull and misiniformation is going to have to be smacked down - hard.

        So who decides what keys can be added to the bootloader? The end user, in the case of every x86 board.

        No they fucking don't. There will be one key in there, and that will allow you to boot Windows. How many motherboard manufacturers do you think are going to implement a whole key management system in their firmware that Windows does not require, you silly idiot?

        However, I'm seeing this deliberate misiniformation coming up more and more, probably because it's all certain people have left to tell us that there i

        • by EdZ (755139) on Sunday December 30, 2012 @10:39AM (#42425935)

          No they do not, so I don't know where you're getting this from.

          The Windows 8 Hardware Certification requirements published by Microsoft [microsoft.com]. To quote the relevant section:

          Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following: It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

          Mandatory. Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.

    • by jbolden (176878)

      If the FSF were more responsible about these things, they could register with Microsoft as a signing authority and have their key be one of the default signing keys embedded in hardware. Then we have asian manufacturers, Microsoft and FSF and everyone is going to trust one of them.

      • Oh, I see. Microsoft is now a de facto authority without which we can't use a computer. Who gave them that prerogative?

  • by Joe_Dragon (2206452) on Saturday December 29, 2012 @09:39PM (#42423501)

    What about severs and web hosts / ECT.

    Windows 7 UEFI secure boot??? enterprise use is way to big for that to get locked out.

    Where is HP and DELL in this???

    Supermicro??

    Tyan??

    Linux in Medical Devices (do really want MS windows to be the only choice there??)

    http://blogs.windriver.com/medical/2011/11/using-linux-in-medical-devices-what-developers-and-manufacturers-need-to-know.html [windriver.com]

    • You can easily disable secure boot for all but the ARM tablets (tablets are rarely open to begin with).

      The only way secure boot will ever be a serious problem is if Microsoft actually grows the balls to force OEMs to enable secure boot and force it locked on at all times. To be honest, I'm all for doom and gloom but I just don't see this ever happening. The legal jungle gym Microsoft would thrust themselves into would be so ridiculous that it would make the monopoly charges over Internet Explorer look like

  • Bread buttered (Score:5, Insightful)

    by EmperorOfCanada (1332175) on Saturday December 29, 2012 @09:46PM (#42423531)
    Desktop motherboard manufacturers know that in the past and in the present that following the dictates of Microsoft is how to survive. But those days are mostly over. I doubt any of the MB manufacturers are going to stand up and fart in Microsoft's face and say NO. But I suspect they know the trend is moving away from Microsoft and with the Linux noises that companies like Valve are making that Microsoft will only get weaker. Thus they will probably pretend to put UEFI onto the motherboard but make it really really easy for anyone with the capability to install linux to turn it off. So I suspect that the motherboards will soon come with UEFI enabled by default (maybe) but that you can either go into the bios and turn it off or short a jumper.

    Other options would be to leave a weakness in the system so that it is easily hacked and thus bypassed; this way they can meet the letter of Microsoft's law but not at all the spirit. And of course they don't need to make a hole, they know people will find a hole and they won't bother patching it. But I just don't see the manufacturers coming out and directly attracting Microsoft's rage. Plus companies know that all kinds of businesses will want to put a whole range of products on their systems from oddballs like DOS with many wanting XP, Vista, and Windows 7. It wasn't that long ago that I saw an ATM running OS/2. I suspect the guts of the ATM were newish.

    But in the near term Microsoft is going to ask "Who farted?" and the various manufacturers are going to pretend that they didn't.

    All that said, Microsoft's worst nightmare would be for a company to start releasing Motherboards/Machines with UEFI disabled as a feature and telling the world that smart discerning high-end customers buy systems without UEFI and that the drones buy what the suits at Microsoft tell them. What microsoft seems to forget that while computer nerds running things like Linux are not a significant market share in and of themselves they are who guides, or outright chooses what systems get picked. Minimally how many slashdoter's are involved by their families when they are picking machines. Without starting a religious war about my personal tastes I can say that when people around me are buying a system I give them a fairly narrow range of choices that if they stray from I won't take their "urgent" calls at 10pm when things are going wrong a month later. "Oh your poorly designed laptop that sucks cooling air in only from the bottom overheated when sitting on the sofa and now you need your data pulled from its carcass? How about no." So while people like us probably only represent 1% of the market we probably influence 30+% of the market. So if we don't like UEFI the manufacturers will soon find that we have a bigger vote than simplistic market surveys might otherwise suggest. So even if they totally cave to MS I suspect cracks will appear fairly quickly.
    • windows 8 stink as well hurts ms a 7 boot loader will help alot of this may be DOA as it will be a hard sell with a MB that can only boot windows 8

    • by Kjella (173770)

      Desktop motherboard manufacturers know that in the past and in the present that following the dictates of Microsoft is how to survive. But those days are mostly over. I doubt any of the MB manufacturers are going to stand up and fart in Microsoft's face and say NO. But I suspect they know the trend is moving away from Microsoft and with the Linux noises that companies like Valve are making that Microsoft will only get weaker. Thus they will probably pretend to put UEFI onto the motherboard but make it really really easy for anyone with the capability to install linux to turn it off.

      Whether Microsoft is experiencing competition from Macs or iPads or Android tablets doesn't matter, the only thing is how many repurpose a machine that came with Windows installed. That market share is still 1% and more importantly the motherboard manufacturers don't care - they got their sale back when it had Windows on it. Hell if Linux fans have to buy a different motherboard to run Linux on it, they get double sales.

      Plus companies know that all kinds of businesses will want to put a whole range of products on their systems from oddballs like DOS with many wanting XP, Vista, and Windows 7.

      And Microsoft will, if they're kind, sign MS-DOS, XP, Vista, Windows 7 and anything else

  • Let's put on our thinking caps folks. Return Oriented Programing is an exploit engineering technique that uses the existing signed and/or encrypted code to create the exploit code. That means Secure Boot is defenseless to stop this type of exploit. If the application or OS code has mistakes in it then a function pointer on the stack, or in the heap (read/write memory) can be overwritten and be used by exploits via return oriented programming, and SecureBoot won't help one bit -- The code that's running is signed and/or encrypted. So if the Application or OS code isn't secure (which it won't be) then SecureBoot is pointless. What that? It won't be able to infect a boot sector? Well, if you've got malicious code running on your system then there exists an exploit vector that cane simply be re-exploited next time you boot up. See? Pointless.

    Ah, but what if the Application and OS code could be written to be secure against stack smashing and undesired code pointer manipulations? Well then, there wouldn't be any exploit vectors that you needed SecureBoot to protect you against. See? Pointless.

    Well, I say "Pointless", but what I mean is useless from an end user perspective. I don't mean to gloss over the only real use SecureBoot has: To prevent you from installing your own OSs and Applications, and having control over your own computers.

    • by Bengie (1121981)

      So if the Application or OS code isn't secure (which it won't be) then SecureBoot is pointless.

      SecureBoot is about booting securely, anything after the boot is up to the OS to handle.

      I hear the OS/Apps can be by exploited, so no point in using a firewall.

      SecureBoot can protect you against against physical access.

      I am not saying SecureBoot is the best implementation, but the basic idea of it is good. We need some form of DRM system that the user can manage to protect their system from physical access or general boot exploits.

      • I was going to mod you up but then I read your final sentence:

        We need some form of DRM system that the user can manage to protect their system from physical access or general boot exploits.

        Secure Boot is *not* (necessarily) DRM. It all comes down to who controls the keys. If the owner controls the keys then Secure Boot is a good thing. If the owner does not control the keys then Secure Boot is a form of DRM and it is a bad thing. If the user/owner has control and can use Secure Boot to protect their system then it is not DRM.

        The big danger of Secure Boot is that, unlike conventional DRM, it can be actually be made secure.

    • by mrchaotica (681592) * on Sunday December 30, 2012 @02:03AM (#42424585)

      I don't mean to gloss over the only real use SecureBoot has: To prevent you from installing your own OSs and Applications, and having control over your own computers.

      Nevertheless, you did exactly that IMO. Please allow me to reiterate for the benefit of others:

      Technical solutions as proposed above are irrelevant, because the fundamental problem here is that I SHOULDN'T HAVE TO FIND A GODDAMN EXPLOIT TO RUN MY OWN CODE ON MY OWN COMPUTER!

  • I'm supportive of this campaign, but I'm turned off by their $50.00 USD minimum for individual donations. I don't have a lot of spare income, but will often donate $5 or $10 to what I think is a good cause. I've always assumed that if enough people do likewise, my small contribution will add up to something significant.

    The only reason I can think of to justify a minimum contribution amount would be if they are issuing receipts for tax deductions and there is some cost involved in doing so. Even if that case

    • The article is wrong. I went through the links in the article and donated $10 without a problem.
  • ... it is possible for the owner to disable it.. I have no problem with this being accomplished either in BIOS settings or even if it requires placing a pin jumper on the motherboard.

    As for OS's that won't run with UEFI disabled. I have no use for them.

  • by Anonymous Coward

    I support FSF in most things, but this is an important feature.

    Rootkits are a very real problem, and SecureBoot is a good step towards eliminating them.

    As long as there is some way for the user to disable it, I'm happy. Although it could be a bit tricky to achieve that without breaking the security model. Perhaps a hardware switch that can only be accessed by removing a few screws from the case...

    • Rootkits are a very real problem, and SecureBoot is a good step towards eliminating them.

      In Windows. So how about Microsoft just allows us users of other operating systems to turn the "feature" off and just leave us the hell alone?

      Oh yeah, because then they can't squash their competition so easily--they would be forced to continue competing on fair terms like performance, features, software, and other real factors. When they release a dud like Windows ME, Vista, or Win8/RT, their customers will be unable install an alternative operating system on it, or even a different version of Windows. P

  • by gnujoshua (540710) on Saturday December 29, 2012 @10:58PM (#42423877) Homepage
    This post is a little misleading. We think Secure Boot is OK [fsf.org] so long as computer makers implement it in a way that it still allows a user to control his or her own computer. What we don't want computer makers to do is implement UEFI in such a way that a user is unable to sign their own software (e.g. bootloader) AND they are unable to turn Secure Boot off -- we call such an implementation Restricted Boot (because we want to emphasize that it instead of providing security, it exists to restrict a user from controlling his or her own device). We hope that computer makers will choose to implement UEFI in a way that truly does provide security and control, and many are implementing Secure Boot in this way.

    Joshua Gay
    Licensing & Compliance Manager
    Free Software Foundation
  • by nimbius (983462) on Saturday December 29, 2012 @11:06PM (#42423897) Homepage

    it always has been: in the community.
    when they kicked around ACPI as a standard that intentionally didnt 'just work' on linux, we made it work.
    when dvd was a big-two game, the community came together again and made that work as well
    when windows mandated the wholly superfluous 'windows' key we simply coopted it to our own desires. Awesomewm, for example.
    absolutely tireless effort was spent making sure every iteration of broken windows continued to be supported as a dual-boot option in Grub.

    We engineered solutions for their docs, excels, and even the very programs that ran only on windows in the form of Wine.
    secure boot could come, and against it will stand a threat that microsoft has consistently underestimated: Hackers. We cannot be lobbied against, or coded around. there is no NDA we recognize or understand. Im not saying UEFI shouldnt be stopped, just that if and when it comes, we have been ready since the dawn of the kernel to make it do what we want it to do.

(1) Never draw what you can copy. (2) Never copy what you can trace. (3) Never trace what you can cut out and paste down.

Working...