See https://www.openwall.com/lists/oss-security/2023/07/24/1. I'll bump linux-firmware now, but there's fixes coming in kernels as well as a fallback.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=487850f324ac0f01332f2f12412f6f817aa45149 commit 487850f324ac0f01332f2f12412f6f817aa45149 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-07-24 18:15:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-07-24 18:16:06 +0000 sys-kernel/linux-firmware: add 20230625_p20230724 Bug: https://bugs.gentoo.org/911160 Signed-off-by: Sam James <sam@gentoo.org> sys-kernel/linux-firmware/Manifest | 1 + .../linux-firmware-20230625_p20230724.ebuild | 403 +++++++++++++++++++++ 2 files changed, 404 insertions(+)
Note that it's currently unclear if the microcode is enough for most machines: * https://www.tomshardware.com/news/zenbleed-bug-allows-data-theft-from-amds-zen-2-processors-patches-released indicates not * AMD's advisory: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html * Unclear if the advisories & articles are talking about just waiting for a new agesa in BIOS/firmware update, which normally can be mitigated with a new microcode version, or if the relevant models actually aren't fixed by latest microcode * https://news.ycombinator.com/item?id=36853437
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6390ce05738eac80fc06663a73ca6b22fdaee8d1 commit 6390ce05738eac80fc06663a73ca6b22fdaee8d1 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-07-25 04:36:15 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-07-25 04:59:34 +0000 sys-kernel/linux-firmware: stabilize 20230625_p20230724 Note that for zenrot, likely still need to upgrade kernels as well: https://bugs.gentoo.org/911160#c2. Bug: https://bugs.gentoo.org/911160 Signed-off-by: Sam James <sam@gentoo.org> sys-kernel/linux-firmware/linux-firmware-20230625_p20230724.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I was wondering why people got confused about stackrot vs zenbleed vs the general fork() bug in 6.4, and then I realised I called this "zenrot" in the bug... :|
According to /lib/firmware/amd-ucode/README, few CPUs have microcode available to fix zenbleed: For example, for zen/zen+/zen2 (family ID 0x17) **cat /lib/firmware/amd-ucode/README | grep 0x17** Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes So, the update in the gentoo package linux-firmware will not fix zenbleed for most CPUs. Is this correct?
(In reply to tetumetal from comment #5) > According to /lib/firmware/amd-ucode/README, few CPUs have microcode > available to fix zenbleed: > [...] > So, the update in the gentoo package linux-firmware will not fix zenbleed > for most CPUs. Is this correct? That's my understanding.
(In reply to Sam James from comment #6) > (In reply to tetumetal from comment #5) > > According to /lib/firmware/amd-ucode/README, few CPUs have microcode > > available to fix zenbleed: > > [...] > > So, the update in the gentoo package linux-firmware will not fix zenbleed > > for most CPUs. Is this correct? > > That's my understanding. OK, then the link posted above from AMD makes sense: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html So, I guess those few updated models mentioned in the amd-ucode/README, for Family=0x17, must be the EPYCs. And for regular people, the patch will be distributed through bios updates from PC manufacturers, following the described schedule
Also, I want to add that I ran spectre-meltdown-checker v0.46 on my system, and this was the result regarding zenbleed: CVE-2023-20593 aka 'Zenbleed, cross-process information leak' * Zenbleed mitigation is supported by kernel: YES (found zenbleed message in kernel image) * Zenbleed kernel mitigation enabled and active: YES (FP_BACKUP_FIX bit set in DE_CFG) * Zenbleed mitigation is supported by CPU microcode: NO > STATUS: NOT VULNERABLE (Your kernel mitigates Zenbleed) After some investigation, I found that the linux kernel was updated with a mitigation from an AMD developer: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a9266b79cacdd02b888aed1308c308ad6d4ee4e I have the latest kernel 5.10.187 available from Gentoo, and it seems that I already go that patch in: dmesg | grep Zenbleed Zenbleed: please update your microcode for the most optimal fix So, I guess that having that patch from the kernel is enough to mitigate zenbleed. However, the patch is disabling some hardware that may cause some performance penalty.
(In reply to tetumetal from comment #8) > [...] > > So, I guess that having that patch from the kernel is enough to mitigate > zenbleed. However, the patch is disabling some hardware that may cause some > performance penalty. This is my understanding too. I'm sorry for not explicitly stating it in the bug, I'd planned to, then I think I assumed I had and forgot.
(In reply to Sam James from comment #9) > (In reply to tetumetal from comment #8) > > [...] > > > > So, I guess that having that patch from the kernel is enough to mitigate > > zenbleed. However, the patch is disabling some hardware that may cause some > > performance penalty. > > This is my understanding too. I'm sorry for not explicitly stating it in the > bug, I'd planned to, then I think I assumed I had and forgot. No worries, I just wrote some conclusions here in this bug report, so people with more experience than me could verify them. Thanks,
