You have been subscribed to a public bug: Kdump log
---Problem Description--- The expectation for Secure Execution is that users encrypt their root device as part of the setup process. However, Kdumping on an Ubuntu 20.04 guest with an encrypted root partition drops user to initramfs console. When attempted on a non-secure, but encrypted guest, results came out to be the same. ---uname output--- Linux T257KVX 5.4.0-21-generic #25-Ubuntu SMP Sat Mar 28 13:10:00 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = Type: 8562 Model: A00, LT2 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Create a guest with an encrypted root partition. Encryption was done using the process available within the install. virt-install --name ali-kdump-enc --vcpu 2 --memory 4096 --disk size=8,path=/guestimages/ali-kdump-enc.qcow2,driver.iommu=on --network network=default,model=virtio,driver.iommu=on --controller type=virtio- serial,driver.iommu=on --controller type=scsi,driver.iommu=on --memballoon none --boot hd --cdrom http://cdimage.ubuntu.com/ubuntu- server/daily-live/current/focal-live-server-s390x.iso 2. Install linux-crashdump apt install linux-crashdump 3. Proceed through to converting the guest into a secure one, taking extra steps to make the crashkernel large enough to accommodate the swiotlb (I used 1G) sudo genprotimg -r /boot/initrd.img -p parmfile -i /boot/vmlinuz --no-verify -o /boot/secure-linux -V -k T257.crt 4. zipl and reboot into the now secured guest 5. Verify that kdump is ready - kdump-config show - kdump-config status - cat /sys/kernel/kexec_crash_size 6. Trigger a dump sudo sysctl -w kernel.sysrq=1 echo c > /proc/sysrq-trigger However, when this happens, I get the results presented in the kdump- sec-enc.log file. I suspected it was due to the root partition being encrypted and expecting a password on startup (as this happened on an encrypted, non- secure guest, but not on their non-encrypted counterparts), so I attempted to setup a keyfile on a new guest that I created before the installation of linux-crashdump, and conversion into a secure guest using the following set of steps. 1. Create the key file in the unencrypted /boot partition # dd if=/dev/urandom of=/boot/keyfile bs=1024 count=4 2. Set permissions # chmod 0400 /boot/keyfile 3. Add the new file as unlock key to the encrypted volume # cryptsetup -v luksAddKey /dev/vda2 /boot/keyfile Enter any passphrase: Enter your old/existing passphrase here. Expected output: Key slot 0 unlocked. Command successful. 4. Update /etc/crypttab with the line: vda2_crypt UUID=684af433-487f-4c81-b310-81338a49588d /boot/keyfile luks 5. Update /etc/cryptsetup-initramfs/conf-hook to allow enable your keyfile at boot, e.g.: KEYFILE_PATTERN=/boot/keyfile 6. Update initramfs with the following: update-initramfs -u This will bypass the request for a password on boot, however, I still ran into the same errors presented in the log file (kdump-sec-enc.log). -Post a private note with access information to the machine that the bug is occuring on. Guest Log Guest's qemu log file The kernel version for the guest that this was executed on is as follows: xxxxx-kdump-sec-enc:~$ uname -r 5.4.0-26-generic The host is slightly behind, but the bug takes place in context of the guest's starting and stopping Canonical, please advice on how to enable dumping onto an encrypted volume to maintain confidentiality. ** Affects: linux (Ubuntu) Importance: Undecided Assignee: Skipper Bug Screeners (skipper-screen-team) Status: New ** Tags: architecture-s39064 bugnameltc-185637 severity-medium targetmilestone-inin2004 -- Kdumping on an Ubuntu 20.04 guest with an encrypted root partition drops user to initramfs console https://bugs.launchpad.net/bugs/1875826 You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. -- 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
