linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: linux-kernel@vger.kernel.org, H Peter Anvin <hpa@zytor.com>
Subject: Re: [PATCH 1/8] x86, microcode, intel: forbid some incorrect metadata
Date: Sun, 5 Oct 2014 19:34:54 +0200	[thread overview]
Message-ID: <20141005173453.GC9377@pd.tnic> (raw)
In-Reply-To: <1410197875-19252-2-git-send-email-hmh@hmh.eng.br>

On Mon, Sep 08, 2014 at 02:37:47PM -0300, Henrique de Moraes Holschuh wrote:
> The Intel SDM vol 3A, section 9.11.1, and also table 9-6, requires that
> the Data Size field be a multiple of 4 bytes.  All of the microcode
> update header structures are dword-based, so the Total Size field must
> also be a multiple of the dword size.
> 
> Ensure that data_size is a multiple of the dword size (4 bytes).  The
> driver code assumes this to be true for both data_size and total_size,
> and will not work correctly otherwise.
> 
> Futhermore, require that total_size be a multiple of 1024, as per the
> Intel SDM, vol 3A, section 9.11.1, page 9-28; table 9-6, page 9-29, and
> others.  Test added by request of Borislav Petkov.
> 
> Also refuse a microcode update with a microcode revision of zero.
> According to the Intel SDM, vol 3A, section 9.11.7, page 9-36, a
> microcode revision of zero is special:
> 
>     "CPUID returns a value in a model specific register in addition to
>     its usual register return values.  The semantics of CPUID cause it
>     to deposit an update ID value in the 64-bit model-specific register
>     at address 08BH (IA32_BIOS_SIGN_ID).  If no update is present in the
>     processor, the value in the MSR remains unmodified.  The BIOS must
>     pre-load a zero into the MSR before executing CPUID.  If a read of
>     the MSR at 8BH still returns zero after executing CPUID, this
>     indicates that no update is present."
> 
> This effectively reserves revision zero to mean "no microcode update
> installed on the processor": the microcode loader cannot differentiate
> sucess from failure when updating microcode to the same revision as the
> one currently installed on the processor, and this would always happen
> to updates to revision zero in the BIOS/UEFI loader.
> 
> There is every reason to be paranoid about any microcode update with a
> revision of zero, as Intel will never release such a microcode update.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> ---
>  arch/x86/kernel/cpu/microcode/intel_lib.c |   25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/intel_lib.c b/arch/x86/kernel/cpu/microcode/intel_lib.c
> index ce69320..25915e3 100644
> --- a/arch/x86/kernel/cpu/microcode/intel_lib.c
> +++ b/arch/x86/kernel/cpu/microcode/intel_lib.c
> @@ -55,9 +55,10 @@ int microcode_sanity_check(void *mc, int print_err)
>  	total_size = get_totalsize(mc_header);
>  	data_size = get_datasize(mc_header);
>  
> -	if (data_size + MC_HEADER_SIZE > total_size) {
> +	if ((data_size % DWSIZE) || (total_size % 1024) ||
> +	    (data_size + MC_HEADER_SIZE > total_size)) {
>  		if (print_err)
> -			pr_err("error! Bad data size in microcode data file\n");
> +			pr_err("error: bad data size or total size in microcode data file\n");

Shorten:

	pr_err("error: bad data/total size in microcode data file\n");

>  		return -EINVAL;
>  	}
>  
> @@ -83,6 +84,26 @@ int microcode_sanity_check(void *mc, int print_err)
>  		ext_sigcount = ext_header->count;
>  	}
>  
> +	/*
> +	 * A version 1 loader cannot differentiate failure from success when
> +	 * attempting a microcode update to the same revision as the one
> +	 * currently installed.  The loader is supposed to never attempt a
> +	 * same-version update (or a microcode downgrade, for that matter).
> +	 *
> +	 * This will always cause issues for microcode updates to revision zero
> +	 * in the UEFI/BIOS microcode loader: the processor reports a revision
> +	 * of zero when it is running without any microcode updates installed,
> +	 * such as after a reset/power up.
> +	 *
> +	 * Intel will never issue a microcode update with a revision of zero
> +	 * for the version 1 loader.  Reject it.
> +	 */

This comment is too long. How about this instead:

	/*
	 * 0 is not a valid microcode revision as it is used to denote the
	 * failure of a microcode update, see MSR 0x8b (IA32_BIOS_SIGN_ID):
	 *
	 * "It is required that this register field be pre-loaded with zero
	 * prior to executing the CPUID, function 1. If the field remains
	 * equal to zero, then there is no microcode update loaded. Another
	 * non-zero value will be the signature."
	 */

This is one of those seldom times where the documentation is actually clear. :-)

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-10-05 17:35 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 17:37 [PATCH 0/8] x86, microcode, intel: fixes and enhancements Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 1/8] x86, microcode, intel: forbid some incorrect metadata Henrique de Moraes Holschuh
2014-10-05 17:34   ` Borislav Petkov [this message]
2014-10-05 19:37     ` Henrique de Moraes Holschuh
2014-10-05 21:13       ` Borislav Petkov
2014-10-05 21:49         ` Henrique de Moraes Holschuh
2014-10-06  5:15           ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 2/8] x86, microcode, intel: don't update each HT core twice Henrique de Moraes Holschuh
2014-10-20 13:32   ` Borislav Petkov
2014-10-20 18:24     ` Henrique de Moraes Holschuh
2014-10-28 17:31       ` Borislav Petkov
2014-10-31 18:43         ` Henrique de Moraes Holschuh
2014-11-01 11:06           ` Borislav Petkov
2014-11-01 19:20             ` Henrique de Moraes Holschuh
2014-11-04 15:53               ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 3/8] x86, microcode, intel: clarify log messages Henrique de Moraes Holschuh
2014-10-20 13:52   ` Borislav Petkov
2014-10-21 14:13     ` Henrique de Moraes Holschuh
2014-10-29  9:54       ` Borislav Petkov
2014-10-31 20:08         ` Henrique de Moraes Holschuh
2014-11-07 17:37           ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 4/8] x86, microcode, intel: add error logging to early update driver Henrique de Moraes Holschuh
2014-10-20 15:08   ` Borislav Petkov
2014-10-21 14:10     ` Henrique de Moraes Holschuh
2014-10-30 17:41       ` Borislav Petkov
2014-10-30 18:15         ` Joe Perches
2014-10-31 20:10         ` Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 5/8] x86, microcode, intel: don't check extsig entry checksum Henrique de Moraes Holschuh
2014-10-30 20:25   ` Borislav Petkov
2014-10-31 17:14     ` Henrique de Moraes Holschuh
2014-11-07 17:49       ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 6/8] x86, microcode, intel: use cpuid explicitly instead of sync_core Henrique de Moraes Holschuh
2014-11-07 17:56   ` Borislav Petkov
2014-11-07 18:40     ` Henrique de Moraes Holschuh
2014-11-07 19:48       ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 7/8] x86, microcode, intel: guard against misaligned microcode data Henrique de Moraes Holschuh
2014-09-18  0:48   ` Henrique de Moraes Holschuh
2014-11-07 19:59   ` Borislav Petkov
2014-11-07 22:54     ` Henrique de Moraes Holschuh
2014-11-07 23:48       ` Borislav Petkov
2014-11-08 21:57         ` Henrique de Moraes Holschuh
2014-11-11 10:47           ` Borislav Petkov
2014-11-11 16:57             ` Henrique de Moraes Holschuh
2014-11-11 17:13               ` Borislav Petkov
2014-11-11 19:54                 ` Henrique de Moraes Holschuh
2014-11-12 12:31                   ` Borislav Petkov
2014-11-13  0:18                     ` Henrique de Moraes Holschuh
2014-11-13 11:53                       ` Borislav Petkov
2014-11-15 23:10                         ` Henrique de Moraes Holschuh
2014-11-24 17:35                           ` Borislav Petkov
2014-11-25 13:29                             ` Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 8/8] x86, microcode, intel: defend apply_microcode_intel with BUG_ON Henrique de Moraes Holschuh
2014-11-07 20:05   ` Borislav Petkov
2014-11-07 22:56     ` Henrique de Moraes Holschuh
2014-11-07 23:48       ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141005173453.GC9377@pd.tnic \
    --to=bp@alien8.de \
    --cc=hmh@hmh.eng.br \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).