Re: Updating x86 microcode in stable

[Ben Hutchings]

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 , "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.


signature.asc
Description: This is a digitally signed message part

Re: Updating x86 microcode in stable

[Henrique de Moraes Holschuh]

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

Re: Updating libvirt and qemu in stable

[Guido Günther]

On Tue, May 15, 2018 at 05:52:14PM +0100, Ben Hutchings wrote:
> In order to support Spectre v2 mitigation in Windows guests, I believe
> the microcoded mitigation features (IBPB and IBRS) need to be exposed
> to them.  This may also be useful for Linux guests using OVMF, unless
> it is rebuilt with the retpoline mitigation.
> 
> The kernel side of this in KVM was already implemented in version
> 4.9.82-1+deb9u1, although the microcode updates are not yet in stable.
> 
> libvirt and qemu (and maybe other related packages) also need to be
> updated so that they recognise and enable the new CPU feature bits for
> guests.  Is this likely to be doable?

With  libvirt should already work iff qemu
handles ibpb and ibrs (1.12.0 and 1.11.1 onward according to ¹). I've
just tested this on sid with 1.12 and Westmere-IBRS and the recent
microcode update.

For stable we need to update libvirt's cpu_map.xml to support non
host-passthrough configuration. E.g. virt-manager uses host-model which
needs an updated cpu_map.xml.

Cheers,
 -- Guido


¹) https://www.qemu.org/2018/02/14/qemu-2-11-1-and-spectre-update/

Bug#898765: nmu: eccodes_2.7.3-2

[Alastair McKinstry]

On 15/05/2018 18:54, Gilles Filippini wrote:


Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

eccodes binary packages were built by the maintainer for arch amd64,
and it seems he used a GCC version different from 7.3.0 because building
metview on amd64 with default GCC FTBFS with:
/<>/src/libMvMacroApi/macro_api_f90.f90:23:6:

use grib_api
   1
Fatal Error: Cannot read module file 'grib_api.mod' opened at (1), because it 
was created by a different version of GNU Fortran


I did build eccodes (2.7.3-2) with gfortran 8, but I did so deliberately 
to provide the compatible mod file needed to test the ECMWF / meteo 
stack with gcc / g++ / gfortran 8.
metview is now (5.0.1-3) also compiled with gfortran-8 and compiles 
successfully. See the changelogs / diffs for the packages 
(https://salsa.debian.org/science-team/eccodes, etc)



The ECMWF packages (magics++, metview in particular) contain a lot of 
old-style C++ code, and typically FTBFS on g++ upgrades, needing syntax 
fixes for new warnings, etc. To ensure they compile and work (on all 
archs) required building eccodes with gfortran8 to get the dependencies 
working then building all with experimental.


So, these packages (eccodes, flextra, flexpart, metview) are temporarily 
hard-coded to use gfortran-8. I will revert this when the transition is 
compete.

grib_api.mod is part of libeccodes-dev.

Please rebuild eccodes with default GCC for amd64.

nmu eccodes_2.7.3-2 . amd64 . unstable . -m "Rebuild with GCC 7.3.0"

Thanks,

Thanks

--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.