Re: [PATCH v4 33/39] x86: Prevent 32 bit operations for 64 bit shstk tasks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2022-12-04 at 12:51 -0800, Rick Edgecombe wrote:
> On Sat, 2022-12-03 at 14:49 -0800, Andy Lutomirski wrote:
> > On Fri, Dec 2, 2022 at 4:44 PM Rick Edgecombe
> > <rick.p.edgecombe@xxxxxxxxx> wrote:
> > > 
> > > So since 32 bit is not easy to support, and there are likely not
> > > many
> > > users. More cleanly don't support 32 bit signals in a 64 bit
> > > address
> > > space by not allowing 32 bit ABI signal handlers when shadow
> > > stack
> > > is
> > > enabled. Do this by clearing any 32 bit ABI signal handlers when
> > > shadow
> > > stack is enabled, and disallow any further 32 bit ABI signal
> > > handlers.
> > > Also, return an error code for the clone operations when in a 32
> > > bit
> > > syscall.
> > > 
> > 
> > This seems unfortunate.  The result will be a highly
> > incomprehensible
> > crash.  Maybe instead deny enabling shadow stack in the first
> > place?
> > Or at least pr_warn_once if anything gets flushed.
> 
> Thanks for the suggestion! Denying seems much better, I'll change it.

Argh, the solution only work in the normal case where the first task
enables shadow stack. Otherwise the process could:
1. Have two threads without shadow stack
2. Enable shadow stack in thread 1
3. Register 32 bit handler from thread 2
4. Handle 32 bit signal in thread 1

For this amount of special case ugliness it should fix the whole
problem I think.

Trying to fix it up by adding 32 bit signal blocking state into struct
sighand_struct, so it would actually be per-process, spills this into
core code. I think it might not be the best solution. I'm not sure what
is yet.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux