Re: [PATCH 28/34] x86: wire up mprotect_key() system call

From	Thomas Gleixner <tglx@linutronix.de>
Newsgroups	linux.kernel
Subject	Re: [PATCH 28/34] x86: wire up mprotect_key() system call
Date	2015-12-08 21:40 +0100
Message-ID	<qDxdf-75c-5@gated-at.bofh.it> (permalink)
References	<qBNct-4nR-3@gated-at.bofh.it> <qBNct-4nR-1@gated-at.bofh.it> <qDvuO-5Xs-7@gated-at.bofh.it> <qDvO9-6je-5@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Tue, 8 Dec 2015, Dave Hansen wrote:
> On 12/08/2015 10:44 AM, Thomas Gleixner wrote:
> > On Thu, 3 Dec 2015, Dave Hansen wrote:
> >>  #include <asm-generic/mman.h>
> >> diff -puN mm/Kconfig~pkeys-16-x86-mprotect_key mm/Kconfig
> >> --- a/mm/Kconfig~pkeys-16-x86-mprotect_key	2015-12-03 16:21:31.114920208 -0800
> >> +++ b/mm/Kconfig	2015-12-03 16:21:31.119920435 -0800
> >> @@ -679,4 +679,5 @@ config NR_PROTECTION_KEYS
> >>  	# Everything supports a _single_ key, so allow folks to
> >>  	# at least call APIs that take keys, but require that the
> >>  	# key be 0.
> >> +	default 16 if X86_INTEL_MEMORY_PROTECTION_KEYS
> >>  	default 1
> > 
> > What happens if I set that to 42?
> > 
> > I think we want to make this a runtime evaluated thingy. If pkeys are
> > compiled in, but the machine does not support it then we don't support
> > 16 keys, or do we?
> 
> We do have runtime evaluation:
> 
> #define arch_max_pkey() (boot_cpu_has(X86_FEATURE_OSPKE) ?      \
>                              CONFIG_NR_PROTECTION_KEYS : 1)
> 
> The config option really just sets the architectural limit for how many
> are supported.  So it probably needs a better name at least.  Let me
> take a look at getting rid of this config option entirely.

Well, it does not set the architectural limit. It sets some random
value which the guy who configures the kernel choses.

The limit we have in the architecture is 16 because we only have 4
bits for it.
 
arch_max_pkey() is architecture specific, so we can make this:

#define arch_max_pkey() (boot_cpu_has(X86_FEATURE_OSPKE) ? 16 : 1)

And when we magically get more bits in the next century, then '16' can
become a variable or whatever.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[PATCH 28/34] x86: wire up mprotect_key() system call Dave Hansen <dave@sr71.net> - 2015-12-04 02:20 +0100
  Re: [PATCH 28/34] x86: wire up mprotect_key() system call Thomas Gleixner <tglx@linutronix.de> - 2015-12-08 19:50 +0100
    Re: [PATCH 28/34] x86: wire up mprotect_key() system call Dave Hansen <dave@sr71.net> - 2015-12-08 20:10 +0100
      Re: [PATCH 28/34] x86: wire up mprotect_key() system call Thomas Gleixner <tglx@linutronix.de> - 2015-12-08 21:40 +0100

csiph-web