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

[Demi Marie Obenour <demiobenour@xxxxxxxxx>]

On 5/12/25 10:58 AM, 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.

Nit: retpoline, not repoline.

>>> 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.

What about Intel IBRS with an INT3 after the branch?

> 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.

Does adding an LFENCE after every indirect call make sense?
What about RET?

As an aside, this seems like the beginning of the end for object-oriented
programming in kernels and other software that needs to be concerned with
speculative execution security vulnerabilities.  If every indirect jump
completely stalls the pipeline, it’s almost certainly much faster to use
switch/case or (if the language has it) pattern-matching.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)