From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web12.436.1599668494288910227 for ; Wed, 09 Sep 2020 09:21:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GC+SMojr; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: philmd@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599668493; 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:autocrypt:autocrypt; bh=KsPYIDMTSe1RH6iCiFwaa7NBXMqGUqJ3COyOa/bVpuI=; b=GC+SMojr9nIUSBuYyelX69p+WIKPfrtCnXOquSTqE+Y3lhmA3OEGP9zxoxZtrR9ihcfojZ aZGpKSQBdOljVxixXkU60WDSgLJ8ZfJXquha7VJ/6Hy9L58nLNvkOkYMeiVgx5+hlc8LfD EYo5NjSxd6B1QRN1WR/5sFDDOCkAuA8= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-373-xikmhwbeM-WEKDmPPMympA-1; Wed, 09 Sep 2020 12:21:15 -0400 X-MC-Unique: xikmhwbeM-WEKDmPPMympA-1 Received: by mail-wr1-f69.google.com with SMTP id k13so1160647wrl.4 for ; Wed, 09 Sep 2020 09:21:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KsPYIDMTSe1RH6iCiFwaa7NBXMqGUqJ3COyOa/bVpuI=; b=mC2d+i6t+IZaz52atjUjuYjMJXlFJU0WOaE7eAQI203SxIU4axMqhbQxcu/RaLv/QD 8eaRFlAck1bJjlY8Eg2JYjbe5GX2R1MuAtG5yMWeQDJLSWG9/7mDc95GlwRk72hVZAv6 bj7M3RbsiTO35N5b/aWMt/T4yM0H+JXMFrvKKxeRnS4nAVS9dlLkAX0GKY0QnJmcV6pt nUBb5KSGnTwet/mk+KS9t8gf4HkChzMmYDBIxDxerKRcQvwTnWumwwY0bnAGbrKD3vcZ OgZ1QbggMAZkzCTL7dRiQGYtPzr5tipL+Y3LMY9DdW3PUXYyifEhOcYMBqTTClY2f6r5 REMg== X-Gm-Message-State: AOAM530EIR+IamLu38H90ZILuU7YSUKcAFWMZDlalJ2yEXAChsAkLUl0 F6kFNN48HgrPGjguCDvFt02V1DIrDF53sNF7XP8ap9I1Zhb8wZdL9y+zZ/9ATCushOqExpL5a97 +yZj7WzgFDZntnA== X-Received: by 2002:a1c:740c:: with SMTP id p12mr4266157wmc.176.1599668474453; Wed, 09 Sep 2020 09:21:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynDSW7h0nsp/P2gR/eZDEZmJciW4kxKSS6Zyw/23w+Pgi+nV7nxyfid2Tdf2OwBPL5BYiLKg== X-Received: by 2002:a1c:740c:: with SMTP id p12mr4266136wmc.176.1599668474221; Wed, 09 Sep 2020 09:21:14 -0700 (PDT) Return-Path: Received: from [192.168.1.36] (65.red-83-57-170.dynamicip.rima-tde.net. [83.57.170.65]) by smtp.gmail.com with ESMTPSA id d18sm5151657wrm.10.2020.09.09.09.21.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2020 09:21:13 -0700 (PDT) Subject: Re: [PATCH] OvmfPkg/README: HTTPS Boot: describe host-side TLS cipher suites forwarding To: Laszlo Ersek , edk2-devel-groups-io Cc: Ard Biesheuvel , Gary Lin , Jordan Justen References: <20200907161825.10893-1-lersek@redhat.com> From: =?UTF-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: Date: Wed, 9 Sep 2020 18:21:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200907161825.10893-1-lersek@redhat.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@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 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? 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 >