Hi Laszlo,
After the discussion with team member, we still prefer to use the PCD solution.
In HttpDxe driver, we don't want to locate/use a nonstandard protocol. We think
It's not a general solution for the UEFI driver.
Thanks,
Jiaxin
> -----Original Message-----
> From: Wu, Jiaxin
> Sent: Wednesday, January 24, 2018 11:40 AM
> To: Wu, Jiaxin <jiaxin...@intel.com>; Laszlo Ersek <ler...@redhat.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
>
> Hi Laszlo,
>
> More comments:
>
> >
> > Dynamic PCDs is just one of the solutions for the required settings, just
> > like
> the
> > platform protocol (HTTPS_CONFIG_PROTOCOL), provides the capability to
> > support the global HTTPS configuration.
> >
> > Each solutions have its own advantages and disadvantages:
> > 1) PCD can simplify the problem and it's easy to use for the other platform
> not
> > only OVMF, but as you said, it's perhaps overkill.
> > 2) The additional platform protocol looks flexible and reasonably, but it
> makes
> > the specific platform have the optional dependency ["OVMF hooks a NULL-
> class
> > library into HttpDxe that introduces a new DEPEX on the protocol. Other
> > platforms would not delay HttpDxe."]. If the user doesn't want HTTPS feature
> > but only HTTP, it has to include one NULL protocol.
> >
>
> I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL,
> which makes me better understanding your comments.
>
> MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
> <LibraryClasses>
> ...
> NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
> }
>
> So, as you said, it's just the platform behavior so as to hook the platform
> produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch
> PciHostBridgeDxe driver. That's good to me.
>
> For HTTPS configuration, the HttpDxe configuration is only happened during the
> protocol instance calling, which is created by service binding protocol. So,
> it
> looks only happened after EndofDxe phase. If so, it will be no such optional
> dependency to wait for the platform DXE driver produces the
> EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL.
>
> Anyway, for above two solutions, I need review them with other colleagues and
> help to collect the comments for both of them, then feedback to you. Thank you
> so such.
>
>
> > Now, I think we are discussing the most appropriate way for the HTTPS
> > controlling. It's NOT related to who should be responsible for the solution
> > coding, you know we are always thinking from the user's perspective:).
> >
> >
> > > >
> > > > If you really think that HttpDxe should only care about these two items
> > > > (CA cert and cipher list), then I have another question: do you think it
> > > > makes sense to introduce another non-volatile UEFI variable, for the
> > > > cipher suites too? This would make things uniform, and perhaps
> > > > TlsAuthConfigDxe could expose the cipher suites too, as a list of
> > > > checkboxes. Just an idea.
> > >
> > > So, apparently we indeed care about these two options mostly, i.e., the
> > > CA certs, and the cipher suites.
> > >
> > > However, I was informed that OVMF should simply forward the *textual*
> > > cipher list representation, with preferably no processing at all before
> > > the string reaches the OpenSSL code. In other words, OVMF should set the
> > > PCD -- or, even better, variable -- to a *character string* like this:
> > >
> > >
> >
> "kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!EXP:!DES:!RC4:!RC2:!IDEA:!SEE
> > > D:!eNULL:!aNULL:!MD5:!SSLv2"
> > >
> > > Is this feasible?
> >
> > It looks impossible to simply forward the *textual*cipher list to OpenSSL
> > from
> > the aspect of EFI_TLS_PROTOCOL.
> >
> > //************************************************************
> > // EFI_TLS_CIPHER
> > //************************************************************
> > typedef struct {
> > UINT8 Data1;
> > UINT8 Data2;
> > } EFI_TLS_CIPHER;
> > Note: The definition of EFI_TLS_CIPHER is from RFC 5246 A.4.1.Hello
> Messages.
> > The value of
> > EFI_TLS_CIPHER is from TLS Cipher Suite Registry of IANA.
> >
> >
> > >
> > > Thanks,
> > > Laszlo
> >
> >
>
>
> Thanks,
> Jiaxin
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
