On Mon, Sep 07, 2020 at 06:18:25PM +0200, Laszlo Ersek wrote: > In QEMU commit range 4abf70a661a5..69699f3055a5, 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".
Looks good to me :) Reviewed-by: Gary Lin <g...@suse.com> > > Cc: Ard Biesheuvel <ard.biesheu...@arm.com> > Cc: Gary Lin <g...@suse.com> > Cc: Jordan Justen <jordan.l.jus...@intel.com> > Cc: Philippe Mathieu-Daudé <phi...@redhat.com> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852 > Signed-off-by: Laszlo Ersek <ler...@redhat.com> > --- > OvmfPkg/README | 24 ++++++++++++-------- > 1 file changed, 15 insertions(+), 9 deletions(-) > > diff --git a/OvmfPkg/README b/OvmfPkg/README > index 3dd28474ead4..2009d9d29796 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.1 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.0 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 > -- > 2.19.1.3.g30247aa5d201 > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#65123): https://edk2.groups.io/g/devel/message/65123 Mute This Topic: https://groups.io/mt/76689975/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
