On Tue, 2018-01-23 at 23:40 +0100, Borislav Petkov wrote:
> 
> 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:

Right. There *was* a warning during build but we removed that. At the
time, the plan (at least in my head) was to use IBRS instead, if the
retpoline compiler wasn't available. For now we're just going to remain
vulnerable. I'm now wondering if we should reinstate that warning.

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

Andi actually implemented this, but it ended up being watered down
somewhat.