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.
--
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.