Fix (+follow-up) needed for SEV-SNP vulnerability
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned | ||
Kinetic |
Fix Committed
|
Medium
|
Unassigned | ||
linux-gcp (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned |
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.
CVE References
no longer affects: | linux-gcp (Ubuntu) |
description: | updated |
no longer affects: | linux-oracle (Ubuntu) |
no longer affects: | linux-oracle (Ubuntu Jammy) |
no longer affects: | linux-oracle (Ubuntu Kinetic) |
no longer affects: | linux-oracle (Ubuntu Lunar) |
no longer affects: | linux-gcp (Ubuntu Kinetic) |
no longer affects: | linux-gcp (Ubuntu Lunar) |
no longer affects: | linux-gcp (Ubuntu Kinetic) |
no longer affects: | linux-gcp (Ubuntu Lunar) |
no longer affects: | linux (Ubuntu Lunar) |
Changed in linux (Ubuntu Kinetic): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Kinetic): | |
status: | New → Fix Committed |
Changed in linux-gcp (Ubuntu Jammy): | |
status: | New → Fix Committed |
tags: |
added: verification-done-jammy verification-done-kinetic removed: verification-needed-jammy verification-needed-kinetic |
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 2013198
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.