From 6089c232e8019338a2233956f4488c3ad701aeb0 Mon Sep 17 00:00:00 2001 From: Chris Murphy Date: Jun 01 2020 01:44:21 +0000 Subject: add rationale for lockdown and reference --- diff --git a/hibernationstatus.md b/hibernationstatus.md index eb3e9cb..c602c28 100644 --- a/hibernationstatus.md +++ b/hibernationstatus.md @@ -1,6 +1,6 @@ -# Supporting hibernation in Workstation ed., draft 1 +# Supporting hibernation in Workstation ed., draft 2 -2020-05-28 +2020-05-31 **Synopsis:** @@ -33,21 +33,21 @@ We will support an install time means of enabling hibernation retained via Custo **Current significant impediments:** - UEFI Secure Boot is overwhelmingly present and enabled by default on new computers; -- kernel lockdown policy inhibits hibernation when Secure Boot is enabled; +- kernel lockdown policy inhibits hibernation when Secure Boot is enabled [4]; - ACPI bugs can be transient and difficult to fix or work around; hibernation can mean data loss due to failed entry or exit; -- resource requirements for the permanent swap partition can be excessive, Anaconda history states the reason for the current swap partition size [4] is to accommodate hibernation; +- resource requirements for the permanent swap partition can be excessive, Anaconda history states the reason for the current swap partition size [5] is to accommodate hibernation; - large swap partition exacerbates performance problems in swap heavy workloads. **Necessary enhancements to hibernation:** -- signed and encrypted hibernation image [5]. +- signed and encrypted hibernation image [6]. *Note:* This is the most central nugget needed for limited hibernation support. Encrypted swap is inadequate because encryption alone provides no integrity. Even though there is an authentication component to the encryption, the image can't be said to be authentic -- as-in trustworthy. To provide the required trust and confidentiality, the hibernation image needs to be both signed and encrypted. **Nice to have enhancements to hibernation:** -- dynamic swapfiles created and enabled prior to hibernation entry [6]; -- single interface for determining the location of the hibernation image for all file systems [7]; +- dynamic swapfiles created and enabled prior to hibernation entry [7]; +- single interface for determining the location of the hibernation image for all file systems [8]; - TPM2 support, or alternative, for storing the key(s) needed to resume. @@ -62,18 +62,23 @@ We will support an install time means of enabling hibernation retained via Custo [LWN: Short waits with umwait](https://lwn.net/Articles/790920/) [LWN: The pseudo cpuidle driver](https://lwn.net/Articles/820870/) -[4] RAM to swap ratio is typically 1:1 although there is a cap at 64G. +[4] +UEFI Secure Boot cryptographically verifies that the kernel is in fact a Fedora built and signed kernel. Resuming from hibernation completely replaces memory contents with that of the image, and if the hibernation image isn't also cryptographically signed and verified, it becomes an attack vector. The lockdown policy prevents the hibernation image from being a loophole around UEFI Secure Boot. +[Linux kernel lockdown and UEFI Secure Boot - mjg59 2018](https://mjg59.dreamwidth.org/50577.html) +[LWN: Kernel lockdown](https://lwn.net/Articles/706637/) + +[5] RAM to swap ratio is typically 1:1 although there is a cap at 64G. https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/core/storage.py#L299 -[5] +[6] Joey Lee @ SUSE recently confirmed [this lkml email](https://lkml.org/lkml/2019/7/10/601) is the latest status of that work. -[6] +[7] Developing this means hibernation capability could be enabled post-install, and more easily serve competing use cases. Use cases that don't need hibernation would avoid the space wasted for a dedicated and unused swap partition. Use cases that need hibernation would be supported without a swap partition being created at install time. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MML5MAKBFNEXBT67TCOVUWGFNOUDYUUP/ https://pagure.io/fedora-workstation/issue/120#comment-618549 -[7] +[8] https://github.com/systemd/systemd/issues/11939#issuecomment-471684411