On Fri, May 29, 2020 at 9:12 PM John M. Harris Jr <joh...@splentity.com> wrote: > > On Friday, May 29, 2020 5:25:23 PM MST Chris Murphy wrote: > > On Fri, May 29, 2020 at 6:06 PM John M. Harris Jr <joh...@splentity.com>
> > >You can test hibernation right > > > now, and it will work. When you boot back up, it'll have everything just > > > as you left it. What systems is it broken on, those with Secure Boot? > > > > Not broken, disabled. That's the policy both upstream and in Fedora. > > Then why not just re-enable it? Why in the world is it disabled? It's a security risk that is incompatible with having UEFI Secure Boot enabled. The entire point of UEFI Secure Boot is to ensure cryptographic verification that the kernel you're running is in fact a Fedora built and signed kernel. Since resuming from hibernation completely replaces memory contents with that of the image, if the hibernation image isn't cryptographically signed too, it's an attack vector that permits arbitrary code execution, including even in the kernel. I will add a footnote clarifying this in draft 2. The proper enhancement is signed and encrypted hibernation images. If people want this to work, it's highly recommended they look into picking up the stalled work in this area. There is hardware attrition under way. And that means hibernation is getting tested less and less, with fewer kernel and desktop bug reports. And testers. It's a real going-concern problem. >If it's > disabled, why did it work when I ran `systemctl hibernate`? Why does it work > with KDE Spin out of box? Your system doesn't have UEFI Secure Boot or it isn't enabled. With Secure Boot enabled, hibernation is one of many things that is subject to kernel lockdown across all of Fedora products including KDE. https://lwn.net/Articles/706637/ > I asked above, but it wasn't answered, and your answer to this has me a bit > confused. Is Secure Boot the issue that is blocking resume from working > properly? If so, I can ensure that Secure Boot is enabled on the hardware that > supports it, and try hibernation there. UEFI Secure Boot does not do the blocking. But it is used to enable the kernel lockdown policy, and the lockdown policy inhibits various things including hibernation. Specifically it will block both hibernation entry and resume. [ 0.850908] Lockdown: swapper/0: hibernation is restricted; see man kernel_lockdown.7 $ sudo systemctl hibernate Failed to hibernate system via logind: Sleep verb "hibernate" not supported Which also results in this: [109941.217325] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 > > Regardless, if that's the case, wouldn't it make more sense to keep > hibernation available in the UI where it's supported well, the systems without > Secure Boot? A trivial check for that could be false if BIOS, and false if > efivars doesn't show that it was booted with secure boot. I don't know whether or when there will be any changes to UI. I think it's already conditional now. The option to hibernate appears in the GUI on my test system that can hibernate and doesn't appear on the systems it's not supported on. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
