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

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

[Andrew Cooper]

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@citrix.com>
---
CC: Anthony PERARD <anthony.perard@vates.tech>
CC: Michal Orzel <michal.orzel@amd.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Julien Grall <julien@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Stefano Stabellini <sstabellini@kernel.org>

CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
change.
---
 xen/common/Kconfig | 51 +++++++++-------------------------------------
 1 file changed, 10 insertions(+), 41 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 4bec78c6f267..03ef6d87abc0 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -162,29 +162,21 @@ config STATIC_MEMORY
 menu "Speculative hardening"
 
 config INDIRECT_THUNK
-	bool "Speculative Branch Target Injection Protection"
+	bool "Out-of-line Indirect Call/Jumps"
 	depends on CC_HAS_INDIRECT_THUNK
 	default y
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
+	  Compile Xen with out-of-line indirect call and jumps.
 
-	  One source of data leakage is via branch target injection.
-
-	  When enabled, indirect branches are implemented using a new construct
-	  called "retpoline" that prevents speculation.
+	  This allows Xen to mitigate a variety of speculative vulnerabilities
+	  by choosing a hardware-dependent instruction sequence to implement
+	  (e.g. function pointers) safely.  "Retpoline" is one such sequence.
 
 config SPECULATIVE_HARDEN_ARRAY
 	bool "Speculative Array Hardening"
 	default y
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of data leakage is via speculative out-of-bounds array
-	  accesses.
+	  Compile Xen with extra hardening for some array accesses.
 
 	  When enabled, specific array accesses which have been deemed liable
 	  to be speculatively abused will be hardened to avoid out-of-bounds
@@ -193,19 +185,12 @@ config SPECULATIVE_HARDEN_ARRAY
 	  This is a best-effort mitigation.  There are no guarantees that all
 	  areas of code open to abuse have been hardened.
 
-	  If unsure, say Y.
-
 config SPECULATIVE_HARDEN_BRANCH
 	bool "Speculative Branch Hardening"
 	default y
 	depends on X86
-        help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of misbehaviour is by executing the wrong basic block
-	  following a conditional jump.
+	help
+	  Compile Xen with extra hardening for some conditional branches.
 
 	  When enabled, specific conditions which have been deemed liable to
 	  be speculatively abused will be hardened to avoid entering the wrong
@@ -216,43 +201,27 @@ config SPECULATIVE_HARDEN_BRANCH
 	  optimisations in the compiler haven't subverted the attempts to
 	  harden.
 
-	  If unsure, say Y.
-
 config SPECULATIVE_HARDEN_GUEST_ACCESS
 	bool "Speculative PV Guest Memory Access Hardening"
 	default y
 	depends on PV
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of data leakage is via speculative accesses to hypervisor
-	  memory through guest controlled values used to access guest memory.
+	  Compile Xen with extra hardening for PV guest memory access.
 
 	  When enabled, code paths accessing PV guest memory will have guest
 	  controlled addresses massaged such that memory accesses through them
 	  won't touch hypervisor address space.
 
-	  If unsure, say Y.
-
 config SPECULATIVE_HARDEN_LOCK
 	bool "Speculative lock context hardening"
 	default y
 	depends on X86
 	help
-	  Contemporary processors may use speculative execution as a
-	  performance optimisation, but this can potentially be abused by an
-	  attacker to leak data via speculative sidechannels.
-
-	  One source of data leakage is via speculative accesses to lock
-	  critical regions.
+	  Compile Xen with extra hardening for locked regions.
 
 	  This option is disabled by default at run time, and needs to be
 	  enabled on the command line.
 
-	  If unsure, say Y.
-
 endmenu
 
 menu "Other hardening"

base-commit: aea52ce607fe716acc56ad89f07e1513c89018eb
-- 
2.39.5

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

[Roger Pau Monné]

On Thu, May 08, 2025 at 05:03:36PM +0100, 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@citrix.com>

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

You are the expert on those things :).

> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> 
> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
> change.

I don't have a strong opinion either way TBH.  Would you maybe like to
rename the menu visible text to "Speculative Conditional Branch Hardening"?

> ---
>  xen/common/Kconfig | 51 +++++++++-------------------------------------
>  1 file changed, 10 insertions(+), 41 deletions(-)
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 4bec78c6f267..03ef6d87abc0 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -162,29 +162,21 @@ config STATIC_MEMORY
>  menu "Speculative hardening"
>  
>  config INDIRECT_THUNK
> -	bool "Speculative Branch Target Injection Protection"
> +	bool "Out-of-line Indirect Call/Jumps"
>  	depends on CC_HAS_INDIRECT_THUNK
>  	default y
>  	help
> -	  Contemporary processors may use speculative execution as a
> -	  performance optimisation, but this can potentially be abused by an
> -	  attacker to leak data via speculative sidechannels.

It would be nice if this boilerplate text could be made the "help" of
the top level menu entry, but that's not possible with Kconfig.

Thanks, Roger.

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

[Andrew Cooper]

On 09/05/2025 9:14 am, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 05:03:36PM +0100, 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@citrix.com>
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
>
> You are the expert on those things :).
>
>> ---
>> CC: Anthony PERARD <anthony.perard@vates.tech>
>> CC: Michal Orzel <michal.orzel@amd.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Julien Grall <julien@xen.org>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>
>> CONFIG_SPECULATIVE_HARDEN_BRANCH really ought to be named
>> CONFIG_SPECULATIVE_HARDEN_CONDITIONAL, but this would be a (minor) functional
>> change.
> I don't have a strong opinion either way TBH.  Would you maybe like to
> rename the menu visible text to "Speculative Conditional Branch Hardening"?

Hmm yeah, that's better than nothing.

>
>> ---
>>  xen/common/Kconfig | 51 +++++++++-------------------------------------
>>  1 file changed, 10 insertions(+), 41 deletions(-)
>>
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index 4bec78c6f267..03ef6d87abc0 100644
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -162,29 +162,21 @@ config STATIC_MEMORY
>>  menu "Speculative hardening"
>>  
>>  config INDIRECT_THUNK
>> -	bool "Speculative Branch Target Injection Protection"
>> +	bool "Out-of-line Indirect Call/Jumps"
>>  	depends on CC_HAS_INDIRECT_THUNK
>>  	default y
>>  	help
>> -	  Contemporary processors may use speculative execution as a
>> -	  performance optimisation, but this can potentially be abused by an
>> -	  attacker to leak data via speculative sidechannels.
> It would be nice if this boilerplate text could be made the "help" of
> the top level menu entry, but that's not possible with Kconfig.

When speculation was entirely new, something needed to introduce it (not
that I think this was great to start with), but nowadays any all
developers/sysadmins/distro-packagers will be aware of it.

Or, if they're not aware, a paragraph like this isn't going to help them.

~Andrew

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

[Jan Beulich]

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@citrix.com>
> ---
> CC: Anthony PERARD <anthony.perard@vates.tech>
> CC: Michal Orzel <michal.orzel@amd.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Julien Grall <julien@xen.org>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> 
> 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.

Jan

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

[Andrew Cooper]

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@citrix.com>
>> ---
>> CC: Anthony PERARD <anthony.perard@vates.tech>
>> CC: Michal Orzel <michal.orzel@amd.com>
>> CC: Jan Beulich <jbeulich@suse.com>
>> CC: Julien Grall <julien@xen.org>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>
>> 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.

~Andrew

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

[Jan Beulich]

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@citrix.com>
>>> ---
>>> CC: Anthony PERARD <anthony.perard@vates.tech>
>>> CC: Michal Orzel <michal.orzel@amd.com>
>>> CC: Jan Beulich <jbeulich@suse.com>
>>> CC: Julien Grall <julien@xen.org>
>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>
>>> 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

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

[Demi Marie Obenour]

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@citrix.com>
>>> ---
>>> CC: Anthony PERARD <anthony.perard@vates.tech>
>>> CC: Michal Orzel <michal.orzel@amd.com>
>>> CC: Jan Beulich <jbeulich@suse.com>
>>> CC: Julien Grall <julien@xen.org>
>>> CC: Roger Pau Monné <roger.pau@citrix.com>
>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>
>>> 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)