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.web11.4389.1600767210218594559 for ; Tue, 22 Sep 2020 02:33:30 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Enp9v+vV; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: philmd@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600767209; 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=az4EMDdP4AxYb881GF/w7nSDy30h5sz14FfwuDTBIhw=; b=Enp9v+vViLtVGceg3RATypafSwgVLOTNsf6QHHhkupHPxydDKiUkkx36Vq/ipXYV9qKP6w veCi38ugPwGkx5DLtAoD4GCv+qCxklW7St+Px3G2IZkHaZgnu7v88vYwRU3MI1WcReg5zF TERMqEMCTNxnARQ1T26YdVz6Cfb3jZQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-28-ZLgUy1bhOeyHYZIhBQGlcw-1; Tue, 22 Sep 2020 05:33:27 -0400 X-MC-Unique: ZLgUy1bhOeyHYZIhBQGlcw-1 Received: by mail-wm1-f70.google.com with SMTP id m25so688667wmi.0 for ; Tue, 22 Sep 2020 02:33:27 -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=az4EMDdP4AxYb881GF/w7nSDy30h5sz14FfwuDTBIhw=; b=BKyzPk23fbOUL9BGKhUU+zyfn/8tcTD4cUOGa+AnCrrIOtSBle2alzppx99TDMr/Vk 4ls3zYIyDAbEYdTNuV7b85vq0JQY9IhQMIZA4I8cnDm83vIJ/S3PeboU/teYxYa3igC9 wzhuf/vSP/BjUJrBu0RLIs9YTopCTkboVZmy2o3dTz3rkTS5+G62S+elGpJUsqlaWXmQ q2ISDB34+POU1RnhRZFBdhyRCSUw0YQ+qG++hdavFw0U1mg9/bFYqveL/pB5t8I29ZK4 Dsr/bIRKeYLdoqPMGMJnBvrT4wTsRj2ZvJ17AfIoqiJXgEUebet9YGFQWp4bTSmNIwiW 4Bug== X-Gm-Message-State: AOAM5339TOTxC111ZaujXNT17GwKkm1+rBF7pqlyQzDdII4VvlTnNb2T jbKhap1WtCNpDH2JGt1jebdhE/zZY5Nb3hSCybbqgUOYWLKc4KuBWqA3mObDbgENM0RQevvxudn +JI0drZIPZm6uRA== X-Received: by 2002:a1c:a988:: with SMTP id s130mr666wme.31.1600767206233; Tue, 22 Sep 2020 02:33:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXQfp0pOK7DLH/S1GMteiGpWVqsBmAObrA9dRWi1IN6Rko66O4P7TPE3GCReYbG1Pxkke07w== X-Received: by 2002:a1c:a988:: with SMTP id s130mr639wme.31.1600767205930; Tue, 22 Sep 2020 02:33:25 -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 i15sm26094813wrb.91.2020.09.22.02.33.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2020 02:33:25 -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: <20200922091827.12617-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, 22 Sep 2020 11:33:24 +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: <20200922091827.12617-1-lersek@redhat.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US On 9/22/20 11:18 AM, Laszlo Ersek wrote: > In QEMU commit range 4abf70a661a5..69699f3055a5 (later fixed up in QEMU > commit 4318432ccd3f), 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 > Signed-off-by: Laszlo Ersek > Reviewed-by: Gary Lin > Reviewed-by: Philippe Mathieu-Daudé > --- > > Notes: > v2: > > - Move the feature boundary from between QEMU 5.0 and 5.1 to 5.1<->5.2 > (the necessary upstream QEMU commit 4318432ccd3f will only be released > as part of 5.2). Update both the README contents and the commit > message. :/ Thanks for the updates in v2, all good now. > > - Indent the "Using QEMU " list entries, and prefix them with a > hyphen, for better separation. [Phil] > > - Pick up Gary's R-b. > > - Pick up Phil's R-b. > > - Do not pick up Phil's T-b. > > Repo: https://pagure.io/lersek/edk2.git > Branch: tianocore_2852_v2 > > OvmfPkg/README | 24 ++++++++++++-------- > 1 file changed, 15 insertions(+), 9 deletions(-) > > diff --git a/OvmfPkg/README b/OvmfPkg/README > index 3dd28474ead4..70f0c4152686 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.2 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.1 or earlier, the array has to be passed from a file: > + > + -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 >