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
