Re: [PATCH] xen/Kconfig: Improve help test for speculative options

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.05.2025 16:58, Andrew Cooper wrote:
> On 12/05/2025 11:58 am, Jan Beulich wrote:
>> On 08.05.2025 18:03, Andrew Cooper wrote:
>>> The text for CONFIG_INDIRECT_THUNK isn't really correct, and was already 
>>> stale
>>> by the time speculative vulnerabilities hit the headlines in 2018.  It is
>>> specifically an out-of-line-ing mechansim, and repoline is one of several
>>> safety sequences used.
>>>
>>> Some of this boilerplate has been copied into all other options, and isn't
>>> interesting for the target audience given that they're all in a "Speculative
>>> Hardning" menu.
>>>
>>> Reword it to be more concise.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> ---
>>> CC: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>> CC: Michal Orzel <michal.orzel@xxxxxxx>
>>> CC: Jan Beulich <jbeulich@xxxxxxxx>
>>> CC: Julien Grall <julien@xxxxxxx>
>>> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>
>>> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
>>> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) 
>>> functional
>>> change.
>> Hmm, so you're suggesting all the straight-line speculation changes then 
>> ought
>> to be conditional upon a separate, new Kconfig control? So far I've keyed 
>> them
>> all to this one.
> 
> Straight line speculation is complicated in multiple ways, and our
> understanding has evolved over time.
> 
> I'd forgotten that we grouped it with HARDEN_BRANCH, and it is not an
> ideal grouping.  What we have in the way of SLS protections are token at
> best.
> 
> First, in light of Branch Type Confusion on Fam17h processors, where any
> instruction can manifest as a speculative branch, there's nothing that
> can be done.  (This was demonstrated rather more thoroughly with SRSO
> than BTC.)
> 
> There is straight line decode (at least) through any branch the
> predictor doesn't know about.  Only "taken branches" get tracked, but
> also you get a higher rate of SLS immediately after leaving userspace
> for a long time (such that the branch predictor fully lost supervisor
> state).  Again, this is inherent and we cannot control it.
> 
> Intel say that a branch type mismatch (for a direct branch) will halt at
> decode.  Indirect branches are documented to potentially suffer SLS. 
> AMD Fam19h say that any branch type mismatch will halt at decode.  Also,
> with AMD IBRS, indirect branches stall dispatch until they execute.
> 
> 
> Therefore, it's indirect branches which are of most concern.
> 
> Putting an INT3 after any unconditional JMP *ind is easy.  Compilers
> even support doing this.  CALL *ind on the other hand has architectural
> execution beyond it, so if protection is needed, LFENCE is the only option.

Is it valid to summarize your reply as "throw away any SLS patches you have"?

Jan