Thread (148 messages) 148 messages, 20 authors, 2019-03-12

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

From: Jiri Kosina <jikos@kernel.org>
Date: 2019-01-05 19:24:07
Also in: linux-mm, lkml

On Sat, 5 Jan 2019, Vlastimil Babka wrote:
quoted
There are possibilities [1] how mincore() could be used as a converyor of 
a sidechannel information about pagecache metadata.

Provide vm.mincore_privileged sysctl, which makes it possible to mincore() 
start returning -EPERM in case it's invoked by a process lacking 
CAP_SYS_ADMIN.
Haven't checked the details yet, but wouldn't it be safe if anonymous private
mincore() kept working, and restrictions were applied only to page cache?
I was considering that, but then I decided not to do so, as that'd make 
the interface even more confusing and semantics non-obvious in the 
'privileged' case.
quoted
The default behavior stays "mincore() can be used by anybody" in order to 
be conservative with respect to userspace behavior.
What if we lied instead of returned -EPERM, to not break userspace so 
obviously? I guess false positive would be the safer lie?
So your proposal basically would be

if (privileged && !CAP_SYS_ADMIN)
	if (pagecache)
		return false;
	else
		return do_mincore()

right ?

I think userspace would hate us for that semantics, but on the other hand 
I can sort of understand the 'mincore() is racy anyway, so what' argument, 
if that's what you are suggesting.

But then, I have no idea what userspace is using mincore() for. 
https://codesearch.debian.net/search?q=mincore might provide some insight 
I guess (thanks Matthew).

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