From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web11.15594.1599717788826091559 for ; Wed, 09 Sep 2020 23:03:09 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HNAOax24; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599717788; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/gJ1fXhPHmKwyNQdtXX7/lJXIln2njdLbYhuJ5B2WEQ=; b=HNAOax245Yf8SECuZC7AmIluI87Pweb/TTlmREAFvYfP9p1E0M5Jgi2wpR3XnvH65VYc+n bQx0ml+kJgpOu4txXDEy/dnOgVBdipXXyymqWEpU/U5k/9L9Ihn+F29hvAdsAdePh6RGlu nsuF7IQxZLi2f3MWUpRLNnOCpqtbsdo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-84-K5R3687qN-a0IQ6z8gOgXg-1; Thu, 10 Sep 2020 02:03:00 -0400 X-MC-Unique: K5R3687qN-a0IQ6z8gOgXg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 93A571084D65; Thu, 10 Sep 2020 06:02:58 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-181.ams2.redhat.com [10.36.112.181]) by smtp.corp.redhat.com (Postfix) with ESMTP id 243ED702E7; Thu, 10 Sep 2020 06:02:56 +0000 (UTC) Subject: Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , edk2-devel-groups-io Cc: Ard Biesheuvel , Gary Lin , Jordan Justen References: <20200907161825.10893-1-lersek@redhat.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 10 Sep 2020 08:02:56 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US On 09/09/20 18:21, Philippe Mathieu-Daudé wrote: > On 9/7/20 6:18 PM, 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". >> >> Cc: Ard Biesheuvel >> Cc: Gary Lin >> Cc: Jordan Justen >> Cc: Philippe Mathieu-Daudé >> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2852 > > Thanks for addressing this BZ for me... > >> Signed-off-by: Laszlo Ersek >> --- >> 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 -a -o >> >> 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= >> - >> 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 >> + for more >> + information on the "priority" property.) >> + >> + Using QEMU 5.0 or earlier, the array has to be passed from a file: > > What about using a '-' to list each "Using QEMU ..." and make the > separation clearer? I can do that, yes. There are three possibilities: - prefix just one line (in each affected paragraph) with the hyphen, - prefix the first line of each paragraph with the hyphen, plus indent the rest of the *same paragraph* by 2 spaces. - prefix the first line of each paragraph with the hyphen, plus indent the rest of the *text* that applies to the QEMU versions being discussed. Which one do you prefer? Thanks, Laszlo > > Regardless: > Reviewed-by: Philippe Mathieu-Daude > Tested-by: Philippe Mathieu-Daude > >> + >> + -fw_cfg name=etc/edk2/https/ciphers,file= >> + >> + 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 >> >> 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 \ >> | 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 >> >