From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
"Laurent Vivier" <laurent@vivier.eu>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Ard Biesheuvel" <ardb@kernel.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Daniel P. Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH v2 1/2] x86: only modify setup_data if the boot protocol indicates safety
Date: Tue, 6 Sep 2022 12:51:50 +0200 [thread overview]
Message-ID: <YxcmRhwrtGBsMGev@zx2c4.com> (raw)
In-Reply-To: <YxclCJ3FKSE6neu/@zx2c4.com>
On Tue, Sep 06, 2022 at 12:46:32PM +0200, Jason A. Donenfeld wrote:
> On Tue, Sep 06, 2022 at 06:45:34AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Sep 06, 2022 at 12:43:55PM +0200, Jason A. Donenfeld wrote:
> > > On Tue, Sep 6, 2022 at 12:40 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Tue, Sep 06, 2022 at 12:36:56PM +0200, Jason A. Donenfeld wrote:
> > > > > It's only safe to modify the setup_data pointer on newer kernels where
> > > > > the EFI stub loader will ignore it. So condition setting that offset on
> > > > > the newer boot protocol version. While we're at it, gate this on SEV too.
> > > > > This depends on the kernel commit linked below going upstream.
> > > > >
> > > > > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > > > > Cc: Laurent Vivier <laurent@vivier.eu>
> > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > > > > Cc: Peter Maydell <peter.maydell@linaro.org>
> > > > > Cc: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > > > > Cc: Richard Henderson <richard.henderson@linaro.org>
> > > > > Cc: Ard Biesheuvel <ardb@kernel.org>
> > > > > Link: https://lore.kernel.org/linux-efi/20220904165321.1140894-1-Jason@zx2c4.com/
> > > > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> > > >
> > > > BTW what does it have to do with SEV?
> > > > Is this because SEV is not going to trust the data to be random anyway?
> > >
> > > Daniel (now CC'd) pointed out in one of the previous threads that this
> > > breaks SEV, because the image hash changes.
> > >
> > > Jason
> >
> > Oh I see. I'd add a comment maybe and definitely mention this
> > in the commit log.
>
> Sure, will do.
Actually, I'm wrong. This is already done implicitly below with a huge
comment:
/*
* If we're starting an encrypted VM, it will be OVMF based, which uses the
* efi stub for booting and doesn't require any values to be placed in the
* kernel header. We therefore don't update the header so the hash of the
* kernel on the other side of the fw_cfg interface matches the hash of the
* file the user passed in.
*/
if (!sev_enabled()) {
memcpy(setup, header, MIN(sizeof(header), setup_size));
}
So I'll remove the SEV bit from this commit. Whoops. Glad you asked
about it.
Jason
next prev parent reply other threads:[~2022-09-06 12:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220906103657.282785-1-Jason@zx2c4.com>
2022-09-06 10:40 ` [PATCH v2 1/2] x86: only modify setup_data if the boot protocol indicates safety Michael S. Tsirkin via
2022-09-06 10:43 ` Jason A. Donenfeld
2022-09-06 10:45 ` Michael S. Tsirkin
2022-09-06 10:46 ` Jason A. Donenfeld
2022-09-06 10:51 ` Jason A. Donenfeld [this message]
2022-09-06 11:27 ` [PATCH v3 " Jason A. Donenfeld
2022-09-06 11:27 ` [PATCH v3 2/2] x86: re-enable rng seeding via setup_data Jason A. Donenfeld
2022-09-07 7:59 ` Gerd Hoffmann
2022-09-06 11:14 ` [PATCH v2 1/2] x86: only modify setup_data if the boot protocol indicates safety Ard Biesheuvel
2022-09-06 11:33 ` Daniel P. Berrangé
2022-09-08 11:30 ` Laszlo Ersek
2022-09-08 12:28 ` Ard Biesheuvel
2022-09-08 12:42 ` Daniel P. Berrangé
2022-09-06 10:46 ` Gerd Hoffmann via
2022-09-06 10:48 ` Jason A. Donenfeld
2022-09-06 10:27 [PATCH] " Jason A. Donenfeld
2022-09-06 10:37 ` [PATCH v2 1/2] " Jason A. Donenfeld
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=YxcmRhwrtGBsMGev@zx2c4.com \
--to=jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=berrange@redhat.com \
--cc=f4bug@amsat.org \
--cc=kraxel@redhat.com \
--cc=laurent@vivier.eu \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.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.