[PATCH] x86: allow easier disabling of BTI mitigations

[PATCH] x86: allow easier disabling of BTI mitigations

[Jan Beulich]

Support both a "disable everything" and a "disable all RSB overwriting"
sub-option.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -246,7 +246,7 @@ enough. Setting this to a high value may
 the NMI watchdog is also enabled.
 
 ### bti (x86)
-> `= List of [ thunk=retpoline|lfence|jmp, ibrs=<bool>, ibpb=<bool>, rsb_{vmexit,native}=<bool> ]`
+> `= List of [ <bool>, thunk=retpoline|lfence|jmp, ibrs=<bool>, ibpb=<bool>, rsb=<bool>, rsb_{vmexit,native}=<bool> ]`
 
 Branch Target Injection controls.  By default, Xen will pick the most
 appropriate BTI mitigations based on compiled in support, loaded microcode,
@@ -255,6 +255,9 @@ and hardware details.
 **WARNING: Any use of this option may interfere with heuristics.  Use with
 extreme care.**
 
+A (negative) boolean value can be specified to turn off all mitigations.
+(Use of a positive boolean value is invalid.)
+
 If Xen was compiled with INDIRECT_THUNK support, `thunk=` can be used to
 select which of the thunks gets patched into the `__x86_indirect_thunk_%reg`
 locations.  The default thunk is `retpoline` (generally preferred for Intel
@@ -268,6 +271,8 @@ functionality is still set up so IBRS ca
 On hardware supporting IBPB, the `ibpb=` option can be used to prevent Xen
 from issuing Branch Prediction Barriers on vcpu context switches.
 
+The `rsb=` option can be used to uniformly suppress RSB overwriting.
+
 The `rsb_vmexit=` and `rsb_native=` options can be used to fine tune when the
 RSB gets overwritten.  There are individual controls for an entry from HVM
 context, and an entry from a native (PV or Xen) context.
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -50,7 +50,18 @@ static int __init parse_bti(const char *
         if ( !ss )
             ss = strchr(s, '\0');
 
-        if ( !strncmp(s, "thunk=", 6) )
+        val = parse_bool(s, ss);
+        if ( !val )
+        {
+            opt_thunk = THUNK_JMP;
+            opt_ibrs = 0;
+            opt_ibpb = false;
+            opt_rsb_native = false;
+            opt_rsb_vmexit = false;
+        }
+        else if ( val > 0 )
+            rc = -EINVAL;
+        else if ( !strncmp(s, "thunk=", 6) )
         {
             s += 6;
 
@@ -71,6 +82,11 @@ static int __init parse_bti(const char *
             opt_rsb_native = val;
         else if ( (val = parse_boolean("rsb_vmexit", s, ss)) >= 0 )
             opt_rsb_vmexit = val;
+        else if ( (val = parse_boolean("rsb", s, ss)) >= 0 )
+        {
+            opt_rsb_native = val;
+            opt_rsb_vmexit = val;
+        }
         else
             rc = -EINVAL;
 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH] x86: allow easier disabling of BTI mitigations

[Andrew Cooper]

On 01/02/18 08:52, Jan Beulich wrote:
> @@ -268,6 +271,8 @@ functionality is still set up so IBRS ca
>  On hardware supporting IBPB, the `ibpb=` option can be used to prevent Xen
>  from issuing Branch Prediction Barriers on vcpu context switches.
>  
> +The `rsb=` option can be used to uniformly suppress RSB overwriting.
> +
>  The `rsb_vmexit=` and `rsb_native=` options can be used to fine tune when the
>  RSB gets overwritten.  There are individual controls for an entry from HVM
>  context, and an entry from a native (PV or Xen) context.

It would probably be  better to merge your change into this paragraph. 
How about:

The `rsb=`, `rsb_vmexit=` and `rsb_native=` options can be used to
control when the RSB gets overwritten.  The former control all RSB
overwriting, while the latter two can be used to fine tune overwriting
on from HVM context, and an entry from a native (PV or Xen) context.

?

Otherwise, Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

I really need to find some time to implement bti=hvm-only

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel