Ubuntu 22.10 (Kinetic Kudu) has reached end of life, so this bug will
not be fixed for that specific release.
** Changed in: linux (Ubuntu Kinetic)
Status: Fix Committed => Won't Fix
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-gcp 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:
Fix Released
Status in linux-gcp source package in Jammy:
Fix Released
Status in linux source package in Kinetic:
Won't Fix
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
