On Mon, 2021-02-22 at 11:17 -0800, Dan Williams wrote:

On Mon, Feb 22, 2021 at 2:24 AM Mike Rapoport [off-list ref]
wrote:

quoted

On Mon, Feb 22, 2021 at 07:34:52AM +0000, Matthew Garrett wrote:

quoted

On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote:

quoted

It is unsafe to allow saving of secretmem areas to the
hibernation snapshot as they would be visible after the resume
and this essentially will defeat the purpose of secret memory
mappings.

Sorry for being a bit late to this - from the point of view of
running processes (and even the kernel once resume is complete),
hibernation is effectively equivalent to suspend to RAM. Why do
they need to be handled differently here?

Hibernation leaves a copy of the data on the disk which we want to
prevent.

Why not document that users should use data at rest protection
mechanisms for their hibernation device? Just because secretmem can't
assert its disclosure guarantee does not mean the hibernation device
is untrustworthy.

It's not just data at rest.  Part of the running security guarantees
are that the kernel never gets access to the data.  To support
hibernate and swap we have to break that, so it reduces the runtime
security posture as well as the data at rest one.

This argues we could do it with a per region flags (something like less
secure or more secure mappings), but when you give users that choice
most of them rarely choose less secure.

James