mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: qemu-devel@nongnu.org, "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	"Dov Murik" <dovmurik@linux.ibm.com>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Daniel P . Berrangé" <berrange@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: [PATCH RFC 0/7] revert RNG seed mess
Date: Wed, 8 Feb 2023 16:12:23 -0500	[thread overview]
Message-ID: <20230208211212.41951-1-mst@redhat.com> (raw)

All attempts to fix up passing RNG seed via setup_data entry failed.
Let's just rip out all of it.  We'll start over.


Warning: all I did was git revert the relevant patches and resolve the
(trivial) conflicts. Not even compiled - it's almost midnight here.

Jason this is the kind of approach I'd like to see, not yet another
pointer math rich patch I need to spend time reviewing. Just get us back
to where we started. We can redo "x86: use typedef for SetupData struct"
later if we want, it's benign.

Could you do something like this pls?
Or test and ack if this patchset happens to work by luck.

Michael S. Tsirkin (7):
  Revert "x86: don't let decompressed kernel image clobber setup_data"
  Revert "x86: do not re-randomize RNG seed on snapshot load"
  Revert "x86: re-initialize RNG seed when selecting kernel"
  Revert "x86: reinitialize RNG seed on system reboot"
  Revert "x86: use typedef for SetupData struct"
  Revert "x86: return modified setup_data only if read as memory, not as
    file"
  Revert "hw/i386: pass RNG seed via setup_data entry"

 include/hw/i386/microvm.h |   5 +-
 include/hw/i386/pc.h      |   3 -
 include/hw/i386/x86.h     |   3 +-
 include/hw/nvram/fw_cfg.h |  31 ----------
 hw/i386/microvm.c         |  17 ++----
 hw/i386/pc.c              |   4 +-
 hw/i386/pc_piix.c         |   2 -
 hw/i386/pc_q35.c          |   2 -
 hw/i386/x86.c             | 122 ++++++++++----------------------------
 hw/nvram/fw_cfg.c         |  21 ++-----
 10 files changed, 49 insertions(+), 161 deletions(-)

-- 
MST


             reply	other threads:[~2023-02-08 21:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08 21:12 Michael S. Tsirkin [this message]
2023-02-08 21:12 ` [PATCH RFC 1/7] Revert "x86: don't let decompressed kernel image clobber setup_data" Michael S. Tsirkin
2023-02-14 16:36   ` Daniel P. Berrangé
2023-02-08 21:12 ` [PATCH RFC 2/7] Revert "x86: do not re-randomize RNG seed on snapshot load" Michael S. Tsirkin
2023-02-14 16:36   ` Daniel P. Berrangé
2023-02-08 21:12 ` [PATCH RFC 3/7] Revert "x86: re-initialize RNG seed when selecting kernel" Michael S. Tsirkin
2023-02-14 16:37   ` Daniel P. Berrangé
2023-02-08 21:12 ` [PATCH RFC 4/7] Revert "x86: reinitialize RNG seed on system reboot" Michael S. Tsirkin
2023-02-14 16:37   ` Daniel P. Berrangé
2023-02-08 21:12 ` [PATCH RFC 5/7] Revert "x86: use typedef for SetupData struct" Michael S. Tsirkin
2023-02-09  7:41   ` Michael S. Tsirkin
2023-02-14 16:37   ` Daniel P. Berrangé
2023-02-08 21:12 ` [PATCH RFC 6/7] Revert "x86: return modified setup_data only if read as memory, not as file" Michael S. Tsirkin
2023-02-09 15:52   ` Jason A. Donenfeld
2023-02-10 11:31     ` Daniel P. Berrangé
2023-02-14 16:38   ` Daniel P. Berrangé
2023-02-08 21:12 ` [PATCH RFC 7/7] Revert "hw/i386: pass RNG seed via setup_data entry" Michael S. Tsirkin
2023-02-14 16:45   ` Daniel P. Berrangé
2023-02-14 18:03     ` Michael S. Tsirkin
2023-02-09  6:03 ` [PATCH RFC 0/7] revert RNG seed mess Dov Murik
2023-02-09  6:34   ` Dov Murik
2023-02-09 15:46 ` Nathan Chancellor
2023-02-10 11:32 ` Daniel P. Berrangé
2023-02-20 10:48   ` Daniel P. Berrangé
2023-02-20 11:54     ` 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=20230208211212.41951-1-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=Jason@zx2c4.com \
    --cc=berrange@redhat.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=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

all inboxes | Powered by JetHome®