From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] x86, microcode: Add option to allow downgrading of microcode
Date: Fri, 13 Dec 2013 19:00:15 -0200 [thread overview]
Message-ID: <20131213210015.GA26925@khazad-dum.debian.net> (raw)
In-Reply-To: <1386363843-32530-2-git-send-email-andi@firstfloor.org>
On Fri, 06 Dec 2013, Andi Kleen wrote:
> For testing purposes it can be useful to downgrade microcode.
> Normally the driver only allows upgrading.
...
> int
> update_match_revision(struct microcode_header_intel *mc_header, int rev)
> {
> + if (allow_downgrade)
> + return 1;
> return ((int)mc_header->rev <= rev) ? 0 : 1;
> }
Two points maybe worth some thinking about:
1. We might want to forbid downgrading to version 0 of a microcode. Version
zero is supposed to mean "running factory-provided microcode" and there is
absolutely no way an attempt to downgrade to version 0 is not an attack of
some sort.
And we know for a fact that is a very unwise idea to let strange microcode
get past the kernel driver and into the microcode update microcode itself.
2. This change has unintended side-effects that ought to be at least
documented:
In "allow downgrade" mode, should you send a microcode pack with several
microcodes to the kernel, and more than one of them might apply to the
running processor (when the pf_flags of two or more of the microcodes are
not disjoint), either the first or the last (I didn't check) will be the
one chosen.
I've seen in the wild microcodes where both rev X and Y (when Y > X) could
be applied to a specific processor, but rev X was intended to more
processors (more bits set in pf_mask) than rev. Y. I don't think they were
in the same Intel microcode update datafile, but it can happen. In normal
upgrade-only mode this works correctly, while in your proposed downgrade
mode, it won't.
The upgrade/downgrade rules for negative release microcodes are different,
it might be a good idea to ask someone at Intel to clarify these rules
(including whether release X or Y should be installed when X < Y < 0). So
far, I've only heard of negative release numbers in the microcodes shipped
inside the BIOS/EFI images of some server boards and embedded products, and
I was told they're reserved for "internal Intel development microcode" or
something like that.
--
"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
next prev parent reply other threads:[~2013-12-13 21:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 21:04 [PATCH 1/2] x86, microcode: Do Intel microcode revision check signed Andi Kleen
2013-12-06 21:04 ` [PATCH 2/2] x86, microcode: Add option to allow downgrading of microcode Andi Kleen
2013-12-13 21:00 ` Henrique de Moraes Holschuh [this message]
2013-12-15 0:40 ` Henrique de Moraes Holschuh
2013-12-10 15:30 ` [PATCH 1/2] x86, microcode: Do Intel microcode revision check signed Konrad Rzeszutek Wilk
2013-12-10 15:55 ` Andi Kleen
2013-12-10 17:09 ` H. Peter Anvin
2013-12-12 23:57 [PATCH 1/2] x86, microcode: Do Intel microcode revision check signed v2 Andi Kleen
2013-12-12 23:57 ` [PATCH 2/2] x86, microcode: Add option to allow downgrading of microcode Andi Kleen
2014-01-24 21:18 [PATCH 1/2] x86, microcode: Do Intel microcode revision check signed v2 Andi Kleen
2014-01-24 21:18 ` [PATCH 2/2] x86, microcode: Add option to allow downgrading of microcode Andi Kleen
2014-01-25 16:35 ` Henrique de Moraes Holschuh
2014-01-25 18:14 ` Andi Kleen
2014-01-28 10:26 ` Henrique de Moraes Holschuh
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=20131213210015.GA26925@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--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
all inboxes | Powered by JetHome®