Message-ID: <26jkoqavu54xo4ctbpxfibhdlbc5kezu2kkyl5fbb7r6oizvo4@cmq5yaeszfqq>
Date: Sat, 8 Jun 2024 09:26:43 +0800
From: Coiby Xu <coxu@...hat.com>
To: kexec@...ts.infradead.org
Cc: Ondrej Kozina <okozina@...hat.com>, Milan Broz <gmazyland@...il.com>, 
	Thomas Staudt <tstaudt@...ibm.com>, Daniel P . Berrangé <berrange@...hat.com>, 
	Kairui Song <ryncsn@...il.com>, Jan Pazdziora <jpazdziora@...hat.com>, 
	Pingfan Liu <kernelfans@...il.com>, Baoquan He <bhe@...hat.com>, Dave Young <dyoung@...hat.com>, 
	linux-kernel@...r.kernel.org, x86@...nel.org, Dave Hansen <dave.hansen@...el.com>, 
	Vitaly Kuznetsov <vkuznets@...hat.com>, Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v4 0/7] Support kdump with LUKS encryption by reusing
 LUKS volume keys

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

Powered by blists - more mailing lists