** Description changed: - See email about SEV-SNP guest attestation + From email discussions with Dionna Glazee from Google: + + + > This email details a critical vulnerability in SEV-SNP attestation + > report integrity protection that must be patched in SEV-SNP-enabled + > kernels. + > + > I'm reaching out since I've been tracking our progress towards a + > stable offering of customer access to SEV-SNP "guest requests". I'd + > like to know how or if y'all test the /dev/sev-guest driver. + > + > The reason I ask is because our host KVM injects failures into the + > guest if requests come too frequently. Test suites that request + > attestation reports in quick succession will fail without very recent + > patches or workaround code in user space. + > + > Technical details, tl;dr + > * Nov 21, 2022: Linux Kernel 6.1 included a security patch 47894e0fa + > that will cause attestation to fail frequently (in GCE). Peter found + > and patched this vulnerability. + > + > Details of security patch 47894e0fa: + > This patch to sev-guest causes more fail-closed situations. All VMM + > errors other than INVALID_LEN will wipe out the VMPCK and close the + > guest's ability to communicate with the security processor. + > Ratelimit failures will also cause a fail-closed situation. + > + > As you may know, guest requests are encrypted by the guest with + > AES_GCM (not AES_GCM_SIV) and then passed through unencrypted memory + > to the host's KVM. KVM forwards that to the crypto/ccp driver to + > deliver to the AMD secure processor to respond to. When the VMM + > returns an error instead of forwarding a request to the secure + > processor, then the guest driver *does not* increment its IV. It can + > therefore reuse an IV on multiple messages with different contents. + > This breaks AES_GCM's security guarantees. + > + > Ratelimiting looks to the guest not as a stalled vCPU, but rather a + > special error response that AMD will include in their next published + > version of the GHCB protocol (I believe v2.02). This allows the guest + > VM to schedule other threads and remain productive while waiting up to + > 2 seconds for a request to be serviced. The special error code to an + > unpatched kernel is just forwarded to the guest as an EIO. User space + > may continue to issue requests, even if it is unsafe to do so.
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/2013198 Title: Fix (+follow-up) needed for SEV-SNP vulnerability Status in linux-oracle package in Ubuntu: New Status in linux-oracle source package in Jammy: New Status in linux-oracle source package in Kinetic: New Status in linux-oracle source package in Lunar: New Bug description: From email discussions with Dionna Glazee from Google: > This email details a critical vulnerability in SEV-SNP attestation > report integrity protection that must be patched in SEV-SNP-enabled > kernels. > > I'm reaching out since I've been tracking our progress towards a > stable offering of customer access to SEV-SNP "guest requests". I'd > like to know how or if y'all test the /dev/sev-guest driver. > > The reason I ask is because our host KVM injects failures into the > guest if requests come too frequently. Test suites that request > attestation reports in quick succession will fail without very recent > patches or workaround code in user space. > > Technical details, tl;dr > * Nov 21, 2022: Linux Kernel 6.1 included a security patch 47894e0fa > that will cause attestation to fail frequently (in GCE). Peter found > and patched this vulnerability. > > Details of security patch 47894e0fa: > This patch to sev-guest causes more fail-closed situations. All VMM > errors other than INVALID_LEN will wipe out the VMPCK and close the > guest's ability to communicate with the security processor. > Ratelimit failures will also cause a fail-closed situation. > > As you may know, guest requests are encrypted by the guest with > AES_GCM (not AES_GCM_SIV) and then passed through unencrypted memory > to the host's KVM. KVM forwards that to the crypto/ccp driver to > deliver to the AMD secure processor to respond to. When the VMM > returns an error instead of forwarding a request to the secure > processor, then the guest driver *does not* increment its IV. It can > therefore reuse an IV on multiple messages with different contents. > This breaks AES_GCM's security guarantees. > > Ratelimiting looks to the guest not as a stalled vCPU, but rather a > special error response that AMD will include in their next published > version of the GHCB protocol (I believe v2.02). This allows the guest > VM to schedule other threads and remain productive while waiting up to > 2 seconds for a request to be serviced. The special error code to an > unpatched kernel is just forwarded to the guest as an EIO. User space > may continue to issue requests, even if it is unsafe to do so. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/2013198/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
