Dave Hansen <dave.hansen@xxxxxxxxx> writes: > On 03/17/2018 02:12 AM, Thomas Gleixner wrote: >>> This is a bit nicer than what Ram proposed because it is simpler >>> and removes special-casing for pkey 0. On the other hand, it does >>> allow applciations to pkey_free() pkey-0, but that's just a silly >>> thing to do, so we are not going to protect against it. >> What's the consequence of that? Application crashing and burning itself or >> something more subtle? > > You would have to: > > pkey_free(0) > ... later > new_key = pkey_alloc(); > // now new_key=0 > pkey_deny_access(new_key); // or whatever > > At which point most apps would probably croak because its stack is > inaccessible. The free itself does not make the key inaccessible, *but* > we could also do that within the existing ABI if we want. I think I > called out that behavior as undefined in the manpage. Allowing key 0 to be freed introduces some pretty weird API IMHO. For example this part of the manpage: An application should not call pkey_free() on any protection key which has been assigned to an address range by pkey_mprotect(2) and which is still in use. The behavior in this case is undefined and may result in an error. You basically can't avoid hitting undefined behaviour with pkey 0, because even if you never assigned pkey 0 to an address range, it *is still in use* - because it's used as the default key for every address range that doesn't have another key. So I don't really think it makes sense to allow pkey 0 to be freed. But I won't die in a ditch over it, I just look forward to a manpage update that can sensibly describe the semantics. cheers
