From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Ard Biesheuvel" <ardb@kernel.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
qemu-devel@nongnu.org, "Xiaoyao Li" <xiaoyao.li@intel.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Laszlo Ersek" <lersek@redhat.com>,
linux-efi@vger.kernel.org
Subject: Re: [PATCH v3] hw/i386: place setup_data at fixed place in memory
Date: Tue, 9 Aug 2022 05:17:16 -0400 [thread overview]
Message-ID: <20220809051644-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <0bd57fab-836b-9898-9e3f-84dc66eca175@redhat.com>
On Fri, Aug 05, 2022 at 07:29:29PM +0200, Paolo Bonzini wrote:
> On 8/5/22 13:08, Ard Biesheuvel wrote:
> > >
> > > Does it work to place setup_data at the end of the cmdline file instead
> > > of having it at the end of the kernel file? This way the first item
> > > will be at 0x20000 + cmdline_size.
> > >
> > Does QEMU always allocate the command line statically like that?
> > AFAIK, OVMF never accesses that memory to read the command line, it
> > uses fw_cfg to copy it into a buffer it allocates itself. And I guess
> > that implies that this region could be clobbered by OVMF unless it is
> > told to preserve it.
>
> No it's not. :( It also goes to gBS->AllocatePages in the end.
>
> At this point it seems to me that without extra changes the whole setup_data
> concept is dead on arrival for OVMF. In principle there's no reason why the
> individual setup_data items couldn't include interior pointers, meaning that
> the setup_data _has_ to be at the address provided in fw_cfg by QEMU.
>
> One way to "fix" it would be for OVMF to overwrite the pointer to the head
> of the list, so that the kernel ignores the setup data provided by QEMU.
> Another way would be to put it in the command line fw_cfg blob and teach
> OVMF to use a fixed address for the command line. Both are ugly, and both
> are also broken for new QEMU / old OVMF.
>
> In any case, I don't think this should be fixed so close to the release. We
> have two possibilities:
>
> 1) if we believe "build setup_data in QEMU" is a feasible design that only
> needs more yak shaving, we can keep the code in, but disabled by default,
> and sort it out in 7.2.
>
> 2) if we go for an alternative design, it needs to be reverted. For example
> the randomness could be in _another_ fw_cfg file, and the linuxboot DMA can
> patch it in the setup_data.
>
>
> With (2) the OVMF breakage would be limited to -dtb, which more or less
> nobody cares about, and we can just look the other way.
>
> Paolo
So IIUC you retract your pc: add property for Linux setup_data random
number seed then? It's neither of the two options above.
--
MST
next prev parent reply other threads:[~2022-08-09 9:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 17:02 [PATCH RFC v1] hw/i386: place setup_data at fixed place in memory Jason A. Donenfeld
2022-08-03 22:25 ` Michael S. Tsirkin
2022-08-03 22:50 ` Jason A. Donenfeld
2022-08-04 0:39 ` Jason A. Donenfeld
2022-08-04 0:44 ` [PATCH v2] " Jason A. Donenfeld
2022-08-04 7:03 ` Michael S. Tsirkin
[not found] ` <bfa5704d-755c-5a52-e7cc-bd9b34e5bb03@redhat.com>
2022-08-04 9:25 ` Daniel P. Berrangé
2022-08-04 10:26 ` Ard Biesheuvel
[not found] ` <eadc852a-63f9-a017-aef7-f046eb56e28f@redhat.com>
2022-08-04 12:11 ` Jason A. Donenfeld
2022-08-04 12:47 ` Jason A. Donenfeld
[not found] ` <5528ca40-50fb-8e92-7f24-80e20c4c983e@redhat.com>
2022-08-04 13:25 ` Jason A. Donenfeld
2022-08-04 12:03 ` Jason A. Donenfeld
2022-08-04 12:11 ` Daniel P. Berrangé
2022-08-04 12:16 ` Ard Biesheuvel
2022-08-04 12:17 ` Jason A. Donenfeld
2022-08-04 12:28 ` Jason A. Donenfeld
[not found] ` <cf60456e-a2cd-a64d-0cee-4bea30708fc9@redhat.com>
2022-08-04 13:28 ` Jason A. Donenfeld
[not found] ` <8254819e-d509-59f4-79e6-e8c0ba4eb2a6@redhat.com>
2022-08-04 14:03 ` Daniel P. Berrangé
2022-08-04 22:56 ` Jason A. Donenfeld
2022-08-04 23:04 ` [PATCH v3] " Jason A. Donenfeld
2022-08-05 8:10 ` Paolo Bonzini
2022-08-05 11:08 ` Ard Biesheuvel
2022-08-05 17:29 ` Paolo Bonzini
2022-08-05 17:56 ` Ard Biesheuvel
2022-08-09 9:17 ` Michael S. Tsirkin [this message]
2022-08-09 14:19 ` Paolo Bonzini
2022-08-05 12:47 ` Jason A. Donenfeld
2022-08-09 12:17 ` Jason A. Donenfeld
2022-08-09 14:07 ` Michael S. Tsirkin
2022-08-09 14:15 ` Daniel P. Berrangé
2022-08-16 8:55 ` [PATCH v2] " Gerd Hoffmann
2022-08-18 15:38 ` Jason A. Donenfeld
2022-08-19 6:40 ` Gerd Hoffmann
2022-08-19 7:16 ` Ard Biesheuvel
2022-08-04 12:54 ` Daniel P. Berrangé
2022-08-04 13:07 ` 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=20220809051644-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=xiaoyao.li@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox