On Sun, Mar 8, 2020 at 12:49 PM Christian Boltz <opensuse(a)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
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:
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
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.
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
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.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org