Bug 1467045 - Hibernate no longer works when Secure Boot is enabled
Summary: Hibernate no longer works when Secure Boot is enabled
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1549844 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-02 08:57 UTC by dac.override
Modified: 2018-11-06 11:46 UTC (History)
38 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 13:21:42 UTC


Attachments (Terms of Use)

Description dac.override 2017-07-02 08:57:51 UTC
Description of problem:

systemctl hibernate no longer works as of 233-6

Version-Release number of selected component (if applicable):

233-6

How reproducible:

systemctl hibernate

Steps to Reproduce:
1. systemctl hibernate
2.
3.

Actual results:

not hibernating

Expected results:

hibernate

Additional info:

Comment 1 Matthew Gilbert 2017-07-17 15:44:18 UTC
I also see this. Worked for me in early F26 alphas, but stopped working and still no longer works. I am also running systemd 233-6. Unfortunately, hibernate is the only sleep method that works on my laptop!

Comment 2 verdre 2017-07-17 17:31:39 UTC
Working fine running systemd 233-6 here, I have a bit of a weird setup though with a swapfile on an encrypted root partition.
Did you add the dracut resume module to your initramfs?

Comment 3 dac.override 2017-07-17 17:36:19 UTC
Did you do a clean install of Fedora 26 Release?

It seems both of use updated from 26-Alpha to Release. So it may be related to the upgrade path?

Nonetheless "sleep verb not supported by systemd-logind" seems unrelated to dracut and initramfs to me.

Comment 4 verdre 2017-07-17 18:14:35 UTC
So the screen doesn't even turn off after systemctl hibernate for you?

I also used it since the Alpha-Release and hibernate is working on both my desktop pc and laptop.

You might want to try another kernel though. With 4.11 my laptop refuses to boot after hibernating and I can't test with 4.11 on my desktop.

Comment 5 dac.override 2017-07-17 18:17:17 UTC
Screen does not turn off, systemctl hibernate just returns.

Ive migrated to rawhide in the meanwhile and there it works again. (Linux 4.13RC0 + systemd v234)

So can't really easily test it on Fedora 26 anymore

Comment 6 Matthew Gilbert 2017-07-17 18:57:20 UTC
I can test, I'm still on F26. All I get when I run systemctl hibernate is:

Failed to hibernate system via logind: Sleep verb not supported

I also have my swap on an encrypted root. How do I add the dracut resume module to my initramfs?

Comment 7 Matthew Gilbert 2017-07-17 18:59:44 UTC
I assume this means resume is in my initramfs:

dracut --list-modules | grep resume                                                                                                    
resume

Comment 8 verdre 2017-07-17 19:30:01 UTC
No, this means that it's available (--help says: --list-modules List all available dracut modules.)

Add this to /etc/dracut.conf:

add_dracutmodules+="resume"


Then rebuild your current initramfs with dracut --force as root. But if hibernating worked before I don't think this will help. And if you're using a swapfile you will also need the resume_offset kernel parameter.

Maybe check if hibernating manually with echo disk > /sys/power/state does work?

Comment 9 Matthew Gilbert 2017-07-17 19:44:25 UTC
Oh shoot, sorry, I'm giving wrong information: I have a swap partition.

/dev/mapper/fedora-swap swap                    swap    defaults,x-systemd.device-timeout=0 0 0

I'm trying the dracut module now. Thanks!

Comment 10 Matthew Gilbert 2017-07-17 19:48:55 UTC
I tried updating dracut, still get verb not supported.

Trying to hibernate manually I get:

[root@]# echo disk > /sys/power/state
bash: echo: write error: Operation not permitted

Comment 11 verdre 2017-07-17 19:52:01 UTC
Seems like /sys/power/disk also plays a role here, maybe this can help:
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

Comment 12 verdre 2017-07-17 19:58:13 UTC
And since kernel-4.11.10 is available by now you might want to test this one.

Comment 13 Matthew Gilbert 2017-07-17 20:02:51 UTC
I can't write /sys/power/disk:

[root@]# echo reboot > /sys/power/disk
bash: echo: write error: Operation not permitted
[root@]# cat /sys/power/disk 
[disabled]

I'll try updating to 4.11.10 to see if it changes.

Comment 14 Matthew Gilbert 2017-07-17 20:12:37 UTC
4.11.10 doesn't change the behavior.

Comment 15 Matthew Gilbert 2017-07-17 20:22:44 UTC
After some googling, I saw folks reporting their /sys/power/disk were disabled if they had secure boot enabled, and that they were able to hibernate if they disabled secure boot. I also tried disabling secure boot, and now can hibernate. Yay!

Except, this used to work with secure boot enabled. Any idea what changed? I'd really like to re-enable secure boot.

Comment 16 verdre 2017-07-17 20:38:06 UTC
Yeah I also saw this before, I just thought it's not worth noticing since you didn't change anything.

No idea, probably some changes in the kernel. If you have some time and want to help, get the kernel sources and use git bisect to find the bad commit, then file a kernel bug and let the kernel devs fix it.
Well, but since the reporter already wrote that updating to a newer kernel or systemd version fixes the bug I assume somebody already fixed it and you can just update to a newer kernel, for example from the kernel vanilla repo: https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

Comment 17 dac.override 2017-07-17 20:40:23 UTC
Its not that simple

Rawhide doesnt have the grub update that enables secure boot that 26 has.

What I am saying is that secure boot is not enabled here on rawhide and this might explain why hibernate works here

Comment 18 verdre 2017-07-17 20:43:29 UTC
Oh, you're right I didn't think of that.
Then someone should really check for kernel bugs and if there are none bisect it, I'll check if I can get secure-boot working on my laptop.

Comment 19 Claude Frantz 2017-08-07 16:45:51 UTC
The kernel is reported as 4.11.11-300.fc26.i686+PAE.

The shutdown in the hibernate state seems to be without errors. The last entries as noted by journalctl:

Aug 07 16:00:03 defi systemd[1]: Reached target Sleep.
-- Subject: Unit sleep.target has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit sleep.target has finished starting up.
-- 
-- The start-up result is done.
Aug 07 16:00:03 defi systemd[1]: Starting Hibernate...
-- Subject: Unit systemd-hibernate.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-hibernate.service has begun starting up.
Aug 07 16:00:03 defi kernel: PM: Hibernation mode set to 'platform'
Aug 07 16:00:03 defi kernel: PM: Syncing filesystems ... 
Aug 07 16:00:03 defi systemd-sleep[13638]: Suspending system...
-- Subject: System sleep state hibernate entered
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- The system has now entered the hibernate sleep state.
...skipping...
Aug 07 16:00:03 defi systemd-logind[677]: Delay lock is active (UID 0/root, PID 2373/upowerd) but inhibitor timeout is reached.
Aug 07 16:00:03 defi systemd[1]: Reached target Sleep.
-- Subject: Unit sleep.target has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit sleep.target has finished starting up.
-- 
-- The start-up result is done.
Aug 07 16:00:03 defi systemd[1]: Starting Hibernate...
-- Subject: Unit systemd-hibernate.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit systemd-hibernate.service has begun starting up.
Aug 07 16:00:03 defi kernel: PM: Hibernation mode set to 'platform'
Aug 07 16:00:03 defi kernel: PM: Syncing filesystems ... 
Aug 07 16:00:03 defi systemd-sleep[13638]: Suspending system...
-- Subject: System sleep state hibernate entered
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- The system has now entered the hibernate sleep state.



After that, the system restarts and it shows the grub2 menu window.

Comment 20 Alan 2017-08-11 10:37:00 UTC
systemd 233-6.fc26

Fedora 26 (upgraded from F24 where this worked)

This is an 2010 Dell with BIOS - secure boot not appicable (no UEFI)


Cinnamon 'user applet' PowerOff does not provide option "hibernate" option in F26.

# systemctl hibernate
Failed to hibernate system via logind: Sleep verb not supported


Kernel booted with "resume=/dev/mapper/vg-swap"

[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.11-300.fc26.x86_64 root=/dev/mapper/vg/LogVol_root ro rd.lvm.lv=vg/LogVol_root rd.lvm.lv=vg/swap rd.lvm.lv=vg/LogVol_usr resume=/dev/mapper/vg-swap LANG=en_GB.UTF-8 rd.driver.blacklist=nouveau vga=837


where /dev/mapper/vg-swap is symlink to /dev/dm-1

$ swapon -s
Filename				Type		Size	Used	Priority
/dev/dm-1                              	partition	1048572	0	-1

Comment 21 Alan 2017-08-11 10:44:07 UTC
contents of:

$ cat /sys/power/disk
[platform] shutdown reboot suspend test_resume

BIOS PC / no secure boot or UEFI

Comment 22 Alan 2017-08-11 14:05:16 UTC
compared my F24 laptop which can succesfully hibernate via "systemctl hiberante"

contents on /etc/systemd/logind.conf and /sys/power/diks are identical

yet F26 does not hibernate

Comment 23 Alan 2017-08-12 14:09:06 UTC
upon further testing, it appears that the F26 system can hibernate!

The machine has 12GB of RAM and only 1GB swap - when the machine is rebooted, it can be sent to hibernate.

After using the system, where the memory used >1.5GB, the hibernate option is no longer available on the GUI or via systemctl.

It appears that criteria for allowing hibernate/system memory usage in F26 differs from F24.

But for my case (BIOS based F26 x64), I will say this is expected behaviour since used RAM exceeds swap.

Comment 24 Gabriel Schulhof 2017-09-04 21:26:43 UTC
I've added resume=<whatever /etc/fstab says is my swap> to my kernel command line and I've added the dracut module and my swap partition is twice the size of my RAM, and I still can't suspend with a fresh installation of F26.

Kernel is 4.12.9-300.fc26.x86_64 and secure boot is on.

Comment 25 Steven Stallion 2017-10-22 16:30:57 UTC
I'm affected by this as well (Fedora 26 x86_64). After enabling hibernate (adding resume= to GRUB_CMDLINE_LINUX and GRUB_DISABLE_RECOVERY=false to /etc/default/grub, I am only able to hibernate if and only if secure boot is disabled.

Comment 26 Zbigniew Jędrzejewski-Szmek 2018-04-10 11:37:36 UTC
@Alan:
> The machine has 12GB of RAM and only 1GB swap - when the machine is rebooted, it can be sent to hibernate.
> After using the system, where the memory used >1.5GB, the hibernate option is no longer available on the GUI or via systemctl.

If you have only 1GB of swap, it is very likely that after some use, the resident memory is higher than the amount of free swap space. When this happens, hibernation is disabled. For reliable hibernation, you needs an amount of swap space at least equal to RAM.

This is unrelated to the issue here, which seems to be Secure-Boot related.

Comment 27 Zbigniew Jędrzejewski-Szmek 2018-04-10 11:38:31 UTC
*** Bug 1549844 has been marked as a duplicate of this bug. ***

Comment 28 Zbigniew Jędrzejewski-Szmek 2018-04-10 11:44:33 UTC
This is outside of the scope of systemd, which just ask the kernel to do the hard work for us ;)

tl;dr version: see comment #c13:

[root@]# echo reboot > /sys/power/disk
bash: echo: write error: Operation not permitted
[root@]# cat /sys/power/disk 
[disabled]

Comment 29 Jeremy Cline 2018-04-10 13:21:42 UTC
Hi,

Unfortunately, hibernation is disabled by the lockdown patch set[0] since there is currently no way to verify the resume image when returning from hibernate.

[0] https://src.fedoraproject.org/rpms/kernel/blob/dcd325ca9e08f74233acb6578d46138bfb4c30aa/f/efi-lockdown.patch#_1088

Comment 30 antoniopassarelli 2018-04-10 14:59:11 UTC
+1

Failed to hibernate system via logind: Sleep verb not supported

fresh installed nor changing grub

Comment 31 antoniopassarelli 2018-04-10 15:01:19 UTC
(In reply to Jeremy Cline from comment #29)
> Hi,
> 
> Unfortunately, hibernation is disabled by the lockdown patch set[0] since
> there is currently no way to verify the resume image when returning from
> hibernate.
> 
> [0]
> https://src.fedoraproject.org/rpms/kernel/blob/
> dcd325ca9e08f74233acb6578d46138bfb4c30aa/f/efi-lockdown.patch#_1088

no way to sign the image?

Comment 32 Jeremy Cline 2018-04-10 17:17:19 UTC
I'm not the authority on this, but my understanding is that yes, there's not currently a way to sign and then verify the image when it's started again so it could be tampered with, thus evading the whole purpose of secure boot.

Comment 33 Daibhidh 2018-04-23 16:10:45 UTC
Why has this bug been closed, can't fix? This is an important feature, imho. At the moment, those people who want hibernation are disabling secure boot in order to get it. This, to me, seems far worse that allowing secure boot with insecure recovery from hibernation.

Can't the hibernation problem be brought to the attention of more people, one or more of whom might see a way of fixing it? I understand that Microsoft Windows 10 uses hibernation in its fast boot - if Windows 10 uses hibernation, why can't Linux?

Comment 34 Jeremy Cline 2018-04-23 17:12:09 UTC
(In reply to Daibhidh from comment #33)
> Why has this bug been closed, can't fix? This is an important feature, imho.

I closed it because it's an intentional limitation of the secure boot lockdown patches rather than a bug. Upstream is aware of it, and I'm not sure that this is the best place to track enhancements for the patch set.

> At the moment, those people who want hibernation are disabling secure boot
> in order to get it. This, to me, seems far worse that allowing secure boot
> with insecure recovery from hibernation.

If we were to drop that patch, it would be a security concern for all users of secure boot which, I believe, is worse than breaking hibernation for the users who require it.

If users wish to allow hibernation and keep secure boot enabled, they are free to build a custom kernel that allows that. They should be aware that they undermining the entire purpose of secure boot, though, since they cannot trust that the image they boot hasn't been tampered with.

> Can't the hibernation problem be brought to the attention of more people,
> one or more of whom might see a way of fixing it? I understand that
> Microsoft Windows 10 uses hibernation in its fast boot - if Windows 10 uses
> hibernation, why can't Linux?

When the patch set (which is not in Linus' tree yet) was submitted for 4.17, the topic of hibernation was briefly discussed: https://marc.info/?l=linux-kernel&m=152414891115530&w=2. Hopefully, it'll eventually be possible to hibernate with secure boot enabled, but for the moment that problem hasn't been solved.

Comment 35 Daibhidh 2018-04-23 20:16:51 UTC
(In reply to Jeremy Cline from comment #34)

Thank you very much for the rapid and informative response, I now feel less in the dark about this.

> (In reply to Daibhidh from comment #33)
> > Why has this bug been closed, can't fix? This is an important feature, imho.
> 
> I closed it because it's an intentional limitation of the secure boot
> lockdown patches rather than a bug. Upstream is aware of it, and I'm not
> sure that this is the best place to track enhancements for the patch set.

As long as a closed problem doesn't become a forgotten problem.

Although it is not a bug, from a user's point of view, it is affecting functionality in the same way as a bug, and, on Google search, for example, it still looks like it is considered to be a bug.

So should there be a problemzilla forum as well as a bugzilla forum, so that problems outside the bug class continue to be tracked?

> > At the moment, those people who want hibernation are disabling secure boot
> > in order to get it. This, to me, seems far worse that allowing secure boot
> > with insecure recovery from hibernation.
> 
> If we were to drop that patch, it would be a security concern for all users
> of secure boot which, I believe, is worse than breaking hibernation for the
> users who require it.
> 
> If users wish to allow hibernation and keep secure boot enabled, they are
> free to build a custom kernel that allows that. They should be aware that
> they undermining the entire purpose of secure boot, though, since they
> cannot trust that the image they boot hasn't been tampered with.

I would still be concerned about the number of people who are turning off secure boot in order to get hibernate to work: they are not able to spend the time customising the kernel in order to make secure boot work with hibernate, so they turn off secure boot altogether.

> > Can't the hibernation problem be brought to the attention of more people,
> > one or more of whom might see a way of fixing it? I understand that
> > Microsoft Windows 10 uses hibernation in its fast boot - if Windows 10 uses
> > hibernation, why can't Linux?
> 
> When the patch set (which is not in Linus' tree yet) was submitted for 4.17,
> the topic of hibernation was briefly discussed:
> https://marc.info/?l=linux-kernel&m=152414891115530&w=2. Hopefully, it'll
> eventually be possible to hibernate with secure boot enabled, but for the
> moment that problem hasn't been solved.

Comment 36 Jeremy Cline 2018-04-24 21:11:29 UTC
(In reply to Daibhidh from comment #35)
> (In reply to Jeremy Cline from comment #34)
> 
> Thank you very much for the rapid and informative response, I now feel less
> in the dark about this.
> 
> > (In reply to Daibhidh from comment #33)
> > > Why has this bug been closed, can't fix? This is an important feature, imho.
> > 
> > I closed it because it's an intentional limitation of the secure boot
> > lockdown patches rather than a bug. Upstream is aware of it, and I'm not
> > sure that this is the best place to track enhancements for the patch set.
> 
> As long as a closed problem doesn't become a forgotten problem.
> 
> Although it is not a bug, from a user's point of view, it is affecting
> functionality in the same way as a bug, and, on Google search, for example,
> it still looks like it is considered to be a bug.
> 
> So should there be a problemzilla forum as well as a bugzilla forum, so that
> problems outside the bug class continue to be tracked?

I'm in the middle of writing some secure boot documentation for https://docs.fedoraproject.org/quick-docs/en-US/kernel/overview.html which should cover hibernation, among other things. Hopefully that will solve this particular issue.

> 
> > > At the moment, those people who want hibernation are disabling secure boot
> > > in order to get it. This, to me, seems far worse that allowing secure boot
> > > with insecure recovery from hibernation.
> > 
> > If we were to drop that patch, it would be a security concern for all users
> > of secure boot which, I believe, is worse than breaking hibernation for the
> > users who require it.
> > 
> > If users wish to allow hibernation and keep secure boot enabled, they are
> > free to build a custom kernel that allows that. They should be aware that
> > they undermining the entire purpose of secure boot, though, since they
> > cannot trust that the image they boot hasn't been tampered with.
> 
> I would still be concerned about the number of people who are turning off
> secure boot in order to get hibernate to work: they are not able to spend
> the time customising the kernel in order to make secure boot work with
> hibernate, so they turn off secure boot altogether.

It's unfortunate, but it's a trade-off between convenience and security, and it's a choice everyone has to make. If you allow hibernation in the current state of the patch set, you've opened yourself up to the attack secure boot was meant to guard against. I think it's safe to say we all want this to both work "out of the box" for everyone and be secure, but work remains to be done.

All that said, there's tools out there like Copr to make it easy for people to build and maintain custom kernels for the community.

Comment 37 John Soros 2018-11-06 11:46:11 UTC
For systems with firmware-encrypted OPAL disks, hibernate should be enabled.


Note You need to log in before you can comment on or make changes to this bug.