linux-kernel - Re: [PATCH 2/2] x86, microcode: Add option to allow downgrading of microcode

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: <20131213210015.GA26925@khazad-dum.debian.net>
Date:	Fri, 13 Dec 2013 19:00:15 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86, microcode: Add option to allow downgrading of
 microcode

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/