Oxide Security Announcement 20230808-1: CVE-2023-20593 Zenbleed

No Oxide products are impacted by this issue. No Oxide computer can boot or operate with an AMD Zen 2 processor installed, nor will that be offered in the future. This vulnerability impacts AMD Zen 2 based CPUs which include the following:

There is no impact from this issue for Oxide products. The following only applies to non-Oxide systems.

This vulnerability allows the leaking of the upper 128-bits of the FPU registers, which depending on the specifics of an operating system, can contain sensitive information as many implementations of cryptography algorithms or even basic memory copying leverage these registers. This allows a process running on a core to see information left behind by a prior process (regardless of whether that process is inside a virtual machine or not).

There is no action required for Oxide products.

For other products and systems, please follow your vendor’s documentation for determining if a Zen 2 CPU is installed is installed. If you have a Zen 2 based CPU listed above installed in a non-Oxide computer, please check that system’s OS or BIOS vendor to see if a CPU microcode update is available.

There are no mitigations available for Oxide systems as Oxide products are not impacted by this vulnerability.

For a more detailed explanation, please see the write up from Tavis Ormandy who discovered this vulnerability.

AMD CPUs support the AVX family of instructions. These instructions extend the CPU’s vector registers to 256-bits often referred to as the YMM registers. These registers shadow the original 128-bit XMM registers. That is, %xmm0[127:0] is the same a %ymm0[127:0]. When switching between the different classes of instructions, it is often required to zero the upper 128-bits of a YMM register. This is most often done with an explicit x86 instruction called vzeroupper which zeros all upper bits of the vector registers.

While x86 registers are explicitly named in the assembler, internally the CPU is much more complex and the common names of registers points to a register file . These hardware resources are shared between both hardware threads within the core and is not statically partitioned. When the vzeroupper instruction is used, rather than actually zero the underlying data, it will often just set a flag indicating that this is the case in the hardware.

The problem occurs when the CPU speculatively executes a vzeroupper and then aborts that due to a misprediction. This can lead the register contents to then contain the prior contents prior to setting the zero flag. This allows another user to read the prior data that was put into the register by either hardware thread.

The following URLs provide additional information about this vulnerability.