Re: MPK: pkey_free and key reuse

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux