Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #875376 > unrolled thread

Bug#886367: partial fix uploaded

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#886367: partial fix uploaded Andreas Heinlein <aheinlein@gmx.com> - 2018-01-15 11:40 +0100
    Bug#886367: partial fix uploaded Henrique de Moraes Holschuh <hmh@debian.org> - 2018-01-15 13:30 +0100

#875376 — Bug#886367: partial fix uploaded

[Multipart message — attachments visible in raw view] — view raw

On Thu, 4 Jan 2018 23:18:49 -0200 Henrique de Moraes Holschuh wrote:
> Intel has released several updates already, but not all of them AFAIK.
>
> These microcode updates are of little impact until the kernel changes to
> activate the new MSRs are deployed. But they do mess with conditional
> jumps and LFENCE.
>
> Anyway, uploading a partial, unofficial set of updates to unstable to
> close the bug. Several processors are still missing. I expect an
> official release from Intel soon, hopefully with updates for everything.
>
> Everyone should look for firmware updates, the usual good vendors
> already have them out, or will have them out by the end of the next
> week.

Sorry for the question, this is not exactly the right place but I know
of no better one:

Do microcode updates delivered by this package have the same effect as
BIOS/Firmware updates? Or do they complement each other?

At our organization, we unfortunately have a large number of different
machines from different vendors, and updating the BIOS on all of them
will be a very time consuming task. So I'd like to ask whether we can
expect the same protection from updated microcode and kernel packages.

Thanks,
Andreas

[toc] | [next] | [standalone]

#875413

On Mon, 15 Jan 2018, Andreas Heinlein wrote:
> On Thu, 4 Jan 2018 23:18:49 -0200 Henrique de Moraes Holschuh wrote:
> > Intel has released several updates already, but not all of them AFAIK.
> >
> > These microcode updates are of little impact until the kernel changes to
> > activate the new MSRs are deployed. But they do mess with conditional
> > jumps and LFENCE.
> >
> > Anyway, uploading a partial, unofficial set of updates to unstable to
> > close the bug. Several processors are still missing. I expect an
> > official release from Intel soon, hopefully with updates for everything.
> >
> > Everyone should look for firmware updates, the usual good vendors
> > already have them out, or will have them out by the end of the next
> > week.
> 
> Sorry for the question, this is not exactly the right place but I know
> of no better one:
> 
> Do microcode updates delivered by this package have the same effect as
> BIOS/Firmware updates? Or do they complement each other?

BIOS/firmware microcode updates are loaded *EXTREMELY* early, before
much of the platform init is done.  It is not the same, and at least in
one case, Intel got things wrong for a while and did not do everything
in the microcode update that it had to.  You'd get regressions with that
one, except if you had the microcode update done by the firmware.  This
issue has been long fixed, though (it happened to the Xeon E5v3).

But nearly always, an *early* microcode update by the operating system
is going to be good enough *as far as the microcode itself goes*.  This
doesn't mean the entire platform is always going to be OK with just a
microcode update.

Firmware updates will have up-to-date ACM modules like SINIT and SGX
system enclaves, as well as other firmware such as Intel ME, that must
*not* be out-of-sync with the microcode functionality.  And firmware
updates often fix outright bugs in the vendor UEFI and SMM code that
could even clash with changed microcode functionality, etc.

> At our organization, we unfortunately have a large number of different
> machines from different vendors, and updating the BIOS on all of them
> will be a very time consuming task. So I'd like to ask whether we can

It is the new reality since (and including) Sandybridge for Intel, and
it is only getting worse.  You will have to find a way to deal with it,
I fear :(

> expect the same protection from updated microcode and kernel packages.

In the general case, you cannot.  But this varies in a case-by-case
basis.  Right now, you very likely want fully updated firmware
everywhere because of Intel ME security holes being fixed recently, for
example.

-- 
  Henrique Holschuh

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web