On 11/09/2017 06:48 AM, Florian Weimer wrote: > On 11/08/2017 09:41 PM, Dave Hansen wrote: >>> (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. >> 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.
