Re: [OPTIONAL/RFC v2 39/39] x86: Add alt shadow stack support

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

 



On 9/29/22 15:29, Rick Edgecombe wrote:
To handle stack overflows, applications can register a separate signal alt
stack to use for the stack to handle signals. To handle shadow stack
overflows the kernel can similarly provide the ability to have an alt
shadow stack.


The overall SHSTK mechanism has a concept of a shadow stack that is valid and not in use and a shadow stack that is in use. This is used, for example, by RSTORSSP. I would like to imagine that this serves a real purpose (presumably preventing two different threads from using the same shadow stack and thus corrupting each others' state).

So maybe altshstk should use exactly the same mechanism. Either signal delivery should do the atomic very-and-mark-busy routine or registering the stack as an altstack should do it.

I think your patch has this maybe 1/3 implemented, but I don't see any atomics, and you seem to have removed (?) the code that actually modifies the token on the stack.

+static bool on_alt_shstk(unsigned long ssp)
+{
+	unsigned long alt_ss_start = current->thread.sas_shstk_sp;
+	unsigned long alt_ss_end = alt_ss_start + current->thread.sas_shstk_size;
+
+	return ssp >= alt_ss_start && ssp < alt_ss_end;
+}

We're forcing AUTODISARM behavior (right?), so I don't think this is needed at all. User code is never "on the alt stack". It's either "on the alt stack but the alt stack is disarmed, so it's not on the alt stack" or it's just straight up not on the alt stack.



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux