public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Alexander Sergeyev <sergeev917@gmail.com>,
	"Van De Ven, Arjan" <arjan.van.de.ven@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Kyle Huey <me@kylehuey.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>,
	Peter Zijlstra <peterz@infradead.org>,
	 linux-kernel@vger.kernel.org
Subject: Re: update spectre v2 microcodes blacklist
Date: Mon, 12 Feb 2018 09:34:46 +0000	[thread overview]
Message-ID: <1518428086.6606.11.camel@infradead.org> (raw)
In-Reply-To: <20180210171459.GA12797@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 2787 bytes --]



On Sat, 2018-02-10 at 20:14 +0300, Alexander Sergeyev wrote:
> > 
> > I didn't fully match the updated revision guidance and spectre_bad_microcodes
> I compared these lists and it seems that the only difference is about skylakes. 
> Everything else is covered by less-or-equal criteria on revision version.
> 
> Both desktop and mobile skylakes are stated to be unaffected for 0xC2:
> 
> { INTEL_FAM6_SKYLAKE_DESKTOP,    0x03, 0xc2 }, // signature 0x000506E3
> { INTEL_FAM6_SKYLAKE_MOBILE,     0x03, 0xc2 }, // signature 0x000406E3
> 
> I reformated the Intel bulletin into json format for ease of automation and 
> batch processing -- it is attached.
> 
> Raw diff between the mainline blacklist and the bulletin looks like:
> @@ -1,5 +1,6 @@
>  { INTEL_FAM6_BROADWELL_CORE,     0x04, 0x28 },
>  { INTEL_FAM6_BROADWELL_GT3E,     0x01, 0x1b },
> +{ INTEL_FAM6_BROADWELL_X,        0x01, 0x0b000023 },
>  { INTEL_FAM6_BROADWELL_X,        0x01, 0x0b000025 },

That's redundant since blacklisting 0x0b000025 will also stop us from
using 0x0b000023 anyway.

> -{ INTEL_FAM6_KABYLAKE_DESKTOP,   0x09, 0x84 },
> -{ INTEL_FAM6_KABYLAKE_DESKTOP,   0x0a, 0x84 },
> -{ INTEL_FAM6_KABYLAKE_DESKTOP,   0x0b, 0x84 },
> -{ INTEL_FAM6_KABYLAKE_MOBILE,    0x09, 0x84 },
> -{ INTEL_FAM6_KABYLAKE_MOBILE,    0x0a, 0x84 },

No, let's not assume 0x84 will be safe on those just yet. Intel
mentioned 0x84 as bad in one of the revisions of the doc, and it's
safer to leave it blacklisted until they explicitly say otherwise.

> -{ INTEL_FAM6_SKYLAKE_DESKTOP,    0x03, 0xc2 },
> -{ INTEL_FAM6_SKYLAKE_MOBILE,     0x03, 0xc2 },

OK. With 0xc2 being exonerated, I believe there is *no* publicly
released microcode for these which needs to be blacklisted, so they can
be removed entirely.

> -{ INTEL_FAM6_SKYLAKE_X,          0x03, 0x0100013e },

Again, that appeared in an earlier version of the document and hasn't
been explicitly cleared.

> +{ INTEL_FAM6_SKYLAKE_X,          0x04, 0x0200003a },
>  { INTEL_FAM6_SKYLAKE_X,          0x04, 0x0200003c },

Redundant again.

> Note: Gemini Lake and Sandy Bridge are not considered (observed in wild).

Ah, but we have more information now from the doc. 

The Gemini Lake 0x22 was observed in the wild, sure, but is also
explicitly mentioned as OK in the latest doc. So I removed it from the
blacklist (again, with no prior Gemini Lake bad microcode, so the line
can be removed entirely).

The Sandy Bridge ones observed in the wild are, however, *newer* than
the "Pre-Mitigation Production MCU" listed for the corresponding CPU in
the table, and thus we should assume they should still be blacklisted.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

  reply	other threads:[~2018-02-12  9:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-10 12:31 update spectre v2 microcodes blacklist Alexander Sergeyev
2018-02-10 17:14 ` Alexander Sergeyev
2018-02-12  9:34   ` David Woodhouse [this message]
2018-02-12 13:56     ` Van De Ven, Arjan
2018-02-12 14:11       ` Alexander Sergeyev

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=1518428086.6606.11.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=alexander.levin@verizon.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=me@kylehuey.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sergeev917@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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