Re: Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
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.
I.e. I am not opposed. But there is more than a bunch of data files involved: the initramsfs integration must be somehow handled by whatever ships the data files.
However, you can also try opening a bug against amd64-microcode with a pointer to new upstream releases should I miss any for longer than a week, or asking for more files to be switched to amd64-microcode, e.g. if the ses datafiles should be in there along with the ucode ones, this could be done.
Either way is fine, what does the majority of the maintainers of linux-firmware-nonfree think about it ?
> 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.
> > I am asking as it keeps nugging me to have to outcomment the updates of that
> > microcode in the changelog (there is again a new one for the upcoming 20200918).
This should be very very easy to automate, but...
> > Would you want to be added in counterpart to the uploaders of firmware-nonfree?
I can do it myself if there is a need to upload a new release and I have to do that upload, but if you guys are using salsa, I'd need to be in the salsa group you're using.
> > Thank you very much for your amd64 microcode work.
> >
> > kind regards,
> > maximilian
> >
> > On Tue, Sep 15, 2020 at 04:55:43PM +0200, Michael Musenbrock wrote:
> > > Source: firmware-nonfree
> > > Severity: important
> > >
> > > Dear maintainer,
> > >
> > > first of all thanks for maintaining and packaging the linux-firmware files repository as debian packages.
> > >
> > > We currently need to manually obtain the linux-firmware.git:amd/amd_sev_fam17h_model3xh.sbin [1] file on
> > > our AMD EPYC servers. The firmware files containing the AMD SEV firmware closing security vulnerabilities [2]
> > > and fixes bugs and adds improvements to the AMD SEV implementation.
> > >
> > > I'm most likely unqualified for legal questions but the LICENSE.amd-sev [3] reads quite similar to the already
> > > added amdgpu license [4]. So I hope this is not the reason, why those files were not added in the past.
> > >
> > > The severity was choosen because it fixes a security vulnerability, please change accordingly if you think
> > > it is wrong.
> > >
> > > Thanks in advance. Best regards,
> > > michael
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd
> > > [2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9836
> > > [3] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amd-sev
> > > [4] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.amdgpu
--
Henrique de Moraes Holschuh <hmh@debian.org>
Reply to: