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

Groups > linux.debian.bugs.dist > #1026716

Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs

Cross-posted to 2 groups.

Show all headers | View raw

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

On Sun, 2020-09-27 at 13:43 -0300, Henrique de Moraes Holschuh wrote:
> Answering from my phone, please excuse brevity and other netiquete
> issues such as poor quoting cleanup.
> 
> On Fri, Sep 25, 2020, at 09:14, maximilian attems wrote:
> > Dear Henrique,
> > 
> > It be great to get your input, hence repinging (;
> > 
> > Especially as linux-firmware is the common upstream source, it be ideal to ship
> > the amd64 mircrocode out of our firmware packages.
> 
> We can ship the ucode and other related data files in linux-firmware-
> nonfree, yes.  But the initramsfs glue needs.to go somewhere.  Either
> it can stick in the older package, and a depends ensures it gets
> installed, or linux-firmware-nonfree must carry it as debian
> packaging.

That's a good point.  firmware-nonfree does have initramfs integration,
but currently that is just triggering update-initramfs for packages
whose firmware might get pulled in automatically.

[...]
> > On Sun, Sep 20, 2020 at 10:36:12AM +0200, maximilian attems wrote:
> > > Dear Henrique, dear debian kernel maintainers, Cc: Michael,
> > > 
> > > Would you agree to generate the amd64-firmware packages directly out of the debian
> > > linux-firmware source package?
> > > 
> > > This way the microcode would be updated on every linux-firmware non-free upload?
> 
> If you guys think this will improve update delivery latency in
> Debian, I am not opposed.  But ucode updates go to security,
> backports and stable unless there is too little feedback to gauge
> regression risk.
> 
>   Is that viable for the whole of linux-firmware-nonfree ?  If not,
> it would make sense to keep the amd64 ucode in a separate package.
[...]

firmware-nonfree is present in backports suites, and does get security
updates (mostly for Wifi and Bluetooth issues).

However, we normally take all changes from linux-firmware.git up to a
specific tag, and that might not be appropriate for the AMD microcode
given the potential for system-breaking regressions.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                               A fail-safe circuit will destroy others.

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

Thread

Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs Michael Musenbrock <michael.musenbrock@gmx.at> - 2020-09-15 17:00 +0200
  Re: Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files  (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs maximilian attems <maks@stro.at> - 2020-09-20 10:40 +0200
    Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs maximilian attems <maks@stro.at> - 2020-09-25 14:20 +0200
      Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs "Henrique de Moraes Holschuh" <hmh@debian.org> - 2020-09-27 18:50 +0200
        Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs Ben Hutchings <ben@decadent.org.uk> - 2020-09-27 23:40 +0200
          Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs "Henrique de Moraes Holschuh" <hmh@debian.org> - 2020-10-02 04:30 +0200

csiph-web