On 15/08/2025 10:03 am, Jan Beulich wrote: > On 14.08.2025 22:09, Andrew Cooper wrote: >> On 14/08/2025 4:11 pm, Jan Beulich wrote: >>> On 08.08.2025 22:23, Andrew Cooper wrote: >>>> Under FRED, SETSSBSY is unavailable, and we want to be setting up FRED >>>> prior >>>> to setting up shadow stacks. As we still need Supervisor Tokens in IDT >>>> mode, >>>> we need mode-specific logic to establish SSP. >>>> >>>> In FRED mode, write a Restore Token, RSTORSSP it, and discard the resulting >>>> Previous-SSP token. >>>> >>>> No change outside of FRED mode. >>>> >>>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >>> Why is it that in patch 17 you could use identical code, but here you can't? >> This caught me out at first too. >> >> For S3, we're going from "no shadow stack" to "back to where we were on >> an active shadow stack". All we need to do is get saved_ssp back into >> the SSP register. >> >> Here, we're going from "no shadow stack" to "on a good, empty, shadow >> stack". For FRED we only need to load a value into SSP, but in IDT mode >> we must also arrange to create a busy Supervisor Token on the base of >> the stack. >> >> We could in principle conditionally write a busy supervisor token, then >> unconditionally RSTORSSP, but that's even more complicated to follow IMO. > Why would the write need to be conditional?
Because the tokens are different. One has the value &addr, and one has &addr + 9. The Supervisor Shadow Stack Token for IDT needs to survive for the lifetime of Xen, while the Restore Token for FRED is temporary and discarded by the logic added in this patch. > Can't we write what effectively > is already there? Or is it more a safety measure to avoid the write when > it's supposed to be unnecessary, to avoid papering over bugs? I genuinely don't understand what you're trying to suggest here. ~Andrew
