Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

From: Jiri Kosina
Date: Sat Jan 05 2019 - 15:43:07 EST

On Sat, 5 Jan 2019, Linus Torvalds wrote:

> > I am still not completely sure what to return in such cases though; we can
> > either blatantly lie and always pretend that the pages are resident
> That's what my untested patch did. Or maybe just claim they are all
> not present?

Thinking about it a little bit more, I believe Vlastimil has a good point
with 'non present' potentially causing more bogus activity in userspace in
response (in an effort to actually make them present, and failing

IOW, I think it's a reasonable expectation that the common scenario is
"check if it's present, and if not, try to fault it in" instead of "check
if it's present, and if it is, try to evict it".

> And again, that patch was entirely untested, so it may be garbage and
> have some fundamental problem.

I will be travelling for next ~24 hours, but I have just asked our QA guys
to run it through some basic battery of testing (which will probably
happen on monday anyway).

> I also don't know exactly what rule might make most sense, but "you can
> write to the file" certainly to me implies that you also could know what
> parts of it are in-core.

I think it's reasonable; I can't really imagine any sidechannel to a
global state be possibly mounted on valid R/W mappings. I'd guess that
probably the most interesting here are the code segments of shared
libraries, allowing to trace victim's execution.

> Who actually _uses_ mincore()? That's probably the best guide to what
> we should do. Maybe they open the file read-only even if they are the
> owner, and we really should look at file ownership instead.

Yeah, well

is a bit too much mess to get some idea quickly I am afraid.

Jiri Kosina