From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web10.17212.1600241758311248214 for ; Wed, 16 Sep 2020 00:35:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fuJE1oCy; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600241757; 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=IIUMXloUUM+evQEGmTr3d7VMbFniiH5iwwLkdi63Vwo=; b=fuJE1oCyK4Jjn4pUo1/b83/BB1ArcSZHBWmdKUxwjp3uu7MkPi2+wK2AEK7c1RTzDPMRQz eE93p8MEUZ7eBEaV50q677yQu5d+I3gc9qeT6mVKgCjiO1adbjhEFU7wQwPDlCHxfBqazW blawQKDt92dq6yKBL7MOgwGxdXfX8ig= 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-144-lRdbWQyIMoWsoLYOk0GhPQ-1; Wed, 16 Sep 2020 03:35:50 -0400 X-MC-Unique: lRdbWQyIMoWsoLYOk0GhPQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 84E0F425CE; Wed, 16 Sep 2020 07:35:49 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-213.ams2.redhat.com [10.36.113.213]) by smtp.corp.redhat.com (Postfix) with ESMTP id DF9C2610F2; Wed, 16 Sep 2020 07:35:47 +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: Wed, 16 Sep 2020 09:35:47 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US On 09/15/20 19:09, Philippe Mathieu-Daudé wrote: > Hi Laszlo, > > On 9/10/20 8:02 AM, Laszlo Ersek wrote: >> 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. > > I'd go with this possibility. Clear and easy. > >> >> - 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. > > (Note that would be my *visual* preference, but I don't think it's > worth it, I prefer we keep the diff short and easy to review). Agreed on both counts :) Thanks! Laszlo