- Move the feature boundary from between QEMU 5.0 and 5.1 to 5.1<->5.2
(the necessary upstream QEMU commit 4318432ccd3f will only be released
as part of 5.2). Update both the README contents and the commit
message.
- Indent the "Using QEMU <version>" list entries, and prefix them with a
hyphen, for better separation. [Phil]
- Pick up Gary's R-b.
- Pick up Phil's R-b.
- Do not pick up Phil's T-b.
Repo: https://pagure.io/lersek/edk2.git
Branch: tianocore_2852_v2
OvmfPkg/README | 24 ++++++++++++--------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/README b/OvmfPkg/README
index 3dd28474ead4..70f0c4152686 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -294,67 +294,73 @@ and encrypted connection.
You can also append a certificate to the existing list with the following
command:
efisiglist -i <old certdb> -a <cert file> -o <new certdb>
NOTE: You may need the patch to make efisiglist generate the correct header.
(https://github.com/rhboot/pesign/pull/40)
* Besides the trusted certificates, it's also possible to configure the trusted
cipher suites for HTTPS through another fw_cfg entry:
etc/edk2/https/ciphers.
- -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
-
OVMF expects a binary UINT16 array which comprises the cipher suites HEX
IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
suite from the intersection of the given list and the built-in cipher
suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
built-in ones.
- While the tool(*5) to create the cipher suite array is still under
- development, the array can be generated with the following script:
+ - Using QEMU 5.2 or later, QEMU can expose the ordered list of permitted TLS
+ cipher suites from the host side to OVMF:
+
+ -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \
+ -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0
+
+ (Refer to the QEMU manual and to
+ <https://gnutls.org/manual/html_node/Priority-Strings.html> for more
+ information on the "priority" property.)
+
+ - Using QEMU 5.1 or earlier, the array has to be passed from a file:
+
+ -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
+
+ whose contents can be generated with the following script, for example:
export LC_ALL=C
openssl ciphers -V \
| sed -r -n \
-e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
| xargs -r -- printf -- '%b' > ciphers.bin
This script creates ciphers.bin that contains all the cipher suite IDs
supported by openssl according to the local host configuration.
You may want to enable only a limited set of cipher suites. Then, you
should check the validity of your list first:
openssl ciphers -V <cipher list>
If all the cipher suites in your list map to the proper HEX IDs, go ahead
to modify the script and execute it:
export LC_ALL=C
openssl ciphers -V <cipher list> \
| sed -r -n \
-e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
| xargs -r -- printf -- '%b' > ciphers.bin
-* In the future (after release 2.12), QEMU should populate both above fw_cfg
- files automatically from the local host configuration, and enable the user
- to override either with dedicated options or properties.
-
(*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
(*2) p11-kit: https://github.com/p11-glue/p11-kit/
(*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
(*4)
https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
-(*5) update-crypto-policies:
https://gitlab.com/redhat-crypto/fedora-crypto-policies
=== OVMF Flash Layout ===
Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
appears in QEMU's physical address space just below 4GB (0x100000000).
OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
Using the 1MB or 2MB image, the layout of the firmware device in memory looks
