Bug 1518473

Summary:	Secure Boot Breaks Hibernate and Hybrid Sleep
Product:	[Fedora] Fedora	Reporter:	陳鐸元 <dannymrt1>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	27	CC:	airlied, ajax, bskeggs, ewk, fedoraproject, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, labbott, linville, mchehab, mjg59, samuel-rhbugs, sorosj, steved
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-11-29 16:32:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description 陳鐸元 2017-11-29 03:02:46 UTC

Description of problem:
When Secure Boot is on, /sys/power/disk is disabled.
Thus, hibernate and hybrid-sleep won't work.

Version-Release number of selected component (if applicable):
4.13.13-300.fc27.x86_64

How reproducible:
Always


Steps to Reproduce:
1. Turn on Secure Boot
2. systemctl hibernate or systemctl hybrid-sleep
3.

Actual results:

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

systemctl hybrid-sleep 
Failed to put system into hybrid sleep via logind: Sleep verb not supported


Expected results:
The system hibernates or hybrid sleeps

Additional info:

Comment 1 Laura Abbott 2017-11-29 16:32:18 UTC

This is intended behavior, per commit text on one of the patches

"There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down."

Comment 2 John Soros 2018-11-06 11:34:50 UTC

So what about the case when an OPAL hard disk is encrypted using the system firmware?