From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web12.2068.1600189797535473919 for ; Tue, 15 Sep 2020 10:09:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Jxh3X/5u; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: philmd@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600189796; 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=U9vGZOGNY/FuxXvtXUdrD/bLk1QQDcSh0rMaiQp8R44=; b=Jxh3X/5uc42+ceLNJvSwFhNhMSmjQXz8KM9y2o+wswPDY2yQ43XhbqaD46STQikMaMdkkB rt+2V9KpWzsPps6zlje2vWIUqR3jLQyBnVmKjc4vY5RgPjV/RJSjzNaH3LjvlHB0EGm5KK nzol9drLsJeU2zocCJu/xK64Ip8nzm8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-188-fm1dvbRUNVededsuqzIlIA-1; Tue, 15 Sep 2020 13:09:51 -0400 X-MC-Unique: fm1dvbRUNVededsuqzIlIA-1 Received: by mail-wm1-f72.google.com with SMTP id c200so62796wmd.5 for ; Tue, 15 Sep 2020 10:09:51 -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=U9vGZOGNY/FuxXvtXUdrD/bLk1QQDcSh0rMaiQp8R44=; b=F8MXQqZYDeOK4ZcDT5IKM7yQ+/enH8q0/YZNxEOUbgejDKhi1F9vkgMc06QXDZjs3N ln9yGXTnRfCfnrKq+aMPOx3hWjw/BaE8ZWLDOAtjZ6v3RVDJE7N9GvcB4Zp9maMjelnx Bn1m2G/58FzMrA8GHJz6L9x/4se2tMdIZF3my2B0UVcWKwrI4sslKIfn+s/as3WxxFMr jWyhMgqe90txTBsPNL0KTCAFKLiaKCPKIamaSa3Nfb32bsa34ay6yYfMyBDx2khg2gWg ydDxKsp6KBwrzIsPArvAocl0A4x/nWzAMTpLY5hwq6zwYqKvMYjO0amFxtg92+EFwU2T lYrg== X-Gm-Message-State: AOAM530w/dQRDjmgXFSKlkgN4XXo6VY6jqKvwGowbgKxuPEgMQwtxajV JbospD0pu1SaJ2rDqy0vyqYh/bt+F49vtLiEYpJ7m1Av9dvNY+8BsfMAdl8/D9aKYlS03ZFwAdV O5hx0KYXvryreFg== X-Received: by 2002:a7b:c210:: with SMTP id x16mr347162wmi.37.1600189790056; Tue, 15 Sep 2020 10:09:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKXAgIptBezJlQv7WPTqmY1Gns9QiStT2l6fOWVBcamzdif+t24oImgwj3R8hXmVQVEaaiPA== X-Received: by 2002:a7b:c210:: with SMTP id x16mr347134wmi.37.1600189789790; Tue, 15 Sep 2020 10:09:49 -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 n21sm334067wmi.21.2020.09.15.10.09.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Sep 2020 10:09:49 -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: Tue, 15 Sep 2020 19:09:47 +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: 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 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). > > 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 >>> >> >