On Tue 02-02-21 10:55:40, James Bottomley wrote:

On Tue, 2021-02-02 at 20:15 +0200, Mike Rapoport wrote:

quoted

On Tue, Feb 02, 2021 at 03:34:29PM +0100, David Hildenbrand wrote:

quoted

On 02.02.21 15:32, Michal Hocko wrote:

quoted

On Tue 02-02-21 15:26:20, David Hildenbrand wrote:

quoted

On 02.02.21 15:22, Michal Hocko wrote:

quoted

On Tue 02-02-21 15:12:21, David Hildenbrand wrote:
[...]

quoted

I think secretmem behaves much more like longterm GUP right
now
("unmigratable", "lifetime controlled by user space",
"cannot go on
CMA/ZONE_MOVABLE"). I'd either want to reasonably well
control/limit it or
make it behave more like mlocked pages.

I thought I have already asked but I must have forgotten. Is
there any
actual reason why the memory is not movable? Timing attacks?

I think the reason is simple: no direct map, no copying of
memory.

This is an implementation detail though and not something
terribly hard
to add on top later on. I was more worried there would be really
fundamental reason why this is not possible. E.g. security
implications.

I don't remember all the details. Let's see what Mike thinks
regarding
migration (e.g., security concerns).

Thanks for considering me a security expert :-)

Yet, I cannot estimate how dangerous is the temporal exposure of
this data to the kernel via the direct map in the simple
map/copy/unmap
sequence.

Well the safest security statement is that we never expose the data to
the kernel because it's a very clean security statement and easy to
enforce. It's also the easiest threat model to analyse.   Once we do
start exposing the secret to the kernel it alters the threat profile
and the analysis and obviously potentially provides the ROP gadget to
an attacker to do the same. Instinct tells me that the loss of
security doesn't really make up for the ability to swap or migrate but
if there were a case for doing the latter, it would have to be a
security policy of the user (i.e. a user should be able to decide their
data is too sensitive to expose to the kernel).

The security/threat model should be documented in the changelog as
well. I am not a security expert but I would tend to agree that not
allowing even temporal mapping for data copying (in the kernel) is the
most robust approach. Whether that is generally necessary for users I do
not know.

From the API POV I think it makes sense to have two
modes. NEVER_MAP_IN_KERNEL which would imply no migrateability, no
copy_{from,to}_user, no gup or any other way for the kernel to access
content of the memory. Maybe even zero the content on the last unmap to
never allow any data leak. ALLOW_TEMPORARY would unmap the page from
the direct mapping but it would still allow temporary mappings for
data copying inside the kernel (thus allow CoW, copy*user, migration).
Which one should be default and which an opt-in I do not know. A less
restrictive mode to be default and the more restrictive an opt-in via
flags makes a lot of sense to me though.

-- 
Michal Hocko
SUSE Labs

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel