Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/

[Laszlo Ersek <lersek@redhat.com>]

On 03/16/16 21:31, Michael S. Tsirkin wrote:
> On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
>> OVMF uses this feature for a few flags. They are all called
>> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which
>> shouldn't be surprising since I seem to have reviewed every patch for
>> that file):
> 
> Wait a second.  You are saying upsteam OVMF puts files there.

Sorry, I wasn't clear enough. OVMF consumes files that are put there by
the user.

> If users add their own flags that happen to be in opt/ovmf/ then
> what happens? And how do they *know* they should avoid that?
> There's no warning, guest just breaks in various ways.
> 
> This is exactly the kind of mess I was worried about. We have a global
> namespace with no way to control what goes where.
> 
> opt/ was for end users not firmware.
> 
> The right thing to do would be for ovmf to reserve itself
> a directory under root.
> 
> This really needs more thought.  For now I'd suggest we drop the whole
> interface from 2.6 and come back to it after 2.6.

I very strongly disagree. -fw_cfg was invented exactly for the purpose
that guest code (mostly, but not exclusively, guest firmware code) can
take settings from the user without QEMU's knowledge. We were conscious
of the namespace question, which is why the opt/ prefix was strongly
recommended for such knobs. Trying to control it all from QEMU (beyond
setting aside the opt/ subdirectory, regardless if it's worded "should"
or "must"), introducing a central registry for prefixes, would defeat
the entire purpose.

Subdividing the namespace under opt/ was purposely left open. Then I
went with opt/ovmf/ for files that OVMF should take from users because
that's the obvious choice.

If we want to be extremely paranoid about the namespace, we can modify
the recommendation to say "use opt/UUID/...", where UUID is generated
with "uuidgen". That's just an example I know from UEFI; it is how the
entire namespace question is side-stepped without a central registry.
Nonetheless, OVMF is the second of two guest firmwares in total, so
"opt/ovmf/" is the obvious choice.

Removing the interface would break existing code in OVMF that (a)
consumes opt/ovmf/... files and (b) doesn't disturb anything at all
otherwise.

Plus, the -fw_cfg option was released in 2.4 (added around commit
81b2b81062).

Laszlo