Re: [PATCH 26/26] x86, pkeys: Documentation

On Wed, Oct 21, 2015 at 12:11 PM, Dave Hansen wrote: > On 10/21/2015 11:55 AM, Andy Lutomirski wrote: >> On Fri, Oct 16, 2015 at 8:12 AM, Dave Hansen wrote: >>> On 10/03/2015 12:27 AM, Ingo Molnar wrote: - Along similar considerations, also add a sys_pkey_query() system call to query

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/21/2015 11:55 AM, Andy Lutomirski wrote: > On Fri, Oct 16, 2015 at 8:12 AM, Dave Hansen wrote: >> On 10/03/2015 12:27 AM, Ingo Molnar wrote: >>> - Along similar considerations, also add a sys_pkey_query() system call to >>> query >>>the mapping of a specific pkey. (returns -EBADF or

Re: [PATCH 26/26] x86, pkeys: Documentation

On Fri, Oct 16, 2015 at 8:12 AM, Dave Hansen wrote: > On 10/03/2015 12:27 AM, Ingo Molnar wrote: >> - Along similar considerations, also add a sys_pkey_query() system call to >> query >>the mapping of a specific pkey. (returns -EBADF or so if the key is not >> mapped >>at the moment.)

Re: [PATCH 26/26] x86, pkeys: Documentation

On Fri, Oct 16, 2015 at 8:12 AM, Dave Hansen wrote: > On 10/03/2015 12:27 AM, Ingo Molnar wrote: >> - Along similar considerations, also add a sys_pkey_query() system call to >> query >>the mapping of a specific pkey. (returns -EBADF or so if the key is not >> mapped >>

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/21/2015 11:55 AM, Andy Lutomirski wrote: > On Fri, Oct 16, 2015 at 8:12 AM, Dave Hansen wrote: >> On 10/03/2015 12:27 AM, Ingo Molnar wrote: >>> - Along similar considerations, also add a sys_pkey_query() system call to >>> query >>>the mapping of a specific pkey.

Re: [PATCH 26/26] x86, pkeys: Documentation

On Wed, Oct 21, 2015 at 12:11 PM, Dave Hansen wrote: > On 10/21/2015 11:55 AM, Andy Lutomirski wrote: >> On Fri, Oct 16, 2015 at 8:12 AM, Dave Hansen wrote: >>> On 10/03/2015 12:27 AM, Ingo Molnar wrote: - Along similar considerations, also add a

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/03/2015 12:27 AM, Ingo Molnar wrote: > - Along similar considerations, also add a sys_pkey_query() system call to > query >the mapping of a specific pkey. (returns -EBADF or so if the key is not > mapped >at the moment.) This too could be vDSO accelerated in the future. > > I.e.

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/03/2015 12:27 AM, Ingo Molnar wrote: > - Along similar considerations, also add a sys_pkey_query() system call to > query >the mapping of a specific pkey. (returns -EBADF or so if the key is not > mapped >at the moment.) This too could be vDSO accelerated in the future. > > I.e.

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/07/2015 01:39 PM, Andy Lutomirski wrote: > On Wed, Oct 7, 2015 at 1:24 PM, Dave Hansen wrote: >> On 10/03/2015 01:17 AM, Ingo Molnar wrote: >>> Right now the native x86 PTE format allows two protection related bits for >>> user-space pages: >>> >>> _PAGE_BIT_RW: if 0 the

Re: [PATCH 26/26] x86, pkeys: Documentation

On Wed, Oct 7, 2015 at 1:24 PM, Dave Hansen wrote: > On 10/03/2015 01:17 AM, Ingo Molnar wrote: >> Right now the native x86 PTE format allows two protection related bits for >> user-space pages: >> >> _PAGE_BIT_RW: if 0 the page is read-only, if 1 then >> it's read-write >>

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/03/2015 01:17 AM, Ingo Molnar wrote: > Right now the native x86 PTE format allows two protection related bits for > user-space pages: > > _PAGE_BIT_RW: if 0 the page is read-only, if 1 then it's > read-write > _PAGE_BIT_NX: if 0 the page is

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > On 10/03/2015 12:27 AM, Ingo Molnar wrote: > > - I'd also suggest providing an initial value with the 'alloc' call. It's > > true > >that user-space can do this itself in assembly, OTOH there's no reason > > not to > >provide a C interface for this. > > You

Re: [PATCH 26/26] x86, pkeys: Documentation

On Wed, Oct 7, 2015 at 1:24 PM, Dave Hansen wrote: > On 10/03/2015 01:17 AM, Ingo Molnar wrote: >> Right now the native x86 PTE format allows two protection related bits for >> user-space pages: >> >> _PAGE_BIT_RW: if 0 the page is read-only, if 1 then >> it's

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/03/2015 01:17 AM, Ingo Molnar wrote: > Right now the native x86 PTE format allows two protection related bits for > user-space pages: > > _PAGE_BIT_RW: if 0 the page is read-only, if 1 then it's > read-write > _PAGE_BIT_NX: if 0 the page is

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/07/2015 01:39 PM, Andy Lutomirski wrote: > On Wed, Oct 7, 2015 at 1:24 PM, Dave Hansen wrote: >> On 10/03/2015 01:17 AM, Ingo Molnar wrote: >>> Right now the native x86 PTE format allows two protection related bits for >>> user-space pages: >>> >>> _PAGE_BIT_RW:

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > On 10/03/2015 12:27 AM, Ingo Molnar wrote: > > - I'd also suggest providing an initial value with the 'alloc' call. It's > > true > >that user-space can do this itself in assembly, OTOH there's no reason > > not to > >provide a C interface for

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/03/2015 12:27 AM, Ingo Molnar wrote: > - I'd also suggest providing an initial value with the 'alloc' call. It's > true >that user-space can do this itself in assembly, OTOH there's no reason not > to >provide a C interface for this. You mean an initial value for the rights

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/03/2015 12:27 AM, Ingo Molnar wrote: > - I'd also suggest providing an initial value with the 'alloc' call. It's > true >that user-space can do this itself in assembly, OTOH there's no reason not > to >provide a C interface for this. You mean an initial value for the rights

Re: [PATCH 26/26] x86, pkeys: Documentation

* Ingo Molnar wrote: > > * Dave Hansen wrote: > > > > Another question, related to enumeration as well: I'm wondering whether > > > there's any way for the kernel to allocate a bit or two for its own > > > purposes - > > > such as protecting crypto keys? Or is the facility fundamentally

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > On 10/01/2015 11:23 PM, Ingo Molnar wrote: > >> > Also, how do we do mprotect_pkey and say "don't change the key"? > > > > So if we start managing keys as a resource (i.e. alloc/free up to 16 of > > them), > > and provide APIs for user-space to do all that, then

Re: [PATCH 26/26] x86, pkeys: Documentation

* Ingo Molnar wrote: > > It's quite likely that you will find that compilers put read-only constants > > in > > the text section, knowing that executable means readable. > > At least with pkeys enabling true --x mappings, that compiler practice > becomes a > (mild) security problem: it

Re: [PATCH 26/26] x86, pkeys: Documentation

* Paolo Bonzini wrote: > > > On 02/10/2015 13:58, Linus Torvalds wrote: > > On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini wrote: > >> On 02/10/2015 00:48, Linus Torvalds wrote: > >>> It's quite likely that you will find that compilers put read-only > >>> constants in the text section,

Re: [PATCH 26/26] x86, pkeys: Documentation

* Paolo Bonzini wrote: > > > On 02/10/2015 13:58, Linus Torvalds wrote: > > On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini wrote: > >> On 02/10/2015 00:48, Linus Torvalds wrote: > >>> It's quite likely that you will find that compilers put read-only >

Re: [PATCH 26/26] x86, pkeys: Documentation

* Ingo Molnar wrote: > > It's quite likely that you will find that compilers put read-only constants > > in > > the text section, knowing that executable means readable. > > At least with pkeys enabling true --x mappings, that compiler practice > becomes a > (mild)

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > On 10/01/2015 11:23 PM, Ingo Molnar wrote: > >> > Also, how do we do mprotect_pkey and say "don't change the key"? > > > > So if we start managing keys as a resource (i.e. alloc/free up to 16 of > > them), > > and provide APIs for user-space to do all

Re: [PATCH 26/26] x86, pkeys: Documentation

* Ingo Molnar wrote: > > * Dave Hansen wrote: > > > > Another question, related to enumeration as well: I'm wondering whether > > > there's any way for the kernel to allocate a bit or two for its own > > > purposes - > > > such as protecting crypto keys?

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 06:38 PM, Linus Torvalds wrote: > On Thu, Oct 1, 2015 at 6:56 PM, Dave Hansen wrote: >> >> Also, a quick ftrace showed that most mmap() callers that set PROT_EXEC >> also set PROT_READ. I'm just assuming that folks are setting PROT_READ >> but aren't _really_ going to read it, so

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 11:23 PM, Ingo Molnar wrote: >> > Also, how do we do mprotect_pkey and say "don't change the key"? > So if we start managing keys as a resource (i.e. alloc/free up to 16 of > them), and > provide APIs for user-space to do all that, then user-space is not supposed > to > touch

Re: [PATCH 26/26] x86, pkeys: Documentation

On 02/10/2015 13:58, Linus Torvalds wrote: > On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini wrote: >> On 02/10/2015 00:48, Linus Torvalds wrote: >>> It's quite likely that you will find that compilers put read-only >>> constants in the text section, knowing that executable means readable. >> >>

Re: [PATCH 26/26] x86, pkeys: Documentation

On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini wrote: > On 02/10/2015 00:48, Linus Torvalds wrote: >> It's quite likely that you will find that compilers put read-only >> constants in the text section, knowing that executable means readable. > > Not on x86 (because it has large immediates; RISC

Re: [PATCH 26/26] x86, pkeys: Documentation

On 02/10/2015 00:48, Linus Torvalds wrote: > It's quite likely that you will find that compilers put read-only > constants in the text section, knowing that executable means readable. Not on x86 (because it has large immediates; RISC machines and s390 do put large constants in the text

Re: [PATCH 26/26] x86, pkeys: Documentation

* Linus Torvalds wrote: > On Thu, Oct 1, 2015 at 6:33 PM, Dave Hansen wrote: > > > > Here it is in a quite fugly form (well, it's not opt-in). Init crashes if > > I > > boot with this, though. > > > > I'll see if I can turn it in to a bit more of an opt-in and see what's > > actually going

Re: [PATCH 26/26] x86, pkeys: Documentation

* Andy Lutomirski wrote: > >> Assuming it boots up fine on a typical distro, i.e. assuming that there > >> are no > >> surprises where PROT_READ && PROT_EXEC sections are accessed as data. > > > > I can't wait to find out what implicitly expects PROT_READ from > > PROT_EXEC mappings. :) So

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > On 10/01/2015 01:39 PM, Kees Cook wrote: > > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: > >> So could we try to add an (opt-in) kernel option that enables this > >> transparently > >> and automatically for all PROT_EXEC && !PROT_WRITE mappings, without any > >>

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > On 10/01/2015 01:39 PM, Kees Cook wrote: > > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: > >> So could we try to add an (opt-in) kernel option that enables this > >> transparently > >> and automatically for all PROT_EXEC &&

Re: [PATCH 26/26] x86, pkeys: Documentation

* Andy Lutomirski wrote: > >> Assuming it boots up fine on a typical distro, i.e. assuming that there > >> are no > >> surprises where PROT_READ && PROT_EXEC sections are accessed as data. > > > > I can't wait to find out what implicitly expects PROT_READ from > >

Re: [PATCH 26/26] x86, pkeys: Documentation

On 02/10/2015 00:48, Linus Torvalds wrote: > It's quite likely that you will find that compilers put read-only > constants in the text section, knowing that executable means readable. Not on x86 (because it has large immediates; RISC machines and s390 do put large constants in the text

Re: [PATCH 26/26] x86, pkeys: Documentation

On 02/10/2015 13:58, Linus Torvalds wrote: > On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini wrote: >> On 02/10/2015 00:48, Linus Torvalds wrote: >>> It's quite likely that you will find that compilers put read-only >>> constants in the text section, knowing that executable

Re: [PATCH 26/26] x86, pkeys: Documentation

On Fri, Oct 2, 2015 at 7:49 AM, Paolo Bonzini wrote: > On 02/10/2015 00:48, Linus Torvalds wrote: >> It's quite likely that you will find that compilers put read-only >> constants in the text section, knowing that executable means readable. > > Not on x86 (because it has

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 06:38 PM, Linus Torvalds wrote: > On Thu, Oct 1, 2015 at 6:56 PM, Dave Hansen wrote: >> >> Also, a quick ftrace showed that most mmap() callers that set PROT_EXEC >> also set PROT_READ. I'm just assuming that folks are setting PROT_READ >> but aren't _really_ going

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 11:23 PM, Ingo Molnar wrote: >> > Also, how do we do mprotect_pkey and say "don't change the key"? > So if we start managing keys as a resource (i.e. alloc/free up to 16 of > them), and > provide APIs for user-space to do all that, then user-space is not supposed > to > touch

Re: [PATCH 26/26] x86, pkeys: Documentation

* Linus Torvalds wrote: > On Thu, Oct 1, 2015 at 6:33 PM, Dave Hansen wrote: > > > > Here it is in a quite fugly form (well, it's not opt-in). Init crashes if > > I > > boot with this, though. > > > > I'll see if I can turn it in to a bit more

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 6:56 PM, Dave Hansen wrote: > > Also, a quick ftrace showed that most mmap() callers that set PROT_EXEC > also set PROT_READ. I'm just assuming that folks are setting PROT_READ > but aren't _really_ going to read it, so we can safely deny them all > access other than exec.

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 3:33 PM, Dave Hansen wrote: > On 10/01/2015 01:39 PM, Kees Cook wrote: >> On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >>> So could we try to add an (opt-in) kernel option that enables this >>> transparently >>> and automatically for all PROT_EXEC && !PROT_WRITE

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 03:48 PM, Linus Torvalds wrote: > On Thu, Oct 1, 2015 at 6:33 PM, Dave Hansen wrote: >> >> Here it is in a quite fugly form (well, it's not opt-in). Init crashes >> if I boot with this, though. >> >> I'll see if I can turn it in to a bit more of an opt-in and see what's >> actually

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 6:33 PM, Dave Hansen wrote: > > Here it is in a quite fugly form (well, it's not opt-in). Init crashes > if I boot with this, though. > > I'll see if I can turn it in to a bit more of an opt-in and see what's > actually going wrong. It's quite likely that you will find

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 03:35 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 3:33 PM, Dave Hansen wrote: >> On 10/01/2015 01:39 PM, Kees Cook wrote: >>> On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: So could we try to add an (opt-in) kernel option that enables this transparently and

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 3:33 PM, Dave Hansen wrote: > On 10/01/2015 01:39 PM, Kees Cook wrote: >> On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >>> So could we try to add an (opt-in) kernel option that enables this >>> transparently >>> and automatically for all PROT_EXEC && !PROT_WRITE

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 01:39 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >> So could we try to add an (opt-in) kernel option that enables this >> transparently >> and automatically for all PROT_EXEC && !PROT_WRITE mappings, without any >> user-space changes and syscalls

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 01:39 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >> * Dave Hansen wrote: If yes then this could be a significant security feature / usecase for pkeys: > > Which CPUs (will) have pkeys? It hasn't been announced publicly, so all I can say

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 1:39 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >> >> * Dave Hansen wrote: >> >>> > If yes then this could be a significant security feature / usecase for >>> > pkeys: > > Which CPUs (will) have pkeys? > >>> > executable sections of shared

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: > > * Dave Hansen wrote: > >> > If yes then this could be a significant security feature / usecase for >> > pkeys: Which CPUs (will) have pkeys? >> > executable sections of shared libraries and binaries could be mapped with >> > pkey >> >

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > > If yes then this could be a significant security feature / usecase for > > pkeys: > > executable sections of shared libraries and binaries could be mapped with > > pkey > > access disabled. If I read the Intel documentation correctly then that > > should > > be

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > > If yes then this could be a significant security feature / usecase for > > pkeys: > > executable sections of shared libraries and binaries could be mapped with > > pkey > > access disabled. If I read the Intel documentation correctly then that > >

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 1:39 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >> >> * Dave Hansen wrote: >> >>> > If yes then this could be a significant security feature / usecase for >>> > pkeys: > > Which CPUs

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: > > * Dave Hansen wrote: > >> > If yes then this could be a significant security feature / usecase for >> > pkeys: Which CPUs (will) have pkeys? >> > executable sections of shared libraries and binaries could

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 01:39 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >> * Dave Hansen wrote: If yes then this could be a significant security feature / usecase for pkeys: > > Which CPUs (will) have pkeys? It hasn't been

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 6:33 PM, Dave Hansen wrote: > > Here it is in a quite fugly form (well, it's not opt-in). Init crashes > if I boot with this, though. > > I'll see if I can turn it in to a bit more of an opt-in and see what's > actually going wrong. It's quite likely that

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 03:48 PM, Linus Torvalds wrote: > On Thu, Oct 1, 2015 at 6:33 PM, Dave Hansen wrote: >> >> Here it is in a quite fugly form (well, it's not opt-in). Init crashes >> if I boot with this, though. >> >> I'll see if I can turn it in to a bit more of an opt-in and see

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 3:33 PM, Dave Hansen wrote: > On 10/01/2015 01:39 PM, Kees Cook wrote: >> On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >>> So could we try to add an (opt-in) kernel option that enables this >>> transparently >>> and automatically for

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 03:35 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 3:33 PM, Dave Hansen wrote: >> On 10/01/2015 01:39 PM, Kees Cook wrote: >>> On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: So could we try to add an (opt-in) kernel option that enables

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 3:33 PM, Dave Hansen wrote: > On 10/01/2015 01:39 PM, Kees Cook wrote: >> On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >>> So could we try to add an (opt-in) kernel option that enables this >>> transparently >>> and automatically for

Re: [PATCH 26/26] x86, pkeys: Documentation

On 10/01/2015 01:39 PM, Kees Cook wrote: > On Thu, Oct 1, 2015 at 4:17 AM, Ingo Molnar wrote: >> So could we try to add an (opt-in) kernel option that enables this >> transparently >> and automatically for all PROT_EXEC && !PROT_WRITE mappings, without any >> user-space changes

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Oct 1, 2015 at 6:56 PM, Dave Hansen wrote: > > Also, a quick ftrace showed that most mmap() callers that set PROT_EXEC > also set PROT_READ. I'm just assuming that folks are setting PROT_READ > but aren't _really_ going to read it, so we can safely deny them all > access

Re: [PATCH 26/26] x86, pkeys: Documentation

* Andy Lutomirski wrote: > This may mean that we want to have a way for binaries to indicate that they > want > their --x segments to be loaded with a particular protection key. The right > way > to do that might be using an ELF note, and I also want to use ELF notes to > allow > turning

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > > I.e. AFAICS pkeys could be used to create true '--x' permissions for > > executable > > (user-space) pages. > > Just remember that all of the protections are dependent on the contents of > PKRU. > If an attacker controls the Access-Disable bit in PKRU for the >

Re: [PATCH 26/26] x86, pkeys: Documentation

* Andy Lutomirski wrote: > This may mean that we want to have a way for binaries to indicate that they > want > their --x segments to be loaded with a particular protection key. The right > way > to do that might be using an ELF note, and I also want to use ELF notes

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > > I.e. AFAICS pkeys could be used to create true '--x' permissions for > > executable > > (user-space) pages. > > Just remember that all of the protections are dependent on the contents of > PKRU. > If an attacker controls the Access-Disable bit in

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Sep 24, 2015 at 12:10 PM, Dave Hansen wrote: > On 09/24/2015 02:49 AM, Ingo Molnar wrote: >> * Dave Hansen wrote: Another question, related to enumeration as well: I'm wondering whether there's any way for the kernel to allocate a bit or two for its own purposes -

Re: [PATCH 26/26] x86, pkeys: Documentation

On 09/24/2015 02:49 AM, Ingo Molnar wrote: > * Dave Hansen wrote: >>> Another question, related to enumeration as well: I'm wondering whether >>> there's any way for the kernel to allocate a bit or two for its own >>> purposes - >>> such as protecting crypto keys? Or is the facility

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > > Another question, related to enumeration as well: I'm wondering whether > > there's any way for the kernel to allocate a bit or two for its own > > purposes - > > such as protecting crypto keys? Or is the facility fundamentally intended > > for > > user-space use

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > > Another question, related to enumeration as well: I'm wondering whether > > there's any way for the kernel to allocate a bit or two for its own > > purposes - > > such as protecting crypto keys? Or is the facility fundamentally intended > > for > >

Re: [PATCH 26/26] x86, pkeys: Documentation

On Thu, Sep 24, 2015 at 12:10 PM, Dave Hansen wrote: > On 09/24/2015 02:49 AM, Ingo Molnar wrote: >> * Dave Hansen wrote: Another question, related to enumeration as well: I'm wondering whether there's any way for the kernel to allocate a bit or two for

Re: [PATCH 26/26] x86, pkeys: Documentation

On 09/24/2015 02:49 AM, Ingo Molnar wrote: > * Dave Hansen wrote: >>> Another question, related to enumeration as well: I'm wondering whether >>> there's any way for the kernel to allocate a bit or two for its own >>> purposes - >>> such as protecting crypto keys? Or is the

Re: [PATCH 26/26] x86, pkeys: Documentation

On 09/20/2015 01:55 AM, Ingo Molnar wrote: > * Dave Hansen wrote: >> +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature >> +which will be found on future Intel CPUs. >> + >> +Memory Protection Keys provides a mechanism for enforcing page-based >> +protections, but without

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature > +which will be found on future Intel CPUs. > + > +Memory Protection Keys provides a mechanism for enforcing page-based > +protections, but without requiring modification of the page tables > +when an

Re: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen wrote: > +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature > +which will be found on future Intel CPUs. > + > +Memory Protection Keys provides a mechanism for enforcing page-based > +protections, but without requiring modification of the page

Re: [PATCH 26/26] x86, pkeys: Documentation

On 09/20/2015 01:55 AM, Ingo Molnar wrote: > * Dave Hansen wrote: >> +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature >> +which will be found on future Intel CPUs. >> + >> +Memory Protection Keys provides a mechanism for enforcing page-based >> +protections,

[PATCH 26/26] x86, pkeys: Documentation

--- b/Documentation/x86/protection-keys.txt | 65 1 file changed, 65 insertions(+) diff -puN /dev/null Documentation/x86/protection-keys.txt --- /dev/null 2015-07-13 14:24:11.435656502 -0700 +++ b/Documentation/x86/protection-keys.txt 2015-09-16

[PATCH 26/26] x86, pkeys: Documentation

--- b/Documentation/x86/protection-keys.txt | 65 1 file changed, 65 insertions(+) diff -puN /dev/null Documentation/x86/protection-keys.txt --- /dev/null 2015-07-13 14:24:11.435656502 -0700 +++ b/Documentation/x86/protection-keys.txt 2015-09-16