Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1299168

Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

From Dave Hansen <dave.hansen@linux.intel.com>
Newsgroups linux.kernel
Subject Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
Date 2015-12-30 00:50 +0100
Message-ID <qLcbD-7bP-1@gated-at.bofh.it> (permalink)
References (10 earlier) <qH9YK-1YM-13@gated-at.bofh.it> <qHa8q-23k-23@gated-at.bofh.it> <qHarL-2rz-17@gated-at.bofh.it> <qHaBs-2uN-3@gated-at.bofh.it> <qHb4t-2GQ-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 12/18/2015 01:45 PM, Linus Torvalds wrote:
> On Fri, Dec 18, 2015 at 1:12 PM, Dave Hansen
> <dave.hansen@linux.intel.com> wrote:
>>
>> But, if we are picking out an execute-only pkey more dynamically, we've
>> got to keep the default value for the entire process somewhere.
> 
> How dynamic do we want to make this, though?

Right now, all I plan to do is make it a one-way trip: if a process does
a prot=PROT_EXEC mapping, we dedicate a key local to that process, and
it gets 14 usable keys.  If it doesn't use prot=PROT_EXEC, then it gets
15 usable keys.

> I haven't looked at the details, and perhaps more importantly, I don't
> know what exactly are the requirements you've gotten from the people
> who are expected to actually use this.
> 
> I think we might want to hardcode a couple of keys as "kernel
> reserved". And I'd rather reserve them up-front than have some user
> program be unhappy later when we want to use them.

The one constant I've heard from the folks that are going to use this is
that 15 keys is not enough.  That's why I'm hesitant to remove _any_ more.

> But I do think we might want to have that "no read access" as a real
> fixed key too, because I think the kernel itself would want to use it:
> 
>  (a) to make sure that it gets the right fault when user space passes
> in a execute-only address to a system call.

Having a dedicated or static key for execute-only doesn't really change
this code.  We just have one extra step to go look in the mm->context
and see which pkey (if any) is assigned to be execute-only in the fault
code.

>  (b) for much more efficient PAGEALLOC_DEBUG for kernel mappings.

The current hardware only applies the keys on _PAGE_USER mappings, so we
can't use it for kernel mappings.

--
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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@kernel.org> - 2015-12-18 02:50 +0100
  Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-18 03:20 +0100
    Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 03:40 +0100
      Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-18 04:00 +0100
        Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 06:30 +0100
          Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? "H. Peter Anvin" <hpa@zytor.com> - 2015-12-18 07:50 +0100
            Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 17:10 +0100
              Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-18 18:00 +0100
              Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-18 19:50 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 20:30 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-18 21:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 21:30 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-18 21:40 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 21:50 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? "H. Peter Anvin" <hpa@zytor.com> - 2015-12-18 22:00 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 22:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-18 22:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-18 22:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-18 22:20 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-18 22:50 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-18 23:30 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-19 00:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-19 00:20 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-19 00:30 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-21 18:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-22 00:00 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-22 00:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-22 00:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-22 00:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-22 00:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Andy Lutomirski <luto@amacapital.net> - 2015-12-22 00:10 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Dave Hansen <dave.hansen@linux.intel.com> - 2015-12-30 00:50 +0100
                Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-18 22:20 +0100
          Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Ingo Molnar <mingo@kernel.org> - 2015-12-18 09:40 +0100
  Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Christoph Hellwig <hch@infradead.org> - 2015-12-18 10:00 +0100
    Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Borislav Petkov <bp@alien8.de> - 2015-12-18 14:00 +0100

csiph-web