Thread (222 messages) 222 messages, 21 authors, 2022-11-03

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

From: "Andy Lutomirski" <luto@kernel.org>
Date: 2022-10-04 17:46:56
Also in: linux-arch, linux-doc, linux-mm, lkml


On Tue, Oct 4, 2022, at 9:12 AM, Edgecombe, Rick P wrote:
On Mon, 2022-10-03 at 16:21 -0700, Andy Lutomirski wrote:
quoted
On 9/29/22 15:29, Rick Edgecombe wrote:
quoted
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
I'm not following how it breaks down into 3 parts, so hopefully I'm not
missing something. We could do a software busy bit for the token at the
end of alt shstk though. It seems like a good idea.
I didn't mean there were three parts.  I just wild @&! guessed the amount of code written versus needed :)
The busy-like bit in the RSTORSSP-type token is not called out as a
busy bit, but instead defined as reserved (must be 0) in some states.
(Note, it is different than the supervisor shadow stack format). Yea,
we could just probably use it like RSTORSSP does for this operation.

Or just invent another new token format and stay away from bits marked
reserved. Then it wouldn't have to be atomic either, since userspace
couldn't use it.
But userspace *can* use it by delivering a signal.  I consider the scenario where two user threads set up the same altshstk and take signals concurrently to be about as dangerous and about as likely (under accidental or malicious conditions) as two user threads doing RSTORSSP at the same time.  Someone at Intel thought the latter was a big deal, so maybe we should match its behavior.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help