From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: qemu-devel@nongnu.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
"Michael S . Tsirkin" <mst@redhat.com>,
"Dov Murik" <dovmurik@linux.ibm.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"H . Peter Anvin" <hpa@zytor.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Borislav Petkov" <bp@alien8.de>,
"Eric Biggers" <ebiggers@kernel.org>
Subject: Re: [PATCH] x86: temporarily remove all attempts to provide setup_data
Date: Wed, 8 Feb 2023 18:26:13 +0000 [thread overview]
Message-ID: <Y+PpRUYHDc1TH2zO@redhat.com> (raw)
In-Reply-To: <20230208180835.234638-1-Jason@zx2c4.com>
On Wed, Feb 08, 2023 at 03:08:35PM -0300, Jason A. Donenfeld wrote:
> All attempts at providing setup_data have been made as an iteration on
> whatever was there before, stretching back to the original
> implementation used for DTBs that [mis]used the kernel image itself.
> We've now had a dozen rounds of bugs and hacks, and the result is
> turning into a pile of unmaintainable and increasingly brittle hacks.
>
> Let's just rip out all the madness and start over. We can re-architect
> this based on having a separate standalone setup_data file, which is how
> it should have been done in the first place. This is a larger project
> with a few things to coordinate, but we can't really begin thinking
> about that while trying to play whack-a-mole with the current buggy
> implementation.
>
> So this commit removes the setup_data setting from x86_load_linux(),
> while leaving intact the infrastructure we'll need in the future to try
> again.
Technically this changes the ABI of the 7.2.0 machine type version
which we would normally avoid.
In practice I think we can probably get away with doing it.
The number of released guest OS that consume the RNG seed is negligible
at this point in time. Any that do consume shouldn't mind much if it
just disappears on next boot, since it was always just an opt-in, and
the kernel will happily still boot without it.
So I'm fine if we just put a note in the commit message acknowledging
that this is an ABI incompatibility for the machine type, but explaining
why it is none the less OK todo in this exceptional circumstance.
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Dov Murik <dovmurik@linux.ibm.com>
> Cc: Tom Lendacky <thomas.lendacky@amd.com>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Daniel P. Berrangé <berrange@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> hw/i386/microvm.c | 15 ++----
> hw/i386/x86.c | 120 +++++-----------------------------------------
> 2 files changed, 17 insertions(+), 118 deletions(-)
Presumably it should be purging all traces of the 'legacy_no_rng_seed'
at the same time, with the view that any future implementation would be
tied to only whatever machine type is current at the time it gets
merged (could be 8.0.0 or 8.1.0 machine type, depending on how quickly
the new design gets settled).
$ git grep legacy_no_rng_seed
hw/i386/pc.c: pcmc->pvh_enabled, pcmc->legacy_no_rng_seed);
hw/i386/pc.c: pcmc->pvh_enabled, pcmc->legacy_no_rng_seed);
hw/i386/pc_piix.c: pcmc->legacy_no_rng_seed = true;
hw/i386/pc_q35.c: pcmc->legacy_no_rng_seed = true;
hw/i386/x86.c: bool legacy_no_rng_seed)
hw/i386/x86.c: if (!legacy_no_rng_seed) {
include/hw/i386/pc.h: bool legacy_no_rng_seed;
include/hw/i386/x86.h: bool legacy_no_rng_seed);
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-02-08 18:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 18:08 [PATCH] x86: temporarily remove all attempts to provide setup_data Jason A. Donenfeld
2023-02-08 18:13 ` Michael S. Tsirkin
2023-02-08 18:14 ` Jason A. Donenfeld
2023-02-08 18:18 ` Michael S. Tsirkin
2023-02-08 18:26 ` Jason A. Donenfeld
2023-02-08 18:31 ` Daniel P. Berrangé
2023-02-08 18:34 ` Jason A. Donenfeld
2023-02-08 18:58 ` Daniel P. Berrangé
2023-02-08 18:14 ` Nathan Chancellor
2023-02-08 19:10 ` Nathan Chancellor
2023-02-08 18:26 ` Daniel P. Berrangé [this message]
2023-02-08 20:43 ` Michael S. Tsirkin
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=Y+PpRUYHDc1TH2zO@redhat.com \
--to=berrange@redhat.com \
--cc=Jason@zx2c4.com \
--cc=bp@alien8.de \
--cc=dovmurik@linux.ibm.com \
--cc=ebiggers@kernel.org \
--cc=hpa@zytor.com \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=nathan@kernel.org \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).