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

Groups > linux.debian.kernel > #61041

Re: Updating x86 microcode in stable

Cross-posted to 2 groups.

Show all headers | View raw

[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.

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web