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.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
--
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:
New
Status in linux source package in Kinetic:
New
Status in linux 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/+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
