On Sat, Mar 2, 2024 at 6:57 AM Szabolcs Nagy <nsz@xxxxxxxxxx> wrote: > > * Mark Brown <broonie@xxxxxxxxxx> [2024-02-21 17:36:12 +0000]: > > > On Wed, Feb 21, 2024 at 09:58:01AM -0500, dalias@xxxxxxxx wrote: > > > On Wed, Feb 21, 2024 at 01:53:10PM +0000, Mark Brown wrote: > > > > On Tue, Feb 20, 2024 at 08:27:37PM -0500, dalias@xxxxxxxx wrote: > > > > > On Wed, Feb 21, 2024 at 12:35:48AM +0000, 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 turn into #UD generating instructions. So any other > > > > > > threads executing those instructions when shadow stack got disabled > > > > > > would be in for a nasty surprise. > > > > > > > This is the kernel's problem if that's happening. It should be > > > > > trapping these and returning immediately like a NOP if shadow stack > > > > > has been disabled, not generating SIGILL. > > > > > > I'm not sure that's going to work out well, all it takes is some code > > > > that's looking at the shadow stack and expecting something to happen as > > > > a result of the instructions it's executing and we run into trouble. A > > > > > 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. > > > > 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 > > the aarch64 behaviour is already nop > for gcs instructions when gcs is disabled. > the isa was designed so async disable is > possible. > > only x86 linux would have to emulate this. On Linux/x86, normal instructions are used to update SSP after checking SHSTK is enabled. If SHSTK is disabled in between, program behavior may be undefined. -- H.J.
