From: Baoquan He <bhe@redhat.com>
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>,
"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>
Subject: Re: [PATCH v4 4/7] crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging
Date: Tue, 4 Jun 2024 21:52:56 +0800 [thread overview]
Message-ID: <Zl8cOOv9gVzdkU0f@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20240523050451.788754-5-coxu@redhat.com>
On 05/23/24 at 01:04pm, Coiby Xu wrote:
> When there is CPU/memory hot-plugging, the kdump kernel image and initrd
> will be reloaded. The user space can write the "reuse" command to
> /sys/kernel/crash_dm_crypt_key so the stored keys can be re-saved again.
>
> Note currently only x86 (commit ea53ad9cf73b ("x86/crash: add x86 crash
> hotplug support")) and ppc (WIP) supports the new infrastructure
> (commit 247262756121 ("crash: add generic infrastructure for crash
> hotplug support")). If the new infrastructure get extended to all arches,
> this patch can be dropped.
I am confused, what is the new infrastructure? And why this patch can be
dropped if 'the new infrastructure' is extended to all arches.
>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> kernel/crash_dump_dm_crypt.c | 30 ++++++++++++++++++++++++++----
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c
> index 89fec768fba8..b4dc881cc867 100644
> --- a/kernel/crash_dump_dm_crypt.c
> +++ b/kernel/crash_dump_dm_crypt.c
> @@ -10,12 +10,13 @@
> // 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 char *STATE_STR[] = {"fresh", "initialized", "recorded", "loaded", "reuse"};
> static enum STATE_ENUM {
> FRESH = 0,
> INITIALIZED,
> RECORDED,
> LOADED,
> + REUSE,
> } state;
>
> static unsigned int key_count;
> @@ -90,12 +91,31 @@ static int record_key_desc(const char *buf, struct dm_crypt_key *dm_key)
> return 0;
> }
>
> +static void get_keys_from_kdump_reserved_memory(void)
> +{
> + struct keys_header *keys_header_loaded;
> +
> + arch_kexec_unprotect_crashkres();
> +
> + keys_header_loaded = kmap_local_page(pfn_to_page(
> + kexec_crash_image->dm_crypt_keys_addr >> PAGE_SHIFT));
> +
> + memcpy(keys_header, keys_header_loaded, keys_header_size);
> + kunmap_local(keys_header_loaded);
> + state = RECORDED;
> +}
> +
> 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]);
> + else if (!strcmp(buf, "reuse")) {
> + state = REUSE;
> + get_keys_from_kdump_reserved_memory();
> + return 0;
> + }
>
> return -EINVAL;
> }
> @@ -175,9 +195,11 @@ int crash_load_dm_crypt_keys(struct kimage *image)
> }
>
> image->dm_crypt_keys_addr = 0;
> - r = build_keys_header();
> - if (r)
> - return r;
> + if (state != REUSE) {
> + r = build_keys_header();
> + if (r)
> + return r;
Is the logic here wrong? Isn't it we return when it's REUSE. If not
REUSE, we need build_keys_header(), then add buffer?
> + }
>
> kbuf.buffer = keys_header;
> kbuf.bufsz = keys_header_size;
> --
> 2.45.0
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
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>,
"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>
Subject: Re: [PATCH v4 4/7] crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging
Date: Tue, 4 Jun 2024 21:52:56 +0800 [thread overview]
Message-ID: <Zl8cOOv9gVzdkU0f@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20240523050451.788754-5-coxu@redhat.com>
On 05/23/24 at 01:04pm, Coiby Xu wrote:
> When there is CPU/memory hot-plugging, the kdump kernel image and initrd
> will be reloaded. The user space can write the "reuse" command to
> /sys/kernel/crash_dm_crypt_key so the stored keys can be re-saved again.
>
> Note currently only x86 (commit ea53ad9cf73b ("x86/crash: add x86 crash
> hotplug support")) and ppc (WIP) supports the new infrastructure
> (commit 247262756121 ("crash: add generic infrastructure for crash
> hotplug support")). If the new infrastructure get extended to all arches,
> this patch can be dropped.
I am confused, what is the new infrastructure? And why this patch can be
dropped if 'the new infrastructure' is extended to all arches.
>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> kernel/crash_dump_dm_crypt.c | 30 ++++++++++++++++++++++++++----
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c
> index 89fec768fba8..b4dc881cc867 100644
> --- a/kernel/crash_dump_dm_crypt.c
> +++ b/kernel/crash_dump_dm_crypt.c
> @@ -10,12 +10,13 @@
> // 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 char *STATE_STR[] = {"fresh", "initialized", "recorded", "loaded", "reuse"};
> static enum STATE_ENUM {
> FRESH = 0,
> INITIALIZED,
> RECORDED,
> LOADED,
> + REUSE,
> } state;
>
> static unsigned int key_count;
> @@ -90,12 +91,31 @@ static int record_key_desc(const char *buf, struct dm_crypt_key *dm_key)
> return 0;
> }
>
> +static void get_keys_from_kdump_reserved_memory(void)
> +{
> + struct keys_header *keys_header_loaded;
> +
> + arch_kexec_unprotect_crashkres();
> +
> + keys_header_loaded = kmap_local_page(pfn_to_page(
> + kexec_crash_image->dm_crypt_keys_addr >> PAGE_SHIFT));
> +
> + memcpy(keys_header, keys_header_loaded, keys_header_size);
> + kunmap_local(keys_header_loaded);
> + state = RECORDED;
> +}
> +
> 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]);
> + else if (!strcmp(buf, "reuse")) {
> + state = REUSE;
> + get_keys_from_kdump_reserved_memory();
> + return 0;
> + }
>
> return -EINVAL;
> }
> @@ -175,9 +195,11 @@ int crash_load_dm_crypt_keys(struct kimage *image)
> }
>
> image->dm_crypt_keys_addr = 0;
> - r = build_keys_header();
> - if (r)
> - return r;
> + if (state != REUSE) {
> + r = build_keys_header();
> + if (r)
> + return r;
Is the logic here wrong? Isn't it we return when it's REUSE. If not
REUSE, we need build_keys_header(), then add buffer?
> + }
>
> kbuf.buffer = keys_header;
> kbuf.bufsz = keys_header_size;
> --
> 2.45.0
>
next prev parent reply other threads:[~2024-06-04 13:53 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
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 [this message]
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=Zl8cOOv9gVzdkU0f@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=berrange@redhat.com \
--cc=coxu@redhat.com \
--cc=dave.hansen@intel.com \
--cc=dyoung@redhat.com \
--cc=gmazyland@gmail.com \
--cc=jpazdziora@redhat.com \
--cc=kernelfans@gmail.com \
--cc=kexec@lists.infradead.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.