Re: [PATCH v4 0/7] Support kdump with LUKS encryption by reusing LUKS volume keys

[Coiby Xu]

The subject prefix should be "[PATCH v5 0/7]". I'm sorry if it causes
any confusion.

On Fri, Jun 07, 2024 at 08:26:10PM +0800, Coiby Xu wrote:
> LUKS is the standard for Linux disk encryption. Many users choose LUKS
> and in some use cases like Confidential VM it's mandated. With kdump
> enabled, when the 1st kernel crashes, the system could boot into the
> kdump/crash kernel and dump the memory image i.e. /proc/vmcore to a
> specified target. Currently, when dumping vmcore to a LUKS
> encrypted device, there are two problems,
>
> - Kdump kernel may not be able to decrypt the LUKS partition. For some
>   machines, a system administrator may not have a chance to enter the
>   password to decrypt the device in kdump initramfs after the 1st kernel
>   crashes; For cloud confidential VMs, depending on the policy the
>   kdump kernel may not be able to unseal the keys with TPM and the
>   console virtual keyboard is untrusted.
>
> - LUKS2 by default use the memory-hard Argon2 key derivation function
>   which is quite memory-consuming compared to the limited memory reserved
>   for kdump. Take Fedora example, by default, only 256M is reserved for
>   systems having memory between 4G-64G. With LUKS enabled, ~1300M needs
>   to be reserved for kdump. Note if the memory reserved for kdump can't
>   be used by 1st kernel i.e. an user sees ~1300M memory missing in the
>   1st kernel.
>
> Besides users (at least for Fedora) usually expect kdump to work out of
> the box i.e. no manual password input is needed. And it doesn't make
> sense to derivate the keys again in kdump kernel which seems to be
> redundant work.
>
> This patch set addresses the above issues by make the LUKS volume keys
> persistent for kdump kernel with the help of cryptsetup's new APIs
> (--link-vk-to-keyring/--volume-key-keyring). Here is the life cycle of
> this kdump copy of LUKS volume keys,
>
> 1. After the 1st kernel loads the initramfs during boot, systemd
>    use an user-input passphrase or TPM-sealed key to de-crypt the LUKS
>    volume keys and then save the volume keys to specified keyring
>    (using the --link-vk-to-keyring API) and the key will expire within
>    specified time.
>
> 2. A user space tool (kdump initramfs builder) writes a key description to
>    /sys/kernel/crash_dm_crypt_keys to inform the 1st kernel to record the
>    key while building the kdump initramfs
>
> 3. The kexec_file_load syscall read the volume keys by recorded key
>    descriptions and then save them key to kdump reserved memory and wipe the
>    copy.
>
> 4. When the 1st kernel crashes and the kdump initramfs is booted, the kdump
>    initramfs asks the kdump kernel to create a user key using the key stored in
>    kdump reserved memory by writing to to /sys/kernel/crash_dm_crypt_keys. Then
>    the LUKS encrypted devide is unlocked with libcryptsetup's
>    --volume-key-keyring API.
>
> 5. The system gets rebooted to the 1st kernel after dumping vmcore to
>    the LUKS encrypted device is finished
>
> After libcryptsetup saving the LUKS volume keys to specified keyring,
> whoever takes this should be responsible for the safety of these copies
> of keys. The keys will be saved in the memory area exclusively reserved
> for kdump where even the 1st kernel has no direct access. And further
> more, two additional protections are added,
> - save the copy randomly in kdump reserved memory as suggested by Jan
> - clear the _PAGE_PRESENT flag of the page that stores the copy as
>   suggested by Pingfan
>
> This patch set only supports x86. There will be patches to support other
> architectures once this patch set gets merged.
>
> v5
> - Baoquan
>   - limit the feature of placing kexec_buf randomly to kdump (CONFIG_CRASH_DUMP)
>   - add documentation for added sysfs API
>   - allow to re-send init command to support the case of user switching to
>     a different LUKS-encrypted target
>   - make CONFIG_CRASH_DM_CRYPT depends on CONFIG_DM_CRYPT
>   - check if the number of keys exceed KEY_NUM_MAX
>   - rename (struct keys_header).key_count as (struct
>     keys_header).total_keys to improve code readiblity
>   - improve commit message
>   - fix the failure of calling crash_exclude_mem_range (there is a split
>     of mem_range)
>   - use ret instead of r as return code
>
> - Greg
>   - add documentation for added sysfs API
>   - avoid spamming kernel logs
>   - fix a buffer overflow issue
>   - keep the state enums synced up with the string values
>   - use sysfs_emit other than sprintf
>   - explain KEY_NUM_MAX and KEY_SIZE_MAX
>   - s/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g
>   - improve code readability
>
> - Rebase onto latest Linus tree
>
>
> v4
> - rebase onto latest Linus tree so Baoquan can apply the patches for
>  code review
> - fix kernel test robot warnings
>
> v3
> - Support CPU/memory hot-plugging [Baoquan]
> - Don't save the keys temporarily to simplify the implementation [Baoquan]
> - Support multiple LUKS encrypted volumes
> - Read logon key instead of user key to improve security [Ondrej]
> - A kernel config option CRASH_DM_CRYPT for this feature (disabled by default)
> - Fix warnings found by kernel test robot
> - Rebase the code onto 6.9.0-rc5+
>
> v2
> - work together with libscryptsetup's --link-vk-to-keyring/--volume-key-keyring APIs [Milan and Ondrej]
> - add the case where console virtual keyboard is untrusted for confidential VM
> - use dm_crypt_key instead of LUKS volume key [Milan and Eric]
> - fix some code format issues
> - don't move "struct kexec_segment" declaration
> - Rebase the code onto latest Linus tree (6.7.0)
>
> v1
> - "Put the luks key handling related to crash_dump out into a separate
>   file kernel/crash_dump_luks.c" [Baoquan]
> - Put the generic luks handling code before the x86 specific code to
>   make it easier for other arches to follow suit [Baoquan]
> - Use phys_to_virt instead of "pfn -> page -> vaddr" [Dave Hansen]
> - Drop the RFC prefix [Dave Young]
> - Rebase the code onto latest Linus tree (6.4.0-rc4)
>
> RFC v2
> - libcryptsetup interacts with the kernel via sysfs instead of "hacking"
>   dm-crypt
>   - to save a kdump copy of the LUKS volume key in 1st kernel
>   - to add a logon key using the copy for libcryptsetup in kdump kernel [Milan]
>   - to avoid the incorrect usage of LUKS master key in dm-crypt [Milan]
> - save the kdump copy of LUKS volume key randomly [Jan]
> - mark the kdump copy inaccessible [Pingfan]
> - Miscellaneous
>   - explain when operations related to the LUKS volume key happen [Jan]
>   - s/master key/volume key/g
>   - use crash_ instead of kexec_ as function prefix
>   - fix commit subject prefixes e.g. "x86, kdump" to x86/crash
>
> Coiby Xu (7):
>  kexec_file: allow to place kexec_buf randomly
>  crash_dump: make dm crypt keys persist for the kdump kernel
>  crash_dump: store dm crypt keys in kdump reserved memory
>  crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging
>  crash_dump: retrieve dm crypt keys in kdump kernel
>  x86/crash: pass dm crypt keys to kdump kernel
>  x86/crash: make the page that stores the dm crypt keys inaccessible
>
> Documentation/ABI/testing/crash_dm_crypt_keys |  35 ++
> arch/x86/kernel/crash.c                       |  20 +-
> arch/x86/kernel/kexec-bzimage64.c             |   7 +
> arch/x86/kernel/machine_kexec_64.c            |  22 ++
> include/linux/crash_core.h                    |   9 +-
> include/linux/crash_dump.h                    |   2 +
> include/linux/kexec.h                         |   8 +
> kernel/Kconfig.kexec                          |   9 +
> kernel/Makefile                               |   1 +
> kernel/crash_dump_dm_crypt.c                  | 338 ++++++++++++++++++
> kernel/kexec_file.c                           |  21 ++
> kernel/ksysfs.c                               |  24 ++
> 12 files changed, 493 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/ABI/testing/crash_dm_crypt_keys
> create mode 100644 kernel/crash_dump_dm_crypt.c
>
>
> base-commit: 8a92980606e3585d72d510a03b59906e96755b8a
> --
> 2.45.1

--
Best regards,
Coiby