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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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 >>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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. >> >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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: >>> >>

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

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:

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

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

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

* 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

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

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

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

* 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

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

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:

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

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: >>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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 >>

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

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.

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

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),

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

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 > >>

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

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 >

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

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),

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

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.

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

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

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

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