Slashdot Mirror
New Secure Boot Patches Break Hibernation
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.
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.
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?
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
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.
http://interserver.net/
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.
My system doesn't hibernate, it passes out from exhaustion.
You could try setting up lm-sensors. Or is your motherboard not supported?
No, "Secure" Boot is overrated. Very few people have any need for it; mostly a tool for corporate entities to strong-arm others in to complying with their every whim.
Because presumably windows verifys the kernel image as it's loading hyberfil.sys into memory, did you not even read the summary?
The leap that TFS needs you to make is that with an unverified hybernation image you can simply remove the disk, overwrite it with an unsigned and modified kernel image and then have the hybernation process load it into memory for you from the trusted boot chain.
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.
That was the sound of the joke going over your head.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
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.
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.
XML is like violence. If it doesn't solve the problem, use more.
it was the same issue with 'winmodems' back in the 90s. yeah its shit, yeah its stupid, but its whats on sale at Best Buy and what teenagers have when they go to college and learn what "GCC" is.
(and by then, you can be damned well sure that SecureBoot will be MANDATORY on all x86 systems- why? Because everyone went along with it, that's why)
Actually it's already kind of mandatory in all new systems, because MS made it a requirement for a system in order to bear the Windows 8-certified logo.
So yeah, if you are a company and want your systems bearing the Win8 certified logo then you have to have Secure Boot enabled and there is absolutely nothing Linux community can do about it.
The practical answer to that concern would be why is the kernel so damn special. You could hijack any number of equally important processes, security wise. init, sshd, apache, any shell, web browser, whatever. Replacing kernel pages in reality isn't really that important if you have access to the entire suspend image...
XML is like violence. If it doesn't solve the problem, use more.
Secureboot is the problem and disabling it(or getting rid of the device for a freer one) is the solution.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
And what is it needed for? Are there any disadvantages from not having it? Will there be any? What are the advantages?
I want to get a new machine. Will more or less secure boot affect the ability to run OS X?
Feel free to answer, whoever answer doesn't have to answer in detail if they don't want to. And no I won't try to google for it all atm.
That's long overdue!
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!
NOT peanut butter & chocolate.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
To many X86 servers do not boot Windows for them to try to push that kind of lock down.
... because hibernate is pointless and never reliably works anyway. Set everything to autosave and get a distro that boots up quickly.
My little Linux and tech blog
I promise I'll stop doing so as soon as someone produces a more accessible user-friendly OS and a more feature-complete Office suite.. If you're not actively contributing to either of these then you're not helping make the problem go away.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
I'm not the one complaining. As I said, provide me with an alternative and I'll stop giving them money. Otherwise it's really just a lot of hot air and noise.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
No hibernation means slow boot and slow boot will make linux more cumbersome for new users. If ubuntu (a.k.a. linux) becomes cumbersome for new users they will tell their friends how sucky linux is. And then their friends, despite of unity, will not switch to ubulinux.
I think, I don't have to spell out the possible horrific consequence: 2013 might not be the year of the linux computer.
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?
And on the Eighth Day, Man created God.
The practical answer to that concern would be why is the kernel so damn special.
You can argue that a particular OS is sloppy in its userland security, but its a bit odd to argue that the kernel isnt worthy of being protected because of that sloppy userland security.
"His name was James Damore."
Because the kernel has complete control. Sure you can compromise ssh/init, but those are userland processes and any other userland process can verify those images are what they should be.
But breaking into the kernel and injecting your rootkit that way means no userland process can verify that the binaries running are NOT compromised. Plus, the kernel has hooks into every process so it can do things that no process itself can do without kernel assistance. So if you wanted a key logger, the kernel can hide it very well.
It's a good point - Linux should be embracing trusted boot technology for higher security operations - we already know of BIOS based OS attacks. Heck, there's one that legitimately installs itself on every hard drive running Windows - if you buy a PC with support for LoJack and have it install itself into the BIOS, everytime the BIOS initializes LoJack, it checks for its files. If not, it hooks itself into Windows so it auto-installs on a new hard drive for computer tracking. Given the vulnerabilities in that module, or other BIOSes, it's possible for a Linux system to be compromised and no one noticing.
Sure, it was invented by Microsoft, and Microsoft (on x86) enforces the user's ability to do an untrusted boot. But Linux has signed bootloaders which allow the user to boot their own self-signed kernels. Given this, why shouldn't Linux have the ability to continue a chain of trust?
It's only a matter of time before some smartass designs some Stuxnet like thing that impacts Linux systems. Maybe most users don't care, but having a server that doesn't boot because the kernel failed the signature check might be necessary for security purposes. Hell, if your financial systems run Linux (including credit card processing systems...)... wouldn't it be nice as an admin to know their ssytems haven't been compromised surreptitiously?
No, I think he's straight on. Secure boot stems from a broken threat model: that kernel access is extremely important. I know about userspace security, but the kernel already secures userspace without secure boot and proper privilege separation secures the kernel. Secure boot is a way of securing the system from root, which is futile (look at SELinux, for example).
This is primarily a technology for vendor lock-in. Always has been, always will be.
Your comments about kernel control and security is spot on. I don't get the "we already got enough security" argument at all. It's like the mantra that Linux somehow is inherently the most secure OS imaginable has gotten the best of some of the community and they actually started believing that there's nothing more to do.
Sure, it was invented by Microsoft, and Microsoft (on x86) enforces the user's ability to do an untrusted boot.
Not sure it was invented by Microsoft. It was specified by UEFI and certainly *pushed* by Microsoft. Parts of the Linux community in an effort to paint everything MS does as inherently bad tried to label Secure Boot bad and then let Microsoft own it. Fortunately that has largely failed.
But Linux has signed bootloaders which allow the user to boot their own self-signed kernels. Given this, why shouldn't Linux have the ability to continue a chain of trust?
Given that Linux is being trusted with large part of our infrastructure I'd say that Linux pretty damn well *must* guarantee a chain of trust. I do not want my bank, government, SSL issuers etc. to be operating compromised systems. As this story illustrates there is still some way to go. When Windows boots it *only* trusts MS signed cabinet files where both executable code, resources and configuration resides. I believe that there's also a weakness in Linux where the configuration can be compromised outside the signing support of some distros.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
"Sure, it was invented by Microsoft, and Microsoft (on x86) enforces the user's ability to do an untrusted boot. But Linux has signed bootloaders which allow the user to boot their own self-signed kernels. Given this, why shouldn't Linux have the ability to continue a chain of trust?"
Because Microsoft can't be trusted. They've proven it time after time. And they certainly can't be trusted to load a competing OS. What happens when Microsoft doesn't have to support XP and Vista any longer and says/pays/both to OEMs "You know that option to turn off secure boot, forget that." "Oh yea, activate the code to lock all internet connected secure boot computers to secure only". Many OEMs already make getting to the secure boot off option as difficult as possible, likely at Microsoft's bidding. Secure boot is a vendor lock-in toy and that's it. Otherwise, Microsoft could have done this ten years ago. Oh that's right, they might have been cutting their throats with the convicted monopolist status they had.
"They suspected that the attackers somehow compromised the system of one of the users and used his access to the systems."
I heard something about the lazy idiot between the screen and the chair. Secure boot doesn't and can't fix stupid.
So when a system is compromised for most of a month, potentially putting users who download binaries at risk and certainly putting them at risk of being served malware coctails, you are ok with the admins not discovering it because you blame the user whose account was compromised?
How about blaming Linux security for attackers being able to root multiple systems from a user account.
And do you feel comfortable that just because you can blame a user it is ok that the admins did not notice anything was wrong before some of the malware emitted error messages which should not come from a server system?
Secure Boot could have prevented the compromise from going on for so long. Who is stupid, really?
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
"vendors who don't/won't produce "label-compliant" products are less likely to receive "marketing assistance" payments from Microsoft."
Just call it bribes and be done with it. Or maybe even kickbacks, etc.
At least he didn't call it $ecure Boot.
PlusFive Slashdot reader for Android. Can post comments.
Secure Boot or Hibernation.
I found it odd that they disabled it. I have re-enabled it in all of my Ubuntu systems and it works perfectly. There's much worse bugs in Ubuntu than hibernation support.
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 as a measure against spam, viruses, and mass copyright infringement.
How in the world has Microsoft, one single software firm, managed to usurp power enough to dictate to hardware manufacturers
It started in 1981, when IBM was looking for an operating system for its 8088-based IBM PC. Microsoft offered to undercut DRI's CP/M by buying the rights to the 86-DOS product from Seattle Computer Products, a company that had sold computer kits built around the Intel 8086 microprocessor, of which the 8088 was a cost-reduced variant. SCP had designed 86-DOS to allow developers of CP/M programs to make quick ports, and at the time, there wasn't much existing software for 8086 computers on which big companies were already relying. So a switch from CP/M to 86-DOS wasn't nearly as painful as a switch from Windows to GNU/Linux would be today.
are we headed towards a second, 'scientific' dark age?
We're already in a cultural dark age due to digital restrictions management on motion pictures and video games.
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, hold F3 and Esc while turning on the power, then press Ctrl+D.
So that you could monitor in how much pain it is in?
Yes, and this lets you trigger the CPU fan to turn on or speed up whenever the CPU is under stress. This way you get nice, quiet operation when the computer is running undemanding applications such as editing the low-definition version of a video, or loud operation when you're out of the room and the computer is running something similarly CPU-demanding with all cores blazing, such as applying the chosen edits and effects to the original high-definition footage.
When I see Schroedinger's joke, a comment that both is and isn't a joke depending on how it's read, I try to make Schroedinger's reply. If the parent comment wasn't a joke, as in the case of my cousin's laptop that has a habit of overheating, my comment is helpful. If it was, my comment is a joke too. KingRobot is perceptive.
If that much security is your concern, shut down properly to save power and eat the time waste of startup, or don't shut down and just leave it running.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
No one but Microsoft has any need for it. For starters, it doesn't serve its advertised purpose -- if it did, we'd see drivers getting blacklisted for ring 0 holes left and right, and I'm not aware of Microsoft blacklisting a single one. So it's not about preventing those eevil haxors from haxoring your machine. What is it for, then? Making sure competition to Windows never goes mainstream.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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".
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.
How about the ability of an OS to use all Windows-compatible software, and the ability to get the computer without OS as cheaply and conveniently as one with Windows?
For many Windows-compatible products, I can do as well or better on Linux (one example: the kernel). For many, there is no satisfactory FLOSS equivalent. This is particularly true of a lot of niche products, which can be crucial to many businesses. Also, many people need something Microsoft-Office-compatible, and there is no such thing. Other office suites might suit them better for their own work, but they need to exchange Word documents with others.
If I need a computer now, and go to a store, I've got a choice of Windows, and maybe MacOSX. I haven't found a local store that stocks Linux or no-OS computers. If I shop on line, I am a lot more likely to get what I specifically want for at least as low a price if I buy it with Windows, wipe it, and install the Linux distro of my choice. I'm not allergic to putting my own desktops together out of components, but I'm not assembling my own laptop.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
No big deal. As I noted above, I am quite willing to admit that I missed your joke as well.
It's possible that I bow to your superior quantum level of humor.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
most people use them as a tool and don't want to be tweaking them and configuring them
So what should one someone who owns a device do when he wants to use the device as a tool but discovers that a particular application is not available for his device because the device's monopoly gatekeeper rejected the concept? For example, someone who plays video games might want to try his hand at making a mod, but games for a certain platform aren't especially mod-friendly. It's a question of headroom for upward mobility.
If I don't as the machines owner feel I have the need or desire to preserve a chain of trust; nobody should force me to do so.
Then shut off Secure Boot and resume into your unsigned hibernation file.
Hibernation actually is a security hole. I'll ignore the kexec issue for now, but encrypted and checksummed hibernate images would be a good thing, and would be nice on a non-SecureBoot system as well. At a minumum, the hibernation image should carry a checksum of { the image data + the kernel that loaded it + relevant platform data }. That would at least prevent partially booting a suspend image with random corruption. Can SecureBoot also provide a secret key used only to encrypt the suspend image and decrypt it during boot? Or some additional data to feed into the checksum that securely identifies the platform? Or keep the suspend checksum in nonvolatile memory that can only be written to by a trusted operating system?