From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A2A2C2272961C for ; Thu, 12 Apr 2018 10:10:42 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F122C406805A; Thu, 12 Apr 2018 17:10:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-142.rdu2.redhat.com [10.10.120.142]) by smtp.corp.redhat.com (Postfix) with ESMTP id E4E2110B0082; Thu, 12 Apr 2018 17:10:40 +0000 (UTC) To: Gary Lin , Ard Biesheuvel , Jordan Justen Cc: edk2-devel@lists.01.org References: <20180411104247.3758-1-lersek@redhat.com> <20180411104247.3758-2-lersek@redhat.com> <20180412070825.46rnknrjmg46sw3j@GaryWorkstation> <1549bd6e-9cca-6727-f9b9-4a00eeb06988@redhat.com> <20180412091024.ha3z6felf4qwylc2@GaryWorkstation> <20180412101711.2aszvfvwde4wahkx@GaryWorkstation> From: Laszlo Ersek Message-ID: Date: Thu, 12 Apr 2018 19:10:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180412101711.2aszvfvwde4wahkx@GaryWorkstation> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 12 Apr 2018 17:10:42 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 12 Apr 2018 17:10:42 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH v2 1/9] OvmfPkg/TlsAuthConfigLib: configure trusted cipher suites for HTTPS boot X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 17:10:42 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit (comment/question at the end for Ard and Jordan) On 04/12/18 12:17, Gary Lin wrote: > On Thu, Apr 12, 2018 at 11:43:35AM +0200, Laszlo Ersek wrote: >> On 04/12/18 11:10, Gary Lin wrote: >>> On Thu, Apr 12, 2018 at 10:49:15AM +0200, Laszlo Ersek wrote: >>>> On 04/12/18 09:08, Gary Lin wrote: >>>>> On Wed, Apr 11, 2018 at 12:42:39PM +0200, Laszlo Ersek wrote: >>>>>> Read the list of trusted cipher suites from fw_cfg and to store it to >>>>>> EFI_TLS_CA_CERTIFICATE_VARIABLE. >>>>>> >>>>>> The fw_cfg file is formatted by the "update-crypto-policies" utility on >>>>>> the host side, so that the host settings take effect in guest HTTPS boot >>>>>> as well. QEMU forwards the file intact to the firmware. The contents are >>>>>> forwarded by NetworkPkg/HttpDxe (in TlsConfigCipherList()) to >>>>>> NetworkPkg/TlsDxe (TlsSetSessionData()) and TlsLib (TlsSetCipherList()). >>>>>> >>>>> Hi Laszlo, >>>>> >>>>> The description mentioned "update-crypto-policies" to format the cipher >>>>> list. The command is not available in openSUSE and I downloaded the command >>>>> from github repo[*]. However, I didn't find any command in the repo >>>>> could create the binary cipher list. >>>> >>>> Right, that feature is underway, and the Crypto team has agreed to >>>> implement it for me. My apologies for being unclear about it. Until >>>> then, a small shell script like the following can be used: >>>> >>>> ----- >>>> 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 >>>> ----- >>>> >>> It would be good to have this script in the description or in the README >>> so that the person who doesn't have the updated update-crypto-policies, >>> like me, can easily generate the cipher list. >> >> I can include this in the commit message, sure. >> >> If you think OvmfPkg/README would be a better place for it: can you >> please submit a patch? ;) It's not just that I'm overloaded (although I >> am), but I always welcome documentation contributions with enthusiasm. >> If the documentation captures real life "user stories", that's for the best. >> >> You could introduce an "HTTPS Boot" section to the README, between >> "Network Support" and "OVMF Flash Layout". You contributed quite a bit >> to HTTPS enablement anyway! >> > Sounds good. I'm also thinking about collecting the fw_cfg entries in > OVMF and documenting them in README. Currently, those entries look like > black magic to the users. Indeed, the fw_cfg entries should ultimately not be used by end-users directly. If that had been the case, I would have chosen different fw_cfg pathnames. Please refer to the following file under QEMU: docs/specs/fw_cfg.txt = Externally Provided Items = That is, if the -fw_cfg cmdline option had been the intended user interface for this feature, then I would have chosen an "opt/" prefix. I chose "etc/" because the pathnames are QEMU-defined (not user-defined), except the QEMU patches will be written later (and it might not be me either). It's too bad that the RHBZs that track this feature (across multiple components) are all private, so I couldn't link them in the blurb and/or the commit messages. Those RHBZs provide a more comprehensive background. They are private because... well don't ask me. I didn't make them private, they got auto-created like that, and I'm sure you know that, if *you* flip a BZ from private to public, then the burden is on *you* to defend your decision facing unpredictable parts of your organization. While I totally disagree with any of these RHBZs being private, I know better than to make them public myself :) >> It's up to you, of course :) If you don't have the time, I'll add the >> script to the commit message. >> > I can find some time next week. No guarantee though ;) Sure, please take your time. (And thank you for taking on the README update.) Meanwhile I'll push these patches with the commit message updates discussed. Ard, Jordan: Gary tested and reviewed this patch (bunch of kudos for that!), but still, can one of you guys please ACK it too? I prefer the patch to go in with maintainer blessing. Similarly to commit 9c7d0d499296 ("OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot", 2018-03-30). Thanks! Laszlo