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 <https://www.amd.com/en/corporate/security-updates>, "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.
Attachment:
signature.asc
Description: This is a digitally signed message part