From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 6A70A21E0BA17 for ; Mon, 5 Feb 2018 02:41:18 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 56A3249003; Mon, 5 Feb 2018 10:46:59 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-166.rdu2.redhat.com [10.10.120.166]) by smtp.corp.redhat.com (Postfix) with ESMTP id ED37A608F0; Mon, 5 Feb 2018 10:46:56 +0000 (UTC) To: "Wu, Jiaxin" , "Kinney, Michael D" , "Fu, Siyuan" , "Ye, Ting" , "Li, Ruth" , "Long, Qin" , "Yao, Jiewen" , "Hsiung, Harry L" Cc: edk2-devel-01 References: <5307d880-d016-ad91-04f5-6b83eb40f905@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635E571@SHSMSX103.ccr.corp.intel.com> <7b529d2c-1e46-3bd5-d8a6-9225a630f23b@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F0B5@SHSMSX103.ccr.corp.intel.com> <366c3083-0eb1-ecb4-2050-654c09135f8a@redhat.com> <93bf358e-7e57-a0f0-b8ba-239e72036c27@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F6BC@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B72741635F7FE@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B72741635F9AF@SHSMSX103.ccr.corp.intel.com> <925c091e-af14-2449-e3ba-f8d6302dea49@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635FE91@SHSMSX103.ccr.corp.intel.com> <99394818-f0d5-8566-c1f7-240004e5cedd@redhat.com> <895558F6EA4E3B41AC93A00D163B72741637DE9E@SHSMSX103.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <49d94fe2-5953-61bf-6252-42fa77eb08fb@redhat.com> Date: Mon, 5 Feb 2018 11:46:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <895558F6EA4E3B41AC93A00D163B72741637DE9E@SHSMSX103.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 05 Feb 2018 10:46:59 +0000 (UTC) Subject: Re: setting the TLS cipher list for HTTPS booting X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 10:41:18 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/05/18 04:33, Wu, Jiaxin wrote: > Hi Laszlo, > > In recent days, we received the comment from Kinney about the PCD > usage in UEFI driver. Kinney doesn't recommend us to use the *dynamic > PCD* in *soft-loading* UEFI driver even though it's not prohibited. > > So, we want to confirm with you whether this is the urgent request > need us to support it ASAP or it's in low priority. > > If you need us support the feature ASAP, we can use the private > variable solution as we discussed before since there is no security > issue and the size requirement is not big. > > If not urgency, we might consider whether need to define a platform to > driver configuration protocol or not. You know it will take a long > time to scandalize one protocol for platform HTTPS configuration in > the future UEFI spec. The variable approach sounds good to me, but with a small twist: Could we please leave it up to the platform whether the private variable is non-volatile versus volatile? Because platform X might want to configure the cipher suite list once, permanently, while platform Y might want to configure the cipher suite list dynamically on each boot. For platform Y, spending any flash space (and flash writing time) on the variable is superfluous. For QEMU / OVMF specifically, I would prefer a volatile, boot-time only variable. After setting this variable, I think OVMF platform code should even lock it down with the edk2 variable lock protocol. In effect this would behave like a "read only" PCD -- no flash impact at all. As long as HttpDxe only calls gRT->GetVariable() (or equivalent wrappers from UefiLib) on the new variable, the variable's attributes should not matter; they can be left to the platform. Thanks! Laszlo >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Thursday, January 25, 2018 8:42 PM >> To: Wu, Jiaxin ; Fu, Siyuan ; Ye, >> Ting ; Long, Qin ; Yao, Jiewen >> ; Hsiung, Harry L >> Cc: edk2-devel-01 >> Subject: Re: setting the TLS cipher list for HTTPS booting >> >> On 01/25/18 05:52, Wu, Jiaxin wrote: >>> Hi Laszlo, >>> >>> The HttpDxe driver needs to install the Driver Binding Protocol so as >>> to check if a specific controller is supported by HttpDxe. HttpDxe >>> can only be started if the TcpServiceBindingProtocol existed. So, it >>> has to follow the UEFI Driver Model. >>> >>> For the PCD usage, I think it should be fine to cover the >>> configuration of UEFI Drivers through the PCD settings. The >>> requirement of *.inf needs to include the PcdLib and the section of >>> [Pcd]. We already have the similar pattern for this usage, for >>> example, Ps2KeyboardDxe, PciBusDxe, PciSioSerialDxe, and etc in >>> MdeModulePkg. Besides, there are some advantages by using PCD >>> compared to the variable. First, PCD is one kind of interface that >>> more formal than a private variable, the setting by PCD is more >>> acceptable by the consumer. Secondly, from a *security* standpoint, >>> variable can be dumped easily from the flash region. Here, even >>> though it's no security impact towards the cipher list storage >>> because it will be public shared to remote server, but we need to >>> think and *align* with other configurations for TLS in HTTPS level. >>> For example, in the future, we might support the HTTPS mutual >>> authentication, than the host PrivateKey/Password >>> (EfiTlsConfigDataTypeHostPrivateKey) *mustn't* be saved as a variable >>> due to its confidentiality, while PCD is good choice. At that time, >>> we will also provide the PCD for EfiTlsConfigDataTypeCACertificate, >>> which is currently setting by the variable (TlsCaCertificate), so as >>> to align all the configuration setting on one line, which can reduce >>> the complexity of platform usage. Finally, we can also save the >>> variable space. >>> >>> From the above, the dynamic PCD is a solution I still preferred. >> >> OK, it works for me. Thanks! >> Laszlo