On Sat, Mar 02, 2024 at 03:57:02PM +0100, Szabolcs Nagy wrote:
> * Mark Brown [2024-02-21 17:36:12 +]:
> > > I said NOP but there's no reason it strictly needs to be a NOP. It
> > > could instead do something reasonable to convey the state of racing
> > > with shadow stack being disabled.
>
On Sat, Mar 2, 2024 at 6:57 AM Szabolcs Nagy wrote:
>
> * Mark Brown [2024-02-21 17:36:12 +]:
>
> > On Wed, Feb 21, 2024 at 09:58:01AM -0500, dal...@libc.org wrote:
> > > On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> > > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.
* Mark Brown [2024-02-21 17:36:12 +]:
> On Wed, Feb 21, 2024 at 09:58:01AM -0500, dal...@libc.org wrote:
> > On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> > > > On Wed, Feb 21, 2024 at 12:35:48AM +, Edg
On Wed, Feb 21, 2024 at 07:22:21PM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > It's fine to turn RDSSP into an actual emulated read of the SSP, or
> > at
> > least an emulated load of zero so that uninitialized data is not left
> > in the target
On Wed, Feb 21, 2024 at 12:25 PM H.J. Lu wrote:
>
> On Wed, Feb 21, 2024 at 12:18 PM H.J. Lu wrote:
> >
> > On Wed, Feb 21, 2024 at 11:22 AM Edgecombe, Rick P
> > wrote:
> > >
> > > On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > > > Due to arbitrarily nestable signal frames, no, t
On Wed, Feb 21, 2024 at 12:18 PM H.J. Lu wrote:
>
> On Wed, Feb 21, 2024 at 11:22 AM Edgecombe, Rick P
> wrote:
> >
> > On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > > Due to arbitrarily nestable signal frames, no, this does not suffice.
> > > An interrupted operation using the lo
On Wed, Feb 21, 2024 at 11:22 AM Edgecombe, Rick P
wrote:
>
> On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > Due to arbitrarily nestable signal frames, no, this does not suffice.
> > An interrupted operation using the lock could be arbitrarily delayed,
> > even never execute again,
On Wed, Feb 21, 2024 at 07:22:21PM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> > Due to arbitrarily nestable signal frames, no, this does not suffice.
> > An interrupted operation using the lock could be arbitrarily delayed,
> > even never execute a
On Wed, 2024-02-21 at 14:06 -0500, dal...@libc.org wrote:
> Due to arbitrarily nestable signal frames, no, this does not suffice.
> An interrupted operation using the lock could be arbitrarily delayed,
> even never execute again, making any call to dlopen deadlock.
Doh! Yep, it is not robust to th
On Wed, Feb 21, 2024 at 06:32:20PM +, Mark Brown wrote:
> On Wed, Feb 21, 2024 at 12:57:19PM -0500, dal...@libc.org wrote:
> > On Wed, Feb 21, 2024 at 05:36:12PM +, Mark Brown wrote:
>
> > > This feels like it's getting complicated and I fear it may be an uphill
> > > struggle to get such
On Wed, Feb 21, 2024 at 06:53:44PM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 13:30 -0500, dal...@libc.org wrote:
> > > 3 is the cleanest and safest I think, and it was thought it might
> > > not
> > > need kernel help, due to a scheme Florian had to direct signals to
> > > specific th
On Wed, 2024-02-21 at 13:30 -0500, dal...@libc.org wrote:
> > 3 is the cleanest and safest I think, and it was thought it might
> > not
> > need kernel help, due to a scheme Florian had to direct signals to
> > specific threads. It's my preference at this point.
>
> The operations where the shadow
On Wed, Feb 21, 2024 at 12:57:19PM -0500, dal...@libc.org wrote:
> On Wed, Feb 21, 2024 at 05:36:12PM +, Mark Brown wrote:
> > This feels like it's getting complicated and I fear it may be an uphill
> > struggle to get such code merged, at least for arm64. My instinct is
> > that it's going t
On Wed, Feb 21, 2024 at 06:12:30PM +, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 12:57 -0500, dal...@libc.org wrote:
> > > This feels like it's getting complicated and I fear it may be an
> > > uphill
> > > struggle to get such code merged, at least for arm64. My instinct
> > > is
> > >
On Wed, 2024-02-21 at 12:57 -0500, dal...@libc.org wrote:
> > This feels like it's getting complicated and I fear it may be an
> > uphill
> > struggle to get such code merged, at least for arm64. My instinct
> > is
> > that it's going to be much more robust and generally tractable to
> > let
> > t
On Wed, Feb 21, 2024 at 05:36:12PM +, Mark Brown wrote:
> On Wed, Feb 21, 2024 at 09:58:01AM -0500, dal...@libc.org wrote:
> > On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> > > > On Wed, Feb 21, 2024 at 12:35
On Wed, Feb 21, 2024 at 09:58:01AM -0500, dal...@libc.org wrote:
> On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> > > On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
> > > > (INCSSP, RSTORSSP, et
On Wed, Feb 21, 2024 at 01:53:10PM +, Mark Brown wrote:
> On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> > On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
>
> > > (INCSSP, RSTORSSP, etc). These are a collection of instructions that
> > > allow limited con
On Tue, Feb 20, 2024 at 08:27:37PM -0500, dal...@libc.org wrote:
> On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
> > (INCSSP, RSTORSSP, etc). These are a collection of instructions that
> > allow limited control of the SSP. When shadow stack gets disabled,
> > these suddenly t
On Tue, 2024-02-20 at 18:59 -0500, Stefan O'Rear wrote:
>
> Ideally for riscv only writes would cause conversion, an incssp
> underflow
> which performs shadow stack reads would be able to fault early.
Why can't makecontext() just clobber part of the low address side of
the passed in stack with a
On Tue, 2024-02-20 at 18:11 -0800, Rick Edgecombe wrote:
> Some specific cases that were still open were longjmp()ing off of a
> custom userspace threading library stack, which may not have left a
> token behind when it jumped to a new stack. And also, potentially off
> of an alt shadow stack in th
On Tue, 2024-02-20 at 20:27 -0500, dal...@libc.org wrote:
> > Then I think WRSS might fit your requirements better than what
> > glibc
> > did. It was considered a reduced security mode that made libc's job
> > much easier and had better compatibility, but the last discussion
> > was
> > to try to
On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
> On Tue, 2024-02-20 at 18:54 -0500, dal...@libc.org wrote:
> > On Tue, Feb 20, 2024 at 11:30:22PM +, Edgecombe, Rick P wrote:
> > > On Tue, 2024-02-20 at 13:57 -0500, Rich Felker wrote:
> > > > On Tue, Feb 20, 2024 at 06:41:05P
On Wed, Feb 21, 2024 at 12:35:48AM +, Edgecombe, Rick P wrote:
> doing. But those threads might be using shadow stack instructions
> (INCSSP, RSTORSSP, etc). These are a collection of instructions that
> allow limited control of the SSP. When shadow stack gets disabled,
> these suddenly turn i
On Tue, Feb 20, 2024 at 06:59:58PM -0500, Stefan O'Rear wrote:
> On Tue, Feb 20, 2024, at 6:30 PM, Edgecombe, Rick P wrote:
> > Maybe I'm misunderstanding. I thought the proposal included allowing
> > shadow stack access to convert normal address ranges to shadow stack,
> > and normal writes to co
On Tue, 2024-02-20 at 18:54 -0500, dal...@libc.org wrote:
> On Tue, Feb 20, 2024 at 11:30:22PM +, Edgecombe, Rick P wrote:
> > On Tue, 2024-02-20 at 13:57 -0500, Rich Felker wrote:
> > > On Tue, Feb 20, 2024 at 06:41:05PM +, Edgecombe, Rick P
> > > wrote:
> > > > Hmm, could the shadow stack
On Tue, Feb 20, 2024, at 6:30 PM, Edgecombe, Rick P wrote:
> On Tue, 2024-02-20 at 13:57 -0500, Rich Felker wrote:
>> On Tue, Feb 20, 2024 at 06:41:05PM +, Edgecombe, Rick P wrote:
>> > Hmm, could the shadow stack underflow onto the real stack then? Not
>> > sure how bad that is. INCSSP (increm
On Tue, Feb 20, 2024 at 11:30:22PM +, Edgecombe, Rick P wrote:
> On Tue, 2024-02-20 at 13:57 -0500, Rich Felker wrote:
> > On Tue, Feb 20, 2024 at 06:41:05PM +, Edgecombe, Rick P wrote:
> > > Hmm, could the shadow stack underflow onto the real stack then? Not
> > > sure how bad that is. INC
On Tue, 2024-02-20 at 20:14 +, Mark Brown wrote:
> > Hmm, could the shadow stack underflow onto the real stack then? Not
> > sure how bad that is. INCSSP (incrementing the SSP register on x86)
> > loops are not rare so it seems like something that could happen.
>
> Yes, they'd trash any pages
On Tue, 2024-02-20 at 13:57 -0500, Rich Felker wrote:
> On Tue, Feb 20, 2024 at 06:41:05PM +, Edgecombe, Rick P wrote:
> > Hmm, could the shadow stack underflow onto the real stack then? Not
> > sure how bad that is. INCSSP (incrementing the SSP register on x86)
> > loops are not rare so it see
On Tue, Feb 20, 2024 at 06:41:05PM +, Edgecombe, Rick P wrote:
> On Tue, 2024-02-20 at 11:36 -0500, Stefan O'Rear wrote:
> > 2. Shadow stack faults on non-shadow stack pages, if flexible shadow
> > stack
> > handling is in effect, cause the affected page to become a shadow
> > stack
> >
On Tue, Feb 20, 2024 at 06:41:05PM +, Edgecombe, Rick P wrote:
> Hi,
>
> I worked on the x86 kernel shadow stack support. I think it is an
> interesting suggestion. Some questions below, and I will think more on
> it.
>
> On Tue, 2024-02-20 at 11:36 -0500, Stefan O'Rear wrote:
> > While discu
Hi,
I worked on the x86 kernel shadow stack support. I think it is an
interesting suggestion. Some questions below, and I will think more on
it.
On Tue, 2024-02-20 at 11:36 -0500, Stefan O'Rear wrote:
> While discussing the ABI implications of shadow stacks in the context
> of
> Zicfiss and musl
On Sat, Feb 3, 2024, at 7:25 AM, Mark Brown wrote:
> The arm64 Guarded Control Stack (GCS) feature provides support for
> hardware protected stacks of return addresses, intended to provide
> hardening against return oriented programming (ROP) attacks and to make
> it easier to gather call stacks fo
Hello,
Mark Brown writes:
> Changes in v8:
> - Invalidate signal cap token on stack when consuming.
> - Typo and other trivial fixes.
> - Don't try to use process_vm_write() on GCS, it intentionally does not
> work.
> - Fix leak of thread GCSs.
> - Rebase onto latest clone3() series.
> - Lin
The arm64 Guarded Control Stack (GCS) feature provides support for
hardware protected stacks of return addresses, intended to provide
hardening against return oriented programming (ROP) attacks and to make
it easier to gather call stacks for applications such as profiling.
When GCS is active a sec
36 matches
Mail list logo
