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: <20190116122026.GF15409@zn.tnic>
Date:   Wed, 16 Jan 2019 13:20:26 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     kan.liang@...ux.intel.com
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
        peterz@...radead.org, mingo@...hat.com, ak@...ux.intel.com,
        eranian@...gle.com
Subject: Re: [PATCH V5 1/4] x86/cpufeature: Add facility to check for min
 microcode revisions

On Mon, Jan 07, 2019 at 02:34:22PM -0800, kan.liang@...ux.intel.com wrote:
> From: Kan Liang <kan.liang@...ux.intel.com>
> 
> For bug workarounds or checks it is useful to check for specific
> microcode revisions.
> 
> Add a new generic function to match the CPU with stepping.
> Add the other function to check the min microcode revisions for
> the matched CPU.
> A new table format is introduced to facilitate the quirk to
> fill the related information.
> 
> This does not change the existing x86_cpu_id because it's an ABI
> shared with modules, and also has quite different requirements,
> as in no wildcards, but everything has to be matched exactly.
> 
> Suggested-by: Thomas Gleixner <tglx@...utronix.de>
> Based-on-code-from: Andi Kleen <ak@...ux.intel.com>

The proper tag is: Originally-by

> Signed-off-by: Kan Liang <kan.liang@...ux.intel.com>
> ---
> 
> Changes since V4:
> - Rename to x86_cpu_check and INTEL_CHECK_UCODE
> - Split x86_min_microcode() into two functions. One is a generic
>   CPU match function with stepping. The other is to check the min
>   microcode revisions.
> 
> The previous discussion can be found here.
> https://lkml.org/lkml/2018/10/10/740
> 
>  arch/x86/include/asm/cpu_device_id.h | 28 ++++++++++++++++++++++++++++
>  arch/x86/kernel/cpu/match.c          | 31 +++++++++++++++++++++++++++++++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
> index baeba05..43f19af 100644
> --- a/arch/x86/include/asm/cpu_device_id.h
> +++ b/arch/x86/include/asm/cpu_device_id.h
> @@ -11,4 +11,32 @@
>  
>  extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match);
>  
> +/*
> + * Match specific microcode revisions.
> + *
> + * vendor/family/model/stepping must be all set.
> + *
> + * only checks against the boot cpu.  When mixed-stepping configs are

s/cpu/CPU/g

> + * valid for a CPU model, add a quirk for every valid stepping and
> + * do the fine-tuning in the quirk handler.
> + */
> +
> +struct x86_cpu_check {

That's not a "check". If anything, it is a descriptor of sorts. I.e.,
x86_cpu_desc or so.

> +	u8	vendor;
> +	u8	family;
> +	u8	model;
> +	u8	stepping;
> +	u32	microcode_rev;

Name those the same way as the corresponding members in struct
cpuinfo_x86 are named, so that there's no confusion about what is what.

> +};
> +
> +#define INTEL_CHECK_UCODE(mod, step, rev) {			\

INTEL_CPU_DESC

or so.

> +	.vendor = X86_VENDOR_INTEL,				\
> +	.family = 6,						\
> +	.model = mod,						\
> +	.stepping = step,					\
> +	.microcode_rev = rev,					\
> +}
> +
> +extern bool x86_cpu_has_min_microcode_rev(const struct x86_cpu_check *table);
> +
>  #endif
> diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
> index 3fed388..408bed37 100644
> --- a/arch/x86/kernel/cpu/match.c
> +++ b/arch/x86/kernel/cpu/match.c
> @@ -48,3 +48,34 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
>  	return NULL;
>  }
>  EXPORT_SYMBOL(x86_match_cpu);
> +
> +static const struct x86_cpu_check *
> +x86_match_cpu_with_stepping(const struct x86_cpu_check *match)
> +{
> +	struct cpuinfo_x86 *c = &boot_cpu_data;
> +	const struct x86_cpu_check *m;
> +
> +	for (m = match; m->family | m->model; m++) {
> +		if (c->x86_vendor != m->vendor)
> +			continue;
> +		if (c->x86 != m->family)
> +			continue;
> +		if (c->x86_model != m->model)
> +			continue;
> +		if (c->x86_stepping != m->stepping)
> +			continue;
> +		return m;
> +	}
> +	return NULL;
> +}
> +
> +bool x86_cpu_has_min_microcode_rev(const struct x86_cpu_check *table)
> +{
> +	const struct x86_cpu_check *res = x86_match_cpu_with_stepping(table);
> +
> +	if (!res || res->microcode_rev > boot_cpu_data.microcode)
> +		return false;
> +
> +	return true;
> +}
> +EXPORT_SYMBOL(x86_cpu_has_min_microcode_rev);

EXPORT_SYMBOL_GPL.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ