On Thu, Jan 11, 2018 at 09:46:26PM +0000, David Woodhouse wrote:
> Add a spectre_v2= option to select the mitigation used for the indirect
> branch speculation vulnerability.
>
> Currently, the only option available is retpoline, in its various forms.
> This will be expanded to cover the new IBRS/IBPB microcode features.
>
> The RETPOLINE_AMD feature relies on a serializing LFENCE for speculation
> control. For AMD hardware, only set RETPOLINE_AMD if LFENCE is a
> serializing instruction, which is indicated by the LFENCE_RDTSC feature.
>
> [ tglx: Folded back the LFENCE/AMD fixes and reworked it so IBRS
> integration becomes simple ]
...
> +static inline bool retp_compiler(void)
> +{
> + return __is_defined(RETPOLINE);
> +}
Btw, this came up today: do we have an idea how to detect objects built
with gcc which has retpoline support?
The only way I could think of is boot the respective kernel and stare at
dmesg:
[ 0.064006] Spectre V2 mitigation: LFENCE not serializing. Switching to
generic retpoline
[ 0.068003] Spectre V2 mitigation: Vulnerable: Minimal generic ASM retpoline
and then deduce that it is not a retpoline-enabled compiler:
> +retpoline_auto:
> + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
> + retpoline_amd:
> + if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) {
> + pr_err("LFENCE not serializing. Switching to generic
> retpoline\n");
> + goto retpoline_generic;
> + }
> + mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_AMD :
> + SPECTRE_V2_RETPOLINE_MINIMAL_AMD;
> + setup_force_cpu_cap(X86_FEATURE_RETPOLINE_AMD);
> + setup_force_cpu_cap(X86_FEATURE_RETPOLINE);
> + } else {
> + retpoline_generic:
> + mode = retp_compiler() ? SPECTRE_V2_RETPOLINE_GENERIC :
> + SPECTRE_V2_RETPOLINE_MINIMAL;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
but that might not always be an option.
And it probably should be a more reliable method which we probably could
use to detect !retpolined modules too.
Hmmm.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
