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

Groups > linux.debian.kernel > #61024 > unrolled thread

Updating x86 microcode in stable

Back to article view | Back to linux.debian.kernel

Contents

  Updating x86 microcode in stable Ben Hutchings <ben@decadent.org.uk> - 2018-05-15 05:00 +0200
    Re: Updating x86 microcode in stable Henrique de Moraes Holschuh <hmh@debian.org> - 2018-05-16 20:00 +0200
      Re: Updating x86 microcode in stable Ben Hutchings <ben@decadent.org.uk> - 2018-05-16 23:30 +0200

#61024 — Updating x86 microcode in stable

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

I notice that amd64-microcode and intel-microcode haven't been updated
in stable this year.  (Indeed, amd64-microcode hasn't been updated at
all this year, but I know AMD has issued an update!)

You have updated intel-microcode in backports suites instead.  What's
the reasoning behind this?  I would expect all microcode updates to
meet the criteria for a stable update (fixing instability or data loss
bugs) or security update.

As you probably know, updated microcode is needed to mitigate against
Spectre v2 when running code that has not been rebuilt with the
"retpoline" mitigation, such as when making BIOS/UEFI calls.  I think
it's also needed to support Spectre v2 mitigation in KVM guests running
Windows.

The Linux kernel in stretch has had support for the microcode-based
mitigation since version 4.9.82-1+deb9u1.  I'm currently working on
backporting these changes to jessie, so microcode updates would be
useful there too.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

[toc] | [next] | [standalone]

#61039

On Tue, 15 May 2018, Ben Hutchings wrote:
> I notice that amd64-microcode and intel-microcode haven't been updated
> in stable this year.  (Indeed, amd64-microcode hasn't been updated at
> all this year, but I know AMD has issued an update!)

AMD did not issue any public updates AFAIK(!), the one we have [which is
not in stable] is only for EPYC processors, and came from SuSE...

So far we do not have a *single* report from someone with an EPYC box
whether it works or not, as far as I know.  I am not confortable with
proposing a stable update for this one unless we get such a report,
since that microcode update is *still* not available in linux-firmware
upstream...

If I am wrong about this, please correct me (and point me to the AMD
microcode release) and I will fix it ASAP.

> You have updated intel-microcode in backports suites instead.  What's
> the reasoning behind this?  I would expect all microcode updates to

One of the stable release managers suggested to be more careful with
this recent crop of microcode updates...

Given the fact that it triggered a number of issues in the kernels of
some vendors (kernel bug, not microcode bug), I agree with their
reasoning, so I did not send a SPU request after an one-month wait.

However, I don't see any reason why we could not start the process for
an upload of intel-microcode to stable right now.  It has been tested
widely enough by Debian users and other distros by now, and the only
kernels that regressed were Ubuntu's (related to apparmor and IBPB
support, worked around by noibpb), AFAIK.

> As you probably know, updated microcode is needed to mitigate against
> Spectre v2 when running code that has not been rebuilt with the
> "retpoline" mitigation, such as when making BIOS/UEFI calls.  I think
> it's also needed to support Spectre v2 mitigation in KVM guests running
> Windows.

Yes, that's correct.

> The Linux kernel in stretch has had support for the microcode-based
> mitigation since version 4.9.82-1+deb9u1.  I'm currently working on
> backporting these changes to jessie, so microcode updates would be
> useful there too.

ACK.  I usually send spu and ospu requests at the same time anyway,
since the criteria for acceptance is mostly the same.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#61041

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

On Wed, 2018-05-16 at 14:57 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 15 May 2018, Ben Hutchings wrote:
> > I notice that amd64-microcode and intel-microcode haven't been updated
> > in stable this year.  (Indeed, amd64-microcode hasn't been updated at
> > all this year, but I know AMD has issued an update!)
> 
> AMD did not issue any public updates AFAIK(!), the one we have [which is
> not in stable] is only for EPYC processors, and came from SuSE...
> 
> So far we do not have a *single* report from someone with an EPYC box
> whether it works or not, as far as I know.  I am not confortable with
> proposing a stable update for this one unless we get such a report,
> since that microcode update is *still* not available in linux-firmware
> upstream...
> 
> If I am wrong about this, please correct me (and point me to the AMD
> microcode release) and I will fix it ASAP.

According to <https://www.amd.com/en/corporate/security-updates>, "AMD
recommended mitigations for GPZ Variant 2 were made available to our
Linux partners and have been released to distribution earlier this
year."

Guess we're not important enough to be a partner. :-(

> > You have updated intel-microcode in backports suites instead.  What's
> > the reasoning behind this?  I would expect all microcode updates to
> 
> One of the stable release managers suggested to be more careful with
> this recent crop of microcode updates...
> 
> Given the fact that it triggered a number of issues in the kernels of
> some vendors (kernel bug, not microcode bug), I agree with their
> reasoning, so I did not send a SPU request after an one-month wait.

Yes, I understand that.

> However, I don't see any reason why we could not start the process for
> an upload of intel-microcode to stable right now.  It has been tested
> widely enough by Debian users and other distros by now, and the only
> kernels that regressed were Ubuntu's (related to apparmor and IBPB
> support, worked around by noibpb), AFAIK.

Thanks.

Ben.

> > As you probably know, updated microcode is needed to mitigate against
> > Spectre v2 when running code that has not been rebuilt with the
> > "retpoline" mitigation, such as when making BIOS/UEFI calls.  I think
> > it's also needed to support Spectre v2 mitigation in KVM guests running
> > Windows.
> 
> Yes, that's correct.
> 
> > The Linux kernel in stretch has had support for the microcode-based
> > mitigation since version 4.9.82-1+deb9u1.  I'm currently working on
> > backporting these changes to jessie, so microcode updates would be
> > useful there too.
> 
> ACK.  I usually send spu and ospu requests at the same time anyway,
> since the criteria for acceptance is mostly the same.
> 
-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web