Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek <lersek@redhat.com>]

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