Thread (32 messages) 32 messages, 6 authors, 2021-05-19

Re: [PATCH v19 6/8] PM: hibernate: disable when there are active secretmem users

From: James Bottomley <hidden>
Date: 2021-05-19 03:52:17
Also in: linux-arch, linux-arm-kernel, linux-fsdevel, linux-kselftest, linux-mm, linux-riscv, lkml

On Tue, 2021-05-18 at 18:49 -0700, Dan Williams wrote:
On Tue, May 18, 2021 at 6:33 PM James Bottomley [off-list ref]
wrote:
quoted
On Tue, 2021-05-18 at 11:24 +0100, Mark Rutland wrote:
quoted
On Thu, May 13, 2021 at 09:47:32PM +0300, Mike Rapoport wrote:
quoted
From: Mike Rapoport <redacted>

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.

Prevent hibernation whenever there are active secret memory
users.
Have we thought about how this is going to work in practice, e.g.
on mobile systems? It seems to me that there are a variety of
common applications which might want to use this which people
don't expect to inhibit hibernate (e.g. authentication agents,
web browsers).
If mobile systems require hibernate, then the choice is to disable
this functionality or implement a secure hibernation store.   I
also thought most mobile hibernation was basically equivalent to
S3, in which case there's no actual writing of ram into storage, in
which case there's no security barrier and likely the inhibition
needs to be made a bit more specific to the suspend to disk case?
quoted
Are we happy to say that any userspace application can
incidentally inhibit hibernate?
Well, yes, for the laptop use case because we don't want suspend to
disk to be able to compromise the secret area.  You can disable
this for mobile if you like, or work out how to implement hibernate
securely if you're really suspending to disk.
Forgive me if this was already asked and answered. Why not document
that secretmem is ephemeral in the case of hibernate and push the
problem to userspace to disable hibernation? In other words
hibernation causes applications to need to reload their secretmem, it
will be destroyed on the way down and SIGBUS afterwards. That at
least gives a system the flexibility to either sacrifice hibernate
for secretmem (with a userspace controlled policy), or sacrifice
secretmem using processes for hibernate.
Well, realistically, there are many possibilities for embedded if it
wants to use secret memory.  However, not really having much of an
interest in the use cases, it's not really for Mike or me to be acting
as armchair fly half.  I think the best we can do is demonstrate the
system for our use cases and let embedded kick the tyres for theirs if
they care, and if not they can disable the feature.

James

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help