Google Confidential Compute fails to boot with shim version 1.47
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Khaled El Mously | ||
Hirsute |
Won't Fix
|
Undecided
|
Khaled El Mously | ||
linux-gcp (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
# Overview
Hirsute and Impish daily builds are currently not booting on Google Confidential Compute. Confidential compute is Google's platform that enables the use of Secure Encrypted Virtualization extension via AMD EPYC CPUs. Booting an image with version 1.45 works, but once upgraded to 1.47, the VM no longer boots, and instead the kernel panics.
Launching the image with secure boot, but without confidential compute works as expected.
# Expected result
The system is able to reboot after the upgrade.
# Actual result
Kernel panic: https:/
# Steps to reproduce
Launch a VM in GCE with confidential compute enabled with a serial v20210511a or later and look at the serial log for the kernel panic. Example CLI command to launch a VM:
$ gcloud beta compute instances create $USER-confident
The last known good working image is daily-ubuntu-
# Logs & notes
* 20210510 manifest (good): https:/
* 20210511a manifest (bad): https:/
* diff between manifests: https:/
* serial logs of failed boot: https:/
# Cause:
shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServi
Memory reserved for EFI runtime/boot services must be remapped as encrypted in the kernel (during boot) if SEV (secure encrypted virtualization) is enabled. The original kernel implementation of ioremap only correctly mapped the region as encrypted for EfiRuntimeServi
Note that this affects all 5.11 kernels not just gcp. It is possible that gcp is the only cloud that uses sev currently (for "Confidential Computing").
# Fix:
Both EfiRuntimeServi
# Test
Without the fix applied, confirmed that I was able to reproduce the issue described here (complete failure to boot, kernel panic)
With fix, confirmed no issues booting
# Regression potential
The fix could potentially cause boot failures, if a memory region is marked encrypted when it shouldn't be. I assume in that case it would cause a panic similar to the one seen here for this bug:
general protection fault, probably for non-canonical address 0x314836c31124d346: 0000 [#1] SMP NOPTI
CVE References
summary: |
- Google Confidnetial Compute fails to boot with 1.47 + Google Confidential Compute fails to boot with 1.47 |
description: | updated |
description: | updated |
description: | updated |
no longer affects: | linux-gcp (Ubuntu) |
no longer affects: | linux-gcp (Ubuntu Hirsute) |
Changed in linux (Ubuntu): | |
assignee: | nobody → Khaled El Mously (kmously) |
Changed in linux (Ubuntu Hirsute): | |
assignee: | nobody → Khaled El Mously (kmously) |
Changed in linux (Ubuntu): | |
status: | New → In Progress |
Changed in linux (Ubuntu Hirsute): | |
status: | New → In Progress |
description: | updated |
description: | updated |
description: | updated |
summary: |
- Google Confidential Compute fails to boot with 1.47 + Google Confidential Compute fails to boot with shim version 1.47 |
no longer affects: | linux-gcp (Ubuntu) |
no longer affects: | linux (Ubuntu Hirsute) |
Changed in linux (Ubuntu Hirsute): | |
status: | New → In Progress |
assignee: | nobody → Khaled El Mously (kmously) |
Changed in linux-gcp (Ubuntu Hirsute): | |
status: | New → Fix Released |
Changed in linux (Ubuntu Hirsute): | |
status: | In Progress → Fix Committed |
I think that this kernel needs a new fix that has been posted to KVM mailing list. The stack trace seems to match the report and the fix.
https:/ /www.spinics. net/lists/ kernel/ msg3968888. html