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.
