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

Reply via email to