All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Borislav Petkov <bp@alien8.de>
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 16:37:03 -0300	[thread overview]
Message-ID: <20141005193703.GB24081@khazad-dum.debian.net> (raw)
In-Reply-To: <20141005173453.GC9377@pd.tnic>

On Sun, 05 Oct 2014, Borislav Petkov wrote:
> On Mon, Sep 08, 2014 at 02:37:47PM -0300, Henrique de Moraes Holschuh wrote:
> > -	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");

will do.

> > +	/*
> > +	 * 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. :-)

Not realy, because it got you confused! :-)

Zero does not denote a failure to update microcode.  What zero means, *when
you did the pre-load and issued a cpuid(1)*, is that the processor microcode
has not been updated since power-on/reset.

What flags a *sucessful* microcode update is a change on IA32_BIOS_SIGN_ID
(which must be read with the zero preload and cpuid(1) protocol).

If IA32_BIOS_SIGN_ID didn't change, the microcode update was rejected...
obviously, this only holds when you never attempt to update the microcode to
the same version the processor already had running.

And that's why we cannot detect whether a same-version update worked or not.

The reason Intel will never issue a microcode with revision zero is because
it cannot be safely applied by UEFI or BIOS at system power up: it would
look like a same-version update (IA32_BIOS_SIGN_ID would return zero before
the update, and would return zero after the update, whether it was applied
sucessfully or not).

And since Intel will never issue such microcode, we don't want to deal with
anything that claims to be a microcode update to revision zero.


IOW, this is a failure:

IA32_BIOS_SIGN_ID before the update is the same as IA32_BIOS_SIGN_ID after
the update attempt.

this is a sucessful update:

IA32_BIOS_SIGN_ID before the update is different from IA32_BIOS_SIGN_ID
after the update attempt.

In any case, you always need to do the zero-preload and cpuid(1) to read
IA32_BIOS_SIGN_ID.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

  reply	other threads:[~2014-10-05 19:37 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
2014-10-05 19:37     ` Henrique de Moraes Holschuh [this message]
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=20141005193703.GB24081@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=bp@alien8.de \
    --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.