All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Dov Murik <dovmurik@linux.ibm.com>
Cc: qemu-devel@nongnu.org, "Tom Lendacky" <thomas.lendacky@amd.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	"James Bottomley" <jejb@linux.ibm.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Tobin Feldman-Fitzthum" <tobin@linux.ibm.com>
Subject: Re: [PATCH] x86: Don't add RNG seed to Linux cmdline for SEV guests
Date: Tue, 7 Feb 2023 16:45:19 -0500	[thread overview]
Message-ID: <20230207164117-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20230207084116.285787-1-dovmurik@linux.ibm.com>

On Tue, Feb 07, 2023 at 08:41:16AM +0000, Dov Murik wrote:
> Recent feature to supply RNG seed to the guest kernel modifies the
> kernel command-line by adding extra data at its end; this breaks
> measured boot with SEV and OVMF, and possibly signed boot.
> 
> Specifically SEV doesn't miss this feature because it uses UEFI/OVMF
> which has its own way of getting random seed (not to mention that
> getting the random seed from the untrusted host breaks the confidential
> computing trust model).

Nope - getting a random seed from an untrusted source should not break
anything assuming you also have some other randomness source.
If you don't then you have other problems.

> Disable the RNG seed feature in SEV guests.
> 
> Fixes: eac7a7791bb6 ("x86: don't let decompressed kernel image clobber setup_data")
> Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com>
> 
> ---
> 
> There might be a need for a wider change to the ways setup_data entries
> are handled in x86_load_linux(); here I just try to restore the
> situation for SEV guests prior to the addition of the SETUP_RNG_SEED
> entry.
> 
> Recent discussions on other (safer?) ways to pass this setup_data entry:
> [1] https://lore.kernel.org/qemu-devel/da39abab9785aea2a2e7652ed6403b6268aeb31f.camel@linux.ibm.com/
> 
> Note that in qemu 7.2.0 this is broken as well -- there the
> SETUP_RNG_SEED entry is appended to the Linux kernel data (and therefore
> modifies and breaks the measurement of the kernel in SEV measured boot).
> A similar fix will be needed there (but I fear this patch cannot be
> applied as-is).

So it's not a regression, is it?

> ---
>  hw/i386/x86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> index eaff4227bd..e65a83f8df 100644
> --- a/hw/i386/x86.c
> +++ b/hw/i386/x86.c
> @@ -1103,7 +1103,7 @@ void x86_load_linux(X86MachineState *x86ms,
>          load_image_size(dtb_filename, setup_data->data, dtb_size);
>      }
>  
> -    if (!legacy_no_rng_seed && protocol >= 0x209) {
> +    if (!legacy_no_rng_seed && protocol >= 0x209 && !sev_enabled()) {
>          setup_data_offset = cmdline_size;
>          cmdline_size += sizeof(SetupData) + RNG_SEED_LENGTH;
>          kernel_cmdline = g_realloc(kernel_cmdline, cmdline_size);
> 
> base-commit: 6661b8c7fe3f8b5687d2d90f7b4f3f23d70e3e8b

I am beginning to think we have been hasty here. no rng seed
should have been then default and requested with a flag.
Then we'd avoid all this heartburn - and SEV might not be the
only workload broken.
Maybe not too late. Jason - objections?

> -- 
> 2.25.1



  parent reply	other threads:[~2023-02-07 21:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07  8:41 [PATCH] x86: Don't add RNG seed to Linux cmdline for SEV guests Dov Murik
2023-02-07 17:28 ` Jason A. Donenfeld
2023-02-07 21:45 ` Michael S. Tsirkin [this message]
2023-02-07 22:17   ` Jason A. Donenfeld
2023-02-07 22:31     ` Michael S. Tsirkin
2023-02-07 22:33       ` Jason A. Donenfeld
2023-02-07 22:49         ` Jason A. Donenfeld
2023-02-08  9:11         ` Michael S. Tsirkin
2023-02-08 11:23           ` Dov Murik
2023-02-08 13:20             ` Michael S. Tsirkin
2023-02-08 13:30               ` Jason A. Donenfeld
2023-02-08 13:58                 ` Michael S. Tsirkin
2023-02-07 23:21   ` Tom Lendacky
2023-02-07 23:24     ` Jason A. Donenfeld
2023-02-08 11:35       ` Dov Murik
2023-02-08 15:26       ` Tom Lendacky
2023-02-08 15:39         ` Michael S. Tsirkin
2023-02-08 15:47         ` Jason A. Donenfeld
2023-02-08 15:49         ` Dov Murik
2023-02-08 15:51           ` Jason A. Donenfeld
2023-02-08 15:52           ` Dov Murik
2023-02-08 15:54           ` Jason A. Donenfeld
2023-02-08 11:57     ` Dov Murik
2023-02-08  9:35   ` Daniel P. Berrangé
2023-02-08  9:50     ` Michael S. Tsirkin
2023-02-08  9:30 ` Daniel P. Berrangé
2023-02-08 11:27   ` Dov Murik

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=20230207164117-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=Jason@zx2c4.com \
    --cc=berrange@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=eduardo@habkost.net \
    --cc=hpa@zytor.com \
    --cc=jejb@linux.ibm.com \
    --cc=kraxel@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@linux.ibm.com \
    /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.