linux-kernel - Re: [PATCH 5/8] x86, pkeys: allocation/free syscalls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Jun 2016 12:37:05 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Dave Hansen <dave@...1.net>
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org,
	linux-api@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-mm@...ck.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, dave.hansen@...ux.intel.com
Subject: Re: [PATCH 5/8] x86, pkeys: allocation/free syscalls

Sorry, I have one more obnoxious question...

> +static inline
> +int mm_pkey_free(struct mm_struct *mm, int pkey)
> +{
> +	/*
> +	 * pkey 0 is special, always allocated and can never
> +	 * be freed.
> +	 */
> +	if (!pkey || !validate_pkey(pkey))
> +		return -EINVAL;
> +	if (!mm_pkey_is_allocated(mm, pkey))
> +		return -EINVAL;
> +
> +	mm_set_pkey_free(mm, pkey);
> +
> +	return 0;
> +}

If I read this right, it doesn't actually remove any pkey restrictions
that may have been applied while the key was allocated.  So there could be
pages with that key assigned that might do surprising things if the key is
reallocated for another use later, right?  Is that how the API is intended
to work?

Thanks,

jon