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>,
	"Eric Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH v5 1/7] kexec_file: allow to place kexec_buf randomly
Date: Sat, 8 Jun 2024 11:12:02 +0200	[thread overview]
Message-ID: <2024060842-entryway-gurgle-4ae2@gregkh> (raw)
In-Reply-To: <20240607122622.167228-2-coxu@redhat.com>

On Fri, Jun 07, 2024 at 08:26:11PM +0800, Coiby Xu wrote:
> Currently, kexec_buf is placed in order which means for the same
> machine, the info in the kexec_buf is always located at the same
> position each time the machine is booted. This may cause a risk for
> sensitive information like LUKS volume key. Now struct kexec_buf has a
> new field random which indicates it's supposed to be placed in a random
> position.
> 
> Suggested-by: Jan Pazdziora <jpazdziora@redhat.com>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
>  include/linux/kexec.h |  4 ++++
>  kernel/kexec_file.c   | 21 +++++++++++++++++++++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index f0e9f8eda7a3..c45bfc727737 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -171,6 +171,7 @@ int kexec_image_post_load_cleanup_default(struct kimage *image);
>   * @buf_min:	The buffer can't be placed below this address.
>   * @buf_max:	The buffer can't be placed above this address.
>   * @top_down:	Allocate from top of memory.
> + * @random:	Place the buffer at a random position.
>   */
>  struct kexec_buf {
>  	struct kimage *image;
> @@ -182,6 +183,9 @@ struct kexec_buf {
>  	unsigned long buf_min;
>  	unsigned long buf_max;
>  	bool top_down;
> +#ifdef CONFIG_CRASH_DUMP
> +	bool random;
> +#endif

Why is the ifdef needed?

>  };
>  
>  int kexec_load_purgatory(struct kimage *image, struct kexec_buf *kbuf);
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 3d64290d24c9..f7538d8f67e0 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -25,6 +25,9 @@
>  #include <linux/elfcore.h>
>  #include <linux/kernel.h>
>  #include <linux/kernel_read_file.h>
> +#ifdef CONFIG_CRASH_DUMP
> +#include <linux/prandom.h>
> +#endif

No ifdef in .c files please.  This should not be an issue.

>  #include <linux/syscalls.h>
>  #include <linux/vmalloc.h>
>  #include "kexec_internal.h"
> @@ -437,6 +440,18 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
>  	return ret;
>  }
>  
> +#ifdef CONFIG_CRASH_DUMP
> +static unsigned long kexec_random_start(unsigned long start, unsigned long end)
> +{
> +	unsigned long temp_start;
> +	unsigned short i;
> +
> +	get_random_bytes(&i, sizeof(unsigned short));
> +	temp_start = start + (end - start) / USHRT_MAX * i;
> +	return temp_start;
> +}
> +#endif

This #ifdef should be handled properly in the .h file.

> +
>  static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
>  				    struct kexec_buf *kbuf)
>  {
> @@ -445,6 +460,10 @@ static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
>  
>  	temp_end = min(end, kbuf->buf_max);
>  	temp_start = temp_end - kbuf->memsz + 1;
> +#ifdef CONFIG_CRASH_DUMP
> +	if (kbuf->random)
> +		temp_start = kexec_random_start(temp_start, temp_end);
> +#endif

Same with this.

And why do you need the boolean at all, why not just have
kexec_random_start() handle this properly for you?

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>,
	"Eric Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH v5 1/7] kexec_file: allow to place kexec_buf randomly
Date: Sat, 8 Jun 2024 11:12:02 +0200	[thread overview]
Message-ID: <2024060842-entryway-gurgle-4ae2@gregkh> (raw)
In-Reply-To: <20240607122622.167228-2-coxu@redhat.com>

On Fri, Jun 07, 2024 at 08:26:11PM +0800, Coiby Xu wrote:
> Currently, kexec_buf is placed in order which means for the same
> machine, the info in the kexec_buf is always located at the same
> position each time the machine is booted. This may cause a risk for
> sensitive information like LUKS volume key. Now struct kexec_buf has a
> new field random which indicates it's supposed to be placed in a random
> position.
> 
> Suggested-by: Jan Pazdziora <jpazdziora@redhat.com>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
>  include/linux/kexec.h |  4 ++++
>  kernel/kexec_file.c   | 21 +++++++++++++++++++++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index f0e9f8eda7a3..c45bfc727737 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -171,6 +171,7 @@ int kexec_image_post_load_cleanup_default(struct kimage *image);
>   * @buf_min:	The buffer can't be placed below this address.
>   * @buf_max:	The buffer can't be placed above this address.
>   * @top_down:	Allocate from top of memory.
> + * @random:	Place the buffer at a random position.
>   */
>  struct kexec_buf {
>  	struct kimage *image;
> @@ -182,6 +183,9 @@ struct kexec_buf {
>  	unsigned long buf_min;
>  	unsigned long buf_max;
>  	bool top_down;
> +#ifdef CONFIG_CRASH_DUMP
> +	bool random;
> +#endif

Why is the ifdef needed?

>  };
>  
>  int kexec_load_purgatory(struct kimage *image, struct kexec_buf *kbuf);
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 3d64290d24c9..f7538d8f67e0 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -25,6 +25,9 @@
>  #include <linux/elfcore.h>
>  #include <linux/kernel.h>
>  #include <linux/kernel_read_file.h>
> +#ifdef CONFIG_CRASH_DUMP
> +#include <linux/prandom.h>
> +#endif

No ifdef in .c files please.  This should not be an issue.

>  #include <linux/syscalls.h>
>  #include <linux/vmalloc.h>
>  #include "kexec_internal.h"
> @@ -437,6 +440,18 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
>  	return ret;
>  }
>  
> +#ifdef CONFIG_CRASH_DUMP
> +static unsigned long kexec_random_start(unsigned long start, unsigned long end)
> +{
> +	unsigned long temp_start;
> +	unsigned short i;
> +
> +	get_random_bytes(&i, sizeof(unsigned short));
> +	temp_start = start + (end - start) / USHRT_MAX * i;
> +	return temp_start;
> +}
> +#endif

This #ifdef should be handled properly in the .h file.

> +
>  static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
>  				    struct kexec_buf *kbuf)
>  {
> @@ -445,6 +460,10 @@ static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
>  
>  	temp_end = min(end, kbuf->buf_max);
>  	temp_start = temp_end - kbuf->memsz + 1;
> +#ifdef CONFIG_CRASH_DUMP
> +	if (kbuf->random)
> +		temp_start = kexec_random_start(temp_start, temp_end);
> +#endif

Same with this.

And why do you need the boolean at all, why not just have
kexec_random_start() handle this properly for you?

thanks,

greg k-h

  parent reply	other threads:[~2024-06-08  9:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07 12:26 [PATCH v4 0/7] Support kdump with LUKS encryption by reusing LUKS volume keys Coiby Xu
2024-06-07 12:26 ` Coiby Xu
2024-06-07 12:26 ` [PATCH v5 1/7] kexec_file: allow to place kexec_buf randomly Coiby Xu
2024-06-07 12:26   ` Coiby Xu
2024-06-08  3:51   ` kernel test robot
2024-06-08  3:51     ` kernel test robot
2024-06-08  4:23   ` kernel test robot
2024-06-08  4:23     ` kernel test robot
2024-06-08  9:12   ` Greg KH [this message]
2024-06-08  9:12     ` Greg KH
2024-06-07 12:26 ` [PATCH v5 2/7] crash_dump: make dm crypt keys persist for the kdump kernel Coiby Xu
2024-06-07 12:26   ` Coiby Xu
2024-06-08  9:19   ` Greg KH
2024-06-08  9:19     ` Greg KH
2024-06-07 12:26 ` [PATCH v5 3/7] crash_dump: store dm crypt keys in kdump reserved memory Coiby Xu
2024-06-07 12:26   ` Coiby Xu
2024-06-07 12:26 ` [PATCH v5 4/7] crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging Coiby Xu
2024-06-07 12:26   ` Coiby Xu
2024-06-07 12:26 ` [PATCH v5 5/7] crash_dump: retrieve dm crypt keys in kdump kernel Coiby Xu
2024-06-07 12:26   ` Coiby Xu
2024-06-07 12:26 ` [PATCH v5 6/7] x86/crash: pass dm crypt keys to " Coiby Xu
2024-06-07 12:26   ` Coiby Xu
2024-06-07 12:26 ` [PATCH v5 7/7] x86/crash: make the page that stores the dm crypt keys inaccessible Coiby Xu
2024-06-07 12:26   ` Coiby Xu
2024-06-08  1:26 ` [PATCH v4 0/7] Support kdump with LUKS encryption by reusing LUKS volume keys Coiby Xu
2024-06-08  1:26   ` Coiby Xu
2024-06-08  9:10   ` Greg KH
2024-06-08  9:10     ` Greg KH

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=2024060842-entryway-gurgle-4ae2@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=ebiederm@xmission.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=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.