All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: jejb@linux.ibm.com, James Bottomley <jejb@linux.ibm.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	DOV MURIK <Dov.Murik1@il.ibm.com>
Subject: Re: [PATCH] x86: fix q35 kernel measurements broken due to rng seeding
Date: Thu, 02 Feb 2023 07:03:31 -0800	[thread overview]
Message-ID: <4396778A-6520-4FB5-9227-1E8850753036@zytor.com> (raw)
In-Reply-To: <d2e01e48fa215684447d17d21d48fa681ab7f7d3.camel@linux.ibm.com>

On February 2, 2023 6:38:12 AM PST, James Bottomley <jejb@linux.ibm.com> wrote:
>On Wed, 2023-02-01 at 15:48 -0500, Jason A. Donenfeld wrote:
>[...]
>> But it sounds like you might now have a concrete suggestion on
>> something even better. I'm CCing hpa, as this is his wheelhouse, and
>> maybe you two can divise the next step while I'm away. Maybe the pad9
>> thing you mentioned is the super nice solution we've been searching
>> for this whole time. When I'm home in 10 days and have internet
>> again, I'll take a look at where thing's are out and try to figure
>> out how I can be productive again with it.
>
>OK, so just FYI HPA, this is the patch I'm thinking of sending to
>linux-kernel to reserve space in struct boot_params for this.  If you
>could take a look and advise on the location before I send the final
>patch, I'd be grateful.  I took space in _pad9 because that's the
>standard method (add on to end), but it does strike me we could also
>use all of _pad8 for the (the addition is only 48 bytes) or even _pad3
>+ hd0_info + hd1_info.
>
>James
>
>---
>
>diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
>index 9338c68e7413..0120ab77dac9 100644
>--- a/arch/x86/boot/header.S
>+++ b/arch/x86/boot/header.S
>@@ -308,7 +308,7 @@ _start:
> 	# Part 2 of the header, from the old setup.S
> 
> 		.ascii	"HdrS"		# header signature
>-		.word	0x020f		# header version number (>= 0x0105)
>+		.word	0x0210		# header version number (>= 0x0105)
> 					# or else old loadlin-1.5 will fail)
> 		.globl realmode_swtch
> realmode_swtch:	.word	0, 0		# default_switch, SETUPSEG
>diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
>index 01d19fc22346..c614ff0755f2 100644
>--- a/arch/x86/include/uapi/asm/bootparam.h
>+++ b/arch/x86/include/uapi/asm/bootparam.h
>@@ -181,6 +181,19 @@ struct ima_setup_data {
> 	__u64 size;
> } __attribute__((packed));
> 
>+/*
>+ * Define a boot_param area for the RNG seed which can be used via the
>+ * setup_data mechanism (so must have a setup_data header) but which
>+ * is embedded in boot_params because qemu has been unable to find
>+ * a safe data space for it.  The value RNG_SEED_LENGTH must not
>+ * change (pad length dependent on it) and must match the value in QEMU
>+ */
>+#define RNG_SEED_LENGTH	32
>+struct random_seed_data {
>+	struct	setup_data s;
>+	__u8	data[RNG_SEED_LENGTH];
>+} __attribute__((packed));
>+
> /* The so-called "zeropage" */
> struct boot_params {
> 	struct screen_info screen_info;			/* 0x000 */
>@@ -228,7 +241,8 @@ struct boot_params {
> 	struct boot_e820_entry e820_table[E820_MAX_ENTRIES_ZEROPAGE]; /* 0x2d0 */
> 	__u8  _pad8[48];				/* 0xcd0 */
> 	struct edd_info eddbuf[EDDMAXNR];		/* 0xd00 */
>-	__u8  _pad9[276];				/* 0xeec */
>+	struct random_seed_data random_seed;		/* 0xeec */
>+	__u8  _pad9[228];				/* 0xf1c */
> } __attribute__((packed));
> 
> /**
>diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
>index 6b58610a1552..fb719682579d 100644
>--- a/arch/x86/kernel/kexec-bzimage64.c
>+++ b/arch/x86/kernel/kexec-bzimage64.c
>@@ -110,13 +110,10 @@ static int setup_e820_entries(struct boot_params *params)
> 	return 0;
> }
> 
>-enum { RNG_SEED_LENGTH = 32 };
>-
> static void
>-setup_rng_seed(struct boot_params *params, unsigned long params_load_addr,
>-	       unsigned int rng_seed_setup_data_offset)
>+setup_rng_seed(struct boot_params *params, unsigned long params_load_addr)
> {
>-	struct setup_data *sd = (void *)params + rng_seed_setup_data_offset;
>+	struct setup_data *sd = &params->random_seed.s;
> 	unsigned long setup_data_phys;
> 
> 	if (!rng_is_initialized())
>@@ -125,7 +122,8 @@ setup_rng_seed(struct boot_params *params, unsigned long params_load_addr,
> 	sd->type = SETUP_RNG_SEED;
> 	sd->len = RNG_SEED_LENGTH;
> 	get_random_bytes(sd->data, RNG_SEED_LENGTH);
>-	setup_data_phys = params_load_addr + rng_seed_setup_data_offset;
>+	setup_data_phys = params_load_addr + offsetof(struct boot_params,
>+						      random_seed);
> 	sd->next = params->hdr.setup_data;
> 	params->hdr.setup_data = setup_data_phys;
> }
>@@ -306,7 +304,7 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params,
> 	}
> 
> 	/* Setup RNG seed */
>-	setup_rng_seed(params, params_load_addr, setup_data_offset);
>+	setup_rng_seed(params, params_load_addr);
> 
> 	/* Setup EDD info */
> 	memcpy(params->eddbuf, boot_params.eddbuf,
>

NAK. We need to fix the actual problem of the kernel stomping on memory it shouldn't, not paper around it.



  reply	other threads:[~2023-02-02 15:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 13:57 [PATCH] x86: fix q35 kernel measurements broken due to rng seeding James Bottomley
2023-02-01 14:35 ` Daniel P. Berrangé
2023-02-01 14:56   ` James Bottomley
2023-02-01 15:12     ` Jason A. Donenfeld
2023-02-01 15:14     ` Daniel P. Berrangé
2023-02-01 15:10 ` Jason A. Donenfeld
2023-02-01 15:24   ` James Bottomley
2023-02-01 16:41     ` Dov Murik
2023-02-01 16:50     ` Peter Maydell
2023-02-01 19:35       ` James Bottomley
2023-02-01 17:51     ` Jason A. Donenfeld
2023-02-01 20:38       ` James Bottomley
2023-02-01 20:48         ` Jason A. Donenfeld
2023-02-02 14:38           ` James Bottomley
2023-02-02 15:03             ` H. Peter Anvin [this message]
2023-02-02 15:17               ` James Bottomley
2023-02-02 18:56                 ` H. Peter Anvin
2023-02-02 19:02                 ` H. Peter Anvin
2023-02-02 19:13                 ` H. Peter Anvin

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=4396778A-6520-4FB5-9227-1E8850753036@zytor.com \
    --to=hpa@zytor.com \
    --cc=Dov.Murik1@il.ibm.com \
    --cc=Jason@zx2c4.com \
    --cc=jejb@linux.ibm.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.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.