New Secure Boot Patches Break Hibernation 196
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.
Re:Making root not root? (Score:5, Informative)
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.
Re:Sign the hibernation file (Score:4, Informative)
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.
SecureBoot is a modern version of vendor lockin (Score:4, Informative)
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?
Re:Sign the hibernation file (Score:0, Informative)
I wish people wouldn't resort to ridiculous hyperbole when the underlying argument is reasonable.
The point of secure boot is not vendor lock-in, it's the chain of proof, as the GP attested. There are some reasons why this has downsides for FOSS, but that's the purpose.
When you say shit like this you sound like the people who say the point of DRM is to control your computer or remove your fundamental freedoms, when in actuality the point of DRM is to promote sales through reducing piracy. Whether or not it's successful, that's its point.
A more effective vendor lock-in would probably have no signed 3rd party bootloader.