On 11/09/2017 06:48 AM, Florian Weimer wrote:

On 11/08/2017 09:41 PM, Dave Hansen wrote:

quoted

quoted

(B) If a key is reused, existing threads retain their access rights,
while there is an expectation that pkey_alloc denies access for the
threads except the current one.

Where does this expectation come from?

For me, it was the access_rights argument to pkey_alloc.  What else
would it do?  For the current thread, I can already set the rights with
a PKRU write, so the existence of the syscall argument is puzzling.

The manpage is pretty bare here.  But the thought was that, in most
cases, you will want to allocate a key and start using it immediately.
This was in response to some feedback on one of the earlier reviews of
the patch set.

quoted

Using the malloc() analogy, we
don't expect that free() in one thread actively takes away references to
the memory held by other threads.

But malloc/free isn't expected to be a partial antidote to random
pointer scribbling.

Nor is protection keys intended to be an antidote for use-after-free.

I think we should either implement revoke on pkey_alloc, with a
broadcast to all threads (the pkey_set race can be closed by having a
vDSO for that an the revocation code can check %rip to see if the old
PKRU value needs to be fixed up).  Or we add the two pkey_alloc flags I
mentioned earlier.

That sounds awfully complicated to put in-kernel.  I'd be happy to
review the patches after you put them together once we see how it looks.

You basically want threads to broadcast their PKRU values at pkey_free()
time.  That's totally doable... in userspace.  You just need a mechanism
for each thread to periodically check if they need an update.  I don't
think we need kernel intervention and vDSO magic for that.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>