Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1283492 > unrolled thread
| Started by | Dave Hansen <dave@sr71.net> |
|---|---|
| First post | 2015-12-04 02:20 +0100 |
| Last post | 2015-12-08 21:40 +0100 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[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
| From | Dave Hansen <dave@sr71.net> |
|---|---|
| Date | 2015-12-04 02:20 +0100 |
| Subject | [PATCH 28/34] x86: wire up mprotect_key() system call |
| Message-ID | <qBNct-4nR-1@gated-at.bofh.it> |
From: Dave Hansen <dave.hansen@linux.intel.com> This is all that we need to get the new system call itself working on x86. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-api@vger.kernel.org --- b/arch/x86/entry/syscalls/syscall_32.tbl | 1 + b/arch/x86/entry/syscalls/syscall_64.tbl | 1 + b/arch/x86/include/uapi/asm/mman.h | 6 ++++++ b/mm/Kconfig | 1 + 4 files changed, 9 insertions(+) diff -puN arch/x86/entry/syscalls/syscall_32.tbl~pkeys-16-x86-mprotect_key arch/x86/entry/syscalls/syscall_32.tbl --- a/arch/x86/entry/syscalls/syscall_32.tbl~pkeys-16-x86-mprotect_key 2015-12-03 16:21:31.109919982 -0800 +++ b/arch/x86/entry/syscalls/syscall_32.tbl 2015-12-03 16:21:31.118920390 -0800 @@ -383,3 +383,4 @@ 374 i386 userfaultfd sys_userfaultfd 375 i386 membarrier sys_membarrier 376 i386 mlock2 sys_mlock2 +377 i386 pkey_mprotect sys_pkey_mprotect diff -puN arch/x86/entry/syscalls/syscall_64.tbl~pkeys-16-x86-mprotect_key arch/x86/entry/syscalls/syscall_64.tbl --- a/arch/x86/entry/syscalls/syscall_64.tbl~pkeys-16-x86-mprotect_key 2015-12-03 16:21:31.111920072 -0800 +++ b/arch/x86/entry/syscalls/syscall_64.tbl 2015-12-03 16:21:31.118920390 -0800 @@ -332,6 +332,7 @@ 323 common userfaultfd sys_userfaultfd 324 common membarrier sys_membarrier 325 common mlock2 sys_mlock2 +326 common pkey_mprotect sys_pkey_mprotect # # x32-specific system call numbers start at 512 to avoid cache impact diff -puN arch/x86/include/uapi/asm/mman.h~pkeys-16-x86-mprotect_key arch/x86/include/uapi/asm/mman.h --- a/arch/x86/include/uapi/asm/mman.h~pkeys-16-x86-mprotect_key 2015-12-03 16:21:31.113920163 -0800 +++ b/arch/x86/include/uapi/asm/mman.h 2015-12-03 16:21:31.118920390 -0800 @@ -20,6 +20,12 @@ ((vm_flags) & VM_PKEY_BIT1 ? _PAGE_PKEY_BIT1 : 0) | \ ((vm_flags) & VM_PKEY_BIT2 ? _PAGE_PKEY_BIT2 : 0) | \ ((vm_flags) & VM_PKEY_BIT3 ? _PAGE_PKEY_BIT3 : 0)) + +#define arch_calc_vm_prot_bits(prot, key) ( \ + ((key) & 0x1 ? VM_PKEY_BIT0 : 0) | \ + ((key) & 0x2 ? VM_PKEY_BIT1 : 0) | \ + ((key) & 0x4 ? VM_PKEY_BIT2 : 0) | \ + ((key) & 0x8 ? VM_PKEY_BIT3 : 0)) #endif #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 _ -- 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/
[toc] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2015-12-08 19:50 +0100 |
| Message-ID | <qDvuO-5Xs-7@gated-at.bofh.it> |
| In reply to | #1283492 |
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? 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/
[toc] | [prev] | [next] | [standalone]
| From | Dave Hansen <dave@sr71.net> |
|---|---|
| Date | 2015-12-08 20:10 +0100 |
| Message-ID | <qDvO9-6je-5@gated-at.bofh.it> |
| In reply to | #1286765 |
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.
--
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/
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2015-12-08 21:40 +0100 |
| Message-ID | <qDxdf-75c-5@gated-at.bofh.it> |
| In reply to | #1286779 |
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/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web