linux-kernel - Re: [PATCH v3 6/6] x86/cpufeature: Blacklist SPEC

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]

Date:   Wed, 24 Jan 2018 18:29:32 +0100
From:   Greg KH <gregkh@...ux-foundation.org>
To:     David Woodhouse <dwmw@...zon.co.uk>
Cc:     arjan@...ux.intel.com, tglx@...utronix.de, karahmed@...zon.de,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        tim.c.chen@...ux.intel.com, bp@...en8.de, peterz@...radead.org,
        pbonzini@...hat.com, ak@...ux.intel.com,
        torvalds@...ux-foundation.org, dave.hansen@...el.com,
        gnomes@...rguk.ukuu.org.uk
Subject: Re: [PATCH v3 6/6] x86/cpufeature: Blacklist SPEC_CTRL on early
 Spectre v2 microcodes

On Wed, Jan 24, 2018 at 04:57:05PM +0000, David Woodhouse wrote:
> We don't refuse to load the affected microcodes; just refuse to use SPEC_CTRL
> if they're detected.
> 
> AMD has a feature bit for "PRED_CMD only", which Intel didn't do. When disabling
> SPEC_CTRL we can actually turn on that AMD bit to allow IBPB to still be used.
> 
> We handle the other AMD bits here too, because hypervisors *may* have been
> exposing those bits even on Intel chips, for fine-grained control of what's
> available.
> 
> Signed-off-by: David Woodhouse <dwmw@...zon.co.uk>
> ---
>  arch/x86/kernel/cpu/intel.c | 76 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index b720dac..f5c7f61 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -102,6 +102,64 @@ static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *c)
>  		ELF_HWCAP2 |= HWCAP2_RING3MWAIT;
>  }
>  
> +/*
> + * Early microcode releases for the Spectre v2 mitigation were broken.
> + * Information taken from;
> + * • https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf
> + * • https://kb.vmware.com/s/article/52345
> + * • Microcode revisions observed in the wild
> + * • releasenote from 20180108 microcode release
> + */
> +struct sku_microcode {
> +	u8 model;
> +	u8 stepping;
> +	u32 microcode;
> +};
> +static const struct sku_microcode spectre_bad_microcodes[] = {
> +	{ INTEL_FAM6_KABYLAKE_DESKTOP, 0x0B, 0x80 },
> +	/* Corrected typo in Intel doc */
> +	{ INTEL_FAM6_KABYLAKE_DESKTOP, 0x0A, 0x80 },
> +	{ INTEL_FAM6_KABYLAKE_MOBILE, 0x0A, 0x80 },
> +	{ INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x80 },
> +	{ INTEL_FAM6_KABYLAKE_DESKTOP, 0x09, 0x80 },
> +	{ INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003C },
> +	{ INTEL_FAM6_SKYLAKE_MOBILE, 0x03, 0x000000C2 },
> +	{ INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0x000000C2 },
> +	{ INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 },
> +	{ INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x0000001B },
> +	{ INTEL_FAM6_HASWELL_ULT, 0x01, 0x21 },
> +	{ INTEL_FAM6_HASWELL_GT3E, 0x01, 0x18 },
> +	{ INTEL_FAM6_HASWELL_CORE, 0x03, 0x23 },
> +	{ INTEL_FAM6_IVYBRIDGE_X, 0x04, 0x42a },
> +	{ INTEL_FAM6_HASWELL_X, 0x02, 0x3b },
> +	{ INTEL_FAM6_HASWELL_X, 0x04, 0x10 },
> +	{ INTEL_FAM6_HASWELL_CORE, 0x03, 0x23 },
> +	{ INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 },
> +	{ INTEL_FAM6_BROADWELL_XEON_D, 0x03, 0x7000011 },
> +	{ INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x0000001B },
> +	{ INTEL_FAM6_BROADWELL_X, 0x01, 0x0b000025 },
> +	/* Dropped repeat of KBL Desktop 906E9, 0x80 */
> +	{ INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e },
> +	/* Dropped repeat of SKX 50654, 0x200003c */

Nit, but why comment that you dropped a repeat?  No one cares, do they?
You already said above where this info came from.

Anyway, not a big deal at all:

Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>