Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
On Sun, Sep 27, 2020, at 18:27, Ben Hutchings wrote: > 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. This is still true :( > 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. So, until a more workable solution is found, if you need amd64-microcode to carry any other data files, please file a bug. If I am behind an update for any reason, please file a bug. I will see it and act on it. You don't need to wait to see if I noticed the upstream update or not, file the bug as soon as you're prepared to. There was a mention about a pending security update of SES firmware in this thread. If this needs an amd64-microcode release and if the ses firmware should go into that release, please explicitly say so, preferably in a new bug report, so that we can keep this one open until a final decision is done whether we should drop amd64-microcode as a separate package or keep it just for scripts, or keep the status-quo. -- Henrique de Moraes Holschuh
Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
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. signature.asc Description: This is a digitally signed message part
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
Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
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. Thanks for letting us know. kind regards, maximilian 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? > 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). > > Would you want to be added in counterpart to the uploaders of > firmware-nonfree? > > 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 > > signature.asc Description: PGP signature
Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
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? 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). Would you want to be added in counterpart to the uploaders of firmware-nonfree? 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 > signature.asc Description: PGP signature
Bug#970395: firmware-nonfree: Please add AMD-SEV firmware files (amd-folder) to close CVE-2019-9836 on specific EPYC-CPUs
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
