Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0

On Wed, Mar 14, 2018 at 10:51:26AM -0700, Dave Hansen wrote:

On 03/14/2018 10:14 AM, Ram Pai wrote:

quoted

I look at key-0 as 'the key'. It has special status. 
(a) It always exist.

Do you mean "is always allocated"?

always allocated and cannot be freed. Hence always exists.

If we let it freed, than yes 'it is always allocated', but
may not 'always exist'.

quoted

(b) it cannot be freed.

This is the one I'm questioning.

this is a philosophical question. Should we allow the application 
shoot-its-own-feet or help it from doing so. I tend to
gravitate towards the later.

quoted

(c) it is assigned by default.

I agree on this totally. :)

good. we have some common ground :)

quoted

(d) its permissions cannot be modified.

Why not?  You could pretty easily get a thread going that had its stack
covered with another pkey and that was being very careful what it
accesses.  It could pretty easily set pkey-0's access or write-disable bits.

ok. I see your point. Will not argue against it.

quoted

(e) it bypasses key-permission checks when assigned.

I don't think this is necessary.  I think the only rule we *need* is:

	pkey-0 is allocated implicitly at execve() time.  You do not
	need to call pkey_alloc() to allocate it.

And can be explicitly associated with any address range ?

quoted

An arch need not necessarily map 'the key-0' to its key-0.  It could
internally map it to any of its internal key of its choice, transparent
to the application.

I don't understand what you are saying here.

I was trying to disassociate the notion that "application's key-0 
means hardware's key-0". Nevermind. its not important for this
discussion.

-- 
Ram Pai