[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/
Date: Thu, 17 Mar 2016 10:43:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 03/17/16 09:42, Gerd Hoffmann wrote:
>   Hi,
>>> Having a mis-use of this feature become "institutionalized" over time was
>>> seen as a low/negligible risk at the time. Do we have any new reasons
>>> to worry about it ?
>> 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):
> seabios has a few flags too, in etc/.  Some of them are supported
> directly by qemu (such as setting the boot menu delay).  Others are not,
> and I'd like to be able to use -fw_cfg for them for testing/debugging
> (any use cases beyond that should be supported by adding a less obscure
> way to set them to qemu, similar to the boot delay).
> Oh, and that'll most likely be more seabios testing than qemu testing,
> so why require me build a special qemu version for that?


> On the ovmf flags:  What kind of flags are there?  Anything a normal
> user might want to set?

Occasionally, yes.

- "opt/ovmf/PcdPropertiesTableEnable" controls whether the "properties
table" UEFI feature is enabled. Some guest OSes support it, some others
are broken by it. It defaults to false.

- "opt/ovmf/PcdSetNxForStack" controls whether the stack is made
non-executable at the start of the DXE phase. This is meant as a
security feature in edk2 generally, it is not specific to OVMF; only the
way it is exposed to users is specific to OVMF. It used to default to
TRUE, but then people reported that a non-executable stack was breaking
grub2-efi binaries that had been shipped on Debian installer ISOs
sometime during the middle ages. So I was forced to change the default
to FALSE (and I hate that compromise to this day).

- "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which the
64-bit MMIO BARs are allocated. It defaults to 32GB (and as you
suggested, a natural alignment is also ensured, both for the default
32GB, and for the user's choice, if any). The "X-" prefix signals that
this is an experimental knob without any promise of stability. There are
two imporant use cases for this knob at the moment: (a) if a user has a
bunch of MMIO-hungry assignable devices, allow him/her to experiment
with this flag, and report his/her data to us, so we can come up with
smart heuristics, (b) allow a user to disable the high allocation of
64-bit MMIO BARs entirely, by setting the value to 0.

The edk2 BAR allocation code prefers to allocate 64-bit BARs actually
high -- unlike SeaBIOS --, and this has already exposed problems. For
example, such devices don't work -- at the moment -- behind PXBs, if you
use OVMF. Marcel is going to enhance PXB to support this (thank you!),
but even until then (and for yet unknown similar issues), this flag
allows a user to force the edk2 allocator to keep those 64-bit BARs
under 4GB, at least if there is enough room for them there.)

In downstream, we have two more (same purpose but separately for ARM and
- opt/aavmf/PcdResizeXterm
- opt/ovmf/PcdResizeXterm

(These settings are downstream only because the underlying feature that
they control was rejected by upstream.)

The feature they control is the following: assume you are at the UEFI
shell prompt, and you have at least two console devices (e.g., one
serial console you are looking at in xterm, and one video display you
are looking at with spice), with the text output being mirrored to both.
The MODE command allows you to select various text resolutions that are
supported by all of your console devices simultaneously. Let's say you
change from the default 80x25 to 100x31. This will correctly resize your
video display, and also change the textual resolution used on the serial
console, but it will *not* resize your xterm. Which means the serial
console output will be garbled when you scroll, when you use commands
that print wide tables, and so on. If the user sets the above knob to Y,
then the xterm will also be resized (via control sequences). Sometimes
this feature is invaluable, sometimes it's very annoying. It defaults to N.

- Another flag I might expose later is "PcdHiiOsRuntimeSupport". This
would control whether various bits of UEFI configuration that are
normally accessible through TUI forms in the UEFI setup are also exposed
as a large binary blob to the runtime OS. As I understand it, this
feature is meant to allow OS-level vendor applications to mess with
various firmware settings. For now OVMF inherits the central default Y.
It is somewhat costly, so I think I'll flip the default for OVMF to N,
but expose the knob under "opt/ovmf/PcdHiiOsRuntimeSupport" to support
people who want to experiment with this.


The X-... knob might go away at any time, the others are likely to stay.

And, obviously, exposing this kind of knob with dedicated QEMU options
is out of question.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]