[v2,0/5] Support kdump with LUKS encryption by reusing LUKS volume key

  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 key 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 key again in kdump kernel which seems to be
redundant work.

This patch set addresses the above issues by reusing the LUKS volume key
in 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 key,

 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 key and then save the volume key 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 the key description to
    /sys/kernel/crash_dm_crypt_key to inform the 1st kernel to save a
    temporary copy of the volume key while building the kdump initramfs

 3. The kexec_file_load syscall saves the temporary copy of the volume
    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 the key
    description to /sys/kernel/crash_dm_crypt_key. 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 key to specified keyring,
whoever takes this should be responsible for the safety of this copy
of key. This key 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.

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 (5):
  kexec_file: allow to place kexec_buf randomly
  crash_dump: save the dm crypt key temporarily
  crash_dump: retrieve dm crypt key in kdump kernel
  x86/crash: pass the dm crypt key to kdump kernel
  x86/crash: make the page that stores the dm crypt key inaccessible

 arch/x86/kernel/crash.c            |  15 +-
 arch/x86/kernel/kexec-bzimage64.c  |   7 +
 arch/x86/kernel/machine_kexec_64.c |  18 +++
 include/linux/crash_core.h         |   7 +-
 include/linux/crash_dump.h         |   2 +
 include/linux/kexec.h              |   6 +
 kernel/Makefile                    |   2 +-
 kernel/crash_dump_dm_crypt.c       | 234 +++++++++++++++++++++++++++++
 kernel/kexec_file.c                |  15 ++
 kernel/ksysfs.c                    |  23 ++-
 10 files changed, 324 insertions(+), 5 deletions(-)
 create mode 100644 kernel/crash_dump_dm_crypt.c
  

Hi Coiby,

I've started working on a patchset for systemd utility. I have one 
question/suggestion:

On 10/01/2024 08:15, 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 key 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 key again in kdump kernel which seems to be
> redundant work.
> 
> This patch set addresses the above issues by reusing the LUKS volume key
> in 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 key,
> 
>   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 key and then save the volume key 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 the key description to
>      /sys/kernel/crash_dm_crypt_key to inform the 1st kernel to save a
>      temporary copy of the volume key while building the kdump initramfs

So this volume key copy cached by systemd utility in 1st kernel does not 
have to be readable from userspace.

> 
>   3. The kexec_file_load syscall saves the temporary copy of the volume
>      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 the key
>      description to /sys/kernel/crash_dm_crypt_key. Then the LUKS
>      encrypted devide is unlocked with libcryptsetup's
>      --volume-key-keyring API.

Unlike here where it has to readable from uspace so that libcryptsetup 
can verify the volume key.

Is it correct?
O.

> 
>   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 key to specified keyring,
> whoever takes this should be responsible for the safety of this copy
> of key. This key 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.
>
  

On Tue, Jan 16, 2024 at 11:37:10AM +0100, Ondrej Kozina wrote:
>Hi Coiby,

Hi Ondrej,

>
>I've started working on a patchset for systemd utility. I have one 
>question/suggestion:
>
>On 10/01/2024 08:15, 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 key 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 key again in kdump kernel which seems to be
>>redundant work.
>>
>>This patch set addresses the above issues by reusing the LUKS volume key
>>in 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 key,
>>
>>  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 key and then save the volume key 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 the key description to
>>     /sys/kernel/crash_dm_crypt_key to inform the 1st kernel to save a
>>     temporary copy of the volume key while building the kdump initramfs
>
>So this volume key copy cached by systemd utility in 1st kernel does 
>not have to be readable from userspace.
>
>>
>>  3. The kexec_file_load syscall saves the temporary copy of the volume
>>     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 the key
>>     description to /sys/kernel/crash_dm_crypt_key. Then the LUKS
>>     encrypted devide is unlocked with libcryptsetup's
>>     --volume-key-keyring API.
>
>Unlike here where it has to readable from uspace so that libcryptsetup 
>can verify the volume key.
>
>Is it correct?
>O.

Oh, my assumed --link-vk-to-keyring only support user key which must be
wrong. So yes, you are absolutely correct that "volume key copy cached
by systemd utility in 1st kernel does not have to be readable from
userspace". Thanks for the suggestion!