On Mon, Oct 03, 2022 at 06:33:52PM +0000, Edgecombe, Rick P wrote: > On Mon, 2022-10-03 at 10:04 -0700, Kees Cook wrote: > > > 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): > > > > 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? Nah; I think it's a good solution. I was just trying to make sure I understood it correctly. Thanks! -- Kees Cook
