linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>,
	Chuck Ebbert <cebbert.lkml@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: x86, microcode: BUG: microcode update that changes x86_capability
Date: Fri, 19 Sep 2014 13:54:05 -0300	[thread overview]
Message-ID: <20140919165405.GE17456@khazad-dum.debian.net> (raw)
In-Reply-To: <CALCETrUaYzBq68gGK7ixdb348jc_c=aKj6rA1=9t=3V3mm=fFw@mail.gmail.com>

On Fri, 19 Sep 2014, Andy Lutomirski wrote:
> Can we change the ucode blob format for these firmwares so that old
> kernels won't apply them?  I have no other good ideas.  The trouble is
> that distros *should* push out the new ucode, but only if there's some
> guarantee that they'll only be applied early, never late.

All it takes is to rm the /lib/firmware/intel-ucode/<haswell f-m-s> files,
while not touching the microcode you will add to the early initramfs.

Anyway, if you want to fix this through the stable kernel updates:

The intel microcode driver does a "sanity check" pass over all cpus before
the update, attempting to locate the appropriate microcode.  It is trivial
to add the following logic to it:

if cpu_has(hle) && cpuid_in_table(haswell_cpuids) { ignore the microcode }.

You don't even have to key on the current microcode revision, as we don't
know for sure it will be safe to update these processors again when the BIOS
force-enabled HLE anyway.

We can enhance the blacklist to only key on the old microcode that always
enables Intel TSX later, if this proves to be safe.

-- 
  "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-09-19 16:54 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 13:52 x86, microcode: BUG: microcode update that changes x86_capability Henrique de Moraes Holschuh
2014-09-18 19:14 ` Andy Lutomirski
2014-09-18 19:53   ` Chuck Ebbert
2014-09-18 19:55     ` H. Peter Anvin
2014-09-18 20:06       ` Henrique de Moraes Holschuh
2014-09-19  0:13         ` Henrique de Moraes Holschuh
2014-09-19  0:23           ` Andy Lutomirski
2014-09-19  0:28             ` H. Peter Anvin
2014-09-19  1:00               ` Andy Lutomirski
2014-09-19  8:03                 ` Borislav Petkov
2014-09-19 11:00             ` Henrique de Moraes Holschuh
2014-09-19 11:29               ` Borislav Petkov
2014-09-19 12:54                 ` Chuck Ebbert
2014-09-19 13:14                   ` Josh Boyer
2014-09-19 13:37                     ` Chuck Ebbert
2014-09-19 15:00                   ` Borislav Petkov
2014-09-19 16:13                     ` Andy Lutomirski
2014-09-19 16:54                       ` Henrique de Moraes Holschuh [this message]
2014-09-19 16:42                     ` Henrique de Moraes Holschuh
2014-09-23 20:00                       ` Borislav Petkov
2014-09-24 14:56                         ` Henrique de Moraes Holschuh
2014-09-24 15:00                           ` Andy Lutomirski
2014-09-24 17:45                             ` Henrique de Moraes Holschuh
2014-09-24 17:48                               ` Andy Lutomirski
2014-09-24 18:59                                 ` Henrique de Moraes Holschuh
2014-09-24 19:34                                   ` Andy Lutomirski
2014-09-25  8:57                               ` Borislav Petkov
2014-09-25  8:51                           ` Borislav Petkov
2014-09-25 11:36                             ` Henrique de Moraes Holschuh
2014-09-25 12:10                               ` Borislav Petkov
2014-09-25 14:40                                 ` Henrique de Moraes Holschuh
2014-09-25 14:56                                   ` Borislav Petkov
2014-09-25 15:30                                     ` Henrique de Moraes Holschuh
2014-09-25 15:50                                       ` Borislav Petkov
2014-09-25 16:41                                         ` Henrique de Moraes Holschuh
2014-09-25 16:57                                           ` Borislav Petkov
2014-09-25 17:09                                             ` Henrique de Moraes Holschuh
2014-09-19 13:51                 ` Henrique de Moraes Holschuh
2014-09-19 14:49                   ` Borislav Petkov
2014-09-19 17:22                     ` Henrique de Moraes Holschuh
2014-09-19 22:35               ` Henrique de Moraes Holschuh
2014-09-29 11:51                 ` Henrique de Moraes Holschuh
2014-09-19  9:56     ` Henrique de Moraes Holschuh
2014-09-19 16:11   ` Henrique de Moraes Holschuh
2014-09-22  0:37 ` Andi Kleen
2014-09-22  0:51   ` H. Peter Anvin
2014-09-22  0:58     ` Andi Kleen

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=20140919165405.GE17456@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=bp@alien8.de \
    --cc=cebbert.lkml@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /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;
as well as URLs for NNTP newsgroup(s).