1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
|
# OVMF runtime configuration
Some aspects of OVMF can be configured from the host, mostly by adding
firmware config files using the qemu command line option `-fw_cfg`.
The official namespace prefix for edk2 is `opt/org.tianocore/` which
is used by most options. Some options are elsewhere for historical
reasons.
## TLS: etc/edk2/https/cacerts
This is a list of root CA certificates which the firmware should
accept when talking to TLS servers, stored in EFI signature database
format. Fedora and CentOS provide a copy of the host root CA database
(which is used by openssl & friends too) in the correct format. Using
that is as simple as:
```
qemu-system-x86_64 \
-fw_cfg name=etc/edk2/https/cacerts,file=/etc/pki/ca-trust/extracted/edk2/cacerts.bin
```
For a more strict configuration where only one or very few servers are
allowed (instead of pretty much any https server on the public
internet) you can use the `virt-fw-sigdb` utility from the
[virt-firmware project](https://gitlab.com/kraxel/virt-firmware) to
create a database with only these server certificates:
```
GUID=$(uuidgen)
virt-fw-sigdb -o mycerts.esl \
--add-cert ${GUID} /etc/pki/tls/certs/${server1}.crt \
--add-cert ${GUID} /etc/pki/tls/certs/${server2}.crt
qemu-system-x86_64 \
-fw_cfg name=etc/edk2/https/cacerts,file=mycerts.esl
```
## TLS: etc/edk2/https/ciphers
Configres the allowed TLS chiper suites. Using the host's system
configuration works this way:
```
qemu-system-x86_64 \
-object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
-fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
```
## Network: opt/org.tianocore/IPv4Support
As the name suggests, this enables/disables IPv4 support. Default:
enabled. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/IPv4Support,string=no
```
## Network: opt/org.tianocore/IPv6Support
Same for IPv6.
## Network: opt/org.tianocore/IPv4PXESupport
This enables/disables PXE network boot over IPv4. This does not
affect HTTP boot. Default: enabled. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=no
```
## Network: opt/org.tianocore/IPv6PXESupport
Same for IPv6.
## Network: opt/org.tianocore/VirtioNetSupport
This enables/disables the edk2 driver for virtio net devices.
Default: enabled. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/VirtioNetSupport,string=no
```
## Network: opt/org.tianocore/ISCSISupport
This enables/disables the edk2 driver for iSCSI.
Default: disabled. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/ISCSISupport,string=yes
```
## Security: opt/ovmf/PcdSetNxForStack
Set stack pages as not executable in page tables. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/ovmf/PcdSetNxForStack,string=yes
```
## Security: opt/org.tianocore/UninstallMemAttrProtocol
Do not provide the `EFI_MEMORY_ATTRIBUTE_PROTOCOL` protocol. This is
a workaround for a bug in shim version 15.6. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/UninstallMemAttrProtocol,string=yes
```
## Shell: opt/org.tianocore/EFIShellSupport
This enables/disables the EFI shell.
Default: enabled. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/EFIShellSupport,string=no
```
## Security: opt/org.tianocore/EnableLegacyLoader
OVMF can load linux kernels in two ways:
* modern: load them as EFI binary, let the linux kernel's EFI stub
handle initrd loading, exiting boot services etc.
* legacy: load kernel + initrd directly, patch kernel setup header
with initrd location, ...
OVMF will try the modern way first, in case of a failure fallback to
the legacy method. The legacy loader will not do secure boot
verification though. Disabling the legacy loader using this option
will plug that hole. It will also break booting prehistoric kernels
without EFI stub. If you are using kernels that old secure boot
support is the least of your problems though ...
The linux kernel is typically signed by the distro secure boot keys
and is verified by the distro `shim.efi` binary. qemu release 10.0
(ETA ~ March 2025) will get support for passing the shim binary
(additionally to kernel + initrd) to the firmware, so the usual secure
boot verification can work with direct kernel load too.
For now the legacy loader is enabled by default. Once the new qemu
release is available in most linux distros the defaut will be flipped
to disabled.
Usage (qemu 10.0+):
```
qemu-system-x86_64 \
-shim /boot/efi/EFI/${distro}/shimx64.efi \
-kernel /path/to/kernel \
-initrd /path/to/initamfs \
-append "kernel command line" \
-fw_cfg name=opt/org.tianocore/EnableLegacyLoader,string=no
```
## Platform: opt/org.tianocore/X-Cpuhp-Bugcheck-Override
On some older qemu versions CPU hotplug support was broken. OVMF
detects that and will by default log an error message and stop. When
setting this option OVMF will continue despite qemu being buggy. It
is only safe to set that option if you do not use CPU hotplug. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/X-Cpuhp-Bugcheck-Override,string=yes
```
## Platform: opt/ovmf/X-PciMmio64Mb
Historically OVMF has by default used 32GB of address space for the
64-bit PCI MMIO window. This option can be used to change that size.
Recent OVMF versions have started to use a larger MMIO window by
default, with the actual size depending on the address space size
supported by the CPU. With this the default configuration should
cover alot more use cases and it should be rather rare that this
option must be used to enlarge the MMIO window.
Usage example (128GB / 131072 MB):
```
qemu-system-x86_64 -fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=131072
```
## Platform: physical address space bits
OVMF will check the supported physical address space bits (via CPUID)
when creating the address space layout. OVMF will use the complete
available address space and place the 64-bit PCI MMIO window near the
top of the address space.
The `host-phys-bits-limit` property of the `-cpu` option can be used
to reduce the address space used by OVMF.
Usage:
```
qemu-system-x86_64 -cpu ${name},host-phys-bits=on,host-phys-bits-limit=42
```
## Platform: opt/org.tianocore/PagingLevel
Configure the number of paging levels (4 or 5) OVMF will use. Four
paging levels are better for compatibility, not all OSes can handle
5-level paging being active at ExitBootServices time. Five paging
levels are better for huge VMs, the address space managed by OVMF can
be larger.
Default: Use 5-level paging in case more than 1TB of memory is
present, 4-level paging otherwise.
Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/PagingLevel,string=5
```
## Other: opt/org.tianocore/UsbStorageSupport
This enables/disables the edk2 driver for USB storage devices.
Default: enabled. Usage:
```
qemu-system-x86_64 -fw_cfg name=opt/org.tianocore/UsbStorageSupport,string=yes
```
|
