Re: [PATCH 19/22] x86/boot: Use RSTORSSP to establish SSP

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.08.2025 00:09, Andrew Cooper wrote:
> 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.cooper3@xxxxxxxxxx>
>>>> 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.

I think I misunderstood your earlier reply, so the questions probably
indeed didn't make a while lot of sense.

Jan