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 <[email protected]>
