linux-kernel - Re: [PATCH v8 04/12] x86/spectre: Add boot time option to select Spectre v2 mitigation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180123224014.dsbzps4hydt6h7ed@pd.tnic>
Date:   Tue, 23 Jan 2018 23:40:14 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     David Woodhouse <dwmw@...zon.co.uk>
Cc:     Andi Kleen <ak@...ux.intel.com>, Paul Turner <pjt@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>, tglx@...utronix.de,
        Kees Cook <keescook@...gle.com>,
        Rik van Riel <riel@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...capital.net>,
        Jiri Kosina <jikos@...nel.org>, gnomes@...rguk.ukuu.org.uk,
        x86@...nel.org, thomas.lendacky@....com,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH v8 04/12] x86/spectre: Add boot time option to select
 Spectre v2 mitigation

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.