All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Coiby Xu <coxu@redhat.com>
Cc: kexec@lists.infradead.org, "Ondrej Kozina" <okozina@redhat.com>,
	"Milan Broz" <gmazyland@gmail.com>,
	"Thomas Staudt" <tstaudt@de.ibm.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Kairui Song" <ryncsn@gmail.com>,
	"Jan Pazdziora" <jpazdziora@redhat.com>,
	"Pingfan Liu" <kernelfans@gmail.com>,
	"Baoquan He" <bhe@redhat.com>, "Dave Young" <dyoung@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"Vivek Goyal" <vgoyal@redhat.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	"open list:KERNEL HARDENING (not covered by other
	areas):Keyword:b__counted_byb" <linux-hardening@vger.kernel.org>
Subject: Re: [PATCH v4 2/7] crash_dump: make dm crypt keys persist for the kdump kernel
Date: Thu, 23 May 2024 09:21:08 +0200	[thread overview]
Message-ID: <2024052334-protegee-cheating-5934@gregkh> (raw)
In-Reply-To: <20240523050451.788754-3-coxu@redhat.com>

On Thu, May 23, 2024 at 01:04:43PM +0800, Coiby Xu wrote:
> A sysfs /sys/kernel/crash_dm_crypt_keys is provided for user space to make
> the dm crypt keys persist for the kdump kernel. User space can send the
> following commands,
> - "init KEY_NUM"
>   Initialize needed structures
> - "record KEY_DESC"
>   Record a key description. The key must be a logon key.

"logon"?  What is that?

> 
> User space can also read this API to learn about current state.

But you don't document it in Documentation/ABI/ so we don't know if this
really is the case, and no one will know how to use it :(

> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
>  include/linux/crash_core.h   |   5 +-
>  kernel/Kconfig.kexec         |   8 +++
>  kernel/Makefile              |   1 +
>  kernel/crash_dump_dm_crypt.c | 113 +++++++++++++++++++++++++++++++++++
>  kernel/ksysfs.c              |  22 +++++++
>  5 files changed, 148 insertions(+), 1 deletion(-)
>  create mode 100644 kernel/crash_dump_dm_crypt.c
> 
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 44305336314e..6bff1c24efa3 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -34,7 +34,10 @@ static inline void arch_kexec_protect_crashkres(void) { }
>  static inline void arch_kexec_unprotect_crashkres(void) { }
>  #endif
>  
> -
> +#ifdef CONFIG_CRASH_DM_CRYPT
> +int crash_sysfs_dm_crypt_keys_read(char *buf);
> +int crash_sysfs_dm_crypt_keys_write(const char *buf, size_t count);
> +#endif
>  
>  #ifndef arch_crash_handle_hotplug_event
>  static inline void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { }
> diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
> index 6c34e63c88ff..88525ad1c80a 100644
> --- a/kernel/Kconfig.kexec
> +++ b/kernel/Kconfig.kexec
> @@ -116,6 +116,14 @@ config CRASH_DUMP
>  	  For s390, this option also enables zfcpdump.
>  	  See also <file:Documentation/arch/s390/zfcpdump.rst>
>  
> +config CRASH_DM_CRYPT
> +	bool "Support saving crash dump to dm-crypt encrypted volume"
> +	depends on CRASH_DUMP
> +	help
> +	  With this option enabled, user space can intereact with
> +	  /sys/kernel/crash_dm_crypt_keys to make the dm crypt keys
> +	  persistent for the crash dump kernel.
> +
>  config CRASH_HOTPLUG
>  	bool "Update the crash elfcorehdr on system configuration changes"
>  	default y
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 3c13240dfc9f..f2e5b3e86d12 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_VMCORE_INFO) += vmcore_info.o elfcorehdr.o
>  obj-$(CONFIG_CRASH_RESERVE) += crash_reserve.o
>  obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
>  obj-$(CONFIG_CRASH_DUMP) += crash_core.o
> +obj-$(CONFIG_CRASH_DM_CRYPT) += crash_dump_dm_crypt.o
>  obj-$(CONFIG_KEXEC) += kexec.o
>  obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
>  obj-$(CONFIG_KEXEC_ELF) += kexec_elf.o
> diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c
> new file mode 100644
> index 000000000000..78809189084a
> --- /dev/null
> +++ b/kernel/crash_dump_dm_crypt.c
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <keys/user-type.h>
> +#include <linux/crash_dump.h>
> +
> +#define KEY_NUM_MAX 128
> +#define KEY_SIZE_MAX 256

Why these values?

> +
> +// The key scription has the format: cryptsetup:UUID 11+36+1(NULL)=48
> +#define KEY_DESC_LEN 48
> +
> +static char *STATE_STR[] = {"fresh", "initialized", "recorded", "loaded"};
> +static enum STATE_ENUM {
> +	FRESH = 0,
> +	INITIALIZED,
> +	RECORDED,
> +	LOADED,
> +} state;

How are you going to keep these enums synced up with the string values?

> +
> +static unsigned int key_count;
> +static size_t keys_header_size;
> +
> +struct dm_crypt_key {
> +	unsigned int key_size;
> +	char key_desc[KEY_DESC_LEN];
> +	u8 data[KEY_SIZE_MAX];
> +};
> +
> +static struct keys_header {
> +	unsigned int key_count;
> +	struct dm_crypt_key keys[] __counted_by(key_count);
> +} *keys_header;
> +
> +static size_t get_keys_header_size(struct keys_header *keys_header,
> +				   size_t key_count)
> +{
> +	return struct_size(keys_header, keys, key_count);
> +}
> +
> +static int init(const char *buf)
> +{
> +	unsigned int total_keys;
> +	char dummy[5];

Why 5?

> +
> +	if (sscanf(buf, "%4s %u", dummy, &total_keys) != 2)

Didn't you just overflow dummy now?

> +		return -EINVAL;
> +
> +	if (key_count > KEY_NUM_MAX) {
> +		pr_err("Exceed the maximum number of keys (KEY_NUM_MAX=%u)\n",
> +		       KEY_NUM_MAX);

Do not let userspace spam the kernel log directly if it sends it invalid
data.

> +		return -EINVAL;
> +	}
> +
> +	keys_header_size = get_keys_header_size(keys_header, total_keys);
> +	key_count = 0;
> +
> +	keys_header = kzalloc(keys_header_size, GFP_KERNEL);
> +	if (!keys_header)
> +		return -ENOMEM;
> +
> +	keys_header->key_count = total_keys;
> +	state = INITIALIZED;
> +	return 0;
> +}
> +
> +static int record_key_desc(const char *buf, struct dm_crypt_key *dm_key)
> +{
> +	char key_desc[KEY_DESC_LEN];
> +	char dummy[7];
> +
> +	if (state != INITIALIZED)
> +		pr_err("Please send the cmd 'init <KEY_NUM>' first\n");

Again, don't let userspace spam the log.

> +
> +	if (sscanf(buf, "%6s %s", dummy, key_desc) != 2)
> +		return -EINVAL;
> +
> +	if (key_count >= keys_header->key_count) {
> +		pr_warn("Already have %u keys", key_count);
> +		return -EINVAL;
> +	}
> +
> +	strscpy(dm_key->key_desc, key_desc, KEY_DESC_LEN);
> +	pr_debug("Key%d (%s) recorded\n", key_count, dm_key->key_desc);
> +	key_count++;
> +
> +	if (key_count == keys_header->key_count)
> +		state = RECORDED;
> +
> +	return 0;
> +}
> +
> +static int process_cmd(const char *buf, size_t count)
> +{
> +	if (strncmp(buf, "init ", 5) == 0)
> +		return init(buf);
> +	else if (strncmp(buf, "record ", 7) == 0)
> +		return record_key_desc(buf, &keys_header->keys[key_count]);
> +
> +	return -EINVAL;
> +}
> +
> +int crash_sysfs_dm_crypt_keys_write(const char *buf, size_t count)
> +{
> +	if (!is_kdump_kernel())
> +		return process_cmd(buf, count);
> +	return -EINVAL;
> +}
> +EXPORT_SYMBOL(crash_sysfs_dm_crypt_keys_write);

EXPORT_SYMBOL_GPL() as you are dealing with a sysfs api?


> +
> +int crash_sysfs_dm_crypt_keys_read(char *buf)
> +{
> +	return sprintf(buf, "%s\n", STATE_STR[state]);

sysfs_emit() please.

> +}
> +EXPORT_SYMBOL(crash_sysfs_dm_crypt_keys_read);

Again, EXPORT_SYMBOL_GPL()?

> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 07fb5987b42b..2ba4dcbf5816 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -167,6 +167,25 @@ static ssize_t vmcoreinfo_show(struct kobject *kobj,
>  }
>  KERNEL_ATTR_RO(vmcoreinfo);
>  
> +#ifdef CONFIG_CRASH_DM_CRYPT
> +static ssize_t crash_dm_crypt_keys_show(struct kobject *kobj,
> +					struct kobj_attribute *attr, char *buf)
> +{
> +	return crash_sysfs_dm_crypt_keys_read(buf);
> +}
> +
> +static ssize_t crash_dm_crypt_keys_store(struct kobject *kobj,
> +					 struct kobj_attribute *attr,
> +					 const char *buf, size_t count)
> +{
> +	int ret;
> +
> +	ret = crash_sysfs_dm_crypt_keys_write(buf, count);
> +	return ret < 0 ? ret : count;

Personally, I hate ? : lines, just write it out, the compiler is the
same and this way it is much more readable:
	if (ret < 0)
		return ret;
	return count;

thanks,

greg k-h

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Coiby Xu <coxu@redhat.com>
Cc: kexec@lists.infradead.org, "Ondrej Kozina" <okozina@redhat.com>,
	"Milan Broz" <gmazyland@gmail.com>,
	"Thomas Staudt" <tstaudt@de.ibm.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Kairui Song" <ryncsn@gmail.com>,
	"Jan Pazdziora" <jpazdziora@redhat.com>,
	"Pingfan Liu" <kernelfans@gmail.com>,
	"Baoquan He" <bhe@redhat.com>, "Dave Young" <dyoung@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"Vivek Goyal" <vgoyal@redhat.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	"open list:KERNEL HARDENING (not covered by other
	areas):Keyword:b__counted_byb" <linux-hardening@vger.kernel.org>
Subject: Re: [PATCH v4 2/7] crash_dump: make dm crypt keys persist for the kdump kernel
Date: Thu, 23 May 2024 09:21:08 +0200	[thread overview]
Message-ID: <2024052334-protegee-cheating-5934@gregkh> (raw)
In-Reply-To: <20240523050451.788754-3-coxu@redhat.com>

On Thu, May 23, 2024 at 01:04:43PM +0800, Coiby Xu wrote:
> A sysfs /sys/kernel/crash_dm_crypt_keys is provided for user space to make
> the dm crypt keys persist for the kdump kernel. User space can send the
> following commands,
> - "init KEY_NUM"
>   Initialize needed structures
> - "record KEY_DESC"
>   Record a key description. The key must be a logon key.

"logon"?  What is that?

> 
> User space can also read this API to learn about current state.

But you don't document it in Documentation/ABI/ so we don't know if this
really is the case, and no one will know how to use it :(

> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
>  include/linux/crash_core.h   |   5 +-
>  kernel/Kconfig.kexec         |   8 +++
>  kernel/Makefile              |   1 +
>  kernel/crash_dump_dm_crypt.c | 113 +++++++++++++++++++++++++++++++++++
>  kernel/ksysfs.c              |  22 +++++++
>  5 files changed, 148 insertions(+), 1 deletion(-)
>  create mode 100644 kernel/crash_dump_dm_crypt.c
> 
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 44305336314e..6bff1c24efa3 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -34,7 +34,10 @@ static inline void arch_kexec_protect_crashkres(void) { }
>  static inline void arch_kexec_unprotect_crashkres(void) { }
>  #endif
>  
> -
> +#ifdef CONFIG_CRASH_DM_CRYPT
> +int crash_sysfs_dm_crypt_keys_read(char *buf);
> +int crash_sysfs_dm_crypt_keys_write(const char *buf, size_t count);
> +#endif
>  
>  #ifndef arch_crash_handle_hotplug_event
>  static inline void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { }
> diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
> index 6c34e63c88ff..88525ad1c80a 100644
> --- a/kernel/Kconfig.kexec
> +++ b/kernel/Kconfig.kexec
> @@ -116,6 +116,14 @@ config CRASH_DUMP
>  	  For s390, this option also enables zfcpdump.
>  	  See also <file:Documentation/arch/s390/zfcpdump.rst>
>  
> +config CRASH_DM_CRYPT
> +	bool "Support saving crash dump to dm-crypt encrypted volume"
> +	depends on CRASH_DUMP
> +	help
> +	  With this option enabled, user space can intereact with
> +	  /sys/kernel/crash_dm_crypt_keys to make the dm crypt keys
> +	  persistent for the crash dump kernel.
> +
>  config CRASH_HOTPLUG
>  	bool "Update the crash elfcorehdr on system configuration changes"
>  	default y
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 3c13240dfc9f..f2e5b3e86d12 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_VMCORE_INFO) += vmcore_info.o elfcorehdr.o
>  obj-$(CONFIG_CRASH_RESERVE) += crash_reserve.o
>  obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
>  obj-$(CONFIG_CRASH_DUMP) += crash_core.o
> +obj-$(CONFIG_CRASH_DM_CRYPT) += crash_dump_dm_crypt.o
>  obj-$(CONFIG_KEXEC) += kexec.o
>  obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
>  obj-$(CONFIG_KEXEC_ELF) += kexec_elf.o
> diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c
> new file mode 100644
> index 000000000000..78809189084a
> --- /dev/null
> +++ b/kernel/crash_dump_dm_crypt.c
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <keys/user-type.h>
> +#include <linux/crash_dump.h>
> +
> +#define KEY_NUM_MAX 128
> +#define KEY_SIZE_MAX 256

Why these values?

> +
> +// The key scription has the format: cryptsetup:UUID 11+36+1(NULL)=48
> +#define KEY_DESC_LEN 48
> +
> +static char *STATE_STR[] = {"fresh", "initialized", "recorded", "loaded"};
> +static enum STATE_ENUM {
> +	FRESH = 0,
> +	INITIALIZED,
> +	RECORDED,
> +	LOADED,
> +} state;

How are you going to keep these enums synced up with the string values?

> +
> +static unsigned int key_count;
> +static size_t keys_header_size;
> +
> +struct dm_crypt_key {
> +	unsigned int key_size;
> +	char key_desc[KEY_DESC_LEN];
> +	u8 data[KEY_SIZE_MAX];
> +};
> +
> +static struct keys_header {
> +	unsigned int key_count;
> +	struct dm_crypt_key keys[] __counted_by(key_count);
> +} *keys_header;
> +
> +static size_t get_keys_header_size(struct keys_header *keys_header,
> +				   size_t key_count)
> +{
> +	return struct_size(keys_header, keys, key_count);
> +}
> +
> +static int init(const char *buf)
> +{
> +	unsigned int total_keys;
> +	char dummy[5];

Why 5?

> +
> +	if (sscanf(buf, "%4s %u", dummy, &total_keys) != 2)

Didn't you just overflow dummy now?

> +		return -EINVAL;
> +
> +	if (key_count > KEY_NUM_MAX) {
> +		pr_err("Exceed the maximum number of keys (KEY_NUM_MAX=%u)\n",
> +		       KEY_NUM_MAX);

Do not let userspace spam the kernel log directly if it sends it invalid
data.

> +		return -EINVAL;
> +	}
> +
> +	keys_header_size = get_keys_header_size(keys_header, total_keys);
> +	key_count = 0;
> +
> +	keys_header = kzalloc(keys_header_size, GFP_KERNEL);
> +	if (!keys_header)
> +		return -ENOMEM;
> +
> +	keys_header->key_count = total_keys;
> +	state = INITIALIZED;
> +	return 0;
> +}
> +
> +static int record_key_desc(const char *buf, struct dm_crypt_key *dm_key)
> +{
> +	char key_desc[KEY_DESC_LEN];
> +	char dummy[7];
> +
> +	if (state != INITIALIZED)
> +		pr_err("Please send the cmd 'init <KEY_NUM>' first\n");

Again, don't let userspace spam the log.

> +
> +	if (sscanf(buf, "%6s %s", dummy, key_desc) != 2)
> +		return -EINVAL;
> +
> +	if (key_count >= keys_header->key_count) {
> +		pr_warn("Already have %u keys", key_count);
> +		return -EINVAL;
> +	}
> +
> +	strscpy(dm_key->key_desc, key_desc, KEY_DESC_LEN);
> +	pr_debug("Key%d (%s) recorded\n", key_count, dm_key->key_desc);
> +	key_count++;
> +
> +	if (key_count == keys_header->key_count)
> +		state = RECORDED;
> +
> +	return 0;
> +}
> +
> +static int process_cmd(const char *buf, size_t count)
> +{
> +	if (strncmp(buf, "init ", 5) == 0)
> +		return init(buf);
> +	else if (strncmp(buf, "record ", 7) == 0)
> +		return record_key_desc(buf, &keys_header->keys[key_count]);
> +
> +	return -EINVAL;
> +}
> +
> +int crash_sysfs_dm_crypt_keys_write(const char *buf, size_t count)
> +{
> +	if (!is_kdump_kernel())
> +		return process_cmd(buf, count);
> +	return -EINVAL;
> +}
> +EXPORT_SYMBOL(crash_sysfs_dm_crypt_keys_write);

EXPORT_SYMBOL_GPL() as you are dealing with a sysfs api?


> +
> +int crash_sysfs_dm_crypt_keys_read(char *buf)
> +{
> +	return sprintf(buf, "%s\n", STATE_STR[state]);

sysfs_emit() please.

> +}
> +EXPORT_SYMBOL(crash_sysfs_dm_crypt_keys_read);

Again, EXPORT_SYMBOL_GPL()?

> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 07fb5987b42b..2ba4dcbf5816 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -167,6 +167,25 @@ static ssize_t vmcoreinfo_show(struct kobject *kobj,
>  }
>  KERNEL_ATTR_RO(vmcoreinfo);
>  
> +#ifdef CONFIG_CRASH_DM_CRYPT
> +static ssize_t crash_dm_crypt_keys_show(struct kobject *kobj,
> +					struct kobj_attribute *attr, char *buf)
> +{
> +	return crash_sysfs_dm_crypt_keys_read(buf);
> +}
> +
> +static ssize_t crash_dm_crypt_keys_store(struct kobject *kobj,
> +					 struct kobj_attribute *attr,
> +					 const char *buf, size_t count)
> +{
> +	int ret;
> +
> +	ret = crash_sysfs_dm_crypt_keys_write(buf, count);
> +	return ret < 0 ? ret : count;

Personally, I hate ? : lines, just write it out, the compiler is the
same and this way it is much more readable:
	if (ret < 0)
		return ret;
	return count;

thanks,

greg k-h

  reply	other threads:[~2024-05-23  7:21 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23  5:04 [PATCH v4 0/7] Support kdump with LUKS encryption by reusing LUKS volume keys Coiby Xu
2024-05-23  5:04 ` Coiby Xu
2024-05-23  5:04 ` [PATCH v4 1/7] kexec_file: allow to place kexec_buf randomly Coiby Xu
2024-05-23  5:04   ` Coiby Xu
2024-06-04  7:41   ` Baoquan He
2024-06-04  7:41     ` Baoquan He
2024-06-07 12:26     ` Coiby Xu
2024-06-07 12:26       ` Coiby Xu
2024-05-23  5:04 ` [PATCH v4 2/7] crash_dump: make dm crypt keys persist for the kdump kernel Coiby Xu
2024-05-23  5:04   ` Coiby Xu
2024-05-23  7:21   ` Greg KH [this message]
2024-05-23  7:21     ` Greg KH
2024-05-25  7:57     ` Coiby Xu
2024-05-25  7:57       ` Coiby Xu
2024-06-04  8:51   ` Baoquan He
2024-06-04  8:51     ` Baoquan He
2024-06-07 12:27     ` Coiby Xu
2024-06-07 12:27       ` Coiby Xu
2024-06-10  2:00       ` Baoquan He
2024-06-10  2:00         ` Baoquan He
2024-10-18  1:44         ` Coiby Xu
2024-10-18  1:44           ` Coiby Xu
2024-06-05  8:22   ` Baoquan He
2024-06-05  8:22     ` Baoquan He
2024-06-07 12:27     ` Coiby Xu
2024-06-07 12:27       ` Coiby Xu
2024-06-10  1:18       ` Baoquan He
2024-06-10  1:18         ` Baoquan He
2024-10-18  1:02         ` Coiby Xu
2024-10-18  1:02           ` Coiby Xu
2024-06-06  3:11   ` Baoquan He
2024-06-06  3:11     ` Baoquan He
2024-06-07 12:26     ` Coiby Xu
2024-06-07 12:26       ` Coiby Xu
2024-05-23  5:04 ` [PATCH v4 3/7] crash_dump: store dm keys in kdump reserved memory Coiby Xu
2024-05-23  5:04   ` Coiby Xu
2024-05-24  3:17   ` kernel test robot
2024-05-24  3:17     ` kernel test robot
2024-06-04 13:54     ` Baoquan He
2024-06-04 13:54       ` Baoquan He
2024-06-07 12:26       ` Coiby Xu
2024-06-07 12:26         ` Coiby Xu
2024-05-23  5:04 ` [PATCH v4 4/7] crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging Coiby Xu
2024-05-23  5:04   ` Coiby Xu
2024-06-04 13:52   ` Baoquan He
2024-06-04 13:52     ` Baoquan He
2024-05-23  5:04 ` [PATCH v4 5/7] crash_dump: retrieve dm crypt keys in kdump kernel Coiby Xu
2024-05-23  5:04   ` Coiby Xu
2024-06-07  9:50   ` Baoquan He
2024-06-07  9:50     ` Baoquan He
2024-06-07 12:27     ` Coiby Xu
2024-06-07 12:27       ` Coiby Xu
2024-05-23  5:04 ` [PATCH v4 6/7] x86/crash: pass dm crypt keys to " Coiby Xu
2024-05-23  5:04   ` Coiby Xu
2024-06-07  9:57   ` Baoquan He
2024-06-07  9:57     ` Baoquan He
2024-06-07 12:27     ` Coiby Xu
2024-06-07 12:27       ` Coiby Xu
2024-05-23  5:04 ` [PATCH v4 7/7] x86/crash: make the page that stores the dm crypt keys inaccessible Coiby Xu
2024-05-23  5:04   ` Coiby Xu
2024-06-07 10:00   ` Baoquan He
2024-06-07 10:00     ` Baoquan He
2024-06-07 12:27     ` Coiby Xu
2024-06-07 12:27       ` Coiby Xu
2024-06-07 10:06 ` [PATCH v4 0/7] Support kdump with LUKS encryption by reusing LUKS volume keys Baoquan He
2024-06-07 10:06   ` Baoquan He
2024-06-07 12:26   ` Coiby Xu
2024-06-07 12:26     ` Coiby Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024052334-protegee-cheating-5934@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=berrange@redhat.com \
    --cc=bhe@redhat.com \
    --cc=coxu@redhat.com \
    --cc=dave.hansen@intel.com \
    --cc=dyoung@redhat.com \
    --cc=gmazyland@gmail.com \
    --cc=gustavoars@kernel.org \
    --cc=jpazdziora@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernelfans@gmail.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=okozina@redhat.com \
    --cc=ryncsn@gmail.com \
    --cc=tstaudt@de.ibm.com \
    --cc=vgoyal@redhat.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.