[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6.5 14/26] x86: Introduce alternative indirect thunks
>>> On 04.01.18 at 01:15, <andrew.cooper3@xxxxxxxxxx> wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -245,6 +245,20 @@ and not running softirqs. Reduce this if softirqs are > not being run frequently > enough. Setting this to a high value may cause boot failure, particularly if > the NMI watchdog is also enabled. > > +### bti (x86) > +> `= List of [ thunk=retpoline|lfence|plain ]` > + > +Branch Target Injection controls. By default, Xen will pick the most > +appropriate BTI mitigations based on compiled in support, loaded microcode, > +and hardware details. > + > +**WARNING: Any use of this option inhibits all heristcs. Use with extreme > care.** "heuristics" > @@ -27,7 +28,42 @@ enum ind_thunk { > THUNK_NONE, /* Missing compiler support for thunks. */ > > THUNK_RETPOLINE, > -}; > + THUNK_LFENCE, > + THUNK_JMP, > +} opt_thunk __initdata = THUNK_DEFAULT; This wants to be static. > @@ -48,6 +86,31 @@ void __init init_speculation_mitigations(void) > enum ind_thunk thunk = THUNK_DEFAULT; > > /* > + * Has the user specified any custom BTI mitigations? If so, follow > their > + * instructions exactly and disable all heuristics. > + */ > + if ( opt_thunk != THUNK_DEFAULT ) > + { > + thunk = opt_thunk; > + } The braces aren't really needed here. > + else > + { > + /* > + * Evaluate the safest Branch Target Injection mitigations to use. > + * First, begin with compiler-aided mitigations. > + */ > + if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) ) > + { > + /* > + * AMD's recommended mitigation is to set lfence as being > dispatch > + * serialising, and to use IND_THUNK_LFENCE. > + */ > + if ( cpu_has_lfence_dispatch ) > + thunk = THUNK_LFENCE; > + } > + } As asked elsewhere, is the CONFIG_INDIRECT_THUNK dependency here really meaningful for the overall effect? Surely if we can't use thunks in the first place it doesn't matter which variant of them we don't use? Anyway, with at least the first two remarks taken care of Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |