Linux Fixes "Meltdown Lite" Mitigation Handling On Newer Zen 5 CPUs
([AMD] 91 Minutes Ago
AMD Meltdown Lite)
- Reference: 0001501707
- News link: https://www.phoronix.com/news/Meltdown-Lite-Zen-5-Linux-Fix
- Source link:
Linus Torvalds took to some coding himself today to fix a user-address masking non-canonical speculation issue. The Linux kernel needed an adaptation for this "Meltdown Lite" issue due to different behavior with the latest AMD Zen 5 processors.
Linus Torvalds authored and committed today the patch [1]x86: fix user address masking non-canonical speculation issue . In there he explains:
"It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations."
AMD Linux engineer Borislav Petkov [2]commented earlier this week on the Linux kernel mailing list around the difference now with AMD Zen 5 CPUs:
"So I was able to get some info: CLAC/STAC in everything Zen4 and older is serializing so there's no issue there.
Zen5 is a different story and AC is being renamed there and thus, non-serializing. So we'd need to do something there, perhaps something like Josh's patch...
But the good thing is we can alternative it out only for those machines, apart from the rest."
The patch is now in the kernel ahead of the Linux 6.12-rc5 release this weekend and will likely be back-ported to existing stable kernel versions over the coming days.
[3]
More background information on the prior AMD security issue now adapted for Zen 5 coverage can be found via [4]this security bulletin and via CVE-2020-12965 that was made public back in 2022.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86e6b1547b3d013bc392adf775b89318441403c2
[2] https://lore.kernel.org/all/20241023094448.GAZxjFkEOOF_DM83TQ@fat_crate.local/
[3] https://www.phoronix.com/image-viewer.php?id=2024&image=zen_5_lite_lrg
[4] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1010.html
Linus Torvalds authored and committed today the patch [1]x86: fix user address masking non-canonical speculation issue . In there he explains:
"It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:
CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.
But that was true only up until Zen 5, which renames the AC bit. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.
Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers.
It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations."
AMD Linux engineer Borislav Petkov [2]commented earlier this week on the Linux kernel mailing list around the difference now with AMD Zen 5 CPUs:
"So I was able to get some info: CLAC/STAC in everything Zen4 and older is serializing so there's no issue there.
Zen5 is a different story and AC is being renamed there and thus, non-serializing. So we'd need to do something there, perhaps something like Josh's patch...
But the good thing is we can alternative it out only for those machines, apart from the rest."
The patch is now in the kernel ahead of the Linux 6.12-rc5 release this weekend and will likely be back-ported to existing stable kernel versions over the coming days.
[3]
More background information on the prior AMD security issue now adapted for Zen 5 coverage can be found via [4]this security bulletin and via CVE-2020-12965 that was made public back in 2022.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86e6b1547b3d013bc392adf775b89318441403c2
[2] https://lore.kernel.org/all/20241023094448.GAZxjFkEOOF_DM83TQ@fat_crate.local/
[3] https://www.phoronix.com/image-viewer.php?id=2024&image=zen_5_lite_lrg
[4] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1010.html
phoronix