On Thu, 2022-11-17 at 15:17 +0100, Peter Zijlstra wrote: > On Wed, Nov 16, 2022 at 10:38:19PM +0000, Edgecombe, Rick P wrote: > > On Wed, 2022-11-16 at 11:18 +0100, Peter Zijlstra wrote: > > > > > > > > > > Should you write a 64bit value even if the task receiving a > > > > > signal is > > > > > 32bit ? > > > > > > > > 32 bit support was also dropped. > > > > > > How? Task could start life as 64bit, frob LDT to set up 32bit > > > code > > > segment and jump into it and start doing 32bit syscalls, then > > > what? > > > > > > AFAICT those 32bit syscalls will end up doing SA_IA32_ABI > > > sigframes. > > > > Hmm, good point. This series used to support normal 32 bit apps via > > ia32 emulation which would have handled this. But I removed it > > (blocked > > in the enabling logic) because it didn't seem like it would get > > enough > > use to justify the extra code. That doesn't block this scenario > > here > > though. > > > > Pardon the possibly naive question, but is this 32/64 bit mixing > > something any normal, shstk-desiring, applications would actually > > do? O > > r more that they could do? > > It is not something common, but it is something that things like Wine > do IIRC, and it would be a real shame if Wine could not use shadow > stacks or something, right ;-) Since windows has shadow stack support, I guess. But it looks like it doesn't support shadow stacks on 32 bit either. So for the time being, it seems Wine wouldn't use this either... I think... > > But more to the point; since the kernel cannot forbit this scenario > (aside from taking away the LDT entirely) it is something that needs > handling. I'm having to go educate myself a bit on this kind of code mixing and existing ABI expectations. It seems you could also just make 32 bit syscalls from 64 bit code to trigger the same behavior. On one hand if we think that no one will use this, it would be a shame to have to maintain 32 bit shadow stack support. But on the other hand, we have all these apps being automatically marked as supporting shadow stack. If this was not the case, I would think just declaring this unsupported would be the best. For bringing back 32 bit support, the tricky part might be a 32 bit implementation of the new shadow stack sigframe design that supports alt shadow stacks. Setting the high bit to guarantee the frame will not point to user space won't work for 32 bit. But if we are mostly worried about making sure it is still functional we could maybe just have a slightly less protective format for the shadow stack sigframe for 32 bit. It would not have the same SROP protections. Have to think if this is a security hole for 64 bit though. Anyway, I'm still digging on this one, and just wanted to let you know where I was at.
