Re: [PATCH v2 00/39] Shadowstacks for userspace

On Mon, 2022-10-03 at 10:04 -0700, Kees Cook wrote:

quoted

Shadow stack signal format
--------------------------
So to handle alt shadow stacks we need to push some data onto a
stack. To 
prevent SROP we need to push something to the shadow stack that the
kernel can 
[...]
shadow stack return address or a shadow stack tokens. To make sure
it can’t be 
used, data is pushed with the high bit (bit 63) set. This bit is a
linear 
address bit in both the token format and a normal return address,
so it should 
not conflict with anything. It puts any return address in the
kernel half of 
the address space, so would never be created naturally by a
userspace program. 
It will not be a valid restore token either, as the kernel address
will never 
be pointing to the previous frame in the shadow stack.

When a signal hits, the format pushed to the stack that is handling
the signal 
is four 8 byte values (since we are 64 bit only):

quoted

1...old SSP|1...alt stack size|1...alt stack base|0|

Do these end up being non-canonical addresses? (To avoid confusion
with
"real" kernel addresses?)

Usually, but not necessarily with LAM. LAM cannot mask bit 63 though.
So hypothetically they could become "real" kernel addresses some day.
To keep them in the user half but still make sure they are not usable,
you would either have to encode the bits over a lot of entries which
would use extra space, or shrink the available address space, which
could cause compatibility problems.

Do you think it's an issue?