summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2020-09-22 11:18:27 +0200
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>2020-09-22 16:27:58 +0000
commit3f3daf89308930e45f82ae67dd2a2d6e030bb091 (patch)
tree99174cc3e6f0a016c8cbc961e1f3ced3cc53da35
parentfb97626fe04747ec89599dce0992def9a36e2f6b (diff)
downloadedk2-3f3daf89308930e45f82ae67dd2a2d6e030bb091.tar.gz
edk2-3f3daf89308930e45f82ae67dd2a2d6e030bb091.tar.bz2
edk2-3f3daf89308930e45f82ae67dd2a2d6e030bb091.zip
OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding
In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU commit 4318432ccd3f), Phil implemented a QEMU facility for exposing the host-side TLS cipher suite configuration to OVMF. The purpose is to control the permitted ciphers in the guest's UEFI HTTPS boot. This complements the forwarding of the host-side crypto policy from the host to the guest -- the other facet was the set of CA certificates (for which p11-kit patches had been upstreamed, on the host side). Mention the new command line options in "OvmfPkg/README". Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200922091827.12617-1-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
-rw-r--r--OvmfPkg/README24
1 files changed, 15 insertions, 9 deletions
diff --git a/OvmfPkg/README b/OvmfPkg/README
index 3dd28474ea..70f0c41526 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -303,16 +303,27 @@ and encrypted connection.
* 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 \
@@ -337,15 +348,10 @@ and encrypted connection.
-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 ===