Feature: SecureBoot limitation warning

[xenithorb]

Hi, I previously submitted a comment (that I deleted) referencing bug #1

As it turns out I'm using SecureBoot and it just simply doesn't work with that, but I was unaware of that limitation. Perhaps do a check for secureboot and notify the user that it won't work because that's enabled?

Maybe even instead, don't allow the user to turn the extension on if it doesn't pass that check?

It's not necessarily a bug in the extension so much as it was confusing to have to track down the cause of pressing the hibernate button and it not do anything at all.

[p91paul]

Hi, Googling a bit shows that is likely that fedora actually disabled hibernation with secure boot; but as I'm unsure about other distributions, I wouldn't break things for all users. Do you know a reliable way to determine if hibernation is disabled?

[xenithorb]

1. Secure boot does not work with hibernation I because it destroys the trust model. (Unless you use dm-crypt, but they don't seem to care enough to check for that). https://www.phoronix.com/scan.php?page=news_item&px=MTI4NjE
2. GRUB_DISABLE_RECOVERY in /etc/default/grub might be a safe assumption

[p91paul]

I saw that phoronix piece of news. However, the fact that someone posted a patch doesn't mean that it was accepted, especially when the author states that the patch is not intended to be merged as is. I could not find a follow up for that, apart of Fedora users complaing, which makes me think Fedora actually does something to prevent hibernation with secure boot, but leaves me unsure about other distributions.

GRUB_DISABLE_RECOVERY is unrelated to hibernation. You probably mean the noresume kernel command line option; I'll look into that. Can you check if it appears in your /proc/cmdline?

[xenithorb]

https://psohny.wordpress.com/2015/08/13/fedora_hiber/

[xenithorb]

Alternatively, you do need resume=<blockdev> so maybe check for that? I don't think GRUB_DISABLE_RECOVERY is unrelated though

[xenithorb]

Nevermind, you're right about GRUB_DISABLE_RECOVERY, all it does is add an additional option in the menu with 'single' prepended. I thought that was weird too, so I'm not sure where that blog got their misinformation from.

[p91paul]

Another nice thing about that blog post is that they don't advise to do grub2-mkconfig -o /boot/grub2/grub.cfg after editing /etc/default/grub, so the modification to GRUB_DISABLE_RECOVERY has simply no effect :).

Also, directly editing /boot/grub2/grub.cfg is discouraged since invoking grub2-mkconfig -o /boot/grub2/grub.cfg would override them, and some distribution do that after every kernel update (they do have a point since Fedora doesn't though, but still new kernels won't get that option appended). The Right Way (TM) of setting resume=<blockdev> is to add that parameter to GRUB_CMDLINE_LINUX like:

GRUB_CMDLINE_LINUX="rhgb quiet resume=/dev/<your swap partition>"

Then issue the grub2-mkconfig -o /boot/grub2/grub.cfg command to persist that change, and reboot to activate it. Can you try setting that? If you are then allowed to hibernate, that would rule out secure boot.

[xenithorb]

Lol, I didn't even notice the call to edit /boot/grub2/grub.cfg (mainly because for me it's even /boot/efi/EFI/fedora/grub.cfg)

I added resume= to GRUB_CMDLINE_LINUX instinctively

Unfortunately I no longer use GNOME, but if I can recall correctly, my original idea is that, knowing that linux does not support hibernation+secure_boot then a button that says it will hibernate might want to check to see if it has secure boot enable because it won't work as intended, leaving the user in a confused state as to why it wasn't working.

iirc, with your extension, it was my first attempt at getting hibernate to work on linux, and I did not yet possess the knowledge that it simply doesn't work with secure-boot enabled. I opted to keep secure-boot enabled because of the added security benefit when used with dm-crypt.

[p91paul]

Closing this issue. #17 remains open to add some feedback when hibernating won't work.