Forgot your password?
typodupeerror
Bug DRM Linux

New Secure Boot Patches Break Hibernation 196

Posted by Unknown Lamer
from the intentional-side-effects dept.
hypnosec writes "Matthew Garrett published some patches today which break hibernate and kexec support on Linux when Secure Boot is used. The reason for disabling hibernation is that currently the Linux kernel doesn't have the capability of verifying the resume image when returning from hibernation, which compromises the Secure Boot trust model. The reason for disabling the kexec support while running in Secure Boot is that the kernel execution mechanism may be used to load a modified kernel thus bypassing the trust model of Secure Boot." Before arming your tactical nuclear flame cannon, note that mjg says "These patches break functionality that people rely on without providing any functional equivalent, so I'm not suggesting that they be merged as-is." Support for signed kexec should come eventually, but it looks like hibernation will require some clever hacking to support properly in a Restricted Boot environment.
This discussion has been archived. No new comments can be posted.

New Secure Boot Patches Break Hibernation

Comments Filter:
  • by Anonymous Coward on Monday January 28, 2013 @08:22PM (#42721527)

    A patch that is not going to be merged into the kernel proper breaks hibernation with secure boot in Linux...some editor is trying desperately hard to get a flame war started. If you're really that desperate for ideas try something creative, like creating a fake petition to have Minecraft converted from Java to C#. It's not hard to start a flame war.

    Fucktard.

    • by tepples (727027) <{tepples} {at} {gmail.com}> on Monday January 28, 2013 @08:27PM (#42721571) Homepage Journal

      A patch that is not going to be merged into the kernel proper breaks hibernation with secure boot in Linux

      Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.

      • Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.

        My thoughts too. I'm sure that MS has requirements that you will have to meet for MS to allow you to sign a bootstrapper, like e.g. requiring that the user is prompted and alerted to the fact that the system is booted to an alternate OS. Otherwise (if they allowed silent boots to non-Windows OSes) they would risk a rootkit simply silently booting a Linix and then Windows within a compromised VM. However, it is hard to see how an attack using the Linux hibernation and/or kexec vectors could lead to a comprom

        • by Rockoon (1252108)
          A compromised system could simply always hibernate even when the user requests a proper shutdown, and then fake the appearance of a real bootup upon power up.

          While you would not expect such an elaborate design as a form of mass public malware, consider how effective this would be with a more targeted attack.. the trusted boot process nullified to trivially.
      • by Trogre (513942) on Monday January 28, 2013 @09:17PM (#42721929) Homepage

        Is no one else here alarmed at the unreasonable amount of power Microsoft has over the future of GNU/Linux on Secure Boot platforms?

        That alone should be cause enough to lobby hardware manufacturers to have secure boot abolished and to hell with those little "Works with Windows 8" stickers.

        Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot. Therefore the only software that will boot on these systems is software that Microsoft has blessed. I know they would love nothing more to dictate such terms on x86 hardware too. I predict that within five years, notwithstanding active opposition RIGHT NOW, they will do exactly this.

        This, like climate change, is something I really, really hope I am wrong about but fear that I am not.

        • by vux984 (928602)

          Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot.

          if they ship with Windows 8 RT.

          There is nothing stopping asus/acer/google/ and who ever else out there from releasing ARM platforms with secure boot configured any way they like.

          Perhaps, at worst, we are reaching a point int time where if you want a Windows PC you will buy one, and if you don't want a windows PC you will buy one without windows.

          And the people looking to take a windows PC and conve

          • by Nerdfest (867930) on Monday January 28, 2013 @10:24PM (#42722315)

            I just bought a very nice laptop from System76. Good price/performance, fantastic Linux comparability, and no Microsoft tax. I figured I might as well put my money where my mouth is on supporting vendors that have good support for Linux.

          • by hairyfeet (841228)

            And the people looking to take a windows PC and convert it to a linux pc... well they're will always be someone you can take it to to flash an open bios or otherwise 'unlock it'.

            Or those people along with anyone else who actually cares about open hardware could just put their money where their mouths are and buy AMD who is switching to Coreboot [coreboot.org] which is a FOSS BIOS/UEFI replacement. After all no need to "flash an open BIOS" if you already have one.

          • and if you don't want a windows PC you will buy one without windows.

            Good luck finding a PC without Windows that isn't made by Apple in U.S. retail chains. Good luck figuring out how to try the keyboard and screen of a laptop made something like System76 before buying. And good luck connecting the laptop to the Internet should major home ISPs adopt Trusted Network Connect [slashdot.org] as a measure against spam, viruses, and mass copyright infringement.

            • by vux984 (928602)

              Good luck finding a PC without Windows that isn't made by Apple in U.S. retail chains.

              Fast forward to a world of locked bootloaders and I could see PC vendors having a "no-OS, bare hardware, unlocked bootloader" checkbox on every single system they sell.

              It would cost vendors little to do this.

              The reason that it doesn't exist today is because you can already buy any computer you like and put whatever you want on it. So there is no real advantage in offering a no-OS, hardware only solution.

              • Fast forward to a world of locked bootloaders and I could see PC vendors having a "no-OS, bare hardware, unlocked bootloader" checkbox on every single system they sell.

                Unless Microsoft changes the terms of the Windows OEM license to make it economically infeasible to offer such an option, such as its crusade a few years ago against the "naked PC" [zdnet.com].

                It would cost vendors little to do this.

                Other than likely having to pay full retail for Windows if the same company sells PCs without an operating system.

        • Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot. Therefore the only software that will boot on these systems is software that Microsoft has blessed.

          That's just plain wrong. Samsung can ship Android tablets just fine without it even having Secure Boot.

          Last I heard, Samsung shipped a lot of "ARM platforms" with Android and Windows 8 PCs and Windows RT tablets just fine so that means jack shit.

          • by Trogre (513942)

            Perhaps I should have been clearer:

            Microsoft have already mandated that systems with ARM platforms MUST NOT have an option to disable Secure Boot, in order to qualify for Windows 8 hardware certification.

            Source [microsoft.com]:
            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. A Windows Server may also disable Secure Boot

            • Unlike Intel, the market of ARM hardware does not have Microsoft as a dominant player - indeed, its market share there is minuscule. If you want to buy an ARM device that runs Linux, you've got plenty of choices, from Chromebooks to various Android tablets to dedicated GNU/Linux devices. I very much doubt that Linux kernel developers (or the community as a whole) really care that much about the ability to install Ubuntu on their Surface.

        • To many X86 servers do not boot Windows for them to try to push that kind of lock down.

          • by 0123456 (636235) on Monday January 28, 2013 @10:33PM (#42722365)

            To many X86 servers do not boot Windows for them to try to push that kind of lock down.

            Yeah, so? Your $1,000 server motherboard will still be able to run Linux. Doesn't help the rest of us.

            If you give Microsoft the power to control what software will and won't run, then they will use it, sooner or later. It's a fscking retarded idea.

            • by exomondo (1725132)

              If you give Microsoft the power to control what software will and won't run, then they will use it, sooner or later. It's a fscking retarded idea.

              And how exactly would one do that? You mean every motherboard manufacturer is going to build every one of their products locked to Windows 8?

              • by jimicus (737525)

                And how exactly would one do that? You mean every motherboard manufacturer is going to build every one of their products locked to Windows 8?

                They don't need to.

                Linux didn't get where it is today - where more and more non-technical people are trying it every day, where lots of people are saying "actually... this is pretty good. Shame it's terrible for X (where X is something like games) or I'd switch in a heartbeat" overnight. It was a long journey consisting of thousands of baby steps.

                For much of that time, very few would even contemplate trying Linux on the desktop.

                If - and while it's a big "if", I don't think it's an inconceivable one - Micros

        • by Smauler (915644)

          Is no one else here alarmed at the unreasonable amount of power Microsoft has over the future of GNU/Linux on Secure Boot platforms?

          This is one of the reasons why I'm very behind what Valve are doing now - they are pushing for OS independent systems. Yes, they have DRM. They also provide a service better than your games on disks too. I'm absolutely hoping they'll push steam hard, and bring linux with them.

          The only reason I use Windows is for games. If there was another place I could get new, big games

          • by tepples (727027)

            The only reason I use Windows is for games. If there was another place I could get new, big games, I'd switch in a heartbeat.

            If you're willing to give up all amateur games, you could always switch to a console.

        • It's not just about the stickers. It's about the OEM volume deals that come with the stickers. Lose the sticker, and the per-unit licensing cost shoots up by a hundred dollars or so, in an industry where the margin is less than that. As it's not practical to mass-market a machine running anything other than Windows (Imagine the return rate by uneducated users - most of them don't even know what an operating system is), that means that when MS demands something the OEMs have no option but to comply.

          • Lose the sticker, and the per-unit licensing cost shoots up by a hundred dollars or so,

            For a (near) monopoly to do that is a clear breach of EU competition law. Expect someone to realise this will solve Greece's debt problems very soon.

      • AFAIK only boot loaders like shim have actually been signed by Microsoft. But, you may be right...
      • by exomondo (1725132)

        Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.

        Microsoft doesn't control the certificates, VeriSign does, Microsoft can't just 'revoke' certificates and stop SecureBoot from loading them, they don't control any of that.

        • Perhaps the fear is that if the patch is not merged, Microsoft will revoke the certificates that have been used to sign mainstream GNU/Linux distributions.

          Microsoft doesn't control the certificates, VeriSign does, Microsoft can't just 'revoke' certificates and stop SecureBoot from loading them, they don't control any of that.

          Yes they do. The bootload'ers used for booting Linux are signed by Microsoft. The Linux community *could* work with vendors do have a "Linux" certificate installed in the firmware which would allow other boot-loaders to boot. But given the number of vendors that has been deemed impractical. Instead Linux distros (and Matthew Garett) have created boot loaders/shims which are chain-loaded from Microsofts boot-loader. As such they need a MS key.

          Presumably MS has a number of restrictions on how such a boot load

      • by hairyfeet (841228)

        But again its total flamebait as there has been ZERO word or indication to state a position by MSFT one way or another when it comes to the issue.

        Personally I think old Ballmer has too damned much on his plate to give a shit about Linux one way or another ATM, he has pretty much bet the farm as well as his own rep (for what little that is worth) on a strategy that might as well be written in crayon on the back of a napkin, namely "Become Apple" which he is learning, just as HP and RIM learned before him, t

        • Personally I think old Ballmer has too damned much on his plate to give a shit about Linux one way or another ATM

          Then why has B-17 Ballmer's company continued to pressure manufacturers of Android smartphones, charging them as much for the use of FAT file system patents and other essential patents as it would charge for a license of Windows Phone itself?

          namely "Become Apple" which he is learning

          Hence the patent suits.

          Have you SEEN the new Acer ChromeBook? You have an X86 CPU, hard drive, RAM, etc that are so bog standard it hurts yet is so locked down you can't even run Linux X86 on the damned thing!

          To reformat an Acer Chromebook into developer mode [arstechnica.com], hold F3 and Esc while turning on the power, then press Ctrl+D.

    • by Lakitu (136170)

      A patch that is not going to be merged into the kernel proper breaks hibernation with secure boot in Linux...some editor is trying desperately hard to get a flame war started. If you're really that desperate for ideas try something creative, like creating a fake petition to have Minecraft converted from Java to C#. It's not hard to start a flame war.

      why would that start a flame war? Java and C# are basically equivalent.

      • why would that start a flame war? Java and C# are basically equivalent.

        Maybe that would exactly be the first spark. "Why the hell would you do that?!? They are basically equivalent!!" Then some passionate Java or C# coder would point out that "they are FAR from equivalent, just see how this garbage collection feature is implemented much more nicely..."

    • by Curate (783077)
      I agree this article is flame bait, because the patch in question does NOT break hibernation. It only breaks resume from hibernation.
  • Seriously? A patch to block root users from running kernel images? This is like how it works in Windows: applications not running as root aren't allowed to unsigned kernel code. What's the point of making root not root?

    Is he going to disable the 50 other ways in which root programs could take over the kernel, too?

    • by Rockoon (1252108) on Monday January 28, 2013 @08:34PM (#42721611)
      You really dont seem to understand the technologies involved.

      Hibernation does a complete dump of the memory and thread state of the system to disk, and when the computer is later booted a well behaved loader sees the dump and restores the memory and thread states from disk.

      The problem is that anyone with physical access can fuck with the memory dump in between the hibernation and the restore, thereby injecting untrusted code into the supposedly trusted environment.

      But thanks for giving us your ignorant opinion.
      • by tepples (727027) <{tepples} {at} {gmail.com}> on Monday January 28, 2013 @08:41PM (#42721653) Homepage Journal

        The problem is that anyone with physical access can fuck with the memory dump in between the hibernation and the restore

        Anyone with physical access can probably reset the BIOS password and turn off secure boot. But barring that, perhaps one solution is to sign the memory dump with a key stored in the TPM.

        • by Rockoon (1252108) on Monday January 28, 2013 @09:01PM (#42721811)

          Anyone with physical access can probably reset the BIOS password and turn off secure boot.

          The point of secure boot is to make possible a chain of proof attesting that everything that gets loaded into ring0 has not been modified. Clearly if you can disable the chain of proof then you can disabled the chain of proof, but you cannot do so invisibly, which is the entire point of secure boot.

          • by 0123456 (636235) on Monday January 28, 2013 @10:35PM (#42722371)

            The point of secure boot is vendor lockin. The point of Linux is to not be locked to a vendor.

          • Anyone with physical access can probably reset the BIOS password and turn off secure boot.

            The point of secure boot is to make possible a chain of proof attesting that everything that gets loaded into ring0 has not been modified. Clearly if you can disable the chain of proof then you can disabled the chain of proof, but you cannot do so invisibly, which is the entire point of secure boot.

            So, uh, wouldn't we just then perform a SHA512 hash of the dumped hibernation memory? A salted hash is good enough to detect tampering if you're not concerned about hiding the data in the dump. A loader would then perform the same salted hash of memory as it's loading it and abort if the resulting hash doesn't match the on-disk hash. Of course the same code signing chain technology Secure Boot employs can be used to sign the salt & hash to ensure the dump's integrity.

            OK, here's the thing: Is ther

            • by sFurbo (1361249)

              here's no need to even tamper with the boot sector because said malware can simply re-exploit the OS after it's booted up.

              I think the point of secure boot is that today, once the system is rooted, you can install a hypervisor and own the system forever. Repairing the original hole does not save an already rooted system. With secure boot, if the hole is repaired, the system cannot be re-rooted, so any exploits that used that hole are now gone.

        • RTFA, for chrissake.

          The reason behind disabling hibernate functionalities is that currently the Linux kernel doesn’t have the capability of verifying the resume image when returning from hibernation, which compromises the Secure Boot trust mode

          The stupidity, confusion, lies and just plain FUD in every secure boot thread on Slashdot is just plain amazing.

          • Regardless of the SecureBoot issue, the loading of an unverified resume image is a security issue that should be resolved anyway...

            • by DarkOx (621550)

              No its really not. If you can tamper with the resume image it basically means you had physical access to the machine, or something equivalent if the machine is a VM.

              Full disk encryption available on Linux via LUKS can protect the integrity of the resume image. So there is no reason, none, nadda, for the kernel to have some second method to verify the integrity of the suspend to disk image.

              If you are not running FDE than anytime a system has been outside of your physical control it should be assumed to be

              • by DarkOx (621550)

                Replying to my own post. Okay there is one reason to have some secondary method. That reason would be to prevent the lawful owner of said machine who controls the disk encryption keys from altering the image. Which I don't consider to be a legitimate reason. Its my machine I should be able to load anything into its memory I like; by any method I can make work.

          • by tepples (727027)
            From the article:

            currently the Linux kernel doesn’t have the capability of verifying the resume image when returning from hibernation

            I suggested how to add such "capability of verifying":

            perhaps one solution is to sign the [resume image] with a key stored in the TPM.

            I'd be willing to explain this suggestion in more detail. What questions do you have?

    • by citizenr (871508)

      Seriously? A patch to block root users from running kernel images? This is like how it works in Windows: applications not running as root aren't allowed to unsigned kernel code. What's the point of making root not root?

      Is he going to disable the 50 other ways in which root programs could take over the kernel, too?

      This is the precise point of TPM - it takes away control over the computer from user/admin. "Your" computer is not yours anymore.

  • by detain (687995) on Monday January 28, 2013 @08:26PM (#42721567) Homepage
    I think this patch, while it probably wont be something we want in the kernel in the long run, at least is bringing attention to more people that we need to work on kexec and hibernation to better support the secure boot trust model. It offers a solution that does keep a system following the secure boot trust model, and once some people are able to keep a system following that model, they will to keep following the secure boot model but insist on all the old features working again. Hopefully there is enough of this type of push towards getting kexec and Hibernate improved so his patchs ultimately become obsolete.
    • by Junta (36770)
      The SecureBoot model is, frankly, a joke. As soon as you leave the realm of vendor provided OS content, it provides nearly zero protection. Hibernation can't fit into the SecureBoot model, the memory image cannot possibly be signed by the OS vendor private key. kexec could be hypothetically modified to require a signature be passed, but userspace could *look* just like something kexec would produce. Fullscreening qemu-kvm comes to mind...
      • You could sign the hibernate image with a key that is sealed by the TPM.
        • by lingon (559576)
          Unless you passed the entire memory image trough the TPM, how are you going to accomplish this without compromising the key to the operating system?
          • Unless you passed the entire memory image trough the TPM, how are you going to accomplish this without compromising the key to the operating system?

            Let's see. How about computing a hash of the memory and pass that through the TPM?

            I mean, like it is *always* done when digitally signing something.

          • by lindi (634828)

            When you sign an image you actually just first calculate a hash of the image and then sign that hash. It is easy to send the hash to the TPM. The key does not need to exit the TPM at any point.

  • Fuck Secure Boot (Score:5, Insightful)

    by Anonymous Coward on Monday January 28, 2013 @08:42PM (#42721671)

    It's my goddamn computer, my goddamn hardware, and it's MINE. I will run any fucking operating system I goddamn well please on it, and if Microsoft doesn't like that, they can FUCK THEMSELVES right in the GODDAMN EAR.

    • by UltraZelda64 (2309504) on Monday January 28, 2013 @09:38PM (#42722059)

      Why the downmods? Yeah, maybe the AC was just trolling, but his overall point I actually agree with. If anything, it should've been modded +1 "Funny" for the "fuck themselves in the god damn ear" part.

    • It's my goddamn computer, my goddamn hardware, and it's MINE. I will run any fucking operating system I goddamn well please on it, and if Microsoft doesn't like that, they can FUCK THEMSELVES right in the GODDAMN EAR.

      Or you can just disable it...

      • by grcumb (781340) on Tuesday January 29, 2013 @02:03AM (#42723201) Homepage Journal

        It's my goddamn computer, my goddamn hardware, and it's MINE. I will run any fucking operating system I goddamn well please on it, and if Microsoft doesn't like that, they can FUCK THEMSELVES right in the GODDAMN EAR.

        Or you can just disable it...

        What, and miss the chance of seeing Ballmer fuck himself in the goddam ear?

        Shyeah....

    • by blueg3 (192743)

      It's only yours if you buy it. I suggest not buying hardware with Secure Boot, if it bothers you so much. But then, all x86 hardware with Secure Boot is required to have the option to disable that feature. So, you could take that route, too.

  • Conceptually.. (Score:5, Interesting)

    by Junta (36770) on Monday January 28, 2013 @08:48PM (#42721719)
    What distinguishes hibernated memory image from, say, an initrd? Practically speaking, a distro has to allow for initrds to boot that aren't signed by the distribution. In fact, what about booting *any* filesystem? Some may suggest that the goal would be to have every binary signed, but what about end-user maintained scripts and config files? SecureBoot as currently defined only about the OS provider signing what they provide and that leaves a whole lot of area for malicious content outside that scope. It's of little comfort that you have assurance that you are running the correct sshd if, for example, you have malicious ssh_config and malicious authorized_keys.
    • Re:Conceptually.. (Score:5, Insightful)

      by mjg59 (864833) on Monday January 28, 2013 @09:26PM (#42722001) Homepage

      The kernel can execute ring 0 instructions. Your initrd can't. The difference is that you could construct an appropriately modified hibernation image that booted an arbitrary kernel - or even an entirely separate OS. In that scenario, your kernel is effectively a new bootloader, except unlike the signed bootloaders it'll happily boot an entirely unsigned OS. That's unlikely to end well.

      But, conceptually, you're right. Secure Boot doesn't magically make a system secure, but it *is* a vital part of system security - if you can't trust your kernel, any other security you attempt to build is pretty much pointless.

    • by Cassini2 (956052)

      Better question: Wouldn't Microsoft Windows have exactly the same hybernation-resume problem?

  • by sethstorm (512897) on Monday January 28, 2013 @09:13PM (#42721899) Homepage

    Secureboot is the problem and disabling it(or getting rid of the device for a freer one) is the solution.

    • Unfortunately, if you have a Windows 8/RT ARM-based system, disabling Secure Boot cannot be done... so that's not always a solution. Just when we finally get ARM systems useful as general purpose computers to replace x86 instead of being limited to using ARM in pathetic special-purpose systems like routers and cell phones, Microsoft swoops down and fucks everything up. As usual, Microsoft is here using their abusive powers to wreck the day.

  • Secure boot isn't. There is no point in hacking our way into Secure boot because it isn't secure, period. There is always a way around every security design and hobbling the industry with a proprietary technology isn't going to help anyone but incumbent large players. Secure Boot is nothing more than an attempt by Microsoft and other entrenched players to exclude smaller companies. The only secure idea at Microsoft is Linux!
    • Secure boot isn't. There is no point in hacking our way into Secure boot because it isn't secure, period. There is always a way around every security design

      Right. Why do we bother with security in the first place? Let's just disable security features on every system because they will be circumvented anyway. What an absurd argument.

      and hobbling the industry with a proprietary technology isn't going to help anyone but incumbent large players.

      Secure Boot isn't proprietary. It is specified bye UEFI where several of the Linux distros have been represented. Not that you'd know from the hyperbole by some of them, MJG included.

      Secure Boot is nothing more than an attempt by Microsoft and other entrenched players to exclude smaller companies. The only secure idea at Microsoft is Linux!

      Personally I'd like my bank, my government, the military, the SSL issuers to set up their systems so that they'll know if their systems (on which I depe

      • by DarkOx (621550)

        The issue these patches are addressing though have nothing to do with security from the perspective of the machines owner.

        I agree a bios that only executes and signed boot loader and boot loader that only executes a signed kernel image *could* be valuable tools to enable an operator to validate the machine has not been compromised. As the machines owner though *I* not anyone else unless I so designate should have the ability and possess the sole authority to sign boot loaders and kernels.

        There is no legiti

  • ... because hibernate is pointless and never reliably works anyway. Set everything to autosave and get a distro that boots up quickly.

    • by celle (906675)

      "Set everything to autosave and get a distro that boots up quickly."

            And use SSD drives in your machine. If you still have a problem, switch to decaf.

  • by Damouze (766305) on Tuesday January 29, 2013 @01:28AM (#42723069)

    SecureBoot is nothing more than a modern kind of vendor lock-in, so why support it at all? Haven't the FSS and OSS communities by now gained enough leverage on their own to stimulate the development of software in the direction it should go, namely that essential software, like an OS, a BIOS or a piece of firmware, should be free (in the FSS sense) for use by anyone?

    By accepting and even supporting suspicious software and business models such as SecureBoot, aren't the FSS and OSS communities more or less digging their own graves because Microsoft - who admittedly has changed a lot for the better the last few years - owns the very keys their software relies on for proper functioning?

  • Secure Boot or Hibernation.

Work is the crab grass in the lawn of life. -- Schulz

Working...