Improper handling of overlap between protected memory ranges in some microcode for some Intel(R) Processors within Ring 0: Hypervisor may allow an escalation of privilege. Authorized adversary with a privileged user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.
On Tue Jul 25, 2023 at 6:30 PM UTC, Jeffrey Walton wrote: On Tue, Jul 25, 2023 at 2:14 PM Demi Marie Obenour <demi () invisiblethingslab com> wrote: On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. Related, Ubuntu released an updated amd64-microcode around (or before) 1:45 PM EST today. My Ubuntu machines have already been patched.
I was kind of surprised to see how quickly it landed. the updated amd64-microcode only contains the fixes published to linux-firmware, which only affects epyc cpus, as noted. unless you're running epyc cpus (which is slightly unlikely so i thought i'd mention it, but apologies if that is indeed the case) you didn't actually receive any fix.
the latest kernel released today sets the chicken bit if no patched ucode is loaded which also works to mitigate the issue. (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98)
you can test this by running the zenbleed reproduction, from https://cmpxchg8b.com/files/zenbleed-v5.tar.gz
(if it outputs anything, you're vulnerable) Jeff
On Tue, Jul 25, 2023 at 2:14 PM Demi Marie Obenour <demi () invisiblethingslab com> wrote: On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. Related, Ubuntu released an updated amd64-microcode around (or before) 1:45 PM EST today. My Ubuntu machines have already been patched.
I was kind of surprised to see how quickly it landed.
Jeff
Gather Date Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processor. In this flaw, a local attack using gather instruction (load from memory) may infer stale data from previously used vector registers on the same physical core.
Certain optimizations on some Intel processors target “trivial data value” cache-lines, such as all-zero value cache-lines. Such optimizations may lead to changes in cache-allocation or write-back behavior for such cache-lines. It may be possible for a local attacker to distinguish some cases of trivial-data-cache-lines from non-trivial-data cache-lines by inferring cache state using cache timing methods.
Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
Security Fix(es): hw: Special Register Buffer Data Sampling (SRBDS) (CVE-2020-0543) hw: L1D Cache Eviction Sampling (CVE-2020-0549) hw: Vector Register Data Sampling (CVE-2020-0548) For more details about the security issue(s), including the impact, a CVSSscore, acknowledgments, and other related information, refer to the CVE page(s)listed in the References section.Bug Fix(es): Update Intel CPU microcode to microcode-20200609 release: Update of 06-2d-06/0x6d (SNB-E/EN/EP C1/M0) microcode from revision 0x61f up to 0x621; Update of 06-2d-07/0x6d (SNB-E/EN/EP C2/M1) microcode from revision 0x718 up to 0x71a; Update of 06-3c-03/0x32 (HSW C0) microcode from revision 0x27 up to 0x28; Update of 06-3d-04/0xc0 (BDW-U/Y E0/F0) microcode from revision 0x2e up to 0x2f; Update of 06-45-01/0x72 (HSW-U C0/D0) microcode from revision 0x25 up to 0x26; Update of 06-46-01/0x32 (HSW-H C0) microcode from revision 0x1b up to 0x1c; Update of 06-47-01/0x22 (BDW-H/Xeon E3 E0/G0) microcode from revision 0x21 up to 0x22; Update of 06-4e-03/0xc0 (SKL-U/Y D0) microcode from revision 0xd6 up to 0xdc; Update of 06-55-03/0x97 (SKX-SP B1) microcode from revision 0x1000151 up to 0x1000157; Update of 06-55-04/0xb7 (SKX-SP H0/M0/U0, SKX-D M1) microcode (in intel-06-55-04/intel-ucode/06-55-04) from revision 0x2000065 up to 0x2006906; Update of 06-55-06/0xbf (CLX-SP B0) microcode from revision 0x400002c up to 0x4002f01; Update of 06-55-07/0xbf (CLX-SP B1) microcode from revision 0x500002c up to 0x5002f01; Update of 06-5e-03/0x36 (SKL-H/S R0/N0) microcode from revision 0xd6 up to 0xdc; Update of 06-7e-05/0x80 (ICL-U/Y D1) microcode from revision 0x46 up to 0x78; Update of 06-8e-09/0x10 (AML-Y22 H0) microcode from revision 0xca up to 0xd6; Update of 06-8e-09/0xc0 (KBL-U/Y H0) microcode from revision 0xca up to 0xd6; Update of 06-8e-0a/0xc0 (CFL-U43e D0) microcode from revision 0xca up to 0xd6; Update of 06-8e-0b/0xd0 (WHL-U W0) microcode from revision 0xca up to 0xd6; Update of 06-8e-0c/0x94 (AML-Y42 V0, CML-Y42 V0, WHL-U V0) microcode from revision 0xca up to 0xd6; Update of 06-9e-09/0x2a (KBL-G/H/S/X/Xeon E3 B0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0a/0x22 (CFL-H/S/Xeon E3 U0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0b/0x02 (CFL-S B0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0c/0x22 (CFL-H/S P0) microcode from revision 0xca up to 0xd6; Update of 06-9e-0d/0x22 (CFL-H R0) microcode from revision 0xca up to 0xd6. Do not update 06-4e-03 (SKL-U/Y) and 06-5e-03 (SKL-H/S/Xeon E3 v5) to revision 0xdc, use 0xd6 by default. Enable 06-2d-07 (SNB-E/EN/EP) caveat by default. Enable 06-55-04 (SKL-SP/X/W) caveat by default. Avoid find being SIGPIPE'd on early "grep -q" exit in the dracut script. Re-generate initramfs not only for the currently running kernel, but for several recently installed kernels as well. Change the URL to point to the GitHub repository since the microcode download. section at Intel Download Center does not exist anymore. Avoid temporary file creation, used for here-documents in checkcaveats.
USN-3977-1 and USN-3977-2 provided mitigations for Microarchitectural Data Sampling (MDS) vulnerabilities in Intel Microcode for a large number of Intel processor families. This update provides the corresponding updated microcode mitigations for the Intel Sandy Bridge processor family Ke Sun, Henrique Kawakami, Kekai Hu, Rodrigo Branco, Giorgi Maisuradze, Dan Horea Lutas, Andrei Lutas, Volodymyr Pikhur, Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida, Moritz Lipp, Michael Schwarz, and Daniel Gruss discovered that memory previously stored in microarchitectural fill buffers of an Intel CPU core may be exposed to a malicious process that is executing on the same CPU core. A local attacker could use this to expose sensitive information. (CVE-2018-12130) Brandon Falk, Ke Sun, Henrique Kawakami, Kekai Hu, Rodrigo Branco, Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida discovered that memory previously stored in microarchitectural load ports of an Intel CPU core may be exposed to a malicious process that is executing on the same CPU core. A local attacker could use this to expose sensitive information. (CVE-2018-12127) Ke Sun, Henrique Kawakami, Kekai Hu, Rodrigo Branco, Marina Minkin, Daniel Moghimi, Moritz Lipp, Michael Schwarz, Jo Van Bulck, Daniel Genkin, Daniel Gruss, Berk Sunar, Frank Piessens, and Yuval Yarom discovered that memory previously stored in microarchitectural store buffers of an Intel CPU core may be exposed to a malicious process that is executing on the same CPU core. A local attacker could use this to expose sensitive information. (CVE-2018-12126) Ke Sun, Henrique Kawakami, Kekai Hu, Rodrigo Branco, Volodrmyr Pikhur, Moritz Lipp, Michael Schwarz, Daniel Gruss, Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida discovered that uncacheable memory previously stored in microarchitectural buffers of an Intel CPU core may be exposed to a malicious process that is executing on the same CPU core. A local attacker could use this to expose sensitive information. (CVE-2019-11091)
It was discovered that microprocessors utilizing speculative execution and branch prediction may allow unauthorized memory reads via sidechannel attacks. This flaw is known as Spectre. A local attacker could use this to expose sensitive information, including kernel memory. (CVE-2017-5715) This update provides the microcode updates required for the corresponding Linux kernel updates.