Leaving the variable up to the platform setting is good to me.
Mike,
If you have no comments, we will follow the variable solution.
Thanks,
Jiaxin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, February 5, 2018 6:47 PM
> To: Wu, Jiaxin
On 02/05/18 04:33, Wu, Jiaxin wrote:
> 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
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
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
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
On 01/24/18 07:50, Wu, Jiaxin wrote:
> 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.
Ah, I totally missed that
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:
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:
>
Hi Laszlo,
> Jiaxin: I agree with the dynamic PCD solution for the CipherList
> setting, the PCD format can use as following one:
> gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists
> >>> |{0x0}|VOID*|0x000D
> If the platform wants to set the below CipherSuites (RFC
Hi Jiaxin,
two updates:
Jiaxin: I agree with the dynamic PCD solution for the CipherList
setting, the PCD format can use as following one:
gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists
>>> |{0x0}|VOID*|0x000D
If the platform wants to set the below CipherSuites
Hi Jiaxin,
> With above solution, if I understand correctly, the specific platform
> needs to produce such a "EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL", which
> will be consumed by HttpDxe driver.
Yes, that's the idea.
> If not existed, EFI_UNSUPPORTED returned. That's totally a
> incompatibility
> >>
> >> Hello Jiaxin, Siyuan,
> >>
> >> it seems that the "preferred set of ciphers" can be controlled at the
> >> TLS session level.
> >
> >
> > Jiaxin: Yes, TLS CipherList can be configured by TLS protocol.
> >
> >
> >>
> >> With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes several
>
On 01/20/18 07:18, Wu, Jiaxin wrote:
>>
>> Hello Jiaxin, Siyuan,
>>
>> it seems that the "preferred set of ciphers" can be controlled at the
>> TLS session level.
>
>
> Jiaxin: Yes, TLS CipherList can be configured by TLS protocol.
>
>
>>
>> With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes
>
> Hello Jiaxin, Siyuan,
>
> it seems that the "preferred set of ciphers" can be controlled at the
> TLS session level.
Jiaxin: Yes, TLS CipherList can be configured by TLS protocol.
>
> With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes several calls
> to
14 matches
Mail list logo
