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 55F4721E256B4 for ; Thu, 25 Jan 2018 04:36:15 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 854BF78556; Thu, 25 Jan 2018 12:41:44 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-47.rdu2.redhat.com [10.10.121.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83C6E1B482; Thu, 25 Jan 2018 12:41:42 +0000 (UTC) To: "Wu, Jiaxin" , "Fu, Siyuan" , "Ye, Ting" , "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> From: Laszlo Ersek Message-ID: <99394818-f0d5-8566-c1f7-240004e5cedd@redhat.com> Date: Thu, 25 Jan 2018 13:41:41 +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: <895558F6EA4E3B41AC93A00D163B72741635FE91@SHSMSX103.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 25 Jan 2018 12:41:44 +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: Thu, 25 Jan 2018 12:36:16 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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