Re: [PATCH 08/10] PM: hibernate: Mix user key in encrypted hibernate

[Evan Green]

On Fri, May 6, 2022 at 9:08 AM Pavel Machek <pavel@xxxxxx> wrote:
>
> Hi!
Hi Pavel!

>
> > One annoyance of the "preloading" scheme is that hibernate image memory
> > is effectively double-allocated: first by the usermode process pulling
> > encrypted contents off of disk and holding it, and second by the kernel
> > in its giant allocation in prepare_image(). An interesting future
> > optimization would be to allow the kernel to accept and store encrypted
> > page data before the user key is available. This would remove the
> > double allocation problem, as usermode could push the encrypted pages
> > loaded from disk immediately without storing them. The kernel could defer
> > decryption of the data until the user key is available, while still
> > knowing the correct page locations to store the encrypted data in.
>
> Um. Dunno. Won't you run out of memory? Hibernation images can be quite big...
>

As you know, with the way the snapshot mechanism works, a hibernation
image can be at most 50% of RAM. If the system was using more than
that at hibernation time, it has to free up the excess via swap before
hibernating. So during this resume period, there's at least 50% of RAM
to play around in and still be able to preload the hibernation image.

What I've been doing in practice is to load as much of the hibernate
image as possible into memory at the login screen while at the same
time ensuring the system maintains a comfortable margin of free
memory. I have to coerce the kernel into doing its giant allocation in
prepare_image() first since it uses GFP_ATOMIC. This might mean I can
only preload some of the image from disk. With the disk I/O being by
far the longest pole in the tent, hiding even some of that latency
behind the password prompt is still great for perceived resume time.


-Evan