On Thu, Dec 5, 2019 at 8:57 AM Marius Schwarz <fedoradev(a)cloud-foo.de> wrote:
Am 05.12.19 um 13:32 schrieb Lennart Poettering:
Well, the way this has been traditionally done is that the lock screen
is displayed by a program running under the user's identity and that
the user's data is entirely unlocked the entire time during suspend,
That depends on what you have chosen "sleep" or "hibernate" .
If the device just sleeps, your data is unprotected, as the key could be in your still
powered memory bank.
With hibernation, as far as I have seen it with my devices, the hw stops entirely after
saving the memory state to disk,
an encrypted disk I may add. On boot, it asks for the decryption keys as it would
normally do, finds the hibernate signature
on swap ( i presume / which is also encrypted ) and restores memory. I don't see a
way for an attack here.
Hibernation is out of scope to rely on, let alone make a default, for
at least the following reasons:
a. It's not sufficiently well supported upstream for regressions that
may appear in new kernels, and not supported by the Fedora kernel
team.
b. It's disabled by kernel lockdown on UEFI Secure Boot systems.
c. Resource requirements are excessive, there's no dynamic allocation
so to be safe you need to allocate a minimum of 1x RAM for a swap
partition used for a hibernation image. As a consequence, there's now
an excessive amount of relatively slow swap which can result in swap
thrashing and the effective loss of the system. See "Better
interactivity in low-memory situations "
https://pagure.io/fedora-workstation/issue/98
d. There's no release criterion. Therefore the project wouldn't block
release on any discovered bugs. Serious bugs would likely lead to
reverting any use of hibernation by default, and so it's not at all
likely it'll become supported by default.
--
Chris Murphy