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. Thanks, Jiaxin > -----Original Message----- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, January 25, 2018 8:42 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, > Ting <ting...@intel.com>; Long, Qin <qin.l...@intel.com>; Yao, Jiewen > <jiewen....@intel.com>; Hsiung, Harry L <harry.l.hsi...@intel.com> > Cc: edk2-devel-01 <edk2-devel@lists.01.org> > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
