On Fri, 8 Jun 2018 07:53:51 +0200 Florian Weimer <fweimer@xxxxxxxxxx> wrote: > On 06/08/2018 04:34 AM, Ram Pai wrote: > >> > >> So the remaining question at this point is whether the Intel > >> behavior (default-deny instead of default-allow) is preferable. > > > > Florian, remind me what behavior needs to fixed? > > See the other thread. The Intel register equivalent to the AMR by > default disallows access to yet-unallocated keys, so that threads > which are created before key allocation do not magically gain access > to a key allocated by another thread. > That does not make any sense. The threads share the address space so they should also share the keys. Or in other words the keys are supposed to be acceleration of mprotect() so if mprotect() magically gives access to threads that did not call it so should pkey functions. If they cannot do that then they fail the primary purpose. And in any case what semantic that makes sense will you ever get by threads not magically getting new keys? Suppose you will spawn some threads, then allocate a new key, associate it with a piece of protected data, etc. Now the old threads do not have access to the protected data at all. So if they want to access it they have to call into a management thread that created the access key to give them the data. Which means they need to call into the kernel to switch to the management thread. Which completely defeats the purpose of the acceleration of mprotect() which was to avoid calling into the kernel to access the data. In other words you can as well spawn a management process and use shared memory. What's worse, if you wanted to opt out of this feature and give the old threads the new key that's going to be quite a bit of fiddling. That said there might be an enhancement that kind of makes sense. For example if you allocate a key to associate with an area that you want to read most of the time and update occasionally it might make sense to tell the kernel: make the read bit on this key process-global, make the write bit on this key thread-local, and do not allow setting the execute bit at all. Then a thread calling a function to update the data will get write access but other threads will continue to have read access unless they also call a function to update the data. Thanks Michal
