On Sun, Mar 8, 2020 at 12:49 PM Christian Boltz <opensuse@cboltz.de> wrote:
If you are paranoid enough to encrypt your root partition (you should!), then you don't want to have parts of your RAM (like open documents or in worst case your disk encryption key) swapped out to unencrypted swap ;-)
a) use swap on ZRAM https://github.com/systemd/zram-generator b) encrypt swap using /dev/urandom key generated at each boot Both mean hibernation is not possible. One possible solution is in the hibernation+secure boot thread, which could also serve this use case: https://lists.opensuse.org/opensuse-factory/2020-02/msg00385.html
This is somewhat similar to the discussion if you really need to encrypt the root partition, or if encrypting /home is good enough. IMHO it isn't, because for example files in /tmp/ can also contain sensitive data which you don't want to have unencrypted. For example, when you click a PDF attached to a mail in KMail, it will get stored in /tmp/ before it gets opened.
/tmp really should be on tmpfs. The UI/UX of asking the user for two passphrases (boot separate from login) is not acceptable. And further, neither the GRUB nor initramfs environments are sufficiently sophisticated to support i18n, and a11y needs properly. Piecemeal effort here and there to only enhance the security of English language users, and users who restrict their passphrases to ASCII, is just not a modern solution. One possible way of partly solving this is using the TPM to seal the key used to encrypt sysroot. That means leaked user data can be exposed if the entire laptop is stolen, just by booting. Still another way of solving this is using the user supplied login passphrase as an fscrypt master key, to encrypt the files the user session leaks /var, but this requires ext4 or f2fs right now, since Btrfs does yet support in-kernel fscrypt (via VFS). I think that user data should only ever leak into /tmp or ~/, where /tmp is tmpfs by default, and ~/ is encrypted by default. One way of getting to encrypted ~/ by default might be systemd-homed, which has Btrfs support, and locks the LUKS volume upon S3 (suspend-to-RAM), i.e. the DEK is removed from memory.
Sidenote: I have no idea if suspend to disk works with encrypted swap - I don't have any swap to test.
It just makes things more complicated, it doesn't by itself make them more unreliable. They're already unreliable due to myriad ACPI bugs that kernel developers don't have the resources to work around. e.g. one of many S3 bugs that happen on linux but not on Windows, clearly identified kernel regression, and fairly clearly identified ACPI/firmware bug that somehow Windows must work around. https://bugzilla.kernel.org/show_bug.cgi?id=185521 Hypothetically, linux suspend-to-disk should be more reliable if it depends only on S5, rather than S4. However, this too is inconsistent. The're sufficient complexity in the reclaim code, and non-deterministic behavior in anonymous page eviction that hibernation entry can often fail. That makes it difficult to diagnose for even experienced developers and troubleshooters, let alone mere mortals. In the idealized case of suspend-to-disk in a qemu-kvm, hibernation entry fails perhaps 1/3 of the time. That kind of non-determinism in what should be completely deterministic, demonstrates this is a difficult problem. If this leaves a significant minority (let alone majority) who can't reliably hibernate, then is it really worth the development effort to create a generic signed and encrypted hibernation image possible? Or are efforts better spent elsewhere to preserve user data in low power situations? These aren't necessarily mutually exclusive, but it is possible that misaligned expectations result in delays. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org