This issue was introduced in fce96cf04430 ("virt: Add SEV-SNP guest
driver") and thus affects 5.19 kernels and newer.-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2013198 Title: Fix (+follow-up) needed for SEV-SNP vulnerability Status in linux package in Ubuntu: Incomplete Status in linux-gcp package in Ubuntu: New Status in linux-gcp source package in Jammy: Fix Committed Status in linux source package in Kinetic: Fix Committed 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/+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
