On Jun 30, 2016 2:25 PM, "Dave Hansen" wrote:
>
> On 06/30/2016 10:36 AM, Andy Lutomirski wrote:
> >>> We make baseline_pkru a process-wide baseline and store it in
> >>> mm->context. That way, no matter which thread gets interrupted for a
> >>> signal, they see consistent values. We only write
On 06/30/2016 10:36 AM, Andy Lutomirski wrote:
>>> We make baseline_pkru a process-wide baseline and store it in
>>> mm->context. That way, no matter which thread gets interrupted for a
>>> signal, they see consistent values. We only write to it when an app
>>> _specifically_ asks for it to be up
On Mon, Dec 21, 2015 at 3:07 PM, Andy Lutomirski wrote:
> On Mon, Dec 21, 2015 at 3:04 PM, Dave Hansen
> wrote:
>> On 12/18/2015 02:28 PM, Andy Lutomirski wrote:
>> ...
I could imagine that some kernel person would want to use even more
keys, but I think two fixed keys are kind of the m
On 12/18/2015 01:45 PM, Linus Torvalds wrote:
> On Fri, Dec 18, 2015 at 1:12 PM, Dave Hansen
> 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?
On Mon, Dec 21, 2015 at 3:04 PM, Dave Hansen
wrote:
> On 12/18/2015 02:28 PM, Andy Lutomirski wrote:
> ...
>>> I could imagine that some kernel person would want to use even more
>>> keys, but I think two fixed keys are kind of the minimal we'd want to
>>> use.
>>
>> I imagine we'd reserve key 0 f
On 12/21/2015 03:02 PM, Andy Lutomirski wrote:
> On Mon, Dec 21, 2015 at 3:00 PM, Dave Hansen
> wrote:
>> On 12/21/2015 02:52 PM, Andy Lutomirski wrote:
>>> Perhaps this is silly, but what if the default were changed to deny
>>> reads and writes for unallocated keys? Is there a use case that
>>>
On 12/18/2015 02:28 PM, Andy Lutomirski wrote:
...
>> I could imagine that some kernel person would want to use even more
>> keys, but I think two fixed keys are kind of the minimal we'd want to
>> use.
>
> I imagine we'd reserve key 0 for normal page and key 1 for deny-read.
> Let me be a bit mor
On Mon, Dec 21, 2015 at 3:00 PM, Dave Hansen
wrote:
> On 12/21/2015 02:52 PM, Andy Lutomirski wrote:
>> Perhaps this is silly, but what if the default were changed to deny
>> reads and writes for unallocated keys? Is there a use case that
>> breaks?
>
> It's probably a reasonable debugging featur
On 12/21/2015 02:52 PM, Andy Lutomirski wrote:
> Perhaps this is silly, but what if the default were changed to deny
> reads and writes for unallocated keys? Is there a use case that
> breaks?
It's probably a reasonable debugging feature.
But, anything that takes an XSAVE feature out of its "ini
On Dec 22, 2015 2:04 AM, "Dave Hansen" wrote:
>
> On 12/18/2015 03:16 PM, Andy Lutomirski wrote:
> > Hrm. We might also want an option to change pkru and/or baseline_pkru
> > in all threads in the current mm. That's optional but it could be
> > handy. Maybe it would be as simple as having the a
On 12/18/2015 03:16 PM, Andy Lutomirski wrote:
> Hrm. We might also want an option to change pkru and/or baseline_pkru
> in all threads in the current mm. That's optional but it could be
> handy. Maybe it would be as simple as having the allocate-a-pkey call
> have an option to set an initial ba
On Fri, Dec 18, 2015 at 3:16 PM, Andy Lutomirski wrote:
>
> Yes, I think. If I'm using protection keys to protect some critical
> data structure (important stuff in shared memory, important memory
> mapped files, pmem, etc), then I'll allocate a protection key and set
> PKRU to deny writes. The
On Fri, Dec 18, 2015 at 3:08 PM, Linus Torvalds
wrote:
> On Fri, Dec 18, 2015 at 2:28 PM, Andy Lutomirski wrote:
>>
>> Apps that don't want to use the baseline_pkru mechanism could use
>> syscalls to claim ownership of protection keys but then manage them
>> purely with WRPKRU directly. We could
On Fri, Dec 18, 2015 at 2:28 PM, Andy Lutomirski wrote:
>
> Apps that don't want to use the baseline_pkru mechanism could use
> syscalls to claim ownership of protection keys but then manage them
> purely with WRPKRU directly. We could optionally disallow
> mprotect_key on keys that weren't alloc
On Fri, Dec 18, 2015 at 1:45 PM, Linus Torvalds
wrote:
> On Fri, Dec 18, 2015 at 1:12 PM, Dave Hansen
> 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,
On Fri, Dec 18, 2015 at 1:12 PM, Dave Hansen
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?
I haven't looked at the details, and perhaps more importa
On 12/18/2015 01:04 PM, Linus Torvalds wrote:
> On Fri, Dec 18, 2015 at 12:49 PM, Andy Lutomirski wrote:
>>
>> IOW, I like my idea in which signal delivery always sets PKRU to the
>> application-requested-by-syscall values and sigreturn restores it.
>
> So I don't mind that, as long as the whole
On Fri, Dec 18, 2015 at 1:04 PM, Linus Torvalds
wrote:
>
> I do wonder if you need an explicit value, though. I think it's
> reasonable to say that PKRU value 0 is special. It's what we'd start
> processes with, and why not just say that it's what we run signal
> handlers in?
>
> Would any other v
On 12/18/2015 01:02 PM, Andy Lutomirski wrote:
> On Fri, Dec 18, 2015 at 12:58 PM, H. Peter Anvin wrote:
>> > On 12/18/2015 12:49 PM, Andy Lutomirski wrote:
>>> >>
>>> >> IOW, I like my idea in which signal delivery always sets PKRU to the
>>> >> application-requested-by-syscall values and sigretu
On Fri, Dec 18, 2015 at 12:49 PM, Andy Lutomirski wrote:
>
> IOW, I like my idea in which signal delivery always sets PKRU to the
> application-requested-by-syscall values and sigreturn restores it.
So I don't mind that, as long as the whole "sigreturn restores it" is
part of things.
Your origin
On Fri, Dec 18, 2015 at 12:58 PM, H. Peter Anvin wrote:
> On 12/18/2015 12:49 PM, Andy Lutomirski wrote:
>>
>> IOW, I like my idea in which signal delivery always sets PKRU to the
>> application-requested-by-syscall values and sigreturn restores it.
>> Kinda like sigaltstack, but applies to all si
On 12/18/2015 12:49 PM, Andy Lutomirski wrote:
>
> IOW, I like my idea in which signal delivery always sets PKRU to the
> application-requested-by-syscall values and sigreturn restores it.
> Kinda like sigaltstack, but applies to all signals and affects PKRU
> instead of RSP.
>
I think this is t
On Fri, Dec 18, 2015 at 12:37 PM, Linus Torvalds
wrote:
> On Fri, Dec 18, 2015 at 12:07 PM, Dave Hansen
> wrote:
>>
>> But, I think it's a small one. Basically, RSP would have to pointing at
>> a place which was allowed by protection keys for all of the sigframe
>> setup.
>
> Note that the whole
On Fri, Dec 18, 2015 at 12:07 PM, Dave Hansen
wrote:
>
> But, I think it's a small one. Basically, RSP would have to pointing at
> a place which was allowed by protection keys for all of the sigframe
> setup.
Note that the whole "stack is special" is not at all a new issue.
It's the main reason
On Fri, Dec 18, 2015 at 12:07 PM, Dave Hansen
wrote:
> On 12/18/2015 11:21 AM, Andy Lutomirski wrote:
>> On Fri, Dec 18, 2015 at 10:42 AM, Dave Hansen
>> wrote:
>>> On 12/18/2015 08:04 AM, Andy Lutomirski wrote:
1b. If the app malfunctions such that RSP points to pmem, the kernel
MUST N
On 12/18/2015 11:21 AM, Andy Lutomirski wrote:
> On Fri, Dec 18, 2015 at 10:42 AM, Dave Hansen
> wrote:
>> On 12/18/2015 08:04 AM, Andy Lutomirski wrote:
>>> 1b. If the app malfunctions such that RSP points to pmem, the kernel
>>> MUST NOT clobber the pmem space. I think that this basically manda
On Fri, Dec 18, 2015 at 10:42 AM, Dave Hansen
wrote:
> On 12/18/2015 08:04 AM, Andy Lutomirski wrote:
>> 1b. If the app malfunctions such that RSP points to pmem, the kernel
>> MUST NOT clobber the pmem space. I think that this basically mandates
>> that PKRU needs to have some safe state (i.e. d
On 12/18/2015 08:04 AM, Andy Lutomirski wrote:
> 1b. If the app malfunctions such that RSP points to pmem, the kernel
> MUST NOT clobber the pmem space. I think that this basically mandates
> that PKRU needs to have some safe state (i.e. definitely not the init
> state) on signal delivery: the ker
On 12/18/2015 08:04 AM, Andy Lutomirski wrote:
> Which reminds me: __get_user, etc all respect PKRU because the SDM
> says that PKRU affects all user *and* kernel accesses to user memory
> (i.e. anything with _PAGE_USER). Should get_user_pages also respect
> PKRU?
It does. There are a couple of
On Thu, Dec 17, 2015 at 10:43 PM, H. Peter Anvin wrote:
> On December 17, 2015 9:29:21 PM PST, Andy Lutomirski
> wrote:
>>On Dec 17, 2015 6:53 PM, "Dave Hansen"
>>wrote:
>>>
>>> On 12/17/2015 06:32 PM, Andy Lutomirski wrote:
>>> > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen
>> wrote:
>>> >> Bu
On Fri, Dec 18, 2015 at 12:59:14AM -0800, Christoph Hellwig wrote:
> Stupid question, but what the heck is PKRU? A grep of the kernel tree
> shows no results, and a web search returns mostly Thai language results.
That should explain it:
https://lkml.kernel.org/r/20151214190542.39c48...@viggo.jf
On Thu, Dec 17, 2015 at 05:48:56PM -0800, Andy Lutomirski wrote:
> Hi all-
>
> I think that, for PKRU in particular, we want the default signal
> handling behavior to be a bit unusual.
Stupid question, but what the heck is PKRU? A grep of the kernel tree
shows no results, and a web search return
* Andy Lutomirski wrote:
> > >> But what about the register state when delivering a signal? Don't we
> > >> set the registers to the init state? Do we need to preserve PKRU state
> > >> instead of init'ing it? The init state _is_ nice here because it is
> > >> permissive allows us to do somet
On December 17, 2015 9:29:21 PM PST, Andy Lutomirski
wrote:
>On Dec 17, 2015 6:53 PM, "Dave Hansen"
>wrote:
>>
>> On 12/17/2015 06:32 PM, Andy Lutomirski wrote:
>> > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen
> wrote:
>> >> But what about the register state when delivering a signal? Don't
>we
On Dec 17, 2015 6:53 PM, "Dave Hansen" wrote:
>
> On 12/17/2015 06:32 PM, Andy Lutomirski wrote:
> > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen
> > wrote:
> >> But what about the register state when delivering a signal? Don't we
> >> set the registers to the init state? Do we need to preserv
On 12/17/2015 06:32 PM, Andy Lutomirski wrote:
> On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen
> wrote:
>> But what about the register state when delivering a signal? Don't we
>> set the registers to the init state? Do we need to preserve PKRU state
>> instead of init'ing it? The init state _is
On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen
wrote:
> On 12/17/2015 05:48 PM, Andy Lutomirski wrote:
>> I think that, for PKRU in particular, we want the default signal
>> handling behavior to be a bit unusual.
>>
>> When a signal is delivered, I think we should save the entire xstate
>> including
On 12/17/2015 05:48 PM, Andy Lutomirski wrote:
> I think that, for PKRU in particular, we want the default signal
> handling behavior to be a bit unusual.
>
> When a signal is delivered, I think we should save the entire xstate
> including PKRU. I see no reason to do anything other than that.
Ye
Hi all-
I think that, for PKRU in particular, we want the default signal
handling behavior to be a bit unusual.
When a signal is delivered, I think we should save the entire xstate
including PKRU. I see no reason to do anything other than that.
When a signal returns (sigreturn is called), thoug
39 matches
Mail list logo