search

AMDESE / AMDSEV

AMD Secure Encrypted Virtualization
272 stars 84 forks source link

Security Vulnerability related to SEV #180

Open khushboo-dfn opened 10 months ago

khushboo-dfn commented 10 months ago

Hi, Came across this CVE https://access.redhat.com/security/cve/cve-2023-4155 A flaw was found in KVM AMD Secure Encrypted Virtualization (SEV) in the Linux kernel. A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger a double fetch race condition vulnerability and invoke the VMGEXIT handler recursively. If an attacker manages to call the handler multiple times, they can trigger a stack overflow and cause a denial of service or potentially guest-to-host escape in kernel configurations without stack guard pages (CONFIG_VMAP_STACK).

Is a fix planned in the Linux kernel for this? or is it already addressed in snp-host-latest branch of linux kernel?

Thanks, Khushboo

tlendacky commented 10 months ago

Is a fix planned in the Linux kernel for this? or is it already addressed in snp-host-latest branch of linux kernel?

This fix is already in v6.5 (included in v6.5-rc6). It will be part of snp-host-latest once snp-host-latest is rebased on at least v6.5-rc6.

khushboo-dfn commented 10 months ago

Ah I see. This actually brings me to one more question - We are about to release our SEV-SNP based solution as Beta. Do you recommend we use v6.5 branch of linux kernel for host and guest for more robustness? We have been doing our testing with snp-host-latest.

tlendacky commented 10 months ago

Do you recommend we use v6.5 branch of linux kernel for host and guest for more robustness? We have been doing our testing with snp-host-latest.

For the hypervisor support, you will need to start with the snp-host-latest branch, which is currently based off of v6.5-rc2. That release is pretty early in the release cycle and I'm not sure when the branch will be rebased to the recently released v6.5 (or if it may just skip past that to a v6.6-rc). You might be able to rebase successfully to v6.5 on your own, but I wouldn't be able to guarantee that there wouldn't be any conflicts during that process.

Using the upstream Linux v6.5 as a guest would be good, since that includes the support for unaccepted memory, speeding the boot times of larger memory guests.