[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a23739f6-cdb9-a181-8eb3-bb1b7f9c24ad@linux.ibm.com>
Date: Thu, 9 Feb 2023 08:34:51 +0200
From: Dov Murik <dovmurik@...ux.ibm.com>
To: "Michael S. Tsirkin" <mst@...hat.com>, qemu-devel@...gnu.org,
"Jason A. Donenfeld" <Jason@...c4.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Tom Lendacky <thomas.lendacky@....com>,
Gerd Hoffmann <kraxel@...hat.com>,
Daniel P. Berrangé <berrange@...hat.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Richard Henderson <richard.henderson@...aro.org>,
"H . Peter Anvin" <hpa@...or.com>,
Philippe Mathieu-Daudé <philmd@...aro.org>,
Nathan Chancellor <nathan@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Eric Biggers <ebiggers@...nel.org>,
Dov Murik <dovmurik@...ux.ibm.com>
Subject: Re: [PATCH RFC 0/7] revert RNG seed mess
On 09/02/2023 8:03, Dov Murik wrote:
> Hi Michael,
>
> On 08/02/2023 23:12, Michael S. Tsirkin wrote:
>> 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(-)
>>
>
>
> I tested this series with SEV measured boot using AmdSev OVMF. The boot
> succeeds, and the hashes computed for kernel/initrd/cmdline are
> identical to the ones computed by qemu 7.1.0, which are the hashes that
> the guest owner would expect.
>
I also tested that backporting this series to 7.2.0 (skipping
PATCH 1/7 because it was added after the 7.2.0 release) works OK for
booting SEV guest with AmdSev measured boot (and retains the same
kernel/initrd/cmdline hashes as qemu 7.1.0).
-Dov
> As for non-EFI (non-SEV) guests, I did a very simple test of starting a
> non-EFI guest and it looks OK, but more testing is needed.
>
> So:
>
> Tested-by: Dov Murik <dovmurik@...ux.ibm.com>
>
>
> Thank you!
>
> -Dov
Powered by blists - more mailing lists