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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220506160820.GB1060@bug>
Date:   Fri, 6 May 2022 18:08:20 +0200
From:   Pavel Machek <pavel@....cz>
To:     Evan Green <evgreen@...omium.org>
Cc:     linux-kernel@...r.kernel.org,
        Matthew Garrett <mgarrett@...ora.tech>, dlunev@...gle.com,
        zohar@...ux.ibm.com, jejb@...ux.ibm.com,
        linux-integrity@...r.kernel.org, corbet@....net, rjw@...ysocki.net,
        gwendal@...omium.org, jarkko@...nel.org, linux-pm@...r.kernel.org,
        Len Brown <len.brown@...el.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH 08/10] PM: hibernate: Mix user key in encrypted hibernate

Hi!

> 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...

Best regards,
									Pavel