public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
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


  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