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 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 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 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?

  • by Anonymous Coward on Tuesday January 29, 2013 @02:09AM (#42723227)

    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.

"Summit meetings tend to be like panda matings. The expectations are always high, and the results usually disappointing." -- Robert Orben

Working...