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
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.
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."
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.
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.
"DRM is to promote sales through reducing piracy "
No, the point of DRM is to increase profits by removing a potential threat to sales. The point of secure boot is potentially lock hardware to the operating system. The chain of proof is just a selling tactic at best but irrelevant as there are a myriad of ways to compromise a system for those with the will to do so. It's more effective as a wedge to eventually control hardware manufacture. Remember this kind of behavior wouldn't be new for Microsoft.