[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
The Hirsute Hippo has reached End of Life, so this bug will not be fixed for that release. ** Changed in: linux (Ubuntu Hirsute) 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/1931254 Title: Google Confidential Compute fails to boot with shim version 1.47 Status in linux package in Ubuntu: Fix Released Status in linux-gcp package in Ubuntu: Fix Released Status in linux source package in Hirsute: Won't Fix Status in linux-gcp source package in Hirsute: Fix Released 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://paste.ubuntu.com/p/mHrvVc6qBc/ # 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-confidential-testing --zone=us-west1-b --machine-type=n2d-standard-2 --image=daily- ubuntu-2104-hirsute-v20210511a --image-project=ubuntu-os-cloud-devel --confidential-compute --maintenance-policy=TERMINATE The last known good working image is daily- ubuntu-2104-hirsute-v20210510. The upgrade that fails is when shim signed is updated from 1.46+15.4-0ubuntu1 to 1.47+15.4-0ubuntu2 # Logs & notes * 20210510 manifest (good): https://paste.ubuntu.com/p/QjnMPcJj7G/ * 20210511a manifest (bad): https://paste.ubuntu.com/p/PvJQwRXHcG/ * diff between manifests: https://paste.ubuntu.com/p/4nJtGxqGn7/ * serial logs of failed boot: https://paste.ubuntu.com/p/mHrvVc6qBc/ # Cause: shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServicesData to EfiBootServicesData. 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 EfiRuntimeServicesData regions, so when shim changed the type to EfiBootServicesData the kernel bug was exposed 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 EfiRuntimeServicesData and EfiBootServicesData must be mapped as encrypted if SEV is active, as per: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b # 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: [#1] SMP NOPTI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931254/+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
[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
This bug was fixed in the package linux-gcp - 5.11.0-1016.18+21.10.2 --- linux-gcp (5.11.0-1016.18+21.10.2) impish; urgency=medium * impish/linux-gcp: 5.11.0-1016.18+21.10.2 -proposed tracker (LP: #1936486) * Packaging resync (LP: #1786013) - update dkms package versions * Disable Bluetooth in cloud kernels (LP: #1840488) - [Config] gcp: Disable CONFIG_BT [ Ubuntu: 5.11.0-1016.18 ] * hirsute/linux-gcp: 5.11.0-1016.18 -proposed tracker (LP: #1938651) * Some cloud kernels have Android related config options disabled (LP: #1928686) - [config] gcp: Enable Android options for anbox * Disable Bluetooth in cloud kernels (LP: #1840488) - [config] gcp: Disable CONFIG_BT * Packaging resync (LP: #1786013) - update dkms package versions * large_dir in ext4 broken (LP: #1933074) - SAUCE: ext4: fix directory index node split corruption * Add l2tp.sh in net from ubuntu_kernel_selftests back (LP: #1934293) - Revert "UBUNTU: SAUCE: selftests/net -- disable l2tp.sh test" * icmp_redirect.sh in net from ubuntu_kernel_selftests failed on F-OEM-5.6 / F-OEM-5.10 / F-OEM-5.13 / F / G / H (LP: #1880645) - selftests: icmp_redirect: support expected failures * Mute/mic LEDs no function on some HP platfroms (LP: #1934878) - ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 450 G8 - ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 445 G8 - ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 630 G8 * [SRU][OEM-5.10/H] Fix HDMI output issue on Intel TGL GPU (LP: #1934864) - drm/i915: Fix HAS_LSPCON macro for platforms between GEN9 and GEN10 * mute/micmute LEDs no function on HP EliteBook 830 G8 Notebook PC (LP: #1934239) - ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook 830 G8 Notebook PC * ubuntu-host driver lacks lseek ops (LP: #1934110) - ubuntu-host: add generic lseek op * ubuntu_kernel_selftests ftrace fails on arm64 F / aws-5.8 / amd64 F azure-5.8 (LP: #1927749) - selftests/ftrace: fix event-no-pid on 1-core machine * Hirsute update: upstream stable patchset 2021-06-29 (LP: #1934012) - proc: Track /proc/$pid/attr/ opener mm_struct - ASoC: max98088: fix ni clock divider calculation - ASoC: amd: fix for pcm_read() error - spi: Fix spi device unregister flow - spi: spi-zynq-qspi: Fix stack violation bug - bpf: Forbid trampoline attach for functions with variable arguments - net/nfc/rawsock.c: fix a permission check bug - usb: cdns3: Fix runtime PM imbalance on error - ASoC: Intel: bytcr_rt5640: Add quirk for the Glavey TM800A550L tablet - ASoC: Intel: bytcr_rt5640: Add quirk for the Lenovo Miix 3-830 tablet - vfio-ccw: Reset FSM state to IDLE inside FSM - vfio-ccw: Serialize FSM IDLE state with I/O completion - ASoC: sti-sas: add missing MODULE_DEVICE_TABLE - spi: sprd: Add missing MODULE_DEVICE_TABLE - usb: chipidea: udc: assign interrupt number to USB gadget structure - isdn: mISDN: netjet: Fix crash in nj_probe: - bonding: init notify_work earlier to avoid uninitialized use - netlink: disable IRQs for netlink_lock_table() - net: mdiobus: get rid of a BUG_ON() - cgroup: disable controllers at parse time - wq: handle VM suspension in stall detection - net/qla3xxx: fix schedule while atomic in ql_sem_spinlock - RDS tcp loopback connection can hang - net:sfc: fix non-freed irq in legacy irq mode - scsi: bnx2fc: Return failure if io_req is already in ABTS processing - scsi: vmw_pvscsi: Set correct residual data length - scsi: hisi_sas: Drop free_irq() of devm_request_irq() allocated irq - scsi: target: qla2xxx: Wait for stop_phase1 at WWN removal - net: macb: ensure the device is available before accessing GEMGXL control registers - net: appletalk: cops: Fix data race in cops_probe1 - net: dsa: microchip: enable phy errata workaround on 9567 - nvme-fabrics: decode host pathing error for connect - MIPS: Fix kernel hang under FUNCTION_GRAPH_TRACER and PREEMPT_TRACER - dm verity: fix require_signatures module_param permissions - bnx2x: Fix missing error code in bnx2x_iov_init_one() - nvme-tcp: remove incorrect Kconfig dep in BLK_DEV_NVME - nvmet: fix false keep-alive timeout when a controller is torn down - powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P2041 i2c controllers - powerpc/fsl: set fsl,i2c-erratum-a004447 flag for P1010 i2c controllers - spi: Don't have controller clean up spi device before driver unbind - spi: Cleanup on failure of initial setup - i2c: mpc: Make use of i2c_recover_bus() - i2c: mpc: implement erratum A-004447 workaround - ALSA: seq: Fix race of snd_seq_timer_open() - ALSA: firewire-lib: fix the context to call snd_pcm_stop_xrun() - spi: bcm2835: Fix out-of-bounds access with more than 4 slaves - Revert "ACPI: sleep: Put the FACS table after using it" - drm:
[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
** Changed in: linux (Ubuntu Hirsute) Status: In Progress => Fix Committed -- 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/1931254 Title: Google Confidential Compute fails to boot with shim version 1.47 Status in linux package in Ubuntu: Fix Released Status in linux-gcp package in Ubuntu: Fix Committed Status in linux source package in Hirsute: Fix Committed Status in linux-gcp source package in Hirsute: Fix Released 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://paste.ubuntu.com/p/mHrvVc6qBc/ # 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-confidential-testing --zone=us-west1-b --machine-type=n2d-standard-2 --image=daily- ubuntu-2104-hirsute-v20210511a --image-project=ubuntu-os-cloud-devel --confidential-compute --maintenance-policy=TERMINATE The last known good working image is daily- ubuntu-2104-hirsute-v20210510. The upgrade that fails is when shim signed is updated from 1.46+15.4-0ubuntu1 to 1.47+15.4-0ubuntu2 # Logs & notes * 20210510 manifest (good): https://paste.ubuntu.com/p/QjnMPcJj7G/ * 20210511a manifest (bad): https://paste.ubuntu.com/p/PvJQwRXHcG/ * diff between manifests: https://paste.ubuntu.com/p/4nJtGxqGn7/ * serial logs of failed boot: https://paste.ubuntu.com/p/mHrvVc6qBc/ # Cause: shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServicesData to EfiBootServicesData. 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 EfiRuntimeServicesData regions, so when shim changed the type to EfiBootServicesData the kernel bug was exposed 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 EfiRuntimeServicesData and EfiBootServicesData must be mapped as encrypted if SEV is active, as per: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b # 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: [#1] SMP NOPTI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931254/+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
[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
This fix has already been released with impish/linux 5.13.0-11.1. Marking the task for the development kernel as fix released. ** Also affects: linux-gcp (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux-gcp (Ubuntu) ** Also affects: linux-gcp (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu Hirsute) ** Also affects: linux (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: linux-gcp (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Hirsute) Status: New => In Progress ** Changed in: linux (Ubuntu Hirsute) Assignee: (unassigned) => Khaled El Mously (kmously) ** Changed in: linux-gcp (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: linux (Ubuntu) Status: In Progress => Fix Released ** Changed in: linux-gcp (Ubuntu) Status: New => Fix Committed -- 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/1931254 Title: Google Confidential Compute fails to boot with shim version 1.47 Status in linux package in Ubuntu: Fix Released Status in linux-gcp package in Ubuntu: Fix Committed Status in linux source package in Hirsute: In Progress Status in linux-gcp source package in Hirsute: Fix Released 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://paste.ubuntu.com/p/mHrvVc6qBc/ # 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-confidential-testing --zone=us-west1-b --machine-type=n2d-standard-2 --image=daily- ubuntu-2104-hirsute-v20210511a --image-project=ubuntu-os-cloud-devel --confidential-compute --maintenance-policy=TERMINATE The last known good working image is daily- ubuntu-2104-hirsute-v20210510. The upgrade that fails is when shim signed is updated from 1.46+15.4-0ubuntu1 to 1.47+15.4-0ubuntu2 # Logs & notes * 20210510 manifest (good): https://paste.ubuntu.com/p/QjnMPcJj7G/ * 20210511a manifest (bad): https://paste.ubuntu.com/p/PvJQwRXHcG/ * diff between manifests: https://paste.ubuntu.com/p/4nJtGxqGn7/ * serial logs of failed boot: https://paste.ubuntu.com/p/mHrvVc6qBc/ # Cause: shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServicesData to EfiBootServicesData. 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 EfiRuntimeServicesData regions, so when shim changed the type to EfiBootServicesData the kernel bug was exposed 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 EfiRuntimeServicesData and EfiBootServicesData must be mapped as encrypted if SEV is active, as per: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b # 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: [#1] SMP NOPTI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931254/+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
[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
This fix has already been released with hirsute/linux-gcp 5.11.0-1015.17 which is currently in hirsute-updates. For the generic hirsute/linux kernel the fix will be applied for the next SRU cycle. -- 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/1931254 Title: Google Confidential Compute fails to boot with shim version 1.47 Status in linux package in Ubuntu: In Progress Status in linux source package in Hirsute: In Progress 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://paste.ubuntu.com/p/mHrvVc6qBc/ # 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-confidential-testing --zone=us-west1-b --machine-type=n2d-standard-2 --image=daily- ubuntu-2104-hirsute-v20210511a --image-project=ubuntu-os-cloud-devel --confidential-compute --maintenance-policy=TERMINATE The last known good working image is daily- ubuntu-2104-hirsute-v20210510. The upgrade that fails is when shim signed is updated from 1.46+15.4-0ubuntu1 to 1.47+15.4-0ubuntu2 # Logs & notes * 20210510 manifest (good): https://paste.ubuntu.com/p/QjnMPcJj7G/ * 20210511a manifest (bad): https://paste.ubuntu.com/p/PvJQwRXHcG/ * diff between manifests: https://paste.ubuntu.com/p/4nJtGxqGn7/ * serial logs of failed boot: https://paste.ubuntu.com/p/mHrvVc6qBc/ # Cause: shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServicesData to EfiBootServicesData. 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 EfiRuntimeServicesData regions, so when shim changed the type to EfiBootServicesData the kernel bug was exposed 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 EfiRuntimeServicesData and EfiBootServicesData must be mapped as encrypted if SEV is active, as per: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b # 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: [#1] SMP NOPTI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931254/+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
[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-focal -- 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/1931254 Title: Google Confidential Compute fails to boot with shim version 1.47 Status in linux package in Ubuntu: In Progress Status in linux source package in Hirsute: In Progress 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://paste.ubuntu.com/p/mHrvVc6qBc/ # 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-confidential-testing --zone=us-west1-b --machine-type=n2d-standard-2 --image=daily- ubuntu-2104-hirsute-v20210511a --image-project=ubuntu-os-cloud-devel --confidential-compute --maintenance-policy=TERMINATE The last known good working image is daily- ubuntu-2104-hirsute-v20210510. The upgrade that fails is when shim signed is updated from 1.46+15.4-0ubuntu1 to 1.47+15.4-0ubuntu2 # Logs & notes * 20210510 manifest (good): https://paste.ubuntu.com/p/QjnMPcJj7G/ * 20210511a manifest (bad): https://paste.ubuntu.com/p/PvJQwRXHcG/ * diff between manifests: https://paste.ubuntu.com/p/4nJtGxqGn7/ * serial logs of failed boot: https://paste.ubuntu.com/p/mHrvVc6qBc/ # Cause: shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServicesData to EfiBootServicesData. 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 EfiRuntimeServicesData regions, so when shim changed the type to EfiBootServicesData the kernel bug was exposed 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 EfiRuntimeServicesData and EfiBootServicesData must be mapped as encrypted if SEV is active, as per: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b # 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: [#1] SMP NOPTI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931254/+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
[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
Verification steps: 1. Enabled Confidential Compute 2. Change image to daily-ubuntu-2104-hirsute-v20210510 (last working image) 3. Launched image 4. Enabled proposed 5. Updated system https://paste.ubuntu.com/p/mNrZNkVYtB/ 6. Rebooted sucessfully! https://paste.ubuntu.com/p/G9CmvhW9tx/ Marking verification-done ** Tags removed: verification-needed-hirsute ** Tags added: verification-done-hirsute -- 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/1931254 Title: Google Confidential Compute fails to boot with shim version 1.47 Status in linux package in Ubuntu: In Progress Status in linux source package in Hirsute: In Progress 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://paste.ubuntu.com/p/mHrvVc6qBc/ # 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-confidential-testing --zone=us-west1-b --machine-type=n2d-standard-2 --image=daily- ubuntu-2104-hirsute-v20210511a --image-project=ubuntu-os-cloud-devel --confidential-compute --maintenance-policy=TERMINATE The last known good working image is daily- ubuntu-2104-hirsute-v20210510. The upgrade that fails is when shim signed is updated from 1.46+15.4-0ubuntu1 to 1.47+15.4-0ubuntu2 # Logs & notes * 20210510 manifest (good): https://paste.ubuntu.com/p/QjnMPcJj7G/ * 20210511a manifest (bad): https://paste.ubuntu.com/p/PvJQwRXHcG/ * diff between manifests: https://paste.ubuntu.com/p/4nJtGxqGn7/ * serial logs of failed boot: https://paste.ubuntu.com/p/mHrvVc6qBc/ # Cause: shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServicesData to EfiBootServicesData. 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 EfiRuntimeServicesData regions, so when shim changed the type to EfiBootServicesData the kernel bug was exposed 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 EfiRuntimeServicesData and EfiBootServicesData must be mapped as encrypted if SEV is active, as per: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b # 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: [#1] SMP NOPTI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931254/+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
[Kernel-packages] [Bug 1931254] Re: Google Confidential Compute fails to boot with shim version 1.47
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- hirsute' to 'verification-done-hirsute'. If the problem still exists, change the tag 'verification-needed-hirsute' to 'verification-failed- hirsute'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-hirsute -- 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/1931254 Title: Google Confidential Compute fails to boot with shim version 1.47 Status in linux package in Ubuntu: In Progress Status in linux source package in Hirsute: In Progress 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://paste.ubuntu.com/p/mHrvVc6qBc/ # 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-confidential-testing --zone=us-west1-b --machine-type=n2d-standard-2 --image=daily- ubuntu-2104-hirsute-v20210511a --image-project=ubuntu-os-cloud-devel --confidential-compute --maintenance-policy=TERMINATE The last known good working image is daily- ubuntu-2104-hirsute-v20210510. The upgrade that fails is when shim signed is updated from 1.46+15.4-0ubuntu1 to 1.47+15.4-0ubuntu2 # Logs & notes * 20210510 manifest (good): https://paste.ubuntu.com/p/QjnMPcJj7G/ * 20210511a manifest (bad): https://paste.ubuntu.com/p/PvJQwRXHcG/ * diff between manifests: https://paste.ubuntu.com/p/4nJtGxqGn7/ * serial logs of failed boot: https://paste.ubuntu.com/p/mHrvVc6qBc/ # Cause: shim changed the memory type for pages reserved for EFI runtime services, from EfiRuntimeServicesData to EfiBootServicesData. 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 EfiRuntimeServicesData regions, so when shim changed the type to EfiBootServicesData the kernel bug was exposed 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 EfiRuntimeServicesData and EfiBootServicesData must be mapped as encrypted if SEV is active, as per: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d651ee9c71bb12fc0c8eb2786b66cbe5aa3e43b # 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: [#1] SMP NOPTI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931254/+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
