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.
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.
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.
"His name was James Damore."
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.
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.
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.
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.
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.
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.