[edk2-devel] FW: [staging/UEFI_Redfish][PATCH v2] Announce to create "UEFI_Redfish" branch in edk2-staging.
+ Stephano and forward to new list. Hi All, UEFI_Redfish branch has been created on edk2-staging to develop the UEFI Redfish feature: https://github.com/tianocore/edk2-staging/tree/UEFI_Redfish If you need any support, please send the email to edk2-devel mailing list by following edk2-satging process. Thanks, Jiaxin > -Original Message- > From: Wu, Jiaxin > Sent: Monday, January 21, 2019 2:19 AM > To: edk2-devel@lists.01.org > Cc: Leif Lindholm ; Rothman, Michael A > ; Kinney, Michael D > ; Li, Ruth ; Ye, Ting > ; Fu, Siyuan ; Wang, Fan > ; Wu, Jiaxin > Subject: [staging/UEFI_Redfish][PATCH v2] Announce to create > "UEFI_Redfish" branch in edk2-staging. > > v2: Resend the patch as diff adding instead of modifying. > > UEFI_Redfish branch is to develop the UEFI Redfish feature. The code base > of development is based on the release of edk2-stable201811 tag. Please > refer to the patch of Readme.md to get the detailed feature introduction. > > Note: The branch will be created by the end of Jan 28th if no objection. > > Cc: Leif Lindholm > Cc: Rothman Michael A > Cc: Kinney Michael D > Cc: Li Ruth > Cc: Ye Ting > Cc: Fu Siyuan > Cc: Wang Fan > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Wu Jiaxin > --- > Readme.md | 85 > +++ > 1 file changed, 85 insertions(+) > create mode 100644 Readme.md > > diff --git a/Readme.md b/Readme.md > new file mode 100644 > index 00..b9b5ab38e2 > --- /dev/null > +++ b/Readme.md > @@ -0,0 +1,85 @@ > +This branch is used to develop the **UEFI Redfish Feature**. The code > base of development is based on the release of **edk2-stable201811** tag. > + > +The branch owner: > +Fu Siyuan , Ye Ting , Wang Fan > , Wu Jiaxin > + > +## Introduction > +UEFI Redfish is an efficient and secure solution for end users to remote > control and configure UEFI pre-OS environment by leveraging the RESTful API. > It's simple for end users to access the data from UEFI firmware defined in > JSON format. > + > +One of the design goals for UEFI Redfish solution is to provide a scalable > implementation which allow users to easily add/remove/modify each > independent Redfish configure features (RedfishBiosDxe & > RedfishBootInfoDxe). This is done by extracting the generic logic to a single > UEFI driver model driver (RedfishConfigDxe), and several library instances > (DxeRedfishLib & BaseJsonLib). > + > + Supported Features > + * Protocols > +* EFI RestEx Service Binding Protocol > +* EFI RestEx Protocol > +* Redfish ConfigHandler Protocol > +* Redfish Credential Protocol > + > + * Configuration Items via UEFI Redfish > +* [ISCSI Boot Keywords](http://www.uefi.org/confignamespace). > +* HII Opcodes/Questions marked with REST_SYTLE flag or in REST_SYTLE > formset. > +* BootOrder/BootNext variables. > + > + * Redfish Schemas > +* > [AttributeRegistry](https://redfish.dmtf.org/schemas/v1/AttributeRegistry.v > 1_1_0.json) > +* > [ComputerSystemCollection](https://redfish.dmtf.org/schemas/ComputerS > ystemCollection.json) > +* > [ComputerSystem](https://redfish.dmtf.org/schemas/v1/ComputerSystem. > v1_5_0.json) > +* [Bios](https://redfish.dmtf.org/schemas/v1/Bios.v1_0_2.json) > +* > [BootOptionCollection](https://redfish.dmtf.org/schemas/BootOptionCollec > tion.json) > +* > [BootOption](https://redfish.dmtf.org/schemas/BootOption.v1_0_0.json) > + > +If any additional Redfish Schema or a new version of above Schemas are > required to be supported, please send the email to edk2-devel mailing list by > following [edk2-satging process](https://github.com/tianocore/edk2- > staging). > + > + Related Modules > + The following modules are related to UEFI Redfish solution, > **RedfishPkg** is the new package to support UEFI Redfish solution: > + * **RedfishPkg\RestExDxe\RestExDxe.inf** - UEFI driver to enable > standardized RESTful access to resources from UEFI environment. > + > + * **RedfishPkg\Library\DxeRedfishLib** - Library to > Create/Read/Update/Delete (CRUD) resources and provide basic query > abilities by using [URI/RedPath](https://github.com/DMTF/libredfish). > + > + * **RedfishPkg\Library\BaseJsonLib** - Library to encode/decode JSON > data. > + > + * **RedfishPkg\RedfishConfigDxe\RedfishConfigDxe.inf** - UEFI driver to > execute registered Redfish Configuration Handlers: > + > +* **RedfishPkg\Features\RedfishBiosDxe\RedfishBiosDxe.inf** - DXE > driver to register Redfish configuration handler to process "Bios" schema and > "AttributeReg
Re: [edk2] [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
Reviewed-by: Wu Jiaxin
> -Original Message-
> From: Wang, Fan
> Sent: Friday, March 1, 2019 9:57 AM
> To: Fu, Siyuan ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: RE: [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
>
> Thanks, Siyuan, will update commit message for this change.
>
> Best Regards
> Fan
>
> -Original Message-
> From: Fu, Siyuan
> Sent: Thursday, February 28, 2019 6:35 PM
> To: Wang, Fan ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: RE: [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
>
> Hi, Fan
>
> The patch also cancel a timer in driver binding stop, please describe this
> change in commit message, or separate it to another patch.
>
> Reviewed-by: Siyuan Fu
>
> > -Original Message-
> > From: Wang, Fan
> > Sent: Thursday, February 28, 2019 5:10 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ;
> > Wu, Jiaxin
> > Subject: [Patch] NetworkPkg: Fix Duplicate FreePool Error in WCM
> >
> > * REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1577
> >
> > In WiFi Connection Manager scan process, the result received from WiFi
> > device driver will be freed twice, and will cause unexpected errors,
> > and even system crash.
> >
> > This issue also exists in some other places potentially, this patch is
> > to fix these issues.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Wu Jiaxin
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wang Fan
> > ---
> > NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c| 1
> +
> > NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c | 1
> > + .../WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAccess.c |
> > 9
> > +
> > NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrImpl.c | 1
> -
> > 4 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > index 1431cdc7ea..63b0670c63 100644
> > --- a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > +++
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrDriver.c
> > @@ -409,10 +409,11 @@ WifiMgrDxeDriverBindingStop (
> >}
> >
> >//
> >// Close Event
> >//
> > + gBS->SetTimer (Nic->TickTimer, TimerCancel, 0);
> >gBS->CloseEvent (Nic->TickTimer);
> >
> >//
> >// Clean Supported Suites
> >//
> > diff --git
> > a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > index 6db1626f2d..0224823431 100644
> > ---
> a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > +++
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrFileUtil.c
> > @@ -251,10 +251,11 @@ UpdatePage(
> > }
> >} else {
> >
> > if (Private->FileContext->FileName != NULL) {
> >FreePool (Private->FileContext->FileName);
> > + Private->FileContext->FileName = NULL;
> > }
> > Private->FileContext->FileName = FileName;
> >
> > if (FormId == FORMID_ENROLL_CERT) {
> >HiiSetString (Private->RegisteredHandle, diff --git
> >
> a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAcc
> ess
> > .c
> >
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAcc
> ess
> > .c
> > index bfb6b6e5ca..d0d55f46da 100644
> > ---
> >
> a/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAcc
> ess
> > .c
> > +++
> b/NetworkPkg/WifiConnectionManagerDxe/WifiConnectionMgrHiiConfigAc
> > +++ cess.c
> > @@ -445,10 +445,12 @@ WifiMgrRefreshNetworkList (
> > UnicodeSPrint (PortString, PortStringSize, L"AKMSuite: %s
> > CipherSuite: %s", AKMListDisplay, CipherListDisplay);
> > PortHelpToken = HiiSetString (Private->RegisteredHandle, 0,
> > PortString, NULL);
> >}
> >FreePool (AKMListDisplay);
> >FreePool (CipherListDisplay);
> > + AKMListDisplay= NULL;
> > + CipherListDisplay = NULL;
> >
> >HiiCreateGotoOpCode (
> > StartOpCodeHandle,
> > FORMID_CONNECT_NETWORK,
> > PortPromptToken,
> > @@ -530,10 +532,12 @@ WifiMgr
Re: [edk2] [PATCH v1] NetworkPkg/DnsDxe: Check the received packet size before parsing the message.
Thanks Laszlo, I will update the subject to include the CVE number when commit the patch. > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Tuesday, February 26, 2019 7:17 PM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Wang, Fan ; Fu, Siyuan > > Subject: Re: [edk2] [PATCH v1] NetworkPkg/DnsDxe: Check the received packet > size before parsing the message. > > On 02/26/19 09:14, Jiaxin Wu wrote: > > Fix CVE-2018-12178 > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=809 > > > > The DNS driver only checks the received packet size against the > > minimum DNS header size in DnsOnPacketReceived(), later it accesses > > the QueryName and QuerySection beyond the header scope, which might > > cause the pointer within DNS driver points to an invalid entry or > > modifies the memory content beyond the header scope. > > > > This patch is to fix above problem. > > > > Cc: Ye Ting > > Cc: Fu Siyuan > > Cc: Wang Fan > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Wu Jiaxin > > --- > > NetworkPkg/DnsDxe/DnsImpl.c | 77 -- > --- > > NetworkPkg/DnsDxe/DnsImpl.h | 2 + > > 2 files changed, 69 insertions(+), 10 deletions(-) > > Please put the precise CVE number in the subject line. > > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Hi Siyuan,
Both of them should be fine to clear the invalid configuration data. In my
opinion, since the error returned from SetData(), we will treat it as invalid
except the asynchronous process (EFI_NOT_READY). That's already have been
checked in the if condition.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, February 12, 2019 9:05 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Michael Turner ; Ye, Ting
>
> Subject: RE: [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Hi, Jiaxin
>
> I think the Ip6Cfg->SetData() may return other error, which not only because
> invalid config data is used. Why not just check the config data in
> Ip6ConfigReadConfigData()?
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Tuesday, February 12, 2019 8:47 AM
> > To: edk2-devel@lists.01.org
> > Cc: Michael Turner ; Ye, Ting
> > ; Fu, Siyuan ; Wu, Jiaxin
> >
> > Subject: [PATCH v2] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration
> > during driver start.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1448
> >
> > *v2: Add the warning debug message.
> >
> > This patch is to clean the invalid data and continue to start IP6 driver.
> >
> > Cc: Michael Turner
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wu Jiaxin
> > ---
> > NetworkPkg/Ip6Dxe/Ip6Driver.c | 22 --
> > 1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > index 4c607125a6..7ec74f6ebc 100644
> > --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > @@ -586,11 +586,20 @@ Ip6DriverBindingStart (
> > Ip6ConfigDataTypeManualAddress,
> > DataItem->DataSize,
> > DataItem->Data.Ptr
> > );
> > if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> > - goto UNINSTALL_PROTOCOL;
> > + //
> > + // Clean the invalid ManualAddress configuration.
> > + //
> > + Status = Ip6Cfg->SetData (
> > + Ip6Cfg,
> > + Ip6ConfigDataTypeManualAddress,
> > + 0,
> > + NULL
> > + );
> > + DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid
> > ManualAddress configuration.\n"));
> > }
> >}
> >
> >//
> >// If there is any default gateway address, set it.
> > @@ -602,11 +611,20 @@ Ip6DriverBindingStart (
> > Ip6ConfigDataTypeGateway,
> > DataItem->DataSize,
> > DataItem->Data.Ptr
> > );
> > if (EFI_ERROR(Status)) {
> > - goto UNINSTALL_PROTOCOL;
> > + //
> > + // Clean the invalid Gateway configuration.
> > + //
> > + Status = Ip6Cfg->SetData (
> > + Ip6Cfg,
> > + Ip6ConfigDataTypeGateway,
> > + 0,
> > + NULL
> > + );
> > + DEBUG ((EFI_D_WARN, "Ip6DriverBindingStart: Clean the invalid
> Gateway
> > configuration.\n"));
> > }
> >}
> >
> >//
> >// ready to go: start the receiving and timer
> > --
> > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Looks it's enough to add the warning debug message. I have sent the version 2
patch to do that.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, February 12, 2019 8:28 AM
> To: Wu, Jiaxin
> Cc: edk2-devel@lists.01.org; Mike Turner ;
> Ye, Ting
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Yes, Jiaxin. You should not use popup messages unless you 100 percent sure
> the code is running in setup browser.
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Mike Turner [mailto:michael.tur...@microsoft.com]
> > Sent: Monday, February 11, 2019 11:10 PM
> > To: Wu, Jiaxin ; Ye, Ting ; edk2-
> > de...@lists.01.org
> > Cc: Fu, Siyuan
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > I haven't seen any patch for a popup, but message popups during driver
> binding
> > start are not a good thing.
> >
> > Michael R Turner
> > Surface UEFI Development
> > Microsoft Corporation
> > One Redmond Way
> > Redmond WA 98052
> >
> > 425-705-0928
> >
> > This email message may contain confidential and privileged
> information. Any
> > unauthorized use is prohibited. If you are not the intended recipient,
> please
> > contact the sender by reply email and destroy all copies of the original
> > message.
> >
> >
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Sunday, February 10, 2019 7:10 PM
> > To: Ye, Ting ; edk2-devel@lists.01.org
> > Cc: Mike Turner ; Fu, Siyuan
> >
> > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > configuration during driver start.
> >
> > Agree, thanks the comment. I will update the patch.
> >
> >
> >
> > > -Original Message-
> > > From: Ye, Ting
> > > Sent: Monday, February 11, 2019 11:09 AM
> > > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Fu, Siyuan
> > >
> > > Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > Hi Jiaxin,
> > >
> > > I agree we need start IPv6 stack no matter the configuration is valid or
> > > not.
> > > However I would suggest to add more comments and pop up warning
> > > messages to let user know we continue to start IPv6 stack without
> > > using previously saved configuration.
> > >
> > > Thanks,
> > > Ting
> > >
> > > -Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Sunday, February 3, 2019 2:24 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Michael Turner ; Ye, Ting
> > > ; Fu, Siyuan ; Wu, Jiaxin
> > >
> > > Subject: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> > > configuration during driver start.
> > >
> > > REF:
> > >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> > >
> illa.tianocore.org%2Fshow_bug.cgi%3Fid%3D1448data=02%7C01%7C
> Micha
> > >
> el.Turner%40microsoft.com%7C93fb5d7f003b48c6561d08d68fce66f4%7C72f9
> 88b
> > >
> f86f141af91ab2d7cd011db47%7C1%7C0%7C636854514000398927sdata
> =bCAbT
> > > njjX9bmuRiASoCkPiZtdqUY14BDMgyLd%2BYNNx4%3Dreserved=0
> > >
> > > This patch is to clean the invalid data and continue to start IP6 driver.
> > >
> > > Cc: Michael Turner
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Wu Jiaxin
> > > Signed-off-by: Michael Turner
> > > ---
> > > NetworkPkg/Ip6Dxe/Ip6Driver.c | 20 ++--
> > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > b/NetworkPkg/Ip6Dxe/Ip6Driver.c index 4c607125a6..1bd1c61da8 100644
> > > --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> > > @@ -586,11 +586,19 @@ Ip6DriverBindingStart (
> > > Ip6ConfigDataTypeManualAddress,
> > > DataItem->DataSize,
> > > DataItem->Data.Ptr
> > > );
> > > if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> > > - goto UNINSTALL_PROTOCOL;
> > > + /
Re: [edk2] [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration during driver start.
Agree, thanks the comment. I will update the patch.
> -Original Message-
> From: Ye, Ting
> Sent: Monday, February 11, 2019 11:09 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Michael Turner ; Fu, Siyuan
>
> Subject: RE: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6
> configuration during driver start.
>
> Hi Jiaxin,
>
> I agree we need start IPv6 stack no matter the configuration is valid or not.
> However I would suggest to add more comments and pop up warning
> messages to let user know we continue to start IPv6 stack without using
> previously saved configuration.
>
> Thanks,
> Ting
>
> -Original Message-
> From: Wu, Jiaxin
> Sent: Sunday, February 3, 2019 2:24 PM
> To: edk2-devel@lists.01.org
> Cc: Michael Turner ; Ye, Ting
> ; Fu, Siyuan ; Wu, Jiaxin
>
> Subject: [PATCH v1] NetworkPkg/Ip6Dxe: Clean the invalid IPv6 configuration
> during driver start.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1448
>
> This patch is to clean the invalid data and continue to start IP6 driver.
>
> Cc: Michael Turner
> Cc: Ye Ting
> Cc: Fu Siyuan
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin
> Signed-off-by: Michael Turner
> ---
> NetworkPkg/Ip6Dxe/Ip6Driver.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> b/NetworkPkg/Ip6Dxe/Ip6Driver.c index 4c607125a6..1bd1c61da8 100644
> --- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
> +++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
> @@ -586,11 +586,19 @@ Ip6DriverBindingStart (
> Ip6ConfigDataTypeManualAddress,
> DataItem->DataSize,
> DataItem->Data.Ptr
> );
> if (EFI_ERROR(Status) && Status != EFI_NOT_READY) {
> - goto UNINSTALL_PROTOCOL;
> + //
> + // Clean the invalid ManualAddress configuration.
> + //
> + Status = Ip6Cfg->SetData (
> + Ip6Cfg,
> + Ip6ConfigDataTypeManualAddress,
> + 0,
> + NULL
> + );
> }
>}
>
>//
>// If there is any default gateway address, set it.
> @@ -602,11 +610,19 @@ Ip6DriverBindingStart (
> Ip6ConfigDataTypeGateway,
> DataItem->DataSize,
> DataItem->Data.Ptr
> );
> if (EFI_ERROR(Status)) {
> - goto UNINSTALL_PROTOCOL;
> + //
> + // Clean the invalid Gateway configuration.
> + //
> + Status = Ip6Cfg->SetData (
> + Ip6Cfg,
> + Ip6ConfigDataTypeGateway,
> + 0,
> + NULL
> + );
> }
>}
>
>//
>// ready to go: start the receiving and timer
> --
> 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Network Stack Budgeting
Hi Tom, One thing I want to highlight is that our design of network stack is not only for the PXE/HTTP boot trigged in BootManager, but also to make sure it's workable once there is any MNP instance configured by upper drivers (ARP/IPv4/IPv6). Take ARP/IP as an example, once ARP/IP are started, we need a heartbeat to process any ARP requests, which is required by ARP functionality. In such a case, SNP must be started to make ARP/IP drivers works well. Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tomas Pilar (tpilar) > Sent: Friday, January 25, 2019 1:43 AM > To: Laszlo Ersek ; edk2-devel@lists.01.org > Subject: Re: [edk2] Network Stack Budgeting > > > > On 24/01/2019 16:49, Laszlo Ersek wrote: > > On 01/24/19 14:25, Tomas Pilar (tpilar) wrote: > >> Hmm, > >> > >> Mnp->Configure() will eventually call MnpStartSnp(). > >> > >> A grep for Mnp->Configure shows that: > >> * ArpDxe performs this on DriverBinding.Start() > >> * Ip6Dxe performs this on DriverBinding.Start() > >> > >> Ipv4 and DnsDhcp do this as a part of their Configure() they expose in the > API. > > Yes, that makes sense. All of the above drivers are UEFI drivers that > > follow the UEFI driver model, AIUI. As long as the controller is not > > connected from BDS, no BindingStart() function should be called in these. > Ah, but I would expect the BDS to call ConnectController() on the NIC, but I > would not expect the network stack to be started unless the device is > actually chosen for PXE booting. In other words, the above protocols should > follow the example of EFI_DNS4_PROTOCOL that binds against the device > during BDS but .Configure() is not automatically called by > DriverBinding.Start(). > > .Configure() should be called by the BootManager if networking is actually to > be done. That in turn will configure Mnp and start Snp. > > Cheers, > Tom > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
> >> This is my idea to avoid the duplicated mail. I also include Ard and > >> Laszlo to > collect the feedback on how to handle the partial update in the patchset. > >> > > > > Laszlo may disagree with me, but I think that it is not always > > necessary to resend the entire series when only a single patch > > changes. It does depend on the situation, though: if it is a trivial > > patch in a more complicated series then it might make little sense. In > > other case, just resending the whole thing is probably better. > > I think resending one patch can be acceptable, but the subject line > (patch nr) and the threading have to be correct. Also, I don't think > this approach scales beyond exactly one patch-update; it's easy to lose > track of version numbers etc. So "use sparingly" I guess? :) > Thanks all of your comments, to avoid the missing version track, I have resent the whole patch to version 3:). Best Regard! Jiaxin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [staging/UEFI_Redfish][PATCH v1] Announce to create "UEFI_Redfish" branch in edk2-staging.
Good suggestion. Thanks Leif. Already resubmit as version 2. > -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Friday, January 18, 2019 9:19 PM > To: Wu, Jiaxin > Cc: edk2-devel@lists.01.org; Wang, Fan ; Ye, Ting > ; Li, Ruth ; Kinney, Michael D > ; Fu, Siyuan > Subject: Re: [edk2] [staging/UEFI_Redfish][PATCH v1] Announce to create > "UEFI_Redfish" branch in edk2-staging. > > Hi Jiaxin, > > I am happy to see the creation of this branch. However, Could you > possibly resubmit this as a diff adding a Readme.md rather than > modifying it? > > The diff against edk2/Readme.md is not really relevant, and confuses review. > > (For example, in your branch, *delete* the existing Readme.md in a > separate commit, and then in the commit next *add* the one for the > branch. Only the *add* patch needs to be reviewed.) > > Best Regards, > > Leif > > On Fri, Jan 18, 2019 at 05:42:40PM +0800, Jiaxin Wu wrote: > > UEFI_Redfish branch is to develop the UEFI Redfish feature. The code base > > of development is based on the release of edk2-stable201811 tag. Please > > refer to the patch of Readme.md to get the detailed feature introduction. > > > > Note: The branch will be created by the end of Jan 28th if no objection. > > > > Cc: Rothman Michael A > > Cc: Kinney Michael D > > Cc: Li Ruth > > Cc: Ye Ting > > Cc: Fu Siyuan > > Cc: Wang Fan > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Wu Jiaxin > > --- > > Readme.md | 114 > -- > > 1 file changed, 85 insertions(+), 29 deletions(-) > > > > diff --git a/Readme.md b/Readme.md > > index 1ef0780ee0..b9b5ab38e2 100644 > > --- a/Readme.md > > +++ b/Readme.md > > @@ -1,29 +1,85 @@ > > -# EDK II Project > > - > > -A modern, feature-rich, cross-platform firmware development environment > > -for the UEFI and PI specifications from www.uefi.org. > > - > > -Contributions to the EDK II open source project are covered by the > > -[TianoCore Contribution Agreement 1.1](Contributions.txt) > > - > > -The majority of the content in the EDK II open source project uses a > > -[BSD 2-Clause License](License.txt). The EDK II open source project > > contains > > -the following components that are covered by additional licenses: > > -* [AppPkg/Applications/Python/Python- > 2.7.2/Tools/pybench](AppPkg/Applications/Python/Python- > 2.7.2/Tools/pybench/LICENSE) > > -* [AppPkg/Applications/Python/Python- > 2.7.2](AppPkg/Applications/Python/Python-2.7.2/LICENSE) > > -* [AppPkg/Applications/Python/Python- > 2.7.10](AppPkg/Applications/Python/Python-2.7.10/LICENSE) > > -* > [BaseTools/Source/C/BrotliCompress](BaseTools/Source/C/BrotliCompress/LIC > ENSE) > > -* > [MdeModulePkg/Library/BrotliCustomDecompressLib](MdeModulePkg/Library/ > BrotliCustomDecompressLib/LICENSE) > > -* [OvmfPkg](OvmfPkg/License.txt) > > -* > [CryptoPkg/Library/OpensslLib/openssl](CryptoPkg/Library/OpensslLib/openssl/ > LICENSE) > > - > > -The EDK II Project is composed of packages. The maintainers for each > package > > -are listed in [Maintainers.txt](Maintainers.txt). > > - > > -# Resources > > -* [TianoCore](http://www.tianocore.org) > > -* [EDK II](https://github.com/tianocore/tianocore.github.io/wiki/EDK-II) > > -* [Getting Started with EDK > II](https://github.com/tianocore/tianocore.github.io/wiki/Getting-Started-with- > EDK-II) > > -* [Mailing > Lists](https://github.com/tianocore/tianocore.github.io/wiki/Mailing-Lists) > > -* [TianoCore Bugzilla](https://bugzilla.tianocore.org) > > -* [How To > Contribute](https://github.com/tianocore/tianocore.github.io/wiki/How-To- > Contribute) > > +This branch is used to develop the **UEFI Redfish Feature**. The code base > of development is based on the release of **edk2-stable201811** tag. > > + > > +The branch owner: > > +Fu Siyuan , Ye Ting , Wang Fan > , Wu Jiaxin > > + > > +## Introduction > > +UEFI Redfish is an efficient and secure solution for end users to remote > control and configure UEFI pre-OS environment by leveraging the RESTful API. > It's simple for end users to access the data from UEFI firmware defined in > JSON > format. > > + > > +One of the design goals for UEFI Redfish solution is to provide a scalable > implementation which allow users to easily add/remove/modify each > independent Redfish configure features (RedfishBiosDxe & RedfishBootInfoDxe). > This is done by e
Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
Just confirmed with Liming, we don't need to seed the full series patches if
only one is updated.
Thanks,
jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Friday, January 18, 2019 1:29 PM
> To: Wu, Hao A ; Wu, Jiaxin ;
> edk2-devel@lists.01.org
> Cc: Ye, Ting ; Gao, Liming
> Subject: RE: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary NULL pointer check.
>
> Hi, Jiaxin
>
> Yes the full patch series is needed for a v2 version.
>
> And also, why you removed the "(Instance->Token != NULL)" check in the if
> condition?
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-----
> > From: Wu, Hao A
> > Sent: Friday, January 18, 2019 1:22 PM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ; Gao,
> > Liming
> > Subject: RE: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary NULL
> > pointer check.
> >
> > Hi Jiaxin,
> >
> > A comment that is not related with the content of the patch itself:
> > Please help to send the full patch series when a new version is needed.
> >
> > Best Regards,
> > Hao Wu
> >
> > > -----Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Friday, January 18, 2019 1:16 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Ye, Ting; Fu, Siyuan; Wu, Hao A; Gao, Liming; Wu, Jiaxin
> > > Subject: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary
> > > NULL pointer check.
> > >
> > > v2: The DHCP Instance might be destroyed in PxeDhcpDone. So,
> > > we need safe-delete.
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469
> > >
> > > Since the value of Instance is retrieved from the list Entry,
> > > it can't be the NULL pointer, so just remove the unnecessary
> > > check.
> > >
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Cc: Wu Hao A
> > > Cc: Gao Liming
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Wu Jiaxin
> > > ---
> > > MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 11 -
> --
> > > 1 file changed, 4 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > index 98a22a77b4..780f8b4224 100644
> > > --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > > @@ -1,9 +1,9 @@
> > > /** @file
> > >EFI DHCP protocol implementation.
> > >
> > > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > > +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> > > This program and the accompanying materials
> > > are licensed and made available under the terms and conditions of the
> BSD
> > > License
> > > which accompanies this distribution. The full text of the license may be
> > > found at
> > > http://opensource.org/licenses/bsd-license.php
> > >
> > > @@ -1646,16 +1646,13 @@ ON_EXIT:
> > >//
> > >// Iterate through all the DhcpSb Children.
> > >//
> > >NET_LIST_FOR_EACH_SAFE (Entry, Next, >Children) {
> > > Instance = NET_LIST_USER_STRUCT (Entry, DHCP_PROTOCOL, Link);
> > > -
> > > -if ((Instance != NULL) && (Instance->Token != NULL)) {
> > > - Instance->Timeout--;
> > > - if (Instance->Timeout == 0) {
> > > -PxeDhcpDone (Instance);
> > > - }
> > > +Instance->Timeout--;
> > > +if (Instance->Timeout == 0) {
> > > + PxeDhcpDone (Instance);
> > > }
> > >}
> > >
> > >return ;
> > >
> > > --
> > > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
Thanks Siyuan, I will double check that.
> -Original Message-
> From: Fu, Siyuan
> Sent: Friday, January 18, 2019 10:00 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Hao A ; Gao,
> Liming
> Subject: RE: [PATCH v1 1/3] MdeModulePkg/Dhcp4Dxe: Remove
> unnecessary NULL pointer check.
>
> Hi, Jiaxin
>
> > -----Original Message-
> > From: Wu, Jiaxin
> > Sent: Thursday, January 17, 2019 9:01 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Hao A
> > ; Gao, Liming ; Wu, Jiaxin
> >
> > Subject: [PATCH v1 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary
> NULL pointer
> > check.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469
> >
> > Since the value of Instance is retrieved from the list Entry,
> > it can't be the NULL pointer, so just remove the unnecessary
> > check.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Wu Hao A
> > Cc: Gao Liming
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wu Jiaxin
> > ---
> > MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 15 ++
> -
> > 1 file changed, 6 insertions(+), 9 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > index 98a22a77b4..04d47e0759 100644
> > --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> > @@ -1,9 +1,9 @@
> > /** @file
> >EFI DHCP protocol implementation.
> >
> > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> > +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD
> > License
> > which accompanies this distribution. The full text of the license may be
> > found at
> > http://opensource.org/licenses/bsd-license.php
> >
> > @@ -1493,15 +1493,15 @@ DhcpOnTimerTick (
> >IN EFI_EVENT Event,
> >IN VOID *Context
> >)
> > {
> >LIST_ENTRY*Entry;
> > - LIST_ENTRY*Next;
> >DHCP_SERVICE *DhcpSb;
> >DHCP_PROTOCOL *Instance;
> >EFI_STATUSStatus;
> >
> > + Entry= NULL;
> >DhcpSb = (DHCP_SERVICE *) Context;
> >Instance = DhcpSb->ActiveChild;
> >
> >//
> >// 0x is the maximum supported value for elapsed time according to
> RFC.
> > @@ -1644,18 +1644,15 @@ DhcpOnTimerTick (
> >
> > ON_EXIT:
> >//
> >// Iterate through all the DhcpSb Children.
> >//
> > - NET_LIST_FOR_EACH_SAFE (Entry, Next, >Children) {
> > + NET_LIST_FOR_EACH (Entry, >Children) {
>
> The DHCP Instance might be destroyed in PxeDhcpDone (it singals upper
> layer that the DHCP is completed), and the NET_LIST_FOR_EACH is not
> delete-safe, you should not replace it with NET_LIST_FOR_EACH.
>
> > Instance = NET_LIST_USER_STRUCT (Entry, DHCP_PROTOCOL, Link);
> > -
> > -if ((Instance != NULL) && (Instance->Token != NULL)) {
> > - Instance->Timeout--;
> > - if (Instance->Timeout == 0) {
> > -PxeDhcpDone (Instance);
> > - }
> > +Instance->Timeout--;
> > +if (Instance->Timeout == 0) {
> > + PxeDhcpDone (Instance);
> > }
> >}
> >
> >return ;
> >
> > --
> > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/2] MdeModulePkg/NetLib.h: Fix the possible NULL pointer dereference issue.
Hi Laszlo, Thanks review the patch. > > (1) The linked list from BaseLib (LIST_ENTRY) always has at least one > element (the head element), and the list is empty if the head element > points back to itself. In other words, ForwardLink may never be NULL. > > So why is it necessary to check against that case here? > I agree the ForwardLink in valid LIST_ENTRY can't be NULL. Here, I added the more condition check was considering the possible broken case of the LIST_ENTRY. But I also checked the other usage of *_FOR_EACH_SAFE /*_FOR_EACH, looks never or unnecessary to consider that case. If so, please drop the series patches and I will create another series patches to remove the unnecessary check after retrieving the value from list Entry. > (2) If the NULL check is indeed necessary for some reason, then we > should write > > Entry != (ListHead) && Entry != NULL > > in the controlling expression. Because, with the comma operator, the > (Entry != (ListHead)) expression would be evaluated, but its result > would be ignored. > Yes, I was also awared that, so I created patch v2 to fix that: [edk2] [PATCH v2 1/2] MdeModulePkg/NetLib.h: Fix the possible NULL pointer dereference issue. Fix the wrong condition in for cycle. Thanks, Jiaxin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 0/2] Remove unused global variables in
Series Reviewed-by: Jiaxin Wu Thanks, jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Songpeng Li > Sent: Monday, January 14, 2019 5:25 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v1 0/2] Remove unused global variables in > > Uefi-aware compiler found some redundant definitions in > the NetworkPkg. We need to clean them. > > Songpeng Li (2): > NetworkPkg/IScsiDxe: Remove unused global variables. > NetworkPkg/Dhcp6Dxe: Remove an unused global variable. > > NetworkPkg/Dhcp6Dxe/Dhcp6Impl.c | 2 -- > NetworkPkg/IScsiDxe/IScsiConfig.c | 2 -- > NetworkPkg/Dhcp6Dxe/Dhcp6Impl.h | 1 - > 3 files changed, 5 deletions(-) > > -- > 2.18.0.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
Already pushed. SHA-1: 22b35e8bd1f9aea7bbab3a26e8ab4df339454463
Thanks,
Jiaxin
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Monday, January 14, 2019 12:58 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan
> Subject: RE: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
>
> Thanks Jiaxin. Please let me know if anything else is needed to mainline it.
>
> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, January 10, 2019 6:01 PM
> To: Ashish Singhal ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan
> Subject: RE: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
>
> Looks good to me.
>
> Reviewed-by: Wu Jiaxin
>
> Thanks,
> Jiaxin
>
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Friday, January 11, 2019 3:27 AM
> > To: edk2-devel@lists.01.org
> > Cc: Fu, Siyuan ; Wu, Jiaxin
> > ; Ashish Singhal
> > Subject: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
> >
> > Use UEFILib provided protocol uninstallation abstraction instead of
> > direct API for a proper cleanup.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1444
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ashish Singhal
> > ---
> > NetworkPkg/DnsDxe/DnsDriver.c | 30 ++
> > NetworkPkg/HttpBootDxe/HttpBootDxe.c | 15 +--
> > NetworkPkg/HttpDxe/HttpDriver.c | 15 +--
> > NetworkPkg/IpSecDxe/IpSecDriver.c | 15 +--
> > NetworkPkg/TcpDxe/TcpDriver.c | 15 +--
> > NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 15 +--
> > 6 files changed, 35 insertions(+), 70 deletions(-)
> >
> > diff --git a/NetworkPkg/DnsDxe/DnsDriver.c
> > b/NetworkPkg/DnsDxe/DnsDriver.c index 1f9b924..b74f5ba 100644
> > --- a/NetworkPkg/DnsDxe/DnsDriver.c
> > +++ b/NetworkPkg/DnsDxe/DnsDriver.c
> > @@ -510,28 +510,18 @@ DnsDriverEntryPoint (
> > FreePool (mDriverData);
> >
> >Error2:
> > - gBS->UninstallMultipleProtocolInterfaces (
> > - gDns6DriverBinding.DriverBindingHandle,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - NULL
> > - );
> > + EfiLibUninstallDriverBindingComponentName2 (
> > + ,
> > + ,
> > +
> > + );
> >
> >Error1:
> > -gBS->UninstallMultipleProtocolInterfaces (
> > - ImageHandle,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - NULL
> > - );
> > +EfiLibUninstallDriverBindingComponentName2 (
> > + ,
> > + ,
> > +
> > + );
> >
> >return Status;
> > }
> > diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > index 7ec06f960..0b16f95 100644
> > --- a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > +++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> > @@ -1327,16 +1327,11 @@ HttpBootDxeDriverEntryPoint (
> >
> > );
> >if (EFI_ERROR (Status)) {
> > -gBS->UninstallMultipleProtocolInterfaces(
> > - ImageHandle,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - NULL
> > - );
> > +EfiLibUninstallDriverBindingComponentName2(
> > + ,
> > + ,
> > +
> > + );
> >}
> >return Status;
> > }
> > diff --git a/NetworkPkg/HttpDxe/HttpDriver.c
> > b/NetworkPkg/HttpDxe/HttpDriver.c index 8df984d..979d76d 100644
> > --- a/NetworkPkg/HttpDxe/HttpDriver.c
> > +++ b/NetworkPkg/HttpDxe/HttpDriver.c
> > @@ -230,16 +230,11 @@ HttpDxeDriverEntryPoint (
> >
> > );
> >if (EFI_ERROR (Status)) {
> > -gBS->UninstallMultipleProtocolInterfaces (
> > - ImageHandle,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - ,
> > - NULL
> > - );
> > +EfiLibUninstallDriverBindingComponentName2 (
> > + ,
> > + ,
> > +
> > + );
> >}
>
Re: [edk2] [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
Looks good to me.
Reviewed-by: Wu Jiaxin
Thanks,
Jiaxin
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Friday, January 11, 2019 3:27 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin ;
> Ashish Singhal
> Subject: [PATCH] NetworkPkg: Protocol Uninstallation Cleanup
>
> Use UEFILib provided protocol uninstallation abstraction
> instead of direct API for a proper cleanup.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1444
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> NetworkPkg/DnsDxe/DnsDriver.c | 30 ++
> NetworkPkg/HttpBootDxe/HttpBootDxe.c | 15 +--
> NetworkPkg/HttpDxe/HttpDriver.c | 15 +--
> NetworkPkg/IpSecDxe/IpSecDriver.c | 15 +--
> NetworkPkg/TcpDxe/TcpDriver.c | 15 +--
> NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 15 +--
> 6 files changed, 35 insertions(+), 70 deletions(-)
>
> diff --git a/NetworkPkg/DnsDxe/DnsDriver.c
> b/NetworkPkg/DnsDxe/DnsDriver.c
> index 1f9b924..b74f5ba 100644
> --- a/NetworkPkg/DnsDxe/DnsDriver.c
> +++ b/NetworkPkg/DnsDxe/DnsDriver.c
> @@ -510,28 +510,18 @@ DnsDriverEntryPoint (
> FreePool (mDriverData);
>
>Error2:
> - gBS->UninstallMultipleProtocolInterfaces (
> - gDns6DriverBinding.DriverBindingHandle,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - NULL
> - );
> + EfiLibUninstallDriverBindingComponentName2 (
> + ,
> + ,
> +
> + );
>
>Error1:
> -gBS->UninstallMultipleProtocolInterfaces (
> - ImageHandle,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - NULL
> - );
> +EfiLibUninstallDriverBindingComponentName2 (
> + ,
> + ,
> +
> + );
>
>return Status;
> }
> diff --git a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> index 7ec06f960..0b16f95 100644
> --- a/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> +++ b/NetworkPkg/HttpBootDxe/HttpBootDxe.c
> @@ -1327,16 +1327,11 @@ HttpBootDxeDriverEntryPoint (
>
> );
>if (EFI_ERROR (Status)) {
> -gBS->UninstallMultipleProtocolInterfaces(
> - ImageHandle,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - NULL
> - );
> +EfiLibUninstallDriverBindingComponentName2(
> + ,
> + ,
> +
> + );
>}
>return Status;
> }
> diff --git a/NetworkPkg/HttpDxe/HttpDriver.c
> b/NetworkPkg/HttpDxe/HttpDriver.c
> index 8df984d..979d76d 100644
> --- a/NetworkPkg/HttpDxe/HttpDriver.c
> +++ b/NetworkPkg/HttpDxe/HttpDriver.c
> @@ -230,16 +230,11 @@ HttpDxeDriverEntryPoint (
>
> );
>if (EFI_ERROR (Status)) {
> -gBS->UninstallMultipleProtocolInterfaces (
> - ImageHandle,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - NULL
> - );
> +EfiLibUninstallDriverBindingComponentName2 (
> + ,
> + ,
> +
> + );
>}
>return Status;
> }
> diff --git a/NetworkPkg/IpSecDxe/IpSecDriver.c
> b/NetworkPkg/IpSecDxe/IpSecDriver.c
> index f66f89a..3082d99 100644
> --- a/NetworkPkg/IpSecDxe/IpSecDriver.c
> +++ b/NetworkPkg/IpSecDxe/IpSecDriver.c
> @@ -631,16 +631,11 @@ IpSecDriverEntryPoint (
>return Status;
>
> ON_UNINSTALL_IPSEC4_DB:
> - gBS->UninstallMultipleProtocolInterfaces (
> - ImageHandle,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - NULL
> - );
> + EfiLibUninstallDriverBindingComponentName2 (
> +,
> +,
> +
> +);
>
> ON_UNINSTALL_IPSEC:
>gBS->UninstallProtocolInterface (
> diff --git a/NetworkPkg/TcpDxe/TcpDriver.c
> b/NetworkPkg/TcpDxe/TcpDriver.c
> index 2d4b16c..00d172b 100644
> --- a/NetworkPkg/TcpDxe/TcpDriver.c
> +++ b/NetworkPkg/TcpDxe/TcpDriver.c
> @@ -202,16 +202,11 @@ TcpDriverEntryPoint (
>
> );
>if (EFI_ERROR (Status)) {
> -gBS->UninstallMultipleProtocolInterfaces (
> - ImageHandle,
> - ,
> - ,
> - ,
> - ,
> - ,
> - ,
> - NULL
> -
Re: [edk2] [PATCH v2] ShellPkg/TftpDynamicCommand: Change file writing method in tftp
Reviewed-by: Wu Jiaxin
> -Original Message-
> From: Li, Songpeng
> Sent: Thursday, January 10, 2019 10:54 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ray ;
> Wu, Jiaxin
> Subject: [PATCH v2] ShellPkg/TftpDynamicCommand: Change file writing
> method in tftp
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1433
>
> v2: Remove an unused variable.
>
> Current logic of shell tftp download was writing file after tftp
> download finished, when the file is large, it looks like the shell
> tftp command hanged after download was finished. To improve
> end-user experience, the solution is using split file writing
> instead.
>
> This patch update the code to open and close file inside
> DownloadFile(), and save each packet to file within callback
> function CheckPacket().
>
> Since AllocatePage() is no-longer needed, This patch can also
> remove the memory limitation. The download file can be larger
> than system free memory now.
>
> Cc: Jaben Carsey
> Cc: Ruiyu Ni
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Songpeng Li
> ---
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 154 -
> ---
> 1 file changed, 64 insertions(+), 90 deletions(-)
>
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> index ed081b5bad7c..ba753a279b00 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> @@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
> // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
> STATIC CONST CHAR16 mTftpProgressDelete[] =
> L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b
> \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
>
> +// Local File Handle
> +SHELL_FILE_HANDLE mFileHandle;
> +
> +// Path of the local file, Unicode encoded
> +CONST CHAR16 *mLocalFilePath;
> +
> /**
>Check and convert the UINT16 option values of the 'tftp' command
>
> @@ -166,9 +172,6 @@ GetFileSize (
>@param[in] FileSize Size of the file in number of bytes
>@param[in] BlockSize Value of the TFTP blksize option
>@param[in] WindowSize Value of the TFTP window size option
> - @param[out] Data Address where to store the address of the
> buffer
> - where the data of the file were downloaded in
> - case of success.
>
>@retval EFI_SUCCESS The file was downloaded.
>@retval EFI_OUT_OF_RESOURCES A memory allocation failed.
> @@ -184,8 +187,7 @@ DownloadFile (
>IN CONST CHAR8 *AsciiFilePath,
>IN UINTNFileSize,
>IN UINT16 BlockSize,
> - IN UINT16 WindowSize,
> - OUT VOID **Data
> + IN UINT16 WindowSize
>);
>
> /**
> @@ -287,7 +289,6 @@ RunTftp (
>CHAR8 *AsciiRemoteFilePath;
>UINTN FilePathSize;
>CONST CHAR16*Walker;
> - CONST CHAR16*LocalFilePath;
>EFI_MTFTP4_CONFIG_DATA Mtftp4ConfigData;
>EFI_HANDLE *Handles;
>UINTN HandleCount;
> @@ -297,9 +298,6 @@ RunTftp (
>EFI_HANDLE Mtftp4ChildHandle;
>EFI_MTFTP4_PROTOCOL *Mtftp4;
>UINTN FileSize;
> - UINTN DataSize;
> - VOID*Data;
> - SHELL_FILE_HANDLE FileHandle;
>UINT16 BlockSize;
>UINT16 WindowSize;
>
> @@ -309,7 +307,6 @@ RunTftp (
>AsciiRemoteFilePath = NULL;
>Handles = NULL;
>FileSize= 0;
> - DataSize= 0;
>BlockSize = MTFTP_DEFAULT_BLKSIZE;
>WindowSize = MTFTP_DEFAULT_WINDOWSIZE;
>
> @@ -385,7 +382,7 @@ RunTftp (
>UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
>
>if (ParamCount == 4) {
> -LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
> +mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
>} else {
> Walker = RemoteFilePath + StrLen (RemoteFilePath);
> while ((--Walker) >= RemoteFilePath) {
> @@ -394,7 +391,7 @@ RunTftp (
> break;
>}
> }
> -LocalFilePath = Walker + 1;
> +mLocalFilePath = Walker + 1;
>}
>
>//
> @@ -492,7 +489,6 @@ RunTftp (
> (NicNumber < HandleCount) && (ShellStatus != SHELL_SUCCESS);
> NicNumber++) {
Re: [edk2] [PATCH v1] ShellPkg/TftpDynamicCommand: Change file writing method in tftp
Reviewed-by: Wu Jiaxin
Thanks,
Jiaxin
> -Original Message-
> From: Li, Songpeng
> Sent: Wednesday, January 9, 2019 4:42 PM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ray ;
> Wu, Jiaxin
> Subject: [PATCH v1] ShellPkg/TftpDynamicCommand: Change file writing
> method in tftp
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1433
>
> Current logic of shell tftp download was writing file after tftp
> download finished, when the file is large, it looks like the shell
> tftp command hanged after download was finished. To improve
> end-user experience, the solution is using split file writing
> instead.
>
> This patch update the code to open and close file inside
> DownloadFile(), and save each packet to file within callback
> function CheckPacket().
>
> Since AllocatePage() is no-longer needed, This patch can also
> remove the memory limitation. The download file can be larger
> than system free memory now.
>
> Cc: Jaben Carsey
> Cc: Ruiyu Ni
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Songpeng Li
> ---
> ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 152
> +---
> 1 file changed, 64 insertions(+), 88 deletions(-)
>
> diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> index ed081b5bad7c..a53fe16f0683 100644
> --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> @@ -41,6 +41,12 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
> // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
> STATIC CONST CHAR16 mTftpProgressDelete[] =
> L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\
> b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
>
> +// Local File Handle
> +SHELL_FILE_HANDLE mFileHandle;
> +
> +// Path of the local file, Unicode encoded
> +CONST CHAR16 *mLocalFilePath;
> +
> /**
>Check and convert the UINT16 option values of the 'tftp' command
>
> @@ -166,9 +172,6 @@ GetFileSize (
>@param[in] FileSize Size of the file in number of bytes
>@param[in] BlockSize Value of the TFTP blksize option
>@param[in] WindowSize Value of the TFTP window size option
> - @param[out] Data Address where to store the address of the
> buffer
> - where the data of the file were downloaded in
> - case of success.
>
>@retval EFI_SUCCESS The file was downloaded.
>@retval EFI_OUT_OF_RESOURCES A memory allocation failed.
> @@ -184,8 +187,7 @@ DownloadFile (
>IN CONST CHAR8 *AsciiFilePath,
>IN UINTNFileSize,
>IN UINT16 BlockSize,
> - IN UINT16 WindowSize,
> - OUT VOID **Data
> + IN UINT16 WindowSize
>);
>
> /**
> @@ -287,7 +289,6 @@ RunTftp (
>CHAR8 *AsciiRemoteFilePath;
>UINTN FilePathSize;
>CONST CHAR16*Walker;
> - CONST CHAR16*LocalFilePath;
>EFI_MTFTP4_CONFIG_DATA Mtftp4ConfigData;
>EFI_HANDLE *Handles;
>UINTN HandleCount;
> @@ -297,9 +298,7 @@ RunTftp (
>EFI_HANDLE Mtftp4ChildHandle;
>EFI_MTFTP4_PROTOCOL *Mtftp4;
>UINTN FileSize;
> - UINTN DataSize;
>VOID*Data;
> - SHELL_FILE_HANDLE FileHandle;
>UINT16 BlockSize;
>UINT16 WindowSize;
>
> @@ -309,7 +308,6 @@ RunTftp (
>AsciiRemoteFilePath = NULL;
>Handles = NULL;
>FileSize= 0;
> - DataSize= 0;
>BlockSize = MTFTP_DEFAULT_BLKSIZE;
>WindowSize = MTFTP_DEFAULT_WINDOWSIZE;
>
> @@ -385,7 +383,7 @@ RunTftp (
>UnicodeStrToAsciiStrS (RemoteFilePath, AsciiRemoteFilePath, FilePathSize);
>
>if (ParamCount == 4) {
> -LocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
> +mLocalFilePath = ShellCommandLineGetRawValue (CheckPackage, 3);
>} else {
> Walker = RemoteFilePath + StrLen (RemoteFilePath);
> while ((--Walker) >= RemoteFilePath) {
> @@ -394,7 +392,7 @@ RunTftp (
> break;
>}
> }
> -LocalFilePath = Walker + 1;
> +mLocalFilePath = Walker + 1;
>}
>
>//
> @@ -543,7 +541,7 @@ RunTftp (
>goto NextHandle;
> }
>
> -Status = DownloadFile (Mtftp4, RemoteFilePath, AsciiRemoteFilePath,
> FileSize, Block
Re: [edk2] [PATCH v2 0/6] Delete TCP, PXE, iSCSI driver in MdeModulePkg
Series Reviewed-by: Jiaxin Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Siyuan Fu > Sent: Thursday, December 20, 2018 9:49 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Wu, Jiaxin ; > Zeng, Star ; Ni, Ruiyu > Subject: [edk2] [PATCH v2 0/6] Delete TCP, PXE, iSCSI driver in > MdeModulePkg > > Delete TCP, PXE, iSCSI driver in MdeModulePkg > > This patch series is to delete the Tcp4Dxe, UefiPxeBcDxe and IScsi4Dxe > drivers in MdeModulePkg. These drivers will not be maintained and can't > co-work with the dual-stack drivers in NetworkPkg. > > In future, people should use below NetworkPkg drivers instead: > NetworkPkg/IScsiDxe/IScsiDxe.inf > NetworkPkg/TcpDxe/TcpDxe.inf > NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf > These drivers are actively maintained with more bug fixes and new feature > support. > > All edk2 platforms DSC/FDF have already been updated to use the > NetworkPkg > drivers in privious patch. > > Bugzilla link: https://bugzilla.tianocore.org/show_bug.cgi?id=1278 > > v2: > Break original patch to separate commits per module. > > Cc: Jian J Wang > Cc: Hao Wu > Cc: Ruiyu Ni > Cc: Star Zeng > Cc: Jiaxin Wu > > Siyuan Fu (6): > MdeModulePkg: Delete Tcp4Dxe in MdeModulePkg. > NetworkPkg: Remove some clarification from TcpDxe.inf > MdeModulePkg: Delete IScsiDxe in MdeModulePkg. > NetworkPkg: Remove some clarification from IScsiDxe.inf > MdeModulePkg: Delete UefiPxeBcDxe in MdeModulePkg. > NetworkPkg: Remove some clarification from UefiPxeBcDxe.inf > > .../Network/IScsiDxe/ComponentName.c | 283 -- > .../Universal/Network/IScsiDxe/IScsiCHAP.c| 430 --- > .../Universal/Network/IScsiDxe/IScsiConfig.c | 1264 --- > .../Universal/Network/IScsiDxe/IScsiDhcp.c| 472 --- > .../Universal/Network/IScsiDxe/IScsiDriver.c | 676 > .../Network/IScsiDxe/IScsiExtScsiPassThru.c | 412 --- > .../Universal/Network/IScsiDxe/IScsiIbft.c| 539 --- > .../Network/IScsiDxe/IScsiInitiatorName.c | 116 - > .../Universal/Network/IScsiDxe/IScsiMisc.c| 948 -- > .../Universal/Network/IScsiDxe/IScsiProto.c | 2799 --- > .../Universal/Network/IScsiDxe/IScsiTcp4Io.c | 487 --- > MdeModulePkg/Universal/Network/IScsiDxe/Md5.c | 350 -- > .../Universal/Network/Tcp4Dxe/ComponentName.c | 433 --- > .../Universal/Network/Tcp4Dxe/SockImpl.c | 1201 --- > .../Universal/Network/Tcp4Dxe/SockInterface.c | 990 -- > .../Network/Tcp4Dxe/Tcp4Dispatcher.c | 717 > .../Universal/Network/Tcp4Dxe/Tcp4Driver.c| 782 - > .../Universal/Network/Tcp4Dxe/Tcp4Input.c | 1497 - > .../Universal/Network/Tcp4Dxe/Tcp4Io.c| 112 - > .../Universal/Network/Tcp4Dxe/Tcp4Main.c | 674 > .../Universal/Network/Tcp4Dxe/Tcp4Misc.c | 940 -- > .../Universal/Network/Tcp4Dxe/Tcp4Option.c| 352 -- > .../Universal/Network/Tcp4Dxe/Tcp4Output.c| 1238 --- > .../Universal/Network/Tcp4Dxe/Tcp4Timer.c | 584 > .../Network/UefiPxeBcDxe/ComponentName.c | 365 -- > .../Network/UefiPxeBcDxe/PxeBcDhcp.c | 1999 --- > .../Network/UefiPxeBcDxe/PxeBcDriver.c| 665 > .../Network/UefiPxeBcDxe/PxeBcImpl.c | 2989 - > .../Network/UefiPxeBcDxe/PxeBcMtftp.c | 454 --- > .../Network/UefiPxeBcDxe/PxeBcSupport.c | 221 -- > MdeModulePkg/MdeModulePkg.dsc |3 - > .../Network/IScsiDxe/ComponentName.h | 165 - > .../Universal/Network/IScsiDxe/IScsi4Dxe.uni | 25 - > .../Network/IScsiDxe/IScsi4DxeExtra.uni | 20 - > .../Universal/Network/IScsiDxe/IScsiCHAP.h| 106 - > .../Universal/Network/IScsiDxe/IScsiCommon.h | 22 - > .../Universal/Network/IScsiDxe/IScsiConfig.h | 166 - > .../Network/IScsiDxe/IScsiConfigDxe.vfr | 219 -- > .../IScsiDxe/IScsiConfigDxeStrings.uni| 62 - > .../Network/IScsiDxe/IScsiConfigNVDataStruc.h | 109 - > .../Universal/Network/IScsiDxe/IScsiDhcp.h| 55 - > .../Universal/Network/IScsiDxe/IScsiDriver.h | 140 - > .../Universal/Network/IScsiDxe/IScsiDxe.inf | 134 - > .../Network/IScsiDxe/IScsiExtScsiPassThru.h | 22 - > .../Universal/Network/IScsiDxe/IScsiIbft.h| 38 - > .../Universal/Network/IScsiDxe/IScsiImpl.h| 168 - > .../Network/IScsiDxe/IScsiInitiatorName.h | 74 - > .../Universal/Network/IScsiDxe/IScsiMisc.h| 317 -- > .../Universal/Network/IScsiDxe/IScsiProto.h | 1005 -- > .../Universal/Network/IScsiDxe/IScsiTcp4Io.h | 142 - > MdeModulePkg/Universal/Network/IScsiDxe/Md5.h | 80 - > .../Universal/Network/Tcp4Dxe/SockImpl
Re: [edk2] [PATCH v2] NetworkPkg/IScsiDxe: add debug logs for failed SetVariable attempts
Reviewed-by: Jiaxin Wu
> -Original Message-
> From: Vijayenthiran Subramaniam
> [mailto:vijayenthiran.subraman...@arm.com]
> Sent: Wednesday, November 21, 2018 11:36 PM
> To: edk2-devel@lists.01.org; Fu, Siyuan ; Wu, Jiaxin
>
> Cc: Vijayenthiran Subramaniam
> Subject: [PATCH v2] NetworkPkg/IScsiDxe: add debug logs for failed SetVariable
> attempts
>
> Add debug messages for failed attempts to write to a variable.
>
> Cc: Siyuan Fu
> Cc: Jiaxin Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vijayenthiran Subramaniam
>
> ---
> Made the log messages bit more useful.
>
> Thanks,
> Vijayenthiran
>
> NetworkPkg/IScsiDxe/IScsiMisc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
> index dd0d32dcda16..7bed95a8fba3 100644
> --- a/NetworkPkg/IScsiDxe/IScsiMisc.c
> +++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
> @@ -845,6 +845,10 @@ IScsiCreateAttempts (
> );
> FreePool (AttemptConfigOrder);
> if (EFI_ERROR (Status)) {
> + DEBUG ((DEBUG_ERROR,
> +"%a: Failed to set 'InitialAttemptOrder' with Guid (%g): "
> +"%r\n",
> +__FUNCTION__, , Status));
>return Status;
> }
>
> @@ -887,6 +891,10 @@ IScsiCreateAttempts (
> );
> FreePool (AttemptConfigData);
> if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR,
> + "%a: Failed to set variable (mPrivate->PortString) with Guid (%g):
> "
> + "%r\n",
> + __FUNCTION__, , Status));
>return Status;
> }
>}
> --
> 2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1] ShellPkg/TftpDynamicCommand: Clarify the retry count option in command.
Hi Jaben,
The patch already has been pushed after received your/Siyuan reviewed-by tag.
Thanks,
Jiaxin
> -Original Message-
> From: Carsey, Jaben
> Sent: Thursday, November 8, 2018 9:09 AM
> To: Fu, Siyuan ; Wu, Jiaxin ;
> edk2-devel@lists.01.org
> Cc: Ye, Ting
> Subject: RE: [PATCH v1] ShellPkg/TftpDynamicCommand: Clarify the retry
> count option in command.
>
> Wu,
>
> I plan to push this patch tomorrow, but I would like to add this to the commit
> message. What do you think?
>
> "This fixes the bug where parameter value 0 causes failure."
>
> -Jaben
>
> > -Original Message-
> > From: Fu, Siyuan
> > Sent: Monday, November 05, 2018 10:51 PM
> > To: Wu, Jiaxin ; edk2-devel@lists.01.org
> > Cc: Carsey, Jaben ; Ye, Ting
> > Subject: RE: [PATCH v1] ShellPkg/TftpDynamicCommand: Clarify the retry
> > count option in command.
> > Importance: High
> >
> > Reviewed-by: Fu Siyuan
> >
> >
> >
> > > -Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Monday, November 5, 2018 2:59 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Carsey, Jaben ; Ye, Ting
> > ;
> > > Fu, Siyuan ; Wu, Jiaxin
> > > Subject: [PATCH v1] ShellPkg/TftpDynamicCommand: Clarify the retry
> > count
> > > option in command.
> > >
> > > [-c ] is to define the number of times to transmit request
> > > packets and wait for a response. The default value is 6. But it doesn't
> > > specify the behavior of zero value. Here, The patch is to clear that:
> > > Set to zero also means to use the default value.
> > >
> > > Cc: Carsey Jaben
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Wu Jiaxin
> > > ---
> > > ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 6 +-
> > > ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.uni | 3 ++-
> > > 2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> > > b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> > > index ac2813efc3..028686e1ff 100644
> > > --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> > > +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c
> > > @@ -216,11 +216,11 @@ EFI_MTFTP4_CONFIG_DATA
> > DefaultMtftp4ConfigData = {
> > >{ { 0, 0, 0, 0 } }, // SubnetMask- Not relevant
> > > as UseDefaultSetting=TRUE
> > >0,// LocalPort - Automatically
> > > assigned port number.
> > >{ { 0, 0, 0, 0 } }, // GatewayIp - Not relevant
> > > as UseDefaultSetting=TRUE
> > >{ { 0, 0, 0, 0 } }, // ServerIp - Not known yet
> > >69, // InitialServerPort - Standard TFTP
> > > server port
> > > - 6,// TryCount - Max number of
> > > retransmissions.
> > > + 6,// TryCount - The number of
> > > times to transmit request packets and wait for a response.
> > >4 // TimeoutValue - Retransmission
> > > timeout in seconds.
> > > };
> > >
> > > STATIC CONST SHELL_PARAM_ITEM ParamList[] = {
> > >{L"-i", TypeValue},
> > > @@ -419,10 +419,14 @@ RunTftp (
> > >ValueStr = ShellCommandLineGetValue (CheckPackage, L"-c");
> > >if (ValueStr != NULL) {
> > > if (!StringToUint16 (ValueStr, )) {
> > >goto Error;
> > > }
> > > +
> > > +if (Mtftp4ConfigData.TryCount == 0) {
> > > + Mtftp4ConfigData.TryCount = 6;
> > > +}
> > >}
> > >
> > >ValueStr = ShellCommandLineGetValue (CheckPackage, L"-t");
> > >if (ValueStr != NULL) {
> > > if (!StringToUint16 (ValueStr, )) {
> > > diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.uni
> > > b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.uni
> > > index 654e42ad23..ff64912564 100644
> > > --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.uni
> > > +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.uni
> > > @@ -56,11 +56,12 @@
> > > " -i interface - Specifies an adapter name, i.e., eth0.\r\n"
&g
Re: [edk2] [PATCH v2 0/4] Conflict Detection for Tcp and PxeBc Driver
Looks good to me. Series Reviewed-by: Wu Jiaxin Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Songpeng Li > Sent: Monday, October 29, 2018 1:48 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ; Wu, > Jiaxin > Subject: [edk2] [PATCH v2 0/4] Conflict Detection for Tcp and PxeBc Driver > > v2: Modify files: > UefiPxeBcDxe.inf from MdeModulePkg > UefiPxeBcDxe.inf from NetworkPkg > tag protocol guid should be marked as BY_START > > Please refer to the log message of each commit for more details. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1278 > Cc: Ye Ting > Cc: Wu Jiaxin > Cc: Fu Siyuan > Songpeng Li (4): > MdeModulePkg: Add Tag Protocol for PxeBc Driver Conflict Detection. > MdeModulePkg/UefiPxeBcDxe: Add Conflict Detection Process. > NetworkPkg/UefiPxeBcDxe: Add Conflict Detection Process. > NetworkPkg/TcpDxe: Modify the Version of Driver Binding Protocol > > MdeModulePkg/Include/Protocol/PxeBcTag.h | 26 > MdeModulePkg/MdeModulePkg.dec | 5 +++ > .../Network/UefiPxeBcDxe/PxeBcDriver.c| 19 - > .../Network/UefiPxeBcDxe/PxeBcImpl.h | 3 +- > .../Network/UefiPxeBcDxe/UefiPxeBcDxe.inf | 1 + > NetworkPkg/TcpDxe/TcpDriver.c | 4 +- > NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 42 ++- > NetworkPkg/UefiPxeBcDxe/PxeBcImpl.h | 1 + > NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf | 1 + > 9 files changed, 96 insertions(+), 6 deletions(-) > create mode 100644 MdeModulePkg/Include/Protocol/PxeBcTag.h > > -- > 2.18.0.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg/IpSecDxe: Fix issue to parse SA Payload.
Thanks Ting, I will update the comments against the function.
> -Original Message-
> From: Ye, Ting
> Sent: Thursday, October 18, 2018 11:26 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Fu, Siyuan ; Wu, Jiaxin
> Subject: RE: [edk2] [Patch] NetworkPkg/IpSecDxe: Fix issue to parse SA
> Payload.
>
> Hi Jiaxin,
>
> I am confused why we need set values to following local variables when
> Ikev2ParseProposalData marks them as 'out' attribute. Please adds more
> comments why '0' is required and updates 'out' to 'in out' if '0' is
> necessary.
>
> +IntegrityAlgorithm = 0;
> +EncryptAlgorithm = 0;
> +EncryptKeylength = 0;
> +IsSupportEsn = FALSE;
>
> Thanks,
> Ting
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Tuesday, October 16, 2018 9:34 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [edk2] [Patch] NetworkPkg/IpSecDxe: Fix issue to parse SA Payload.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1251
>
> IpSecDxe failed to create the Child SA during parsing SA Payload, the issue
> was caused by the below commit:
>
> SHA-1: 1e0db7b11987d0ec93be7dfe26102a327860fdbd
> * MdeModulePkg/NetworkPkg: Checking for NULL pointer before use.
>
> In above commit, it changed the value of IsMatch in
> Ikev2ChildSaParseSaPayload() to FALSE. That's correct but it exposed the
> potential bug in to match the correct proposal Data, which will cause the
> issue happen.
>
> Cc: Fu Siyuan
> Cc: Ye Ting
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin
> ---
> NetworkPkg/IpSecDxe/Ikev2/Utility.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> b/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> index 0c9c929705..d61bae8c9d 100644
> --- a/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> +++ b/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> @@ -2502,15 +2502,16 @@ Ikev2ChildSaParseSaPayload (
>IntegrityAlgorithm == PreferIntegrityAlgorithm &&
>IsSupportEsn == PreferIsSupportEsn
>) {
> IsMatch = TRUE;
>} else {
> -PreferEncryptAlgorithm = 0;
> -PreferIntegrityAlgorithm = 0;
> -IsSupportEsn = TRUE;
> +IntegrityAlgorithm = 0;
> +EncryptAlgorithm = 0;
> +EncryptKeylength = 0;
> +IsSupportEsn = FALSE;
>}
> - ProposalData = (IKEV2_PROPOSAL_DATA*)((UINT8*)(ProposalData + 1)
> +
> + ProposalData = (IKEV2_PROPOSAL_DATA*)((UINT8*)(ProposalData + 1)
> + +
> ProposalData->NumTransforms * sizeof
> (IKEV2_TRANSFORM_DATA));
> }
>
> ProposalData = (IKEV2_PROPOSAL_DATA *)((IKEV2_SA_DATA
> *)SaPayload->PayloadBuf + 1);
> if (IsMatch) {
> --
> 2.17.1.windows.2
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-test][Patch] uefi-sct\EMS:Add HTTP Test
Reviewed-by: Jiaxin Wu
> -Original Message-
> From: Jin, Eric
> Sent: Friday, October 12, 2018 3:05 PM
> To: edk2-devel@lists.01.org
> Cc: Supreeth Venkatesh ; Wu, Jiaxin
>
> Subject: [edk2-test][Patch] uefi-sct\EMS:Add HTTP Test
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin
> Cc: Supreeth Venkatesh
> Cc: Jiaxin Wu
> ---
> .../EMS/Bin/TestCase/HTTP/Cancel.Conf1.Case1.tcl | 80
> .../Bin/TestCase/HTTP/Configure.Conf2.Case1.tcl| 96 ++
> .../Bin/TestCase/HTTP/Configure.Conf2.Case2.tcl| 118
> .../Bin/TestCase/HTTP/Configure.Conf3.Case1.tcl| 118
> .../Bin/TestCase/HTTP/Configure.Conf4.Case1.tcl| 102 +++
> .../Bin/TestCase/HTTP/GetModeData.Conf1.Case1.tcl | 87 +
> .../Bin/TestCase/HTTP/GetModeData.Conf1.Case2.tcl | 117
> .../Bin/TestCase/HTTP/GetModeData.Conf1.Case3.tcl | 112
> .../Bin/TestCase/HTTP/GetModeData.Conf2.Case1.tcl | 89 +
> .../EMS/Bin/TestCase/HTTP/Include/Http.inc.tcl | 201
> +
> .../TestCase/HTTP/Include/HttpAssertionGuid.tcl| 34
> .../EMS/Bin/TestCase/HTTP/Request.Conf1.Case1.tcl | 122 +
> .../EMS/Bin/TestCase/HTTP/Request.Conf2.Case1.tcl | 165
> +
> .../EMS/Bin/TestCase/HTTP/Request.Conf3.Case1.tcl | 84 +
> .../EMS/Bin/TestCase/HTTP/Request.Conf3.Case2.tcl | 101 +++
> .../EMS/Bin/TestCase/HTTP/Request.Conf3.Case3.tcl | 178
> ++
> .../EMS/Bin/TestCase/HTTP/Response.Conf1.Case1.tcl | 118
> .../EMS/Bin/TestCase/HTTP/Response.Conf2.Case1.tcl | 86 +
> .../EMS/Bin/TestCase/HTTP/Response.Conf2.Case2.tcl | 136 ++
> 19 files changed, 2144 insertions(+)
> create mode 100644 uefi-sct/EMS/Bin/TestCase/HTTP/Cancel.Conf1.Case1.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Configure.Conf2.Case1.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Configure.Conf2.Case2.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Configure.Conf3.Case1.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Configure.Conf4.Case1.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/GetModeData.Conf1.Case1.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/GetModeData.Conf1.Case2.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/GetModeData.Conf1.Case3.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/GetModeData.Conf2.Case1.tcl
> create mode 100644 uefi-sct/EMS/Bin/TestCase/HTTP/Include/Http.inc.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Include/HttpAssertionGuid.tcl
> create mode 100644 uefi-sct/EMS/Bin/TestCase/HTTP/Request.Conf1.Case1.tcl
> create mode 100644 uefi-sct/EMS/Bin/TestCase/HTTP/Request.Conf2.Case1.tcl
> create mode 100644 uefi-sct/EMS/Bin/TestCase/HTTP/Request.Conf3.Case1.tcl
> create mode 100644 uefi-sct/EMS/Bin/TestCase/HTTP/Request.Conf3.Case2.tcl
> create mode 100644 uefi-sct/EMS/Bin/TestCase/HTTP/Request.Conf3.Case3.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Response.Conf1.Case1.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Response.Conf2.Case1.tcl
> create mode 100644 uefi-
> sct/EMS/Bin/TestCase/HTTP/Response.Conf2.Case2.tcl
>
> diff --git a/uefi-sct/EMS/Bin/TestCase/HTTP/Cancel.Conf1.Case1.tcl b/uefi-
> sct/EMS/Bin/TestCase/HTTP/Cancel.Conf1.Case1.tcl
> new file mode 100644
> index 000..62f6967
> --- /dev/null
> +++ b/uefi-sct/EMS/Bin/TestCase/HTTP/Cancel.Conf1.Case1.tcl
> @@ -0,0 +1,80 @@
> +#
> +# Copyright (c) 2018, Intel Corporation. All rights reserved.
> +#
> +# This program and the accompanying materials
> +# are licensed and made available under the terms and conditions of the BSD
> License
> +# which accompanies this distribution. The full text of the license may be
> found at
> +# http://opensource.org/licenses/bsd-license.php
> +#
> +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +#
> +
>
> +CaseLevel CONFORMANCE
> +CaseAttribute AUTO
> +CaseVerboseLevel DEFAULT
> +
> +#
> +# test case Name, category, description, GUID...
> +#
> +CaseGuid 9B735919-A37E-4480-A49A-F0C7F47BBB9C
> +CaseName Cancel.Conf1.Case1
> +CaseCategory HTTP
> +CaseDescription {This case is to test the conformance - EFI_NOT_STARTED.
> \
> + -- This EFI HTTP Protocol instance has not be
Re: [edk2] [Patch] ShellPkg/TftpDynamicCommand: Fix the potentially uninitialized local variable used.
Thanks Star, I have committed the patch since it resolves the VS2012 build error. > -Original Message- > From: Zeng, Star > Sent: Friday, September 28, 2018 10:31 AM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ; Carsey, > Jaben ; Zeng, Star > Subject: RE: [Patch] ShellPkg/TftpDynamicCommand: Fix the potentially > uninitialized local variable used. > > Reviewed-by: Star Zeng > > -----Original Message- > From: Wu, Jiaxin > Sent: Thursday, September 27, 2018 10:42 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ; Carsey, > Jaben ; Zeng, Star ; Wu, > Jiaxin > Subject: [Patch] ShellPkg/TftpDynamicCommand: Fix the potentially > uninitialized local variable used. > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1217 > > Local variable 'Mtftp4Token' might be uninitialized when error happen. This > patch is to resolve the issue. > > Cc: Ye Ting > Cc: Fu Siyuan > Cc: Carsey Jaben > Cc: Zeng Star > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Wu Jiaxin > --- > ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c > b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c > index c66be6b9d9..d4391b9f33 100644 > --- a/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c > +++ b/ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c > @@ -934,10 +934,12 @@ DownloadFile ( >DOWNLOAD_CONTEXT *TftpContext; >EFI_MTFTP4_TOKEN Mtftp4Token; >UINT8 BlksizeBuf[10]; >UINT8 WindowsizeBuf[10]; > > + ZeroMem (, sizeof (EFI_MTFTP4_TOKEN)); > + >// Downloaded file can be large. BS.AllocatePages() is more faster >// than AllocatePool() and avoid fragmentation. >// The downloaded file could be an EFI application. Marking the >// allocated page as EfiBootServicesCode would allow to execute a >// potential downloaded EFI application. > @@ -959,11 +961,10 @@ DownloadFile ( >} >TftpContext->FileSize = FileSize; >TftpContext->DownloadedNbOfBytes = 0; >TftpContext->LastReportedNbOfBytes = 0; > > - ZeroMem (, sizeof (EFI_MTFTP4_TOKEN)); >Mtftp4Token.Filename= (UINT8*)AsciiFilePath; >Mtftp4Token.BufferSize = FileSize; >Mtftp4Token.Buffer = Buffer; >Mtftp4Token.CheckPacket = CheckPacket; >Mtftp4Token.Context = (VOID*)TftpContext; > -- > 2.17.1.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/5] Support windowsize to benefit tftp/pxe download performance.
> > MdeModulePke/Mtftp4Dxe: Support windowsize in read request > operation. > > NetworkPkg/Mtftp6Dxe: Support windowsize in read request operation. > > ShellPkg/TftpDynamicCommand: Add one option for tftp command to > > specify windowsize. > > NetworkPkg: Define one PCD for PXE to specify MTFTP windowsize. > > NetworkPkg/UefiPxeBcDxe: Use the specified MTFTP windowsize. > > You didn't include the (unchanged) patches #1 through #3 from the v1 > series in this posting. Hence, a reminder: please don't forget to pick > up my T-b for patches #1 and #2, from: > Sure, I will pick up the tag. Thanks, Jiaxin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 4/5] NetworkPkg: Define one PCD for PXE to specify MTFTP windowsize.
> > git-am complained about trailing whitespace: > > > (4) and here. > > With those fixed: > > Reviewed-by: Laszlo Ersek > I will fix them. Thanks reminder. /Jiaxin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 6/6] NetworkPkg/UefiPxeBcDxe: Add the clarification compared to UefiPxeBcDxe in MdeModulePkg.
Thanks the correction, I will refine all the patches according your comments before committing the patches. Best Regards! Jiaxin > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Tuesday, September 25, 2018 6:31 PM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan > Subject: Re: [Patch 6/6] NetworkPkg/UefiPxeBcDxe: Add the clarification > compared to UefiPxeBcDxe in MdeModulePkg. > > On 09/25/18 05:44, Jiaxin Wu wrote: > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1205 > > > > This patch is to add the driver usage/difference clarification > > compared to UefiPxeBcDxe in MdeModulePkg. > > > > Cc: Ye Ting > > Cc: Fu Siyuan > > Cc: Laszlo Ersek > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Wu Jiaxin > > --- > > NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf > b/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf > > index e2a0eb44b1..f2ec34df93 100644 > > --- a/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf > > +++ b/NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf > > @@ -1,12 +1,17 @@ > > ## @file > > # Access PXE-compatible devices for network access and network booting. > > # > > # This driver provides PXE Base Code Protocol which is used to accessing > > -# PXE-compatible device for network access or booting. It could work > together > > -# with an IPv4 stack, an IPv6 stack or both. > > +# PXE-compatible device for network access or booting. This driver > supports > > +# both IPv4 and IPv6 network stack. > > # > > +# Notes: > > +# 1) This driver can't co-work with the UefiPxeBcDxe driver in > MdeModulePkg. > > +# 2) This driver includes more bugs fix and supports more features (e.g. > IPv6, > > +# MTFTP windowsize) than the UefiPxeBcDxe driver in MdeModulePkg. > So, we > > +# recommand to use this driver even both of them can be used. > > # > > # Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials > > # are licensed and made available under the terms and conditions of the > BSD License > > > > Same comments as for patch #4. With those updates: > > Reviewed-by: Laszlo Ersek > > Thanks, > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] NetworkPkg: fix read memory access overflow in HTTPBoot.
Besides, I recommend to separate the patch for HttpDxe and HttpUtilitiesDxe.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, September 25, 2018 11:43 AM
> To: Li, Songpeng ; edk2-devel@lists.01.org
> Cc: Wu, Jiaxin
> Subject: RE: [PATCH] NetworkPkg: fix read memory access overflow in
> HTTPBoot.
>
> Hi, Songpeng
>
> The change is ok with me while I have one comment for the original
> AllocateZeroPool() in these places. Since there will be always a CopyMem()
> to fill up data content to the new allocated buffer, there is no need to use
> AllocateZeroPool(), just AllocatePool() and adding null terminator should be
> enough. This will save the unnecessary ZeroMem() time cost for better
> performance. Thanks.
>
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Li, Songpeng
> > Sent: Tuesday, September 25, 2018 11:29 AM
> > To: edk2-devel@lists.01.org
> > Cc: Fu, Siyuan ; Wu, Jiaxin
> > Subject: [PATCH] NetworkPkg: fix read memory access overflow in
> HTTPBoot.
> >
> > The input param String of AsciiStrStr() requires a pointer to
> > Null-terminated string, however in HttpTcpReceiveHeader() and
> > HttpUtilitiesParse(), the Buffersize before AllocateZeroPool()
> > is equal to the size of TCP header, after the CopyMem(), it
> > might not end with Null-terminator. It might cause memory
> > access overflow.
> >
> > Cc: Fu Siyuan
> > Cc: Wu Jiaxin
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1204
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Songpeng Li
> > ---
> > NetworkPkg/HttpDxe/HttpProto.c | 4 ++--
> > NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c | 4 +++-
> > 2 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> > b/NetworkPkg/HttpDxe/HttpProto.c
> > index 94f89f5665..c729f76eff 100644
> > --- a/NetworkPkg/HttpDxe/HttpProto.c
> > +++ b/NetworkPkg/HttpDxe/HttpProto.c
> > @@ -1917,7 +1917,7 @@ HttpTcpReceiveHeader (
> >// Append the response string.
> >//
> >*BufferSize = *SizeofHeaders + Fragment.Len;
> > - Buffer = AllocateZeroPool (*BufferSize);
> > + Buffer = AllocateZeroPool (*BufferSize + 1);
> >if (Buffer == NULL) {
> > Status = EFI_OUT_OF_RESOURCES;
> > return Status;
> > @@ -2016,7 +2016,7 @@ HttpTcpReceiveHeader (
> >// Append the response string.
> >//
> >*BufferSize = *SizeofHeaders + Fragment.Len;
> > - Buffer = AllocateZeroPool (*BufferSize);
> > + Buffer = AllocateZeroPool (*BufferSize + 1);
> >if (Buffer == NULL) {
> > Status = EFI_OUT_OF_RESOURCES;
> > return Status;
> > diff --git a/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> > b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> > index a9a1c7c586..2292b52537 100644
> > --- a/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> > +++ b/NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c
> > @@ -298,6 +298,7 @@ HttpUtilitiesParse (
> >CHAR8 *FieldName;
> >CHAR8 *FieldValue;
> >UINTN Index;
> > + UINTN HttpBufferSize;
> >
> >Status = EFI_SUCCESS;
> >TempHttpMessage = NULL;
> > @@ -311,7 +312,8 @@ HttpUtilitiesParse (
> > return EFI_INVALID_PARAMETER;
> >}
> >
> > - TempHttpMessage = AllocateZeroPool (HttpMessageSize);
> > + HttpBufferSize = HttpMessageSize + 1;
> > + TempHttpMessage = AllocateZeroPool (HttpBufferSize);
> >if (TempHttpMessage == NULL) {
> > return EFI_OUT_OF_RESOURCES;
> >}
> > --
> > 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/5] Support windowsize to benefit tftp/pxe download performance.
Hi Laszlo, > > If that's the case, should we consider the three drivers under > "MdeModulePkg/Universal/Network/" deprecated, and should we abandon > them > completely? > I think the answer is NO (At least for now). In my opinion, the drivers in MdeModulePkg is also useful in some case, because it already has been used in some platform since it's lightweight to reduce the platform size requirement. As you said below, there is no openssl dependency in MdeModulePkg/ISCSI. > If that's the case, then it is really important to document. > > Because, if a user reports a networking-related error (after building > OVMF without NETWORK_IP6_ENABLE), then I wouldn't like to start > investigating, just to find out that the issue was fixed in NetworkPkg a > year earlier. > > Furthermore, if the MdeModulePkg/Universal/Network/ drivers are > deprecated, when do we intend to actually remove them from the tree? > > Oh, wait, is this related to OpenSSL? When including IScsiDxe from > NetworkPkg, OpenSSL is required. When including IScsiDxe from > MdeModulePkg, OpenSSL is not required -- but the networking > functionality may have some known bugs (which are already fixed in > NetworkPkg). > > Is this the real trade-off? > For the missed fixes, that's because we didn't take a look whether it also existed in MdeModulePkg, you know, some issues need to be analyzed case by case and most of them are usage related, but actually, it's not so such critical to the other platform. That's why we prefer/try to stay the same of those drivers in MdeModulePkg, if so, it also can help us reduce the development/testing effort against two sets of stacks. What we prefer is to fix the problem / include new feature separately. As I said before, depends on the request/report from customer. So, that's the reason why we recommend to use the stacks in NetworkPkg. Of Couse, if any issue was exposed in MdeModulePkg, we will help to investigate and fix it. I agree we need document something to highlight that. Siyuan/Ting, if no objection, I will do that in separate patch instead of mixing with this new feature support. Thanks Jiaxin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/5] Support windowsize to benefit tftp/pxe download performance.
Hi Laszlo, I agree there is no document to describe the detailed difference against the overlapped network drivers the between NetworkPkg and MdeModulePkg (except IPv4/IPv6 support ). We only declared that those drivers should not be used at the same (https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg-Getting-Started-Guide). Actually, the problem you mentioned here only exists in ISCSI/TCP/PXE drivers - Tcp4Dxe VS TcpDxe, IScsiDxe VS IScsiDxe, UefiPxeBcDxe VS UefiPxeBcDxe. So, as you said, it's the time for us to add some declaration somewhere (inf or wiki) -- For those three drivers in MdeModulePkg, they will remain unchanged until there is any specific requirement that we need fix any issue. That will greatly reduce the effort to maintain/test those combine of two drivers. So, we don’t recommend to use those three drivers in MdeModulePkg because they might some issues, which has been fixed in the NetworkPkg drivers. If you agree, we will add some statement in the corresponding *.inf files. Thanks, Jiaxin > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, September 19, 2018 7:25 PM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Carsey, Jaben ; > Fu, Siyuan ; Shao, Ming > Subject: Re: [edk2] [Patch 0/5] Support windowsize to benefit tftp/pxe > download performance. > > On 09/19/18 04:20, Wu, Jiaxin wrote: > >> On 09/17/18 07:43, Jiaxin Wu wrote: > >>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=886 > >>> > >>> The series patches are to support the TFTP windowsize option described > in > >> RFC 7440. > >>> TFTP shell command and UEFI PXE driver will use the feature to benefit > the > >> download > >>> performance. > >> > >> I tested this series, between two virtual machines running on my laptop. > >> The TFTP server program that I used was "tftp-server-5.2-22.el7.x86_64". > >> The downloaded file was 478,150,656 bytes in size. I built OVMF with > >> NETWORK_IP6_ENABLE, so that the last patch would take effect for both > >> PXEv4 and PXEv6. > >> > >> Before the series: > >> - PXEv4: 75 seconds (~ 6225 KB/s) > >> - PXEv6: 100 seconds (~ 4669 KB/s) > >> > >> After the series: > >> - PXEv4: 48 seconds (~ 9728 KB/s) > >> - PXEv6: 60 seconds (~ 7782 KB/s) > >> > >> These measurements are very rough (I didn't run them multiple times > >> etc), but I think they are still quite good indicators. > >> > >> For the testing, I used the UEFI boot options in UiApp, and not the > >> shell command, hence I have no feedback on patch #3. > >> > >> For patches #1, #2, and #5: > >> > >> Tested-by: Laszlo Ersek > >> > > > > Thanks the verification. > > > > > >> However, as I pointed out elsewhere in the thread, I think: > >> > >> - You might want to port the changes from patch#5 to > >> "MdeModulePkg/Universal/Network/UefiPxeBcDxe" as well, in a > separate > >> patch (patch #6). > >> > >> - If not, then (a) we should document this feature difference in the INF > >> files of the UefiPxeBcDxe drivers, (b) patch #4 should be re-done so > >> that it target NetworkPkg, not MdeModulePkg. > >> > > > > As I said in the previous email, normally, we only add the new feature into > the combo driver. But I think that's depends on the request. If you want to > include the feature into MdeModulePkg/Universal/Network/UefiPxeBcDxe > since the OVMF platform might use it, I will create patch #6. If not, I will > follow the comments (a)/(b). > > I don't currently have a use case or "requirement" for the window size > feature to work in an OVMF build that does *not* have > NETWORK_IP6_ENABLE. So from my side, we can delay the porting until such > a need materializes (it might never materialize, of course!) > > However, because this information -- i.e., the feature separation > between the IPv4-only, and the combined IPv4/IPv6 driver -- is new to > me, can we please document it somewhere in the code, for example, in the > INF files? We don't have to spell out the TFTP window size feature by > name, just the fact that NetworkPkg's UefiPxeBcDxe has more features in > general (even such features that are orthogonal to internet protocol > version, v4 vs. v6). > > If such documentation already exists, then I missed it, sorry! > > Thanks! > Laszlo > > >> - Patch #4 (regardless of package DEC) should be extended with > >> documentation (both DEC and UNI). > >> > >> Thanks > >> Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 4/5] MdeModulePkg/MdeModulePkg.dec: Define one PCD for PXE to specify MTFTP windowsize.
Thanks Siyuan, I will rename the PCD name for better understanding. > -Original Message- > From: Fu, Siyuan > Sent: Wednesday, September 19, 2018 8:38 AM > To: Wu, Jiaxin ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Shao, Ming > Subject: RE: [Patch 4/5] MdeModulePkg/MdeModulePkg.dec: Define one > PCD for PXE to specify MTFTP windowsize. > > Hi, Jiaxin > > I think we should also update the comments for PcdTftpWindowSize usage. > And could we change the name to PcdPxeTftpWindowSize since it only > impacts the PXE tftp download? > > BestRegards > Fu Siyuan > > > -Original Message- > > From: Wu, Jiaxin > > Sent: Monday, September 17, 2018 1:44 PM > > To: edk2-devel@lists.01.org > > Cc: Ye, Ting ; Fu, Siyuan ; Shao, > > Ming ; Wu, Jiaxin > > Subject: [Patch 4/5] MdeModulePkg/MdeModulePkg.dec: Define one PCD > for PXE > > to specify MTFTP windowsize. > > > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=886 > > > > This patch is to define one new PCD for PXE driver to specify MTFTP > > windowsize so as > > to improve the PXE download performance. The default value is set to 4. > > > > Cc: Ye Ting > > Cc: Fu Siyuan > > Cc: Shao Ming > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Wu Jiaxin > > --- > > MdeModulePkg/MdeModulePkg.dec | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > > index 74a699cbb7..bfc63e5fcb 100644 > > --- a/MdeModulePkg/MdeModulePkg.dec > > +++ b/MdeModulePkg/MdeModulePkg.dec > > @@ -1203,10 +1203,11 @@ > >## This setting can override the default TFTP block size. A value of 0 > > computes > ># the default from MTU information. A non-zero value will be used as > > block size > ># in bytes. > ># @Prompt TFTP block size. > > > gEfiMdeModulePkgTokenSpaceGuid.PcdTftpBlockSize|0x0|UINT64|0x30001 > 026 > > + > gEfiMdeModulePkgTokenSpaceGuid.PcdTftpWindowSize|0x4|UINT64|0x30 > 00102A > > > >## Maximum address that the DXE Core will allocate the > > EFI_SYSTEM_TABLE_POINTER > ># structure. The default value for this PCD is 0, which means that the > > DXE Core > ># will allocate the buffer from the EFI_SYSTEM_TABLE_POINTER structure > > on a 4MB > ># boundary as close to the top of memory as feasible. If this PCD is > > set to a > > -- > > 2.17.1.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/5] Support windowsize to benefit tftp/pxe download performance.
> On 09/17/18 07:43, Jiaxin Wu wrote: > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=886 > > > > The series patches are to support the TFTP windowsize option described in > RFC 7440. > > TFTP shell command and UEFI PXE driver will use the feature to benefit the > download > > performance. > > I tested this series, between two virtual machines running on my laptop. > The TFTP server program that I used was "tftp-server-5.2-22.el7.x86_64". > The downloaded file was 478,150,656 bytes in size. I built OVMF with > NETWORK_IP6_ENABLE, so that the last patch would take effect for both > PXEv4 and PXEv6. > > Before the series: > - PXEv4: 75 seconds (~ 6225 KB/s) > - PXEv6: 100 seconds (~ 4669 KB/s) > > After the series: > - PXEv4: 48 seconds (~ 9728 KB/s) > - PXEv6: 60 seconds (~ 7782 KB/s) > > These measurements are very rough (I didn't run them multiple times > etc), but I think they are still quite good indicators. > > For the testing, I used the UEFI boot options in UiApp, and not the > shell command, hence I have no feedback on patch #3. > > For patches #1, #2, and #5: > > Tested-by: Laszlo Ersek > Thanks the verification. > However, as I pointed out elsewhere in the thread, I think: > > - You might want to port the changes from patch#5 to > "MdeModulePkg/Universal/Network/UefiPxeBcDxe" as well, in a separate > patch (patch #6). > > - If not, then (a) we should document this feature difference in the INF > files of the UefiPxeBcDxe drivers, (b) patch #4 should be re-done so > that it target NetworkPkg, not MdeModulePkg. > As I said in the previous email, normally, we only add the new feature into the combo driver. But I think that's depends on the request. If you want to include the feature into MdeModulePkg/Universal/Network/UefiPxeBcDxe since the OVMF platform might use it, I will create patch #6. If not, I will follow the comments (a)/(b). > - Patch #4 (regardless of package DEC) should be extended with > documentation (both DEC and UNI). > > Thanks > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 4/5] MdeModulePkg/MdeModulePkg.dec: Define one PCD for PXE to specify MTFTP windowsize.
> Subject: Re: [edk2] [Patch 4/5] MdeModulePkg/MdeModulePkg.dec: Define
> one PCD for PXE to specify MTFTP windowsize.
>
> On 09/17/18 07:43, Jiaxin Wu wrote:
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=886
> >
> > This patch is to define one new PCD for PXE driver to specify MTFTP
> windowsize so as
> > to improve the PXE download performance. The default value is set to 4.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Shao Ming
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Wu Jiaxin
> > ---
> > MdeModulePkg/MdeModulePkg.dec | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> > index 74a699cbb7..bfc63e5fcb 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -1203,10 +1203,11 @@
> >## This setting can override the default TFTP block size. A value of 0
> computes
> ># the default from MTU information. A non-zero value will be used as
> block size
> ># in bytes.
> ># @Prompt TFTP block size.
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdTftpBlockSize|0x0|UINT64|0x30001
> 026
> > +
> gEfiMdeModulePkgTokenSpaceGuid.PcdTftpWindowSize|0x4|UINT64|0x30
> 00102A
> >
> >## Maximum address that the DXE Core will allocate the
> EFI_SYSTEM_TABLE_POINTER
> ># structure. The default value for this PCD is 0, which means that the
> > DXE
> Core
> ># will allocate the buffer from the EFI_SYSTEM_TABLE_POINTER structure
> on a 4MB
> ># boundary as close to the top of memory as feasible. If this PCD is
> > set to
> a
> >
>
> The new PCD is missing documentation -- and not just in the DEC file,
> but also in the corresponding UNI file.
>
Agree. I will fix that in the version patch.
> Furthermore, given that the PCD is only used in the next patch (which is
> for NetworkPkg), the PCD should arguably be introduced to NetworkPkg.
>
> ("PcdTftpBlockSize" is different, that one is used in both
> "MdeModulePkg/Universal/Network/UefiPxeBcDxe/" and
> "NetworkPkg/UefiPxeBcDxe".)
>
Agree, I will move the new PCD into the networkpkg.
> ... In fact, that brings me to my next question -- patch #5 only
> modifies "NetworkPkg/UefiPxeBcDxe"; it doesn't modify
> "MdeModulePkg/Universal/Network/UefiPxeBcDxe". The former module is
> usually included as a replacement for the latter, when the platform
> build enables IPv6. Is this intentional? I.e., is it the intent to *not*
> bring this feature to "MdeModulePkg/Universal/Network/UefiPxeBcDxe"?
>
Yes, we only add the new feature into the combo driver.
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2] NetworkPkg: UefiPxeBcDxe: Add EXCLUSIVE attribute when opening SNP protocol installed by PXE.
Correct one of my comments. The new version patch should *NOT* include the reviewed-by tag from previous version. Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Jiaxin > Sent: Wednesday, September 19, 2018 9:32 AM > To: Laszlo Ersek ; Subramanian, Sriram s...@hpe.com>; Wang, Fan ; edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan ; > subraman...@mx0b-002e3701.pphosted.com > Subject: Re: [edk2] [Patch v2] NetworkPkg: UefiPxeBcDxe: Add EXCLUSIVE > attribute when opening SNP protocol installed by PXE. > > > > Subject: [Patch v2] NetworkPkg: UefiPxeBcDxe: Add EXCLUSIVE attribute > > when opening SNP protocol installed by PXE. > > > > > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1152 > > > > > > v2: Sync the same logic to Ipv6 and update code comments. > > > > > > The PXE driver installs a SNP and open this SNP with attribute BY_DRIVER > > > to avoid it being opened by MNP driver, this SNP is also expected not to > > > be opened by other drivers with EXCLUSIVE attribute. In some cases, > other > > > drivers may happen to do this by error, and thus cause a system crash. > > > This patch adds EXCLUSIVE attribute when opening SNP in PXE driver, and > > > will reject all OpenProtocol requests by EXCLUSIVE. > > > > > > Cc: Subramanian, Sriram > > > Cc: Ye Ting > > > Cc: Fu Siyuan > > > Cc: Wu Jiaxin > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Wang Fan > > > --- > > > NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 8 > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > Either my edk2-devel subscription is breaking down, or our discipline > > regarding commit pushing is down the drain, recently. > > > > This patch has been pushed as commit cde5a72d365e. Problems with that > > commit: > > > > (1) The git authorship is marked as "edk2-devel-boun...@lists.01.org". > > That's *wrong*. This patch was authored by Wang Fan > > . > > > > Sorry Laszlo, I didn't check the "Author" field before pushing the patch as I > received the commit request form Fan. I don't know whether it's the patch > reason or TortoiseGit failed to fetch the "Signed-off-by" tag as "Author" > field. > Anyway, I will double check that. > > > (2) The commit lists Siyuan and Jiaxin as having given their reviews. I > > don't see their *v2* reviews anywhere on the list. I see their *v1* > > reviews, but the patch was changed in v2. Wang Fan was correct not to > > carry forward the v1 reviews into the v2 posting. If the v2 posting was > > fine, then Siyuan and Jiaxin should have confirmed that (with R-b's) on > > the list, before pushing the commit. > > > > Yes, you are right, Fan should include the v1 reviewer into the v2 posting, > and > the reviewer should confirm the new version patch even he/she is the final > version committer. > The new version patch should *NOT* include the reviewed-by tag from previous version. > > Another process failure that I'm witnessing is that people forget to > > close BZs once the corresponding fixes are upstream. Sorry but that just > > makes a joke out of bug tracking. > > > > Thanks the reminder, we will pay attention next time. > > > Come on, guys. We can do better than this. Show some discipline and > > dedication to the process, please. The process is not self-serving; it's > > in place to promote mutual understanding. > > > > Laszlo > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2] NetworkPkg: UefiPxeBcDxe: Add EXCLUSIVE attribute when opening SNP protocol installed by PXE.
> > Subject: [Patch v2] NetworkPkg: UefiPxeBcDxe: Add EXCLUSIVE attribute > when opening SNP protocol installed by PXE. > > > > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1152 > > > > v2: Sync the same logic to Ipv6 and update code comments. > > > > The PXE driver installs a SNP and open this SNP with attribute BY_DRIVER > > to avoid it being opened by MNP driver, this SNP is also expected not to > > be opened by other drivers with EXCLUSIVE attribute. In some cases, other > > drivers may happen to do this by error, and thus cause a system crash. > > This patch adds EXCLUSIVE attribute when opening SNP in PXE driver, and > > will reject all OpenProtocol requests by EXCLUSIVE. > > > > Cc: Subramanian, Sriram > > Cc: Ye Ting > > Cc: Fu Siyuan > > Cc: Wu Jiaxin > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Wang Fan > > --- > > NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > Either my edk2-devel subscription is breaking down, or our discipline > regarding commit pushing is down the drain, recently. > > This patch has been pushed as commit cde5a72d365e. Problems with that > commit: > > (1) The git authorship is marked as "edk2-devel-boun...@lists.01.org". > That's *wrong*. This patch was authored by Wang Fan > . > Sorry Laszlo, I didn't check the "Author" field before pushing the patch as I received the commit request form Fan. I don't know whether it's the patch reason or TortoiseGit failed to fetch the "Signed-off-by" tag as "Author" field. Anyway, I will double check that. > (2) The commit lists Siyuan and Jiaxin as having given their reviews. I > don't see their *v2* reviews anywhere on the list. I see their *v1* > reviews, but the patch was changed in v2. Wang Fan was correct not to > carry forward the v1 reviews into the v2 posting. If the v2 posting was > fine, then Siyuan and Jiaxin should have confirmed that (with R-b's) on > the list, before pushing the commit. > Yes, you are right, Fan should include the v1 reviewer into the v2 posting, and the reviewer should confirm the new version patch even he/she is the final version committer. > Another process failure that I'm witnessing is that people forget to > close BZs once the corresponding fixes are upstream. Sorry but that just > makes a joke out of bug tracking. > Thanks the reminder, we will pay attention next time. > Come on, guys. We can do better than this. Show some discipline and > dedication to the process, please. The process is not self-serving; it's > in place to promote mutual understanding. > > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg: UefiPxeBcDxe: Add EXCLUSIVE attribute when opening SNP protocol installed by PXE.
Reviewed-by: Wu Jiaxin
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Friday, September 14, 2018 3:39 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Wu,
> Jiaxin
> Subject: [edk2] [Patch] NetworkPkg: UefiPxeBcDxe: Add EXCLUSIVE
> attribute when opening SNP protocol installed by PXE.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1152
>
> The PXE driver installs a SNP and open this SNP with attribute BY_DRIVER
> to avoid it being opened by MNP driver, this SNP is also expected not to
> be opened by other drivers with EXCLUSIVE attribute. In some cases, other
> drivers may happen to do this by error, and thus cause a system crash.
> This patch adds EXCLUSIVE attribute when opening SNP in PXE driver, and
> will reject all OpenProtocol requests by EXCLUSIVE.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wang Fan
> ---
> NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
> b/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
> index bc9dc914f3..1a9671d373 100644
> --- a/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
> +++ b/NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c
> @@ -821,11 +821,11 @@ PxeBcCreateIp4Children (
> Private->Ip4Nic->Controller,
> ,
> (VOID **) ,
> This->DriverBindingHandle,
> Private->Ip4Nic->Controller,
> -EFI_OPEN_PROTOCOL_BY_DRIVER
> +
> EFI_OPEN_PROTOCOL_BY_DRIVER|EFI_OPEN_PROTOCOL_EXCLUSIVE
> );
> if (EFI_ERROR (Status)) {
>goto ON_ERROR;
> }
>}
> --
> 2.16.2.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] MdeModulePkg/Network: Add 32bit subnet mask support for IP4 PXE boot.
Reviewed-by: Jiaxin Wu
> -Original Message-
> From: Fu, Siyuan
> Sent: Wednesday, August 29, 2018 4:53 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: [PATCH v2] MdeModulePkg/Network: Add 32bit subnet mask
> support for IP4 PXE boot.
>
> V2 update:
> The original patch has a problem, that if an IP child which not using default
> address is
> configured with /32 subnet mask, while the gateway is configured to the
> default route table,
> then the gateway won't take effect on that IP child. This patch fixed the
> problem.
>
> This patch updates IP4 stack to support 32bit subnet mask in PXE boot
> process.
> When 32bit subnet mask is used, the IP4 driver couldn't use the subnet mask
> to determine
> whether destination IP address is on-link or not, so it will always try to
> send
> all the
> packets to the destination IP address directly first, if failed it will
> continue
> to try the default gateway.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Fu Siyuan
> Cc: Ye Ting
> Cc: Wu Jiaxin
> ---
> MdeModulePkg/Include/Library/NetLib.h | 5 +-
> MdeModulePkg/Library/DxeNetLib/DxeNetLib.c| 13 +-
> .../Universal/Network/Ip4Dxe/Ip4Common.h | 2 +-
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.c | 117
> --
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.h | 5 +-
> .../Universal/Network/Ip4Dxe/Ip4Impl.c| 2 +-
> .../Universal/Network/Ip4Dxe/Ip4Output.c | 11 +-
> .../Universal/Network/Ip4Dxe/Ip4Route.c | 26 +++-
> .../Universal/Network/Ip4Dxe/Ip4Route.h | 9 +-
> .../Universal/Network/Mtftp4Dxe/Mtftp4Impl.c | 6 +-
> 10 files changed, 163 insertions(+), 33 deletions(-)
>
> diff --git a/MdeModulePkg/Include/Library/NetLib.h
> b/MdeModulePkg/Include/Library/NetLib.h
> index ef7bc429c1..b7ef99c7b5 100644
> --- a/MdeModulePkg/Include/Library/NetLib.h
> +++ b/MdeModulePkg/Include/Library/NetLib.h
> @@ -422,8 +422,9 @@ NetGetIpClass (
>
>If all bits of the host address of IP are 0 or 1, IP is also not a valid
> unicast
> address,
>except when the originator is one of the endpoints of a point-to-point link
> with a 31-bit
> - mask (RFC3021).
> -
> + mask (RFC3021), or a 32bit NetMask (all 0xFF) is used for special network
> environment (e.g.
> + PPP link).
> +
>@param[in] IpThe IP to check against.
>@param[in] NetMask The mask of the IP.
>
> diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> index bf8f5523e6..63f4724062 100644
> --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> @@ -654,8 +654,9 @@ NetGetIpClass (
>
>If all bits of the host address of IP are 0 or 1, IP is also not a valid
> unicast
> address,
>except when the originator is one of the endpoints of a point-to-point link
> with a 31-bit
> - mask (RFC3021).
> -
> + mask (RFC3021), or a 32bit NetMask (all 0xFF) is used for special network
> environment (e.g.
> + PPP link).
> +
>@param[in] IpThe IP to check against.
>@param[in] NetMask The mask of the IP.
>
> @@ -669,18 +670,20 @@ NetIp4IsUnicast (
>IN IP4_ADDR NetMask
>)
> {
> + INTN MaskLength;
> +
>ASSERT (NetMask != 0);
>
>if (Ip == 0 || IP4_IS_LOCAL_BROADCAST (Ip)) {
> return FALSE;
>}
>
> - if (NetGetMaskLength (NetMask) != 31) {
> + MaskLength = NetGetMaskLength (NetMask);
> + ASSERT ((MaskLength >= 0) && (MaskLength <= IP4_MASK_NUM));
> + if (MaskLength < 31) {
> if (((Ip &~NetMask) == ~NetMask) || ((Ip &~NetMask) == 0)) {
>return FALSE;
> }
> - } else {
> -return TRUE;
>}
>
>return TRUE;
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
> index e0fffc9d0d..994a81f4de 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Common.h
> @@ -55,7 +55,7 @@ typedef struct _IP4_SERVICEIP4_SERVICE;
> /// Compose the fragment field to be used in the IP4 header.
> ///
> #define IP4_HEAD_FRAGMENT_FIELD(Df, Mf, Offset) \
> -((UINT16)(((Df) ? 0x4000 : 0) | ((Mf) ? 0x2000 : 0) | (((Offset) >> 3) &
> 0x1fff)))
> +((UINT16)(((Df) ? IP4_HEAD_DF_MASK : 0) | ((Mf) ?
> IP4_HEAD_MF_MASK : 0) | (((Offset) >> 3) & IP4_HEAD_OFFSET_MASK)))
>
> #define IP4_LAST_FRAGMENT(FragmentField) \
>
Re: [edk2] [Patch 2/2] ShellPkg: Update Ifconfig command to accept 32bit subnet mask.
Reviewed-by: Jiaxin Wu
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, August 28, 2018 9:53 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Ye, Ting ; Wu, Jiaxin
>
> Subject: [Patch 2/2] ShellPkg: Update Ifconfig command to accept 32bit
> subnet mask.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Fu Siyuan
> Cc: Ruiyu Ni
> Cc: Ye Ting
> Cc: Wu Jiaxin
> ---
> ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> index 52415e0ad0..e9f644c739 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> @@ -1032,6 +1032,7 @@ IfConfigSetInterfaceInfo (
>SubnetMask = NTOHL (SubnetMask);
>TempGateway = NTOHL (TempGateway);
>if ((SubnetMask != 0) &&
> + (SubnetMask != 0xu) &&
>!NetIp4IsUnicast (TempGateway, SubnetMask)) {
> ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> (STR_IFCONFIG_INVALID_GATEWAY), gShellNetwork1HiiHandle, VarArg-
> >Arg);
> ShellStatus = SHELL_INVALID_PARAMETER;
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask support for IP4 PXE boot.
Against the below condition code in Ip4Route():
//
// We will always try to use the direct destination address when /32 subnet
mask is used.
//
if (RtEntry == NULL && SubnetMask != IP4_ALLONE_ADDRESS) {
return NULL;
}
If there is no default route { Dest: 0.0.0.0, Mask: 0.0.0.0,NextHope: Gataway }
in instance route table, while it exists in default route table, the failure
will happen. So, we need update the code to handle such case.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, August 28, 2018 5:41 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting
> Subject: RE: [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask
> support for IP4 PXE boot.
>
> Hi, Jiaxin
>
> The IP4 routing logic for /32 subnet mask can be explain as below, maybe I
> need to add it to the commit log or in code comments.
>
> Ip4Output() is called to send a packet
> If a matching route cache (src, dest -> xxx) can be find,
> send the packet to address xxx according to the route cache.
> else
> create a new route cache (src, dest -> dest)
><-
> This is done in Ip4Route()
> if a default gateway is configured, save it to the route cache
> TAG.<- This is done in Ip4Route()
> send the packet to dest
><- This is
> done in Ip4SendFrame()
> if ARP resolve failed for dest
> find the matching route cache and check TAG to see
> if there is a default gateway <- This is done in
> Ip4SendFrameToDefaultRoute ()
> if yes
> update the route cache to (src, dest ->
> default gw)
> send the packet to the default gw
>
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Tuesday, August 28, 2018 4:53 PM
> > To: Fu, Siyuan ; edk2-devel@lists.01.org
> > Cc: Ye, Ting
> > Subject: RE: [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask
> > support for IP4 PXE boot.
> >
> >
> > Hi Siyuan,
> >
> > Below is my code review understanding, maybe something is wrong,
> please
> > correct me.
> >
> > > The "default route" means a route entry with zero SubnetAddress and
> zero
> > > SubnetMask, which will match all the dest address that can't match any
> > other
> > > non-zero Subnet* route entry.
> > > The "instance route table" is a list of route entries which belong to an
> > IP child
> > > instance.
> > > The "default route table" is the route table used by these IP child
> > instances
> > > with default IP address.
> > > A default route (which is just one route entry) may belong to the
> > default
> > > route table, or any instance route table.
> > >
> >
> > Yes, I agree. If there is a default route {Dest: 0.0.0.0, Mask: 0.0.0.0,
> > NextHope: Gataway} in the instance route table, it must be set via IP-
> > >Routes().
> >
> >
> > > The new function Ip4SendFrameToDefaultRoute() will always try to send
> > the
> > > frames to the default entry, so the naming is correct.
> >
> > According above, we want to send the packet to the router (Gataway) via
> > the default route {Dest: 0.0.0.0, Mask: 0.0.0.0, NextHope: Gataway} info,
> > right? But the comments in Ip4Route() said:
> > //
> > // When using /32 subnet mask, the packet will always be sent to the
> > direct
> > // destination first, if we can't find a matching route cache.
> > //
> >
> > > While how to
> > > determine the default route entry is not in this function, the Ip4Route()
> > has
> > > been updated to handle the /32 subnet mask specially, and Ip4Output()
> > will
> > > guarantee we check the instance route table first, then default route
> > table
> > > (the code you quoted).
> >
> > After the code I quoted below in Ip4Output(), the route cache entry found
> > in Ip4SendFrameToDefaultRoute() is {Dest: X.X.X.X, Src: Y.Y.Y.Y, NextHope:
> > X.X.X.X, Tag: { Dest: X.X.X.X, Mask: 255.255.255.255, NextHope:
> > 0.0.0.0} }, if so, looks the package will be sent to NextHope: 0.0.0.0?
> >
> >
> > >
> > > BestRegards
> > > Fu Siyuan
> > >
> > > > -Original Message-
> > > > From: Wu, Jiaxin
> > > > Sent: Tuesday, August 28
Re: [edk2] [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask support for IP4 PXE boot.
Hi Siyuan,
Below is my code review understanding, maybe something is wrong, please correct
me.
> The "default route" means a route entry with zero SubnetAddress and zero
> SubnetMask, which will match all the dest address that can't match any other
> non-zero Subnet* route entry.
> The "instance route table" is a list of route entries which belong to an IP
> child
> instance.
> The "default route table" is the route table used by these IP child instances
> with default IP address.
> A default route (which is just one route entry) may belong to the default
> route table, or any instance route table.
>
Yes, I agree. If there is a default route {Dest: 0.0.0.0, Mask: 0.0.0.0,
NextHope: Gataway} in the instance route table, it must be set via IP->Routes().
> The new function Ip4SendFrameToDefaultRoute() will always try to send the
> frames to the default entry, so the naming is correct.
According above, we want to send the packet to the router (Gataway) via the
default route {Dest: 0.0.0.0, Mask: 0.0.0.0, NextHope: Gataway} info, right?
But the comments in Ip4Route() said:
//
// When using /32 subnet mask, the packet will always be sent to the direct
// destination first, if we can't find a matching route cache.
//
> While how to
> determine the default route entry is not in this function, the Ip4Route() has
> been updated to handle the /32 subnet mask specially, and Ip4Output() will
> guarantee we check the instance route table first, then default route table
> (the code you quoted).
After the code I quoted below in Ip4Output(), the route cache entry found in
Ip4SendFrameToDefaultRoute() is {Dest: X.X.X.X, Src: Y.Y.Y.Y, NextHope:
X.X.X.X, Tag: { Dest: X.X.X.X, Mask: 255.255.255.255, NextHope: 0.0.0.0} }, if
so, looks the package will be sent to NextHope: 0.0.0.0?
>
> BestRegards
> Fu Siyuan
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Tuesday, August 28, 2018 2:51 PM
> > To: Fu, Siyuan ; edk2-devel@lists.01.org
> > Cc: Ye, Ting
> > Subject: RE: [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask
> > support for IP4 PXE boot.
> >
> > Hi Siyuan,
> >
> > In Ip4SendFrameToDefaultRoute(), you tried to find the default gateway IP
> > address by using the found RtCacheEntry->Tag, I'm confused why it's the
> > default gateway? In my understanding, tag is the cache's corresponding
> > route entry. Besides, why we must send the frame to "DefaultRouter",
> > should be the instance router first, then default router? If so, I suggest
> > to rename the function to Ip4SendFrameToRoute(). Then, the logic in the
> > function to retrieve the gateway should be:
> > {
> > if (IpInstance == NULL) {
> > CacheEntry = Ip4Route (IpSb->DefaultRouteTable, Head->Dst, Head-
> >Src,
> > IpIf->SubnetMask);
> > } else {
> > CacheEntry = Ip4Route (IpInstance->RouteTable, Head->Dst, Head->Src,
> > IpIf->SubnetMask);
> > if (CacheEntry == NULL) {
> > CacheEntry = Ip4Route (IpSb->DefaultRouteTable, Head->Dst, Head-
> > >Src, IpIf->SubnetMask);
> > }
> > }
> >
> > if (CacheEntry == NULL) {
> > return EFI_NOT_FOUND;
> > }
> > GateWay = CacheEntry->NextHop;
> > Ip4FreeRouteCacheEntry (CacheEntry);
> > }
> >
> > What do you think?
> >
> > Thanks,
> > Jiaxin
> >
> >
> >
> >
> >
> >
> >
> >
> > > -Original Message-
> > > From: Fu, Siyuan
> > > Sent: Tuesday, August 28, 2018 9:53 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Ye, Ting ; Wu, Jiaxin
> > > Subject: [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask
> > > support for IP4 PXE boot.
> > >
> > > This patch updates IP4 stack to support 32bit subnet mask in PXE boot
> > > process.
> > > When 32bit subnet mask is used, the IP4 driver couldn't use the subnet
> > mask
> > > to determine
> > > whether destination IP address is on-link or not, so it will always try
> > to send
> > > all the
> > > packets to the destination IP address directly first, if failed it will
> > continue
> > > to try the default gateway.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Fu Siyuan
> > > Cc: Ye Ting
> > > Cc: Wu Jiaxin
> > > ---
> > > MdeModulePkg/Include/Library/NetLib.h | 5 +-
> > > MdeModulePkg/Library/DxeNetLib/DxeNetLib.c| 13 +-
> &
Re: [edk2] [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask support for IP4 PXE boot.
Hi Siyuan,
In Ip4SendFrameToDefaultRoute(), you tried to find the default gateway IP
address by using the found RtCacheEntry->Tag, I'm confused why it's the default
gateway? In my understanding, tag is the cache's corresponding route entry.
Besides, why we must send the frame to "DefaultRouter", should be the instance
router first, then default router? If so, I suggest to rename the function to
Ip4SendFrameToRoute(). Then, the logic in the function to retrieve the gateway
should be:
{
if (IpInstance == NULL) {
CacheEntry = Ip4Route (IpSb->DefaultRouteTable, Head->Dst, Head->Src,
IpIf->SubnetMask);
} else {
CacheEntry = Ip4Route (IpInstance->RouteTable, Head->Dst, Head->Src,
IpIf->SubnetMask);
if (CacheEntry == NULL) {
CacheEntry = Ip4Route (IpSb->DefaultRouteTable, Head->Dst, Head->Src,
IpIf->SubnetMask);
}
}
if (CacheEntry == NULL) {
return EFI_NOT_FOUND;
}
GateWay = CacheEntry->NextHop;
Ip4FreeRouteCacheEntry (CacheEntry);
}
What do you think?
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, August 28, 2018 9:53 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: [Patch 1/2] MdeModulePkg/Network: Add 32bit subnet mask
> support for IP4 PXE boot.
>
> This patch updates IP4 stack to support 32bit subnet mask in PXE boot
> process.
> When 32bit subnet mask is used, the IP4 driver couldn't use the subnet mask
> to determine
> whether destination IP address is on-link or not, so it will always try to
> send
> all the
> packets to the destination IP address directly first, if failed it will
> continue
> to try the default gateway.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Fu Siyuan
> Cc: Ye Ting
> Cc: Wu Jiaxin
> ---
> MdeModulePkg/Include/Library/NetLib.h | 5 +-
> MdeModulePkg/Library/DxeNetLib/DxeNetLib.c| 13 +-
> .../Universal/Network/Ip4Dxe/Ip4Common.h | 2 +-
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.c | 117
> --
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.h | 5 +-
> .../Universal/Network/Ip4Dxe/Ip4Impl.c| 2 +-
> .../Universal/Network/Ip4Dxe/Ip4Output.c | 11 +-
> .../Universal/Network/Ip4Dxe/Ip4Route.c | 21 +++-
> .../Universal/Network/Ip4Dxe/Ip4Route.h | 5 +-
> .../Universal/Network/Mtftp4Dxe/Mtftp4Impl.c | 6 +-
> 10 files changed, 154 insertions(+), 33 deletions(-)
>
> diff --git a/MdeModulePkg/Include/Library/NetLib.h
> b/MdeModulePkg/Include/Library/NetLib.h
> index ef7bc429c1..b7ef99c7b5 100644
> --- a/MdeModulePkg/Include/Library/NetLib.h
> +++ b/MdeModulePkg/Include/Library/NetLib.h
> @@ -422,8 +422,9 @@ NetGetIpClass (
>
>If all bits of the host address of IP are 0 or 1, IP is also not a valid
> unicast
> address,
>except when the originator is one of the endpoints of a point-to-point link
> with a 31-bit
> - mask (RFC3021).
> -
> + mask (RFC3021), or a 32bit NetMask (all 0xFF) is used for special network
> environment (e.g.
> + PPP link).
> +
>@param[in] IpThe IP to check against.
>@param[in] NetMask The mask of the IP.
>
> diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> index bf8f5523e6..63f4724062 100644
> --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> @@ -654,8 +654,9 @@ NetGetIpClass (
>
>If all bits of the host address of IP are 0 or 1, IP is also not a valid
> unicast
> address,
>except when the originator is one of the endpoints of a point-to-point link
> with a 31-bit
> - mask (RFC3021).
> -
> + mask (RFC3021), or a 32bit NetMask (all 0xFF) is used for special network
> environment (e.g.
> + PPP link).
> +
>@param[in] IpThe IP to check against.
>@param[in] NetMask The mask of the IP.
>
> @@ -669,18 +670,20 @@ NetIp4IsUnicast (
>IN IP4_ADDR NetMask
>)
> {
> + INTN MaskLength;
> +
>ASSERT (NetMask != 0);
>
>if (Ip == 0 || IP4_IS_LOCAL_BROADCAST (Ip)) {
> return FALSE;
>}
>
> - if (NetGetMaskLength (NetMask) != 31) {
> + MaskLength = NetGetMaskLength (NetMask);
> + ASSERT ((MaskLength >= 0) && (MaskLength <= IP4_MASK_NUM));
> + if (MaskLength < 31) {
> if (((Ip &~NetMask) == ~NetMask) || ((Ip &~NetMask) == 0)) {
>return FALSE;
> }
> - } else {
> -return TRUE;
>}
>
>return TRUE;
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Comm
Re: [edk2] [PATCH 0/5] NetworkPkg: Remove the redundant code and definition.
Series Reviewed-by: Jiaxin Wu after dropping the patch for TlsDxe. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Songpeng Li > Sent: Thursday, August 16, 2018 9:38 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH 0/5] NetworkPkg: Remove the redundant code and > definition. > > Some redundant functions and definitions which are never calld have been > removed. These fuctions are manually searched in source files to make > sure that they are not used elsewhere. > > Songpeng Li (5): > NetworkPkg: IScsiDxe: Remove the redundant code and definition. > NetworkPkg: IpSecDxe: Remove the redundant code. > NetworkPkg: TcpDxe: Remove the redundant code. > NetworkPkg: TlsDxe: Remove the redundant definition. > NetworkPkg: UefiPxeBcDxe: Remove the redundant code. > > NetworkPkg/IScsiDxe/IScsiDxe.inf | 1 - > NetworkPkg/IScsiDxe/IScsiProto.c | 33 > NetworkPkg/IpSecDxe/Ikev2/Payload.c | 18 --- > NetworkPkg/IpSecDxe/Ikev2/Utility.c | 76 > NetworkPkg/IpSecDxe/Ikev2/Utility.h | 67 > NetworkPkg/TcpDxe/TcpOption.c| 32 +--- > NetworkPkg/TcpDxe/TcpOption.h| 18 +-- > NetworkPkg/TlsDxe/TlsDxe.inf | 3 +- > NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c | 23 - > NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.h | 10 > 10 files changed, 3 insertions(+), 278 deletions(-) > > -- > 2.18.0.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/4] NetworkPkg/TlsAuthConfigDxe: fix TlsCaCertificate attributes retrieval
Reviewed-by: Wu Jiaxin
Thanks,
Jiaxin
> -Original Message-
> From: Li, Songpeng
> Sent: Monday, August 20, 2018 2:29 PM
> To: Laszlo Ersek ; edk2-devel-01 de...@lists.01.org>
> Cc: Wu, Jiaxin ; Fu, Siyuan
> Subject: RE: [PATCH 3/4] NetworkPkg/TlsAuthConfigDxe: fix TlsCaCertificate
> attributes retrieval
>
> It worked on my end.
>
> Tested-by: Songpeng Li
>
>
> Thanks & Best Regards,
> Songpeng
>
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Friday, August 17, 2018 10:36 PM
> > To: edk2-devel-01
> > Cc: Wu, Jiaxin ; Fu, Siyuan ; Li,
> > Songpeng
> > Subject: [PATCH 3/4] NetworkPkg/TlsAuthConfigDxe: fix TlsCaCertificate
> > attributes retrieval
> >
> > Per spec, the GetVariable() runtime service is not required to populate
> > (*Attributes) on output when it fails with EFI_BUFFER_TOO_SMALL.
> >
> > Therefore we have to fetch the full contents of the TlsCaCertificate
> > variable temporarily, just so we can (a) get the current attributes, and
> > (b) add EFI_VARIABLE_APPEND_WRITE to them for the subsequent
> > SetVariable()
> > call.
> >
> > Cc: Jiaxin Wu
> > Cc: Siyuan Fu
> > Cc: Songpeng Li
> > Reported-by: Songpeng Li
> > Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1090
> > Fixes: b90c335fbbb674470fbf09601cc522bf61564c30
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Laszlo Ersek
> > ---
> >
> > Notes:
> > Tested via loading the same CA cert .pem file twice in a row, using the
> > HII form, first without any pre-existent TlsCaCertificate variable.
> >
> > Songpeng, can you please test this patch as well, and confirm if it
> > works on your end? Thanks!
> >
> > NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 27
> > +++-
> > 1 file changed, 26 insertions(+), 1 deletion(-)
> >
> > diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> > b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> > index 7259c5e82f61..0780b03bbab4 100644
> > --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> > +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> > @@ -663,6 +663,7 @@ EnrollX509toVariable (
> >EFI_SIGNATURE_LIST*CACert;
> >EFI_SIGNATURE_DATA*CACertData;
> >VOID *Data;
> > + VOID *CurrentData;
> >UINTN DataSize;
> >UINTN SigDataSize;
> >UINT32Attr;
> > @@ -674,6 +675,7 @@ EnrollX509toVariable (
> >CACert= NULL;
> >CACertData= NULL;
> >Data = NULL;
> > + CurrentData = NULL;
> >Attr = 0;
> >
> >Status = ReadFileContent (
> > @@ -716,11 +718,30 @@ EnrollX509toVariable (
> >Status = gRT->GetVariable(
> >VariableName,
> >,
> > - ,
> > + NULL,
> >,
> >NULL
> >);
> >if (Status == EFI_BUFFER_TOO_SMALL) {
> > +//
> > +// Per spec, we have to fetch the variable's contents, even though
> we're
> > +// only interested in the variable's attributes.
> > +//
> > +CurrentData = AllocatePool (DataSize);
> > +if (CurrentData == NULL) {
> > + Status = EFI_OUT_OF_RESOURCES;
> > + goto ON_EXIT;
> > +}
> > +Status = gRT->GetVariable(
> > +VariableName,
> > +,
> > +,
> > +,
> > +CurrentData
> > +);
> > +if (EFI_ERROR (Status)) {
> > + goto ON_EXIT;
> > +}
> > Attr |= EFI_VARIABLE_APPEND_WRITE;
> >} else if (Status == EFI_NOT_FOUND) {
> > Attr = TLS_AUTH_CONFIG_VAR_BASE_ATTR;
> > @@ -751,6 +772,10 @@ ON_EXIT:
> > FreePool (Data);
> >}
> >
> > + if (CurrentData != NULL) {
> > +FreePool (CurrentData);
> > + }
> > +
> >if (X509Data != NULL) {
> > FreePool (X509Data);
> >}
> > --
> > 2.14.1.3.gb7cf6e02401b
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] NetworkPkg: Remove the redundant code and definition.
Looks good to me.
Reviewed-by: Jiaxin Wu
> -Original Message-
> From: Li, Songpeng
> Sent: Monday, August 13, 2018 10:45 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin ; Fu, Siyuan
> Subject: [PATCH] NetworkPkg: Remove the redundant code and definition.
>
> Cc: Jiaxin Wu
> Cc: Siyuan Fu
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1064
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Songpeng Li
> ---
> NetworkPkg/IScsiDxe/IScsiDxe.inf | 1 -
> NetworkPkg/IScsiDxe/IScsiProto.c | 33
> NetworkPkg/IpSecDxe/Ikev2/Payload.c | 18 ---
> NetworkPkg/IpSecDxe/Ikev2/Utility.c | 76
> NetworkPkg/IpSecDxe/Ikev2/Utility.h | 67
> NetworkPkg/TcpDxe/TcpOption.c| 30 ---
> NetworkPkg/TcpDxe/TcpOption.h| 16 --
> NetworkPkg/TlsDxe/TlsDxe.inf | 1 -
> NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c | 23 -
> NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.h | 10
> 10 files changed, 275 deletions(-)
>
> diff --git a/NetworkPkg/IScsiDxe/IScsiDxe.inf
> b/NetworkPkg/IScsiDxe/IScsiDxe.inf
> index 2d96611b44..60737c96ab 100644
> --- a/NetworkPkg/IScsiDxe/IScsiDxe.inf
> +++ b/NetworkPkg/IScsiDxe/IScsiDxe.inf
> @@ -124,7 +124,6 @@
>gEfiIfrTianoGuid ## SOMETIMES_PRODUCES ##
> UNDEFINED
>gEfiAcpiTableGuid ## SOMETIMES_CONSUMES ##
> SystemTable
>gEfiAcpi10TableGuid ## SOMETIMES_CONSUMES ##
> SystemTable
> - gEfiAcpi20TableGuid ## SOMETIMES_CONSUMES ##
> SystemTable
>gEfiAdapterInfoNetworkBootGuid## SOMETIMES_CONSUMES ##
> UNDEFINED
>gEfiAdapterInfoUndiIpv6SupportGuid## SOMETIMES_CONSUMES ##
> GUID
>
> diff --git a/NetworkPkg/IScsiDxe/IScsiProto.c
> b/NetworkPkg/IScsiDxe/IScsiProto.c
> index 7619360568..f4a49c677a 100644
> --- a/NetworkPkg/IScsiDxe/IScsiProto.c
> +++ b/NetworkPkg/IScsiDxe/IScsiProto.c
> @@ -2096,39 +2096,6 @@ IScsiDelTcb (
> }
>
>
> -/**
> - Find the task control block by the initator task tag.
> -
> - @param[in] TcbList The tcb list.
> - @param[in] InitiatorTaskTag The initiator task tag.
> -
> - @return The task control block found.
> - @retval NULL The task control block cannot be found.
> -
> -**/
> -ISCSI_TCB *
> -IScsiFindTcbByITT (
> - IN LIST_ENTRY *TcbList,
> - IN UINT32 InitiatorTaskTag
> - )
> -{
> - ISCSI_TCB *Tcb;
> - LIST_ENTRY *Entry;
> -
> - Tcb = NULL;
> -
> - NET_LIST_FOR_EACH (Entry, TcbList) {
> -Tcb = NET_LIST_USER_STRUCT (Entry, ISCSI_TCB, Link);
> -
> -if (Tcb->InitiatorTaskTag == InitiatorTaskTag) {
> - break;
> -}
> - }
> -
> - return Tcb;
> -}
> -
> -
> /**
>Create a data segment, pad it, and calculate the CRC if needed.
>
> diff --git a/NetworkPkg/IpSecDxe/Ikev2/Payload.c
> b/NetworkPkg/IpSecDxe/Ikev2/Payload.c
> index 218c26f934..1bb5e2e5e5 100644
> --- a/NetworkPkg/IpSecDxe/Ikev2/Payload.c
> +++ b/NetworkPkg/IpSecDxe/Ikev2/Payload.c
> @@ -3104,24 +3104,6 @@ ON_EXIT:
>return Status;
> }
>
> -/**
> - Save some useful payloads after accepting the Packet.
> -
> - @param[in] SessionCommon Pointer to IKEV2_SESSION_COMMON
> related to the operation.
> - @param[in] IkePacket Pointer to received IkePacet.
> - @param[in] IkeType The type used to indicate it is in IkeSa or
> ChildSa or
> Info
> - exchange.
> -
> -**/
> -VOID
> -Ikev2OnPacketAccepted (
> - IN IKEV2_SESSION_COMMON *SessionCommon,
> - IN IKE_PACKET *IkePacket,
> - IN UINT8IkeType
> - )
> -{
> - return;
> -}
>
> /**
>
> diff --git a/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> b/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> index 698aba1327..0c9c929705 100644
> --- a/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> +++ b/NetworkPkg/IpSecDxe/Ikev2/Utility.c
> @@ -290,21 +290,6 @@ Ikev2SaSessionRemove (
>return NULL;
> }
>
> -/**
> - Marking a SA session as on deleting.
> -
> - @param[in] IkeSaSession Pointer to IKEV2_SA_SESSION.
> -
> - @retval EFI_SUCCESS Find the related SA session and marked it.
> -
> -**/
> -EFI_STATUS
> -Ikev2SaSessionOnDeleting (
> - IN IKEV2_SA_SESSION *IkeSaSession
> - )
> -{
> - return EFI_SUCCESS;
> -}
>
> /**
>Free specified Seession Common. The session common would belong to a
> IKE SA or
> @@ -659,33 +644,6 @@ Ikev2ChildSaSessionReg (
>return ;
> }
Re: [edk2] reg: HTTP Request Failure over Internet
Hi Siva,
Since the gateway and Remote IP is accessible from shell, it means the platform
already has the valid gateway, then according the IP policy, it should be ready
for the upper layer to access the Internet, UEFI HttpBootDxe driver has
verified that by registering one valid gateway. So, the problem is quite
possibly in your Http application. My suggestion is that you can check the
source code and compare with the logic in the HttpBootDxe driver or you need
share the source code to me if possible.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Sivaraman Nainar
> Sent: Thursday, August 9, 2018 7:09 PM
> To: Wu, Jiaxin ; Ye, Ting ; Laszlo
> Ersek ; edk2-devel@lists.01.org
> Subject: Re: [edk2] reg: HTTP Request Failure over Internet
>
> Hello Jiaxin,
>
> There is no firewall blocking this. The gateway and Remote IP is accessible
> from shell.
>
> Thanks
> Siva
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Monday, August 6, 2018 1:35 PM
> To: Sivaraman Nainar; Ye, Ting; Laszlo Ersek; edk2-devel@lists.01.org
> Subject: RE: [edk2] reg: HTTP Request Failure over Internet
>
> Is there any proxy or firewall block the connection? Once you set the static
> Ip4Gateway via ifconfig shell command, please try to ping the
> gateway/remote address to check the connection.
>
> Thanks,
> Jiaxin
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Sivaraman Nainar
> > Sent: Saturday, August 4, 2018 5:46 PM
> > To: Wu, Jiaxin ; Ye, Ting ;
> > Laszlo Ersek ; edk2-devel@lists.01.org
> > Subject: Re: [edk2] reg: HTTP Request Failure over Internet
> >
> > Hello Jiaxin,
> >
> > We have tried both the methods and both failed. Do you have any other
> > recommendation?
> >
> > -Siva
> > -Original Message-
> > From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> > Sent: Tuesday, July 31, 2018 7:14 AM
> > To: Sivaraman Nainar; Ye, Ting; Laszlo Ersek; edk2-devel@lists.01.org
> > Subject: RE: [edk2] reg: HTTP Request Failure over Internet
> >
> > Hi Siva,
> >
> > Thanks the report.
> >
> > From the code review, it does the problem for HTTP protocol to route
> > the package over Internet.
> >
> > But I'm confused with your patch that how can you get the RouterAddr
> > since there is no interface for HTTP protocol to get the RouterAddr?
> >
> > > + HttpInstance->Tcp4->Routes (
> > > +HttpInstance->Tcp4,
> > > +FALSE,
> > > +>RemoteAddr,
> > > +>SubnetMask,
> > > +>RouterAddr
> > > +);
> > > +
> >
> > So, I prefer it's the UEFI Spec limitation that HTTP protocol doesn't
> > provide us the interface to set the router info instead of setting it
> > during HTTP configuration. To mitigate the issue, below two
> > solution/workaround can be
> > tried:
> > 1) Ip4Config2 protocol can be leveraged by your HTTP application to
> > register one valid Ip4Gateway into the default route table (just like
> > HttpBootDxe -- HttpBootRegisterIp4Gateway()). The IP policy will route
> > the packet by using the instance's route table first, if not found,
> > the default route table will be tried.
> > 2) Set the static Ip4Gateway via ifconfig shell command. The
> > Ip4Gateway address also will be set to default route table.
> >
> > Thanks,
> > Jiaxin
> >
> >
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Sivaraman Nainar
> > > Sent: Wednesday, July 25, 2018 5:29 PM
> > > To: Ye, Ting ; Laszlo Ersek ;
> > > edk2- de...@lists.01.org
> > > Subject: Re: [edk2] reg: HTTP Request Failure over Internet
> > >
> > > Ting:
> > >
> > > Please find the patch for reference.
> > >
> > > Index: HttpProto.c
> > >
> >
> ==
> > > =
> > > --- HttpProto.c
> > > +++ HttpProto.c
> > > @@ -622,12 +622,20 @@
> > >Status = HttpInstance->Tcp4->Configure (HttpInstance->Tcp4,
> > Tcp4CfgData);
> > >if (EFI_ERROR (Status)) {
> > > DEBUG ((EFI_D_ERROR, "HttpConfigureTcp4 - %r\n", Status));
> > > return Status;
> > >}
> > >
> > > + HttpInstance-&
Re: [edk2] reg: HTTP Request Failure over Internet
Is there any proxy or firewall block the connection? Once you set the static
Ip4Gateway via ifconfig shell command, please try to ping the gateway/remote
address to check the connection.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Sivaraman Nainar
> Sent: Saturday, August 4, 2018 5:46 PM
> To: Wu, Jiaxin ; Ye, Ting ; Laszlo
> Ersek ; edk2-devel@lists.01.org
> Subject: Re: [edk2] reg: HTTP Request Failure over Internet
>
> Hello Jiaxin,
>
> We have tried both the methods and both failed. Do you have any other
> recommendation?
>
> -Siva
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Tuesday, July 31, 2018 7:14 AM
> To: Sivaraman Nainar; Ye, Ting; Laszlo Ersek; edk2-devel@lists.01.org
> Subject: RE: [edk2] reg: HTTP Request Failure over Internet
>
> Hi Siva,
>
> Thanks the report.
>
> From the code review, it does the problem for HTTP protocol to route the
> package over Internet.
>
> But I'm confused with your patch that how can you get the RouterAddr since
> there is no interface for HTTP protocol to get the RouterAddr?
>
> > + HttpInstance->Tcp4->Routes (
> > +HttpInstance->Tcp4,
> > +FALSE,
> > +>RemoteAddr,
> > +>SubnetMask,
> > +>RouterAddr
> > +);
> > +
>
> So, I prefer it's the UEFI Spec limitation that HTTP protocol doesn't provide
> us
> the interface to set the router info instead of setting it during HTTP
> configuration. To mitigate the issue, below two solution/workaround can be
> tried:
> 1) Ip4Config2 protocol can be leveraged by your HTTP application to register
> one valid Ip4Gateway into the default route table (just like HttpBootDxe --
> HttpBootRegisterIp4Gateway()). The IP policy will route the packet by using
> the instance's route table first, if not found, the default route table will
> be
> tried.
> 2) Set the static Ip4Gateway via ifconfig shell command. The Ip4Gateway
> address also will be set to default route table.
>
> Thanks,
> Jiaxin
>
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Sivaraman Nainar
> > Sent: Wednesday, July 25, 2018 5:29 PM
> > To: Ye, Ting ; Laszlo Ersek ;
> > edk2- de...@lists.01.org
> > Subject: Re: [edk2] reg: HTTP Request Failure over Internet
> >
> > Ting:
> >
> > Please find the patch for reference.
> >
> > Index: HttpProto.c
> >
> ==
> > =
> > --- HttpProto.c
> > +++ HttpProto.c
> > @@ -622,12 +622,20 @@
> >Status = HttpInstance->Tcp4->Configure (HttpInstance->Tcp4,
> Tcp4CfgData);
> >if (EFI_ERROR (Status)) {
> > DEBUG ((EFI_D_ERROR, "HttpConfigureTcp4 - %r\n", Status));
> > return Status;
> >}
> >
> > + HttpInstance->Tcp4->Routes (
> > +HttpInstance->Tcp4,
> > +FALSE,
> > +>RemoteAddr,
> > +>SubnetMask,
> > +>RouterAddr
> > +);
> > +
> >Status = HttpCreateTcp4ConnCloseEvent (HttpInstance);
> >if (EFI_ERROR (Status)) {
> > return Status;
> >}
> >
> >Status = HttpCreateTcp4TxEvent (Wrap);
> >
> > -Siva
> > -Original Message-
> > From: Ye, Ting [mailto:ting...@intel.com]
> > Sent: Wednesday, July 25, 2018 1:36 PM
> > To: Laszlo Ersek; Sivaraman Nainar; edk2-devel@lists.01.org
> > Subject: RE: [edk2] reg: HTTP Request Failure over Internet
> >
> > Hi Siva,
> >
> > I didn't receive your patch either. Thanks for reporting the issue, we
> > will try to reproduce it firstly.
> >
> > Thanks,
> > Ting
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Laszlo Ersek
> > Sent: Tuesday, July 24, 2018 8:43 PM
> > To: Sivaraman Nainar ;
> > edk2-devel@lists.01.org
> > Subject: Re: [edk2] reg: HTTP Request Failure over Internet
> >
> > On 07/24/18 14:05, Sivaraman Nainar wrote:
> > > Hello all,
> > >
> > > When an application tried to download the remote file over internet
> > > with
> > the HTTP Get Request it getting failed. If we try via the Intranet
> > then application downloads the target file.
> > >
> > > The remote file is available in the Apache serve
Re: [edk2] [Patch] NetworkPkg/HttpDxe: Stripped square brackets in IPv6 expressed HostName.
Thanks Laszlo, I have refined the patch to v2 with your "Reviewed-by" tag.
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, August 1, 2018 5:49 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan
> Subject: Re: [Patch] NetworkPkg/HttpDxe: Stripped square brackets in IPv6
> expressed HostName.
>
> On 08/01/18 03:54, Jiaxin Wu wrote:
> > In URI, the colon (:) is used to terminate the HostName path before
> > a port number. However, if HostName is expressed as IPv6 format, colon
> > characters in IPv6 addresses will conflict with the colon before port
> > number. To alleviate this conflict in URI, the IPv6 expressed HostName
> > are enclosed in square brackets ([]). To record the real IPv6 HostName,
> > square brackets should be stripped.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin
> > ---
> > NetworkPkg/HttpDxe/HttpImpl.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c
> > index 17deceb395..e05ee9344b 100644
> > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > @@ -403,14 +403,25 @@ EfiHttpRequest (
> > Status = HttpParseUrl (Url, (UINT32) AsciiStrLen (Url), FALSE,
> > );
> > if (EFI_ERROR (Status)) {
> >goto Error1;
> > }
> >
> > -HostName = NULL;
> > -Status = HttpUrlGetHostName (Url, UrlParser, );
> > +Status = HttpUrlGetHostName (Url, UrlParser, );
> > if (EFI_ERROR (Status)) {
> > - goto Error1;
> > + goto Error1;
> > +}
> > +
> > +if (HttpInstance->LocalAddressIsIPv6 && AsciiStrSize (HostName) > 2
> &&
> > +HostName[0] == '[' && *(HostName + (AsciiStrSize (HostName) - 2))
> == ']') {
> > + //
> > + // HostName format is expressed as IPv6, so, remove '[' and ']'.
> > + //
> > + HostNameSize = AsciiStrSize (HostName) - 2;
> > +
> > + CopyMem (HostName, HostName + 1, HostNameSize - 1);
> > +
> > + *(HostName + HostNameSize - 1) = '\0';
> > }
> >
> > Status = HttpUrlGetPort (Url, UrlParser, );
> > if (EFI_ERROR (Status)) {
> >if (HttpInstance->UseHttps) {
> >
>
> There are a number of expressions of the form
>
> *(HostName + Offset)
>
> which could be rewritten more idiomatically as
>
> HostName[Offset]
>
> In addition, I think the code could be optimized by calculating
> AsciiStrSize() only once:
>
> if (HttpInstance->LocalAddressIsIPv6) {
> HostNameSize = AsciiStrSize (HostName);
>
> if (HostNameSize > 2 &&
> HostName[0] == '[' &&
> HostName[HostNameSize - 2] == ']') {
> //
> // HostName format is expressed as IPv6, so, remove '[' and ']'.
> //
> HostNameSize -= 2;
> CopyMem (HostName, HostName + 1, HostNameSize - 1);
> HostName[HostNameSize - 1] = '\0';
> }
> }
>
> Under my proposal, if the inner condition fails, then "HostNameSize"
> will be set as a "side effect", but I don't think that's a problem.
>
>
> Anyway, the patch seems technically correct; if you don't want to submit
> a v2, I'm fine with this variant too:
>
> Reviewed-by: Laszlo Ersek
>
> I have just one request for the subject line, before you push the patch:
> please replace "stripped" with "strip".
>
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg/HttpDxe: Stripped square brackets in IPv6 expressed HostName.
Hi Siyuan,
Even we have one lib for us to get the IPv6 address, I still prefer to use the
patch did, because the format returned from the HttpUrlGetIp6 is
EFI_IPv6_ADDRESS, we have to transform it to CHAR8, which means we also need
another lib included here to do that. Actually, the patch is quite simply even
than API did. What do you think?
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Wednesday, August 1, 2018 10:06 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Laszlo Ersek
> Subject: RE: [Patch] NetworkPkg/HttpDxe: Stripped square brackets in IPv6
> expressed HostName.
>
> Hi, Jiaxin
>
> The HttpLib already has HttpUrlGetIp6() for this.
>
> BestRegards
> Fu Siyuan
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Wednesday, August 1, 2018 9:55 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ; Laszlo
> > Ersek ; Wu, Jiaxin
> > Subject: [Patch] NetworkPkg/HttpDxe: Stripped square brackets in IPv6
> > expressed HostName.
> >
> > In URI, the colon (:) is used to terminate the HostName path before
> > a port number. However, if HostName is expressed as IPv6 format, colon
> > characters in IPv6 addresses will conflict with the colon before port
> > number. To alleviate this conflict in URI, the IPv6 expressed HostName
> > are enclosed in square brackets ([]). To record the real IPv6 HostName,
> > square brackets should be stripped.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin
> > ---
> > NetworkPkg/HttpDxe/HttpImpl.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c
> > index 17deceb395..e05ee9344b 100644
> > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > @@ -403,14 +403,25 @@ EfiHttpRequest (
> > Status = HttpParseUrl (Url, (UINT32) AsciiStrLen (Url), FALSE,
> > );
> > if (EFI_ERROR (Status)) {
> >goto Error1;
> > }
> >
> > -HostName = NULL;
> > -Status = HttpUrlGetHostName (Url, UrlParser, );
> > +Status = HttpUrlGetHostName (Url, UrlParser, );
> > if (EFI_ERROR (Status)) {
> > - goto Error1;
> > + goto Error1;
> > +}
> > +
> > +if (HttpInstance->LocalAddressIsIPv6 && AsciiStrSize (HostName) > 2
> > &&
> > +HostName[0] == '[' && *(HostName + (AsciiStrSize (HostName) - 2))
> > == ']') {
> > + //
> > + // HostName format is expressed as IPv6, so, remove '[' and ']'.
> > + //
> > + HostNameSize = AsciiStrSize (HostName) - 2;
> > +
> > + CopyMem (HostName, HostName + 1, HostNameSize - 1);
> > +
> > + *(HostName + HostNameSize - 1) = '\0';
> > }
> >
> > Status = HttpUrlGetPort (Url, UrlParser, );
> > if (EFI_ERROR (Status)) {
> >if (HttpInstance->UseHttps) {
> > --
> > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] reg: HTTP Request Failure over Internet
Hi Siva,
Thanks the report.
>From the code review, it does the problem for HTTP protocol to route the
>package over Internet.
But I'm confused with your patch that how can you get the RouterAddr since
there is no interface for HTTP protocol to get the RouterAddr?
> + HttpInstance->Tcp4->Routes (
> +HttpInstance->Tcp4,
> +FALSE,
> +>RemoteAddr,
> +>SubnetMask,
> +>RouterAddr
> +);
> +
So, I prefer it's the UEFI Spec limitation that HTTP protocol doesn't provide
us the interface to set the router info instead of setting it during HTTP
configuration. To mitigate the issue, below two solution/workaround can be
tried:
1) Ip4Config2 protocol can be leveraged by your HTTP application to register
one valid Ip4Gateway into the default route table (just like HttpBootDxe --
HttpBootRegisterIp4Gateway()). The IP policy will route the packet by using the
instance's route table first, if not found, the default route table will be
tried.
2) Set the static Ip4Gateway via ifconfig shell command. The Ip4Gateway address
also will be set to default route table.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Sivaraman Nainar
> Sent: Wednesday, July 25, 2018 5:29 PM
> To: Ye, Ting ; Laszlo Ersek ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] reg: HTTP Request Failure over Internet
>
> Ting:
>
> Please find the patch for reference.
>
> Index: HttpProto.c
> ==
> =
> --- HttpProto.c
> +++ HttpProto.c
> @@ -622,12 +622,20 @@
>Status = HttpInstance->Tcp4->Configure (HttpInstance->Tcp4, Tcp4CfgData);
>if (EFI_ERROR (Status)) {
> DEBUG ((EFI_D_ERROR, "HttpConfigureTcp4 - %r\n", Status));
> return Status;
>}
>
> + HttpInstance->Tcp4->Routes (
> +HttpInstance->Tcp4,
> +FALSE,
> +>RemoteAddr,
> +>SubnetMask,
> +>RouterAddr
> +);
> +
>Status = HttpCreateTcp4ConnCloseEvent (HttpInstance);
>if (EFI_ERROR (Status)) {
> return Status;
>}
>
>Status = HttpCreateTcp4TxEvent (Wrap);
>
> -Siva
> -Original Message-
> From: Ye, Ting [mailto:ting...@intel.com]
> Sent: Wednesday, July 25, 2018 1:36 PM
> To: Laszlo Ersek; Sivaraman Nainar; edk2-devel@lists.01.org
> Subject: RE: [edk2] reg: HTTP Request Failure over Internet
>
> Hi Siva,
>
> I didn't receive your patch either. Thanks for reporting the issue, we will
> try
> to reproduce it firstly.
>
> Thanks,
> Ting
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, July 24, 2018 8:43 PM
> To: Sivaraman Nainar ; edk2-devel@lists.01.org
> Subject: Re: [edk2] reg: HTTP Request Failure over Internet
>
> On 07/24/18 14:05, Sivaraman Nainar wrote:
> > Hello all,
> >
> > When an application tried to download the remote file over internet with
> the HTTP Get Request it getting failed. If we try via the Intranet then
> application downloads the target file.
> >
> > The remote file is available in the Apache server. With the attached patch
> the download works fine in Internet and Intranet.
> >
> > Could you review the solution and feedback?
>
> The edk2-devel list software does not reflect attachments to subscribers.
>
> While I disagree with that practice in general -- it breaks conversations
> where
> people justifiedly post small attachments, such as PNG screenshots,
> compressed log files and such --, for posting patches specifically, please use
> git-format-patch and git-send-email. The patch should be in the body of the
> email (please do not copy the patch though; that is guaranteed not to
> work -- please use the git tools).
>
> Official guidelines:
>
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-
> Process
>
> Personal ones from yours truly:
>
> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-
> guide-for-edk2-contributors-and-maintainers
>
> Thanks,
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/6] NetworkPkg/TlsAuthConfigDxe: replace OpenFileByDevicePath() with UefiLib API
Looks good with me.
Reviewed-by: Jiaxin Wu
Thanks,
Jiaxin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, July 19, 2018 4:51 AM
> To: edk2-devel-01
> Cc: Wu, Jiaxin ; Fu, Siyuan
> Subject: [PATCH 3/6] NetworkPkg/TlsAuthConfigDxe: replace
> OpenFileByDevicePath() with UefiLib API
>
> Replace the OpenFileByDevicePath() function with EfiOpenFileByDevicePath()
> from UefiLib, correcting the following issues:
>
> - imprecise comments on OpenFileByDevicePath(),
> - code duplication between this module and other modules,
> - local variable name "EfiSimpleFileSystemProtocol" starting with "Efi"
> prefix,
> - bogus "FileHandle = NULL" assignments,
> - passing a potentially unaligned "FILEPATH_DEVICE_PATH.PathName" field
> to
> a protocol member function (forbidden by the UEFI spec),
> - leaking "Handle1" when the device path type/subtype check fails in the
> loop,
> - stale SHELL_FILE_HANDLE reference in a comment.
>
> Cc: Jiaxin Wu
> Cc: Siyuan Fu
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1008
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek
> ---
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf | 1 -
> NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 141 +---
> 2 files changed, 1 insertion(+), 141 deletions(-)
>
> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> index 3cfcdb9983f1..e5face7b4de5 100644
> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf
> @@ -57,7 +57,6 @@ [LibraryClasses]
> [Protocols]
>gEfiDevicePathProtocolGuid## PRODUCES
>gEfiHiiConfigAccessProtocolGuid ## PRODUCES
> - gEfiSimpleFileSystemProtocolGuid ## SOMETIMES_CONSUMES
>
> [Guids]
>gTlsAuthConfigGuid## PRODUCES ## GUID
> diff --git a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> index 31450b3e4a1b..7259c5e82f61 100644
> --- a/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> +++ b/NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c
> @@ -574,145 +574,6 @@ ON_EXIT:
>return Status;
> }
>
> -/**
> - This function will open a file or directory referenced by DevicePath.
> -
> - This function opens a file with the open mode according to the file path.
> The
> - Attributes is valid only for EFI_FILE_MODE_CREATE.
> -
> - @param[in, out] FilePathOn input, the device path to the file.
> - On output, the remaining device path.
> - @param[out] FileHandle Pointer to the file handle.
> - @param[in] OpenModeThe mode to open the file with.
> - @param[in] Attributes The file's file attributes.
> -
> - @retval EFI_SUCCESS The information was set.
> - @retval EFI_INVALID_PARAMETEROne of the parameters has an invalid
> value.
> - @retval EFI_UNSUPPORTED Could not open the file path.
> - @retval EFI_NOT_FOUNDThe specified file could not be found on
> the
> - device or the file system could not be
> found on
> - the device.
> - @retval EFI_NO_MEDIA The device has no medium.
> - @retval EFI_MEDIA_CHANGEDThe device has a different medium in it
> or the
> - medium is no longer supported.
> - @retval EFI_DEVICE_ERROR The device reported an error.
> - @retval EFI_VOLUME_CORRUPTED The file system structures are
> corrupted.
> - @retval EFI_WRITE_PROTECTED The file or medium is write protected.
> - @retval EFI_ACCESS_DENIEDThe file was opened read only.
> - @retval EFI_OUT_OF_RESOURCES Not enough resources were available
> to open the
> - file.
> - @retval EFI_VOLUME_FULL The volume is full.
> -**/
> -EFI_STATUS
> -EFIAPI
> -OpenFileByDevicePath (
> - IN OUT EFI_DEVICE_PATH_PROTOCOL **FilePath,
> - OUT EFI_FILE_HANDLE *FileHandle,
> - IN UINT64 OpenMode,
> - IN UINT64 Attributes
> - )
> -{
> - EFI_STATUS Status;
> - EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *EfiSimpleFileSystemProtocol;
> - EFI_FILE_PROTOCOL *Handle1;
> - EFI_FILE_PROTOCOL *Handle2;
> - EFI_HANDLE DeviceHandle;
> -
&
Re: [edk2] [Patch v3] NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.
Great, thanks the verification. /Jiaxin
> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Wednesday, July 4, 2018 10:14 AM
> To: Wu, Jiaxin
> Cc: edk2-devel@lists.01.org; Ye, Ting ; Fu, Siyuan
>
> Subject: Re: [edk2] [Patch v3] NetworkPkg/HttpDxe: Fix the bug when
> parsing HTTP(S) message body.
>
> On Wed, Jul 04, 2018 at 08:40:52AM +0800, Jiaxin Wu wrote:
> > *v2: Resolve the conflict commit.
> >
> > *v3: Fixed the failure if BodyLength in HTTP token is less than the received
> > size of HTTPS message.
> >
> > HttpBodyParserCallback function is to parse the HTTP(S) message body so
> as to
> > confirm whether there is the next message header. But it doesn't record
> the
> > parsing message data/length correctly.
> >
> > This patch is refine the parsing logic so as to fix the potential failure.
> >
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Cc: Gary Lin
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin
>
> > Tested-by: Gary Lin
> Thanks for the patch. I've tested this patch with shim and grub2 from
> SLE15 GM, and they worked as expected. A crash in grub2 https connection is
> also gone after applying this patch.
>
> Thanks,
>
> Gary Lin
>
> > ---
> > NetworkPkg/HttpDxe/HttpImpl.c | 112 +---
> -
> > NetworkPkg/HttpDxe/HttpProto.c | 10 +++
> > NetworkPkg/HttpDxe/HttpProto.h | 10 +++
> > 3 files changed, 78 insertions(+), 54 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c
> > index f70e116f38..17deceb395 100644
> > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > @@ -914,10 +914,11 @@ HttpBodyParserCallback (
> >IN CHAR8 *Data,
> >IN UINTN Length,
> >IN VOID *Context
> >)
> > {
> > + HTTP_CALLBACK_DATA*CallbackData;
> >HTTP_TOKEN_WRAP *Wrap;
> >UINTN BodyLength;
> >CHAR8 *Body;
> >
> >if (EventType != BodyParseEventOnComplete) {
> > @@ -926,25 +927,22 @@ HttpBodyParserCallback (
> >
> >if (Data == NULL || Length != 0 || Context == NULL) {
> > return EFI_SUCCESS;
> >}
> >
> > - Wrap = (HTTP_TOKEN_WRAP *) Context;
> > - Body = Wrap->HttpToken->Message->Body;
> > - BodyLength = Wrap->HttpToken->Message->BodyLength;
> > + CallbackData = (HTTP_CALLBACK_DATA *) Context;
> > +
> > + Wrap = (HTTP_TOKEN_WRAP *) (CallbackData->Wrap);
> > + Body = CallbackData->ParseData;
> > + BodyLength = CallbackData->ParseDataLength;
> > +
> >if (Data < Body + BodyLength) {
> > Wrap->HttpInstance->NextMsg = Data;
> >} else {
> > Wrap->HttpInstance->NextMsg = NULL;
> >}
> >
> > -
> > - //
> > - // Free Tx4Token or Tx6Token since already received corrsponding HTTP
> response.
> > - //
> > - FreePool (Wrap);
> > -
> >return EFI_SUCCESS;
> > }
> >
> > /**
> >The work function of EfiHttpResponse().
> > @@ -1189,33 +1187,43 @@ HttpResponseWorker (
> > HttpInstance->Method,
> > HttpMsg->Data.Response->StatusCode,
> > HttpMsg->HeaderCount,
> > HttpMsg->Headers,
> > HttpBodyParserCallback,
> > - (VOID *) ValueInItem,
> > + (VOID *) (>CallbackData),
> > >MsgParser
> > );
> >if (EFI_ERROR (Status)) {
> > goto Error2;
> >}
> >
> >//
> >// Check whether we received a complete HTTP message.
> >//
> >if (HttpInstance->CacheBody != NULL) {
> > +//
> > +// Record the CallbackData data.
> > +//
> > +HttpInstance->CallbackData.Wrap = (VOID *) Wrap;
> > +HttpInstance->CallbackData.ParseData = (VOID *) HttpInstance-
> >CacheBody;
> > +HttpInstance->CallbackData.ParseDataLength = HttpInstance-
> >CacheLen;
> > +
> > +//
> > +// Parse message with CallbackData data.
> > +//
> > Status = HttpParseMessageBody (HttpInstance->MsgParser,
> HttpInstance->CacheLen, HttpInstance->CacheBody);
Re: [edk2] [Patch v2] NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.
Sorry, I can't access below google link:(. It will be better to share us the
steps to reproduce the issue. I don't know whether the below two files are
enough to reproduce the issue, but you can share it to me first, then I will
try that.
> bootx64.efi: 1208528 bytes
> grub.efi: 1057792 bytes
BTW, the issue only happened after applying this patches?
Thanks,
Jiaxin
> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Monday, July 2, 2018 4:17 PM
> To: Wu, Jiaxin
> Cc: Ye, Ting ; edk2-devel@lists.01.org; Fu, Siyuan
>
> Subject: Re: [edk2] [Patch v2] NetworkPkg/HttpDxe: Fix the bug when
> parsing HTTP(S) message body.
>
> On Mon, Jul 02, 2018 at 05:34:29AM +, Wu, Jiaxin wrote:
> > Hi Gary,
> >
> > Thanks the verification, in my part, HTTPS works well. Can you send me
> > the failure wireshark packet/full debug message?
> >
> > (correct the typo)
> >
> Per my test, HTTPS worked for firmware -> bootx64.efi(shim.efi), and
> shim failed to fetch grub2.
>
> Here is the packets captured by wireshark:
> https://drive.google.com/open?id=11UMRtkq521My3VNY75MeKDL8AFI12Rz
> E
>
> From the log, the second connection did start but end suddenly after a
> few packet transmissions.
>
> For reference, here are the sizes of bootx64.efi and grub.efi:
>
> bootx64.efi: 1208528 bytes
> grub.efi: 1057792 bytes
>
> Gary Lin
>
> > Thanks,
> > Jiaxin
> >
> >
> > >
> > > > -Original Message-
> > > > From: Gary Lin [mailto:g...@suse.com]
> > > > Sent: Monday, July 2, 2018 12:17 PM
> > > > To: Wu, Jiaxin
> > > > Cc: edk2-devel@lists.01.org; Ye, Ting ; Fu, Siyuan
> > > >
> > > > Subject: Re: [edk2] [Patch v2] NetworkPkg/HttpDxe: Fix the bug when
> > > > parsing HTTP(S) message body.
> > > >
> > > > On Mon, Jul 02, 2018 at 10:19:30AM +0800, Jiaxin Wu wrote:
> > > > > *v2: Resolve the conflict commit.
> > > > >
> > > > > HttpBodyParserCallback function is to parse the HTTP(S) message
> body so
> > > > as to
> > > > > confirm whether there is the next message header. But it doesn't
> record
> > > > the
> > > > > parsing message data/length correctly.
> > > > >
> > > > > This patch is refine the parsing logic so as to fix the potential
> > > > > failure.
> > > > >
> > > > Hi Jiaxin,
> > > >
> > > > After applying this patch, shim failed to fetch grub.efi through the
> > > > HTTPS connection. It got EFI_BAD_BUFFER_SIZE from HTTP->Response()
> > > and
> > > > I
> > > > found several error messages in the OVMF log:
> > > >
> > > > TcpInput: Discard a packet
> > > > TcpSendIpPacket: No appropriate IpSender.
> > > >
> > > > This only happened with HTTPS. If I replace the HTTPS URL in
> dhcpd.conf
> > > with
> > > > the HTTP URL, it works as expected.
> > > >
> > > > Gary Lin
> > > >
> > > > > Cc: Ye Ting
> > > > > Cc: Fu Siyuan
> > > > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > > > Signed-off-by: Wu Jiaxin
> > > > > Reviewed-by: Fu Siyuan
> > > > > ---
> > > > > NetworkPkg/HttpDxe/HttpImpl.c | 112 +
> -
> > > --
> > > > -
> > > > > NetworkPkg/HttpDxe/HttpProto.c | 10 +++
> > > > > NetworkPkg/HttpDxe/HttpProto.h | 10 +++
> > > > > 3 files changed, 77 insertions(+), 55 deletions(-)
> > > > >
> > > > > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> > > > b/NetworkPkg/HttpDxe/HttpImpl.c
> > > > > index f70e116f38..57a3712c23 100644
> > > > > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > > > > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > > > > @@ -914,10 +914,11 @@ HttpBodyParserCallback (
> > > > >IN CHAR8 *Data,
> > > > >IN UINTN Length,
> > > > >IN VOID *Context
> > > > >)
> > > > > {
> > > > > + HTTP_CALLBACK_DATA*CallbackData;
> > > > >HTTP_TOKEN_WRAP *Wrap;
> > > > >UINTN BodyLength;
> > > > >CHAR8 *
Re: [edk2] [Patch v2] NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.
Hi Gary,
Thanks the verification, in my part, HTTPS works well. Can you send me
the failure wireshark packet/full debug message?
(correct the typo)
Thanks,
Jiaxin
>
> > -Original Message-
> > From: Gary Lin [mailto:g...@suse.com]
> > Sent: Monday, July 2, 2018 12:17 PM
> > To: Wu, Jiaxin
> > Cc: edk2-devel@lists.01.org; Ye, Ting ; Fu, Siyuan
> >
> > Subject: Re: [edk2] [Patch v2] NetworkPkg/HttpDxe: Fix the bug when
> > parsing HTTP(S) message body.
> >
> > On Mon, Jul 02, 2018 at 10:19:30AM +0800, Jiaxin Wu wrote:
> > > *v2: Resolve the conflict commit.
> > >
> > > HttpBodyParserCallback function is to parse the HTTP(S) message body so
> > as to
> > > confirm whether there is the next message header. But it doesn't record
> > the
> > > parsing message data/length correctly.
> > >
> > > This patch is refine the parsing logic so as to fix the potential failure.
> > >
> > Hi Jiaxin,
> >
> > After applying this patch, shim failed to fetch grub.efi through the
> > HTTPS connection. It got EFI_BAD_BUFFER_SIZE from HTTP->Response()
> and
> > I
> > found several error messages in the OVMF log:
> >
> > TcpInput: Discard a packet
> > TcpSendIpPacket: No appropriate IpSender.
> >
> > This only happened with HTTPS. If I replace the HTTPS URL in dhcpd.conf
> with
> > the HTTP URL, it works as expected.
> >
> > Gary Lin
> >
> > > Cc: Ye Ting
> > > Cc: Fu Siyuan
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Wu Jiaxin
> > > Reviewed-by: Fu Siyuan
> > > ---
> > > NetworkPkg/HttpDxe/HttpImpl.c | 112 +-
> --
> > -
> > > NetworkPkg/HttpDxe/HttpProto.c | 10 +++
> > > NetworkPkg/HttpDxe/HttpProto.h | 10 +++
> > > 3 files changed, 77 insertions(+), 55 deletions(-)
> > >
> > > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> > b/NetworkPkg/HttpDxe/HttpImpl.c
> > > index f70e116f38..57a3712c23 100644
> > > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > > @@ -914,10 +914,11 @@ HttpBodyParserCallback (
> > >IN CHAR8 *Data,
> > >IN UINTN Length,
> > >IN VOID *Context
> > >)
> > > {
> > > + HTTP_CALLBACK_DATA*CallbackData;
> > >HTTP_TOKEN_WRAP *Wrap;
> > >UINTN BodyLength;
> > >CHAR8 *Body;
> > >
> > >if (EventType != BodyParseEventOnComplete) {
> > > @@ -926,25 +927,22 @@ HttpBodyParserCallback (
> > >
> > >if (Data == NULL || Length != 0 || Context == NULL) {
> > > return EFI_SUCCESS;
> > >}
> > >
> > > - Wrap = (HTTP_TOKEN_WRAP *) Context;
> > > - Body = Wrap->HttpToken->Message->Body;
> > > - BodyLength = Wrap->HttpToken->Message->BodyLength;
> > > + CallbackData = (HTTP_CALLBACK_DATA *) Context;
> > > +
> > > + Wrap = (HTTP_TOKEN_WRAP *) (CallbackData->Wrap);
> > > + Body = CallbackData->ParseData;
> > > + BodyLength = CallbackData->ParseDataLength;
> > > +
> > >if (Data < Body + BodyLength) {
> > > Wrap->HttpInstance->NextMsg = Data;
> > >} else {
> > > Wrap->HttpInstance->NextMsg = NULL;
> > >}
> > >
> > > -
> > > - //
> > > - // Free Tx4Token or Tx6Token since already received corrsponding
> HTTP
> > response.
> > > - //
> > > - FreePool (Wrap);
> > > -
> > >return EFI_SUCCESS;
> > > }
> > >
> > > /**
> > >The work function of EfiHttpResponse().
> > > @@ -1189,33 +1187,43 @@ HttpResponseWorker (
> > > HttpInstance->Method,
> > > HttpMsg->Data.Response->StatusCode,
> > > HttpMsg->HeaderCount,
> > > HttpMsg->Headers,
> > > HttpBodyParserCallback,
> > > - (VOID *) ValueInItem,
> > > + (VOID *) (>CallbackData),
> > > >MsgParser
> > > );
> > >if (EFI_ERROR (Status)) {
> > > goto Error2;
> > >}
> >
Re: [edk2] [Patch v2] NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.
Hi Gary,
Thanks the verification, in my part, can't HTTPS works well. Can you send me
the failure wireshark packet/debug message to me?
Thanks,
Jiaxin
> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Monday, July 2, 2018 12:17 PM
> To: Wu, Jiaxin
> Cc: edk2-devel@lists.01.org; Ye, Ting ; Fu, Siyuan
>
> Subject: Re: [edk2] [Patch v2] NetworkPkg/HttpDxe: Fix the bug when
> parsing HTTP(S) message body.
>
> On Mon, Jul 02, 2018 at 10:19:30AM +0800, Jiaxin Wu wrote:
> > *v2: Resolve the conflict commit.
> >
> > HttpBodyParserCallback function is to parse the HTTP(S) message body so
> as to
> > confirm whether there is the next message header. But it doesn't record
> the
> > parsing message data/length correctly.
> >
> > This patch is refine the parsing logic so as to fix the potential failure.
> >
> Hi Jiaxin,
>
> After applying this patch, shim failed to fetch grub.efi through the
> HTTPS connection. It got EFI_BAD_BUFFER_SIZE from HTTP->Response() and
> I
> found several error messages in the OVMF log:
>
> TcpInput: Discard a packet
> TcpSendIpPacket: No appropriate IpSender.
>
> This only happened with HTTPS. If I replace the HTTPS URL in dhcpd.conf with
> the HTTP URL, it works as expected.
>
> Gary Lin
>
> > Cc: Ye Ting
> > Cc: Fu Siyuan
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin
> > Reviewed-by: Fu Siyuan
> > ---
> > NetworkPkg/HttpDxe/HttpImpl.c | 112 +---
> -
> > NetworkPkg/HttpDxe/HttpProto.c | 10 +++
> > NetworkPkg/HttpDxe/HttpProto.h | 10 +++
> > 3 files changed, 77 insertions(+), 55 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c
> > index f70e116f38..57a3712c23 100644
> > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > @@ -914,10 +914,11 @@ HttpBodyParserCallback (
> >IN CHAR8 *Data,
> >IN UINTN Length,
> >IN VOID *Context
> >)
> > {
> > + HTTP_CALLBACK_DATA*CallbackData;
> >HTTP_TOKEN_WRAP *Wrap;
> >UINTN BodyLength;
> >CHAR8 *Body;
> >
> >if (EventType != BodyParseEventOnComplete) {
> > @@ -926,25 +927,22 @@ HttpBodyParserCallback (
> >
> >if (Data == NULL || Length != 0 || Context == NULL) {
> > return EFI_SUCCESS;
> >}
> >
> > - Wrap = (HTTP_TOKEN_WRAP *) Context;
> > - Body = Wrap->HttpToken->Message->Body;
> > - BodyLength = Wrap->HttpToken->Message->BodyLength;
> > + CallbackData = (HTTP_CALLBACK_DATA *) Context;
> > +
> > + Wrap = (HTTP_TOKEN_WRAP *) (CallbackData->Wrap);
> > + Body = CallbackData->ParseData;
> > + BodyLength = CallbackData->ParseDataLength;
> > +
> >if (Data < Body + BodyLength) {
> > Wrap->HttpInstance->NextMsg = Data;
> >} else {
> > Wrap->HttpInstance->NextMsg = NULL;
> >}
> >
> > -
> > - //
> > - // Free Tx4Token or Tx6Token since already received corrsponding HTTP
> response.
> > - //
> > - FreePool (Wrap);
> > -
> >return EFI_SUCCESS;
> > }
> >
> > /**
> >The work function of EfiHttpResponse().
> > @@ -1189,33 +1187,43 @@ HttpResponseWorker (
> > HttpInstance->Method,
> > HttpMsg->Data.Response->StatusCode,
> > HttpMsg->HeaderCount,
> > HttpMsg->Headers,
> > HttpBodyParserCallback,
> > - (VOID *) ValueInItem,
> > + (VOID *) (>CallbackData),
> > >MsgParser
> > );
> >if (EFI_ERROR (Status)) {
> > goto Error2;
> >}
> >
> >//
> >// Check whether we received a complete HTTP message.
> >//
> >if (HttpInstance->CacheBody != NULL) {
> > +//
> > +// Record the CallbackData data.
> > +//
> > +HttpInstance->CallbackData.Wrap = (VOID *) Wrap;
> > +HttpInstance->CallbackData.ParseData = (VOID *) HttpInstance-
> >CacheBody;
> > +HttpInstance->CallbackData.ParseDataLength = HttpInstance-
> >CacheLen;
> > +
> > +//
> > +
Re: [edk2] [Patch] MdeModulePkg: Update IP4 driver to check for NULL pointer before using.
Reviewed-by: Wu Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Wednesday, June 27, 2018 9:19 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin
> Subject: [Patch] MdeModulePkg: Update IP4 driver to check for NULL
> pointer before using.
>
> Cc: Ye Ting
> Cc: Wu Jiaxin
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan
> ---
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> index 5a9d828703..6a26143e30 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> @@ -1048,11 +1048,8 @@ Ip4Groups (
>// is decreamented each time an address is removed..
>//
>for (Index = IpInstance->GroupCount; Index > 0 ; Index--) {
> -Group = 0;
> -if(IpInstance->Groups != NULL) {
> - Group = IpInstance->Groups[Index - 1];
> - }
> -
> +ASSERT (IpInstance->Groups != NULL);
> +Group = IpInstance->Groups[Index - 1];
> if ((GroupAddress == NULL) || EFI_IP4_EQUAL (, GroupAddress)) {
>if (EFI_ERROR (Ip4LeaveGroup (IpInstance, NTOHL (Group {
> return EFI_DEVICE_ERROR;
> --
> 2.13.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/9] {Ovmf, Mde, Network, Crypto}Pkg: fixes+features for setting HTTPS cipher suites
Hi Laszlo,
In the commit log of patch 0001, "EFI_TLS_CA_CERTIFICATE_VARIABLE" should be
"EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE".
Others looks good to me.
Series Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
Thanks,
Jiaxin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, April 11, 2018 6:43 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Gary Ching-Pang Lin
> <g...@suse.com>; Wu, Jiaxin <jiaxin...@intel.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Gao, Liming <liming@intel.com>; Kinney,
> Michael D <michael.d.kin...@intel.com>; Long, Qin <qin.l...@intel.com>;
> Fu, Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>
> Subject: [PATCH v2 0/9] {Ovmf,Mde,Network,Crypto}Pkg: fixes+features for
> setting HTTPS cipher suites
>
> Repo: https://github.com/lersek/edk2.git
> Branch: tls_ciphers_v2
>
> This is version 2 of the series posted earlier at
>
> 20180403145149.8925-1-lersek@redhat.com">http://mid.mail-archive.com/20180403145149.8925-1-lersek@redhat.com
> https://lists.01.org/pipermail/edk2-devel/2018-April/023402.html
>
> Changes are noted per patch. One important change cannot be highlighted
> that way however, because it involves the dropping of the following two
> patches from v1:
>
> [edk2] [PATCH 08/13] CryptoPkg/TlsLib: add the "TlsMappingTable.sh"
>POSIX shell script
>
> [edk2] [PATCH 09/13] CryptoPkg/TlsLib: extend "TlsCipherMappingTable"
>
> I retested HTTPS boot with this series; it succeeded. The TLS cipher
> suite preference list came from the system-wide configuration on my
> RHEL-7 laptop; basically the binary CipherId array from the command
> "openssl ciphers -V". The relevant lines from the OVMF log were:
>
> > TlsAuthConfigDxe:SetCipherSuites: stored list of cipher suites (190 byte(s))
> > [...]
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC030
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC02C
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC028
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC024
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC014
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC00A
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x00A5
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x00A3
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x00A1
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x009F
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x006A
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0038
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0088
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0087
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0086
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0085
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC032
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC02E
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC02A
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC026
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC00F
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC005
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x009D
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0084
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x008D
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC02F
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC02B
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC027
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC023
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC013
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC009
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x00A4
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x00A2
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x00A0
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x009E
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0040
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0032
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x009A
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0099
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0098
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0097
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0045
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0044
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0043
> > TlsDxe:TlsSetCipherList: skipping CipherId=0x0042
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC031
> > TlsDxe:TlsSetCipherList: skipping CipherId=0xC02D
> > TlsDxe:TlsSetCipherList: skipping CipherId=
Re: [edk2] [PATCH 00/13] {Ovmf, Mde, Network, Crypto}Pkg: fixes+features for setting HTTPS cipher suites
It's good to me with new coming series patches:).
Thanks,
Jiaxin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, April 11, 2018 4:06 AM
> To: Long, Qin <qin.l...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>;
> edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Ye, Ting
> <ting...@intel.com>; Justen, Jordan L <jordan.l.jus...@intel.com>; Gao,
> Liming <liming@intel.com>; Gary Ching-Pang Lin <g...@suse.com>;
> Kinney, Michael D <michael.d.kin...@intel.com>; Fu, Siyuan
> <siyuan...@intel.com>
> Subject: Re: [edk2] [PATCH 00/13] {Ovmf, Mde, Network, Crypto}Pkg:
> fixes+features for setting HTTPS cipher suites
>
> On 04/10/18 19:06, Long, Qin wrote:
> > Hi, Laszlo,
> >
> > I prefer to open a separate BZ for this TlsCipherMappingTable update.
> > Current list was produced by some rough collections from Jiaxin and me,
> which meet the basic cipher requirement for TLS(v1.0/1.1/1.2) to set up one
> successful connection.
> >
> > Will re-sorted this table based on IANA & IETF-RFCs & EDKII-openssl build
> options.
>
> Thank you, I've just filed
> <https://bugzilla.tianocore.org/show_bug.cgi?id=929> and assigned it to
> you; I hope that's OK.
>
> I hope to send v2 of this series tomorrow, or the day after, after I get
> answers to the (remaining) open questions I asked today.
>
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 00/13] {Ovmf, Mde, Network, Crypto}Pkg: fixes+features for setting HTTPS cipher suites
Hi Laszlo
Appreciate your contribution. I have reviewed the series patches you attached
here. First, I assume you have verified the patches on OVMF and the
functionality works well, then, below are my comments:
1. The patches for OvmfPkg/NetworkPkg (0001-0004) are good to me.
2. For CryptoPkg, the major viewpoint is also related to the
TlsCipherMappingTable. For this table, only include the supported ciphersuites
looks more reasonable. After talked with Qin, I know the unsupported cipher
suites won't be rejected/filtrated by the OpenSSL cipher list setting, if so,
the cipher suite list that passed from the client to the server in the
ClientHello message might also include such unsupported cipher suites. In such
a case, the failure will happen once the server select the unsupported cipher
suite. From the handshake process view, it's unreasonable since the client sent
the desired cipher suites, then the server selected one of them but still met
the error. Anyway, filtrating the unsupported cipher suites as early as
possible is a wise choice. So, TlsCipherMappingTable should only include the
supported cipher suites by reference the security requirement of CryptoPkg.
3. For patch 0006, it's good to me to optimize the searching algorithm since
the table is larger than before.
4. Can we combined some patches together to make the things simple? e.g.
Patches 0005/0007/0010/0011/0012/0013. Those patches are the same purpose to
fix the issues in 0013.
5. For patch 0008, I think it's unnecessary to provide such script. I prefer to
maintain the TlsCipherMappingTable more statical since it's the internal
mapping table. How about we keep it as internal assistant tool?
6. For patch 0009 to extend the TlsCipherMappingTable, I think Qin can help us
to provide the supported cipher suites by reference the security requirement of
CryptoPkg.
Thanks,
Jiaxin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, April 3, 2018 10:52 PM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>; Gary Ching-Pang Lin
> <g...@suse.com>; Wu, Jiaxin <jiaxin...@intel.com>; Justen, Jordan L
> <jordan.l.jus...@intel.com>; Gao, Liming <liming@intel.com>; Kinney,
> Michael D <michael.d.kin...@intel.com>; Long, Qin <qin.l...@intel.com>;
> Fu, Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>
> Subject: [PATCH 00/13] {Ovmf,Mde,Network,Crypto}Pkg: fixes+features for
> setting HTTPS cipher suites
>
> Repo: https://github.com/lersek/edk2.git
> Branch: tls_ciphers
>
> Earlier I posted two patch sets for better platform control of the CA
> certificates used in HTTPS booting (and for putting that control to use
> in OVMF):
>
> [edk2] [PATCH 0/5] NetworkPkg: HTTP and TLS updates
>
> [edk2] [PATCH 0/4] MdeModulePkg, OvmfPkg: support large CA cert list
> for HTTPS boot
>
> These series have been committed; thank you everyone that helped with
> review and testing.
>
> My next goal is better platform control of the TLS cipher suites that
> are used in HTTPS booting (and similarly, putting that control to use in
> OVMF). That's what this series is about.
>
> You'll see references to TianoCore BZ#915 in the commit messages. The BZ
> is not public just yet, because I originally thought that I found
> security issues. It turns out that's not the case, so the BZ should be
> opened up soon. Either way, the commit messages contain enough
> information about the code changes.
>
> I'm aware some of my reviewers are currently traveling for business --
> please take your time and feel free to review the patches whenever it
> best suits you.
>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: Gary Ching-Pang Lin <g...@suse.com>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Jordan Justen <jordan.l.jus...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Michael D Kinney <michael.d.kin...@intel.com>
> Cc: Qin Long <qin.l...@intel.com>
> Cc: Siyuan Fu <siyuan...@intel.com>
> Cc: Ting Ye <ting...@intel.com>
>
> Thanks!
> Laszlo
>
> Laszlo Ersek (13):
> OvmfPkg/TlsAuthConfigLib: configure trusted cipher suites for HTTPS
> boot
> MdePkg/Include/Protocol/Tls.h: pack structures from the TLS RFC
> NetworkPkg/TlsDxe: verify DataSize for EfiTlsCipherList
> NetworkPkg/TlsDxe: clean up byte order conversion for EfiTlsCipherList
> CryptoPkg/TlsLib: replace TlsGetCipherString() with
> TlsGetCipherMapping()
> CryptoPkg/TlsLib: use binary search in the TlsGetCipherMapping()
> function
> CryptoPkg/TlsLib: pre-compute OpensslCipherLength in
> TlsCipherMappingT
Re: [edk2] [PATCH 0/5] NetworkPkg: HTTP and TLS updates
Series Reviewed-by: Jiaxin Wu <jiaxin...@intel.com> Thanks, Jiaxin > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, March 23, 2018 12:39 AM > To: edk2-devel-01 <edk2-devel@lists.01.org> > Cc: Wu, Jiaxin <jiaxin...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: [PATCH 0/5] NetworkPkg: HTTP and TLS updates > > Repo: https://github.com/lersek/edk2.git > Branch: http_and_tls_updates > > Patch #4 fixes TianoCore BZ#909 > <https://bugzilla.tianocore.org/show_bug.cgi?id=909>. > > Patches #2 and #3 are cleanups / preparation for patch #4. > > Patch #1 fixes an independent typo that I noticed in the code while > configuring my DHCP server for HTTP(S) booting. It's isolated, so I put > it first in the series. > > Patch #5 is preparation for future platform enablement, so that a > platform can create both "TlsCaCertificate" and "HttpTlsCipherList" > variables on every boot from scratch as volatile variables (without > flash varstore footprint). > > I regression-tested this series with a successful HTTPS boot of an ISO > image from OVMF, using a DER-formatted self-signed certificate that I > enrolled with TlsAuthConfigDxe. > > Cc: Jiaxin Wu <jiaxin...@intel.com> > Cc: Siyuan Fu <siyuan...@intel.com> > > Thanks, > Laszlo > > Laszlo Ersek (5): > NetworkPkg/HttpBootDxe: fix typo in DHCPv4 packet parsing > NetworkPkg/HttpDxe: use error handler epilogue in > TlsConfigCertificate() > NetworkPkg/HttpDxe: drop misleading comment / status code in cert > config > NetworkPkg/HttpDxe: sanity-check the TlsCaCertificate variable before > use > NetworkPkg/TlsAuthConfigDxe: preserve TlsCaCertificate variable > attributes > > NetworkPkg/HttpBootDxe/HttpBootDhcp4.c | 4 +- > NetworkPkg/HttpDxe/HttpDxe.inf | 3 +- > NetworkPkg/HttpDxe/HttpsSupport.c | 74 ++-- > NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c | 15 ++-- > 4 files changed, 80 insertions(+), 16 deletions(-) > > -- > 2.14.1.3.gb7cf6e02401b ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg: Correct HttpTlsCipherList.h file format to DOS
Reviewed-by: Wu Jiaxin <jiaxin...@intel.com>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Liming Gao
> Sent: Monday, March 26, 2018 10:10 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>
> Subject: [edk2] [Patch] NetworkPkg: Correct HttpTlsCipherList.h file format
> to DOS
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao <liming@intel.com>
> Cc: Wu Jiaxin <jiaxin...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> ---
> NetworkPkg/Include/Guid/HttpTlsCipherList.h | 76 ++
> ---
> 1 file changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/NetworkPkg/Include/Guid/HttpTlsCipherList.h
> b/NetworkPkg/Include/Guid/HttpTlsCipherList.h
> index bbfe488..bd30231 100644
> --- a/NetworkPkg/Include/Guid/HttpTlsCipherList.h
> +++ b/NetworkPkg/Include/Guid/HttpTlsCipherList.h
> @@ -1,38 +1,38 @@
> -/** @file
> - This file defines the HttpTlsCipherList variable for HTTPS to configure Tls
> Cipher List.
> -
> -Copyright (c) 2018, Intel Corporation. All rights reserved.
> -This program and the accompanying materials are licensed and made
> available under
> -the terms and conditions of the BSD License that accompanies this
> distribution.
> -The full text of the license may be found at
> -http://opensource.org/licenses/bsd-license.php.
> -
> -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -
> -**/
> -
> -#ifndef __HTTP_TLS_CIPHER_LIST_H__
> -#define __HTTP_TLS_CIPHER_LIST_H__
> -
> -//
> -// Private Variable for HTTPS to configure Tls Cipher List.
> -// The valid contents of variable must follow the TLS CipherList format
> defined in RFC 5246.
> -// The valid length of variable must be an integral multiple of 2.
> -// For example, if below cipher suites are preferred:
> -//CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = {0x00,0x3C}
> -// CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = {0x00,0x3D}
> -// Then, the contents of variable should be:
> -// {0x00,0x3C,0x00,0x3D}
> -//
> -#define EDKII_HTTP_TLS_CIPHER_LIST_GUID \
> - { \
> -0x46ddb415, 0x5244, 0x49c7, { 0x93, 0x74, 0xf0, 0xe2, 0x98, 0xe7, 0xd3,
> 0x86 } \
> - }
> -
> -#define EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE L"HttpTlsCipherList"
> -
> -extern EFI_GUID gEdkiiHttpTlsCipherListGuid;
> -
> -#endif
> -
> +/** @file
> + This file defines the HttpTlsCipherList variable for HTTPS to configure Tls
> Cipher List.
> +
> +Copyright (c) 2018, Intel Corporation. All rights reserved.
> +This program and the accompanying materials are licensed and made
> available under
> +the terms and conditions of the BSD License that accompanies this
> distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __HTTP_TLS_CIPHER_LIST_H__
> +#define __HTTP_TLS_CIPHER_LIST_H__
> +
> +//
> +// Private Variable for HTTPS to configure Tls Cipher List.
> +// The valid contents of variable must follow the TLS CipherList format
> defined in RFC 5246.
> +// The valid length of variable must be an integral multiple of 2.
> +// For example, if below cipher suites are preferred:
> +//CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = {0x00,0x3C}
> +// CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = {0x00,0x3D}
> +// Then, the contents of variable should be:
> +// {0x00,0x3C,0x00,0x3D}
> +//
> +#define EDKII_HTTP_TLS_CIPHER_LIST_GUID \
> + { \
> +0x46ddb415, 0x5244, 0x49c7, { 0x93, 0x74, 0xf0, 0xe2, 0x98, 0xe7, 0xd3,
> 0x86 } \
> + }
> +
> +#define EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE L"HttpTlsCipherList"
> +
> +extern EFI_GUID gEdkiiHttpTlsCipherListGuid;
> +
> +#endif
> +
> --
> 2.8.0.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] internal structure of EFI_TLS_CA_CERTIFICATE_VARIABLE
Hi Laszlo,
Insert my comments as below:
> The nested loops that parse the signature list in TlsConfigCertificate()
> currently ignore the contents of the following fields:
> - EFI_SIGNATURE_LIST.SignatureType,
> - EFI_SIGNATURE_DATA.SignatureOwner.
>
> I'd like the generator / extractor tool to populate these fields
> correctly right from the start, so that it remain compatible with future
> features added to edk2.
>
>
> So, I suggest that the tool set "EFI_SIGNATURE_LIST.SignatureType" to
> EFI_CERT_X509_GUID ("This identifies a signature based on a DER-encoded
> X.509 certificate"). Because, this is what the current edk2 code assumes
> anyway -- in TlsSetCaCertificate(), we have a comment saying
>
> //
> // DER-encoded binary X.509 certificate or PEM-encoded X.509
> // certificate. Determine whether certificate is from DER encoding, if
> // so, translate it to X509 structure.
> //
>
> (1) Do you agree EFI_CERT_X509_GUID is the right setting for
> "EFI_SIGNATURE_LIST.SignatureType" (even though the edk2 code currently
> ignores it)?
>
> This would also imply that we set
> "EFI_SIGNATURE_LIST.SignatureHeaderSize" to zero, according to the UEFI
> spec.
>
Yes, exactly, EFI_CERT_X509_GUID is the correct SignatureType for the
CACertificate. SignatureHeaderSize should be set to zero. We do miss the check
in HttpDxe driver, I'm fine to add back the SignatureType check in
TlsConfigCertificate(). So, can you report the Bugzilla for this fixing? Thanks.
>
> Furthermore, what would you suggest for
> "EFI_SIGNATURE_DATA.SignatureOwner"? According to the spec, it is "An
> identifier which identifies the agent which added the signature to the
> list", so in theory we could just generate any GUID for the tool with
> "uuidgen". However, based on past experience, this may not be good
> enough; for example, the Secure Boot Logo Test in the Microsoft HCK
> expect the SignatureOwner field (on the Microsoft certificates) to be
> constant 77FA9ABD-0359-4D32-BD60-28F4E78F784B. In other words,
> Microsoft
> want the SignatureOwner field to stand for the organization that issued
> the certificates (i.e., themselves), not for the agent that enrolled the
> certificates.
>
> (2) Do you foresee any such restrictions for the
> "EFI_SIGNATURE_DATA.SignatureOwner" field in
> EFI_TLS_CA_CERTIFICATE_VARIABLE? Or is it safe if we generate a GUID for
> the tool with "uuidgen"?
>
I don't think it's necessary to restrict/stand the GUID in the field of
SignatureOwner for the CA certification (at least for now) since it's only used
to identify the different venders (i.e, Microsoft) so as to avoid the following
content check. In the UEFI part, we also didn't check the SignatureOwner for
the any security consideration. So, I think it's safe to generate a GUID using
the tool at present.
Thanks,
Jiaxin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before the poll function.
Yes, I agree with you. But we still can't raise time event to TPL_NOTIFY,
because in the notify callback function, Udp protocol will be called to
retransmit the packet while it's not allowed to call UDP in the TPL_NOTIFY.
> -Original Message-
> From: Fu, Siyuan
> Sent: Friday, March 2, 2018 9:24 AM
> To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
> Cc: Wang, Fan <fan.w...@intel.com>; Ye, Ting <ting...@intel.com>
> Subject: RE: [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before the
> poll function.
>
> Jiaxin,
>
> There will be problem if someone calls Mtftp.Start() at TPL Callback to
> send/receive a file with your patch. In such case the RestoreTpl() won't be
> able to restore the TPL to application level so it will still while loop in
> the Poll.
>
> BestRegards
> Fu Siyuan
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Friday, March 2, 2018 9:18 AM
> > To: Fu, Siyuan <siyuan...@intel.com>; edk2-devel@lists.01.org
> > Cc: Wang, Fan <fan.w...@intel.com>; Ye, Ting <ting...@intel.com>
> > Subject: RE: [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before
> the
> > poll function.
> >
> > It's not actual hang but always running at while-poll function in the TPL
> > call back level , meanwhile, the while condition depends on another time
> > event that running on the same TPL. If so, the time event might have no
> > chance to be triggered. So, the code will never run out of while () {}:
> >
> > while (Token->Status == EFI_NOT_READY) {
> > This->Poll (This);
> > }
> >
> >
> > Thanks,
> > Jiaxin
> >
> > > -Original Message-
> > > From: Fu, Siyuan
> > > Sent: Thursday, March 1, 2018 7:03 PM
> > > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
> > > Cc: Wang, Fan <fan.w...@intel.com>; Ye, Ting <ting...@intel.com>
> > > Subject: RE: [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before
> the
> > > poll function.
> > >
> > > Hi, Jiaxin
> > >
> > > Do you mean the code which calls MTFTP4->Poll() at TPL_CALLBACK will
> > > cause system hang? This should not happen because all network protocol
> > > should be able to run at TPL_CALLBACK.
> > >
> > > BestRegards
> > > Fu Siyuan
> > >
> > >
> > > > -Original Message-
> > > > From: Wu, Jiaxin
> > > > Sent: Thursday, March 1, 2018 5:38 PM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Wang, Fan <fan.w...@intel.com>; Fu, Siyuan
> <siyuan...@intel.com>;
> > > Ye,
> > > > Ting <ting...@intel.com>
> > > > Subject: [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before
> the
> > > poll
> > > > function.
> > > >
> > > > This patch is to fix the hang issue, which was enrolled by the commit
> > of
> > > > 39b0867d.
> > > > The TPL should be restored before calling poll function at
> > TPL_CALLBACK.
> > > >
> > > > Cc: Wang Fan <fan.w...@intel.com>
> > > > Cc: Fu Siyuan <siyuan...@intel.com>
> > > > Cc: Ye Ting <ting...@intel.com>
> > > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > > Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
> > > > ---
> > > > MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c | 9
> > > ++---
> > > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git
> a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > > > b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > > > index f5f9e6d8f7..64e0463dd9 100644
> > > > --- a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > > > +++ b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > > > @@ -507,24 +507,27 @@ Mtftp4Start (
> > > >if (EFI_ERROR (Status)) {
> > > > Status = EFI_DEVICE_ERROR;
> > > > goto ON_ERROR;
> > > >}
> > > >
> > > > + //
> > > > + // Restore the TPL now, don't call poll function at TPL_CALLBACK.
> > > > + //
> > > > + gBS->RestoreTPL (OldTpl);
> > > > +
> > > >if (Token->Event != NULL) {
> > > > -gBS->RestoreTPL (OldTpl);
> > > > return EFI_SUCCESS;
> > > >}
> > > >
> > > >//
> > > >// Return immediately for asynchronous operation or poll the
> > > >// instance for synchronous operation.
> > > >//
> > > >while (Token->Status == EFI_NOT_READY) {
> > > > This->Poll (This);
> > > >}
> > > > -
> > > > - gBS->RestoreTPL (OldTpl);
> > > > +
> > > >return Token->Status;
> > > >
> > > > ON_ERROR:
> > > >Mtftp4CleanOperation (Instance, Status);
> > > >gBS->RestoreTPL (OldTpl);
> > > > --
> > > > 2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before the poll function.
It's not actual hang but always running at while-poll function in the TPL call
back level , meanwhile, the while condition depends on another time event that
running on the same TPL. If so, the time event might have no chance to be
triggered. So, the code will never run out of while () {}:
while (Token->Status == EFI_NOT_READY) {
This->Poll (This);
}
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Thursday, March 1, 2018 7:03 PM
> To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
> Cc: Wang, Fan <fan.w...@intel.com>; Ye, Ting <ting...@intel.com>
> Subject: RE: [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before the
> poll function.
>
> Hi, Jiaxin
>
> Do you mean the code which calls MTFTP4->Poll() at TPL_CALLBACK will
> cause system hang? This should not happen because all network protocol
> should be able to run at TPL_CALLBACK.
>
> BestRegards
> Fu Siyuan
>
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Thursday, March 1, 2018 5:38 PM
> > To: edk2-devel@lists.01.org
> > Cc: Wang, Fan <fan.w...@intel.com>; Fu, Siyuan <siyuan...@intel.com>;
> Ye,
> > Ting <ting...@intel.com>
> > Subject: [Patch] MdeModulePkg/Mtftp4Dxe: Restore the TPL before the
> poll
> > function.
> >
> > This patch is to fix the hang issue, which was enrolled by the commit of
> > 39b0867d.
> > The TPL should be restored before calling poll function at TPL_CALLBACK.
> >
> > Cc: Wang Fan <fan.w...@intel.com>
> > Cc: Fu Siyuan <siyuan...@intel.com>
> > Cc: Ye Ting <ting...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
> > ---
> > MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c | 9
> ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > index f5f9e6d8f7..64e0463dd9 100644
> > --- a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > +++ b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> > @@ -507,24 +507,27 @@ Mtftp4Start (
> >if (EFI_ERROR (Status)) {
> > Status = EFI_DEVICE_ERROR;
> > goto ON_ERROR;
> >}
> >
> > + //
> > + // Restore the TPL now, don't call poll function at TPL_CALLBACK.
> > + //
> > + gBS->RestoreTPL (OldTpl);
> > +
> >if (Token->Event != NULL) {
> > -gBS->RestoreTPL (OldTpl);
> > return EFI_SUCCESS;
> >}
> >
> >//
> >// Return immediately for asynchronous operation or poll the
> >// instance for synchronous operation.
> >//
> >while (Token->Status == EFI_NOT_READY) {
> > This->Poll (This);
> >}
> > -
> > - gBS->RestoreTPL (OldTpl);
> > +
> >return Token->Status;
> >
> > ON_ERROR:
> >Mtftp4CleanOperation (Instance, Status);
> >gBS->RestoreTPL (OldTpl);
> > --
> > 2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/2] NetworkPkg: Support the platform to configure HTTPS CipherList.
Thanks Laszlo. If no other comments, I will commit this patch by the end of today. Best Regards! Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Tuesday, February 13, 2018 3:56 AM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Fu, > Siyuan <siyuan...@intel.com>; Kinney, Michael D > <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com> > Subject: Re: [edk2] [PATCH v2 0/2] NetworkPkg: Support the platform to > configure HTTPS CipherList. > > Hi Jiaxin, > > On 02/11/18 04:21, Wu, Jiaxin wrote: > > Hi Laszlo, > > > > Can you help to report one Bugzilla for the new feature request? It's better > to describe the reason why we need support in Bugzilla. > > I've filed <https://bugzilla.tianocore.org/show_bug.cgi?id=875>. Thank > you for the patches! > > Laszlo > > > > >> -Original Message- > >> From: Wu, Jiaxin > >> Sent: Sunday, February 11, 2018 11:15 AM > >> To: edk2-devel@lists.01.org > >> Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > >> <michael.d.kin...@intel.com>; Zimmer, Vincent > >> <vincent.zim...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Ye, > >> Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin > >> <jiaxin...@intel.com> > >> Subject: [PATCH v2 0/2] NetworkPkg: Support the platform to configure > >> HTTPS CipherList. > >> > >> V2: > >> * Rename the file/variable name. > >> * Refine the error handling returned from GetVariable. > >> > >> Cc: Laszlo Ersek <ler...@redhat.com> > >> Cc: Kinney Michael D <michael.d.kin...@intel.com> > >> Cc: Zimmer Vincent <vincent.zim...@intel.com> > >> Cc: Yao Jiewen <jiewen@intel.com> > >> Cc: Ye Ting <ting...@intel.com> > >> Cc: Fu Siyuan <siyuan...@intel.com> > >> Contributed-under: TianoCore Contribution Agreement 1.0 > >> Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> > >> > >> Jiaxin Wu (2): > >> NetworkPkg: Define one private variable for HTTPS to set Tls > >> CipherList. > >> NetworkPkg: Read HttpTlsCipherList variable and configure it for HTTPS > >> session. > >> > >> NetworkPkg/HttpDxe/HttpDriver.h | 3 +- > >> NetworkPkg/HttpDxe/HttpDxe.inf | 3 +- > >> NetworkPkg/HttpDxe/HttpsSupport.c | 92 > >> - > >> NetworkPkg/Include/Guid/HttpTlsCipherList.h | 38 > >> NetworkPkg/NetworkPkg.dec | 3 + > >> 5 files changed, 136 insertions(+), 3 deletions(-) > >> create mode 100644 NetworkPkg/Include/Guid/HttpTlsCipherList.h > >> > >> -- > >> 1.9.5.msysgit.1 > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 2/2] NetworkPkg: Read HttpTlsCipherList variable and configure it for HTTPS session.
Thanks the comment, I will integrate it when I commit the patch. > -Original Message- > From: Ye, Ting > Sent: Monday, February 12, 2018 11:06 AM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Fu, > Siyuan <siyuan...@intel.com> > Subject: RE: [PATCH v2 2/2] NetworkPkg: Read HttpTlsCipherList variable and > configure it for HTTPS session. > > Hi Jiaxin, > > In following code, how about use "gEdkiiHttpTlsCipherListGuid" as the > variable GUID as to make it consistent with the variable name? > > + Status = gRT->GetVariable ( > + EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE, > + , > + NULL, > + , > + NULL > + ); > > Others are good to me. > Reviewed-by: Ye Ting <ting...@intel.com> > > Best Regards, > Ting > > -Original Message- > From: Wu, Jiaxin > Sent: Sunday, February 11, 2018 11:15 AM > To: edk2-devel@lists.01.org > Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Ye, > Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin > <jiaxin...@intel.com> > Subject: [PATCH v2 2/2] NetworkPkg: Read HttpTlsCipherList variable and > configure it for HTTPS session. > > v2: > * Refine the error handling returned from GetVariable. > > This patch is to read the HttpTlsCipherList variable and configure it for the > later HTTPS session. > > If the variable is not set by any platform, EFI_NOT_FOUND will be returned > from GetVariable service. In such a case, the default CipherList created in > TlsDxe driver will be used. > > Cc: Laszlo Ersek <ler...@redhat.com> > Cc: Kinney Michael D <michael.d.kin...@intel.com> > Cc: Zimmer Vincent <vincent.zim...@intel.com> > Cc: Yao Jiewen <jiewen@intel.com> > Cc: Ye Ting <ting...@intel.com> > Cc: Fu Siyuan <siyuan...@intel.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> > --- > NetworkPkg/HttpDxe/HttpDriver.h | 3 +- > NetworkPkg/HttpDxe/HttpDxe.inf| 3 +- > NetworkPkg/HttpDxe/HttpsSupport.c | 92 > ++- > 3 files changed, 95 insertions(+), 3 deletions(-) > > diff --git a/NetworkPkg/HttpDxe/HttpDriver.h > b/NetworkPkg/HttpDxe/HttpDriver.h index 93a412a..3b7a7a2 100644 > --- a/NetworkPkg/HttpDxe/HttpDriver.h > +++ b/NetworkPkg/HttpDxe/HttpDriver.h > @@ -1,9 +1,9 @@ > /** @file >The header files of the driver binding and service binding protocol for > HttpDxe driver. > > - Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved. > + Copyright (c) 2015 - 2018, Intel Corporation. All rights > + reserved. >(C) Copyright 2016 Hewlett Packard Enterprise Development LP > >This program and the accompanying materials >are licensed and made available under the terms and conditions of the BSD > License >which accompanies this distribution. The full text of the license may be > found at @@ -59,10 +59,11 @@ // Produced Protocols // #include > > > #include > +#include > > #include > > // > // Driver Version > diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf > b/NetworkPkg/HttpDxe/HttpDxe.inf index 20075f5..56a2472 100644 > --- a/NetworkPkg/HttpDxe/HttpDxe.inf > +++ b/NetworkPkg/HttpDxe/HttpDxe.inf > @@ -1,9 +1,9 @@ > ## @file > # Implementation of EFI HTTP protocol interfaces. > # > -# Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved. > +# Copyright (c) 2015 - 2018, Intel Corporation. All rights > +reserved. > # > # This program and the accompanying materials # are licensed and made > available under the terms and conditions of the BSD License # which > accompanies this distribution. The full text of the license may be found at # > http://opensource.org/licenses/bsd-license.php. > @@ -72,10 +72,11 @@ >gEfiTlsProtocolGuid ## SOMETIMES_CONSUMES >gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES > > [Guids] >gEfiTlsCaCertificateGuid ## SOMETIMES_CONSUMES ## > Variable:L"TlsCaCertificate" > + gHttpTlsCipherListGuid ## SOMETIMES_CONSUMES ## > Vari
Re: [edk2] [PATCH v2 0/2] NetworkPkg: Support the platform to configure HTTPS CipherList.
Hi Laszlo, Can you help to report one Bugzilla for the new feature request? It's better to describe the reason why we need support in Bugzilla. Thanks, Jiaxin > -Original Message- > From: Wu, Jiaxin > Sent: Sunday, February 11, 2018 11:15 AM > To: edk2-devel@lists.01.org > Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Ye, > Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin > <jiaxin...@intel.com> > Subject: [PATCH v2 0/2] NetworkPkg: Support the platform to configure > HTTPS CipherList. > > V2: > * Rename the file/variable name. > * Refine the error handling returned from GetVariable. > > Cc: Laszlo Ersek <ler...@redhat.com> > Cc: Kinney Michael D <michael.d.kin...@intel.com> > Cc: Zimmer Vincent <vincent.zim...@intel.com> > Cc: Yao Jiewen <jiewen@intel.com> > Cc: Ye Ting <ting...@intel.com> > Cc: Fu Siyuan <siyuan...@intel.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> > > Jiaxin Wu (2): > NetworkPkg: Define one private variable for HTTPS to set Tls > CipherList. > NetworkPkg: Read HttpTlsCipherList variable and configure it for HTTPS > session. > > NetworkPkg/HttpDxe/HttpDriver.h | 3 +- > NetworkPkg/HttpDxe/HttpDxe.inf | 3 +- > NetworkPkg/HttpDxe/HttpsSupport.c | 92 > - > NetworkPkg/Include/Guid/HttpTlsCipherList.h | 38 > NetworkPkg/NetworkPkg.dec | 3 + > 5 files changed, 136 insertions(+), 3 deletions(-) > create mode 100644 NetworkPkg/Include/Guid/HttpTlsCipherList.h > > -- > 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 2/2] NetworkPkg: Read TlsCipherList variable and configure it for HTTPS session.
Thanks Laszlo, I will integrate your comments into the new patch. Best Regards! Jiaxin > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, February 9, 2018 6:16 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Ye, > Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: Re: [Patch 2/2] NetworkPkg: Read TlsCipherList variable and > configure it for HTTPS session. > > On 02/09/18 04:59, Jiaxin Wu wrote: > > This patch is to read the TlsCipherList variable and configure it for the > > later HTTPS session. > > > > If the variable is not set by any platform, EFI_NOT_FOUND will be returned > > from GetVariable service. In such a case, the default CipherList created in > > TlsDxe driver will be used. > > > > Cc: Laszlo Ersek <ler...@redhat.com> > > Cc: Kinney Michael D <michael.d.kin...@intel.com> > > Cc: Zimmer Vincent <vincent.zim...@intel.com> > > Cc: Yao Jiewen <jiewen@intel.com> > > Cc: Ye Ting <ting...@intel.com> > > Cc: Fu Siyuan <siyuan...@intel.com> > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> > > --- > > NetworkPkg/HttpDxe/HttpDriver.h | 3 +- > > NetworkPkg/HttpDxe/HttpDxe.inf| 3 +- > > NetworkPkg/HttpDxe/HttpsSupport.c | 92 > ++- > > 3 files changed, 95 insertions(+), 3 deletions(-) > > > > diff --git a/NetworkPkg/HttpDxe/HttpDriver.h > b/NetworkPkg/HttpDxe/HttpDriver.h > > index 93a412a..eba7d32 100644 > > --- a/NetworkPkg/HttpDxe/HttpDriver.h > > +++ b/NetworkPkg/HttpDxe/HttpDriver.h > > @@ -1,9 +1,9 @@ > > /** @file > >The header files of the driver binding and service binding protocol for > HttpDxe driver. > > > > - Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved. > > + Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. > >(C) Copyright 2016 Hewlett Packard Enterprise Development LP > > > >This program and the accompanying materials > >are licensed and made available under the terms and conditions of the > BSD License > >which accompanies this distribution. The full text of the license may be > found at > > @@ -59,10 +59,11 @@ > > // Produced Protocols > > // > > #include > > > > #include > > +#include > > > > #include > > > > // > > // Driver Version > > diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf > b/NetworkPkg/HttpDxe/HttpDxe.inf > > index 20075f5..b1d7bd2 100644 > > --- a/NetworkPkg/HttpDxe/HttpDxe.inf > > +++ b/NetworkPkg/HttpDxe/HttpDxe.inf > > @@ -1,9 +1,9 @@ > > ## @file > > # Implementation of EFI HTTP protocol interfaces. > > # > > -# Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved. > > +# Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials > > # are licensed and made available under the terms and conditions of the > BSD License > > # which accompanies this distribution. The full text of the license may be > found at > > # http://opensource.org/licenses/bsd-license.php. > > @@ -72,10 +72,11 @@ > >gEfiTlsProtocolGuid ## SOMETIMES_CONSUMES > >gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES > > > > [Guids] > >gEfiTlsCaCertificateGuid ## SOMETIMES_CONSUMES > > ## > Variable:L"TlsCaCertificate" > > + gTlsCipherListGuid ## SOMETIMES_CONSUMES > > ## > Variable:L"TlsCipherList" > > > > [Pcd] > >gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections ## > CONSUMES > >gEfiNetworkPkgTokenSpaceGuid.PcdHttpsAuthenticationMode## > SOMETIMES_CONSUMES > >gEfiNetworkPkgTokenSpaceGuid.PcdHttpsHostPublicCert## > SOMETIMES_CONSUMES > > diff --git a/NetworkPkg/HttpDxe/HttpsSupport.c > b/NetworkPkg/HttpDxe/HttpsSupport.c > > index 288082a..62cb867 100644 > > --- a/NetworkPkg/HttpDxe/HttpsSupport.c > > +++ b/NetworkPkg/HttpDxe/HttpsSupport.c > > @@ -1,9 +1,9 @@ > > /** @file > >Miscellaneous routines specific to Https for HttpDxe driver. > > > > -Copyright (c) 2016 - 2017, Intel
Re: [edk2] [Patch 0/2] NetworkPkg: Support the platform to configure TLS CipherList.
Hi Laszlo, Besides the compatibility consideration, we'd better *not* put CipherList and CaCertificate into one variable. In the future, we prefer to manage the CaCertificate with other cert configuration items together (e.g. HostPublicCert, HostPrivateCert, etc ) rather than the parameters like CipherList. You know we can't save the host cert pairs as variable due to the security consideration. So, case by case, let's keep current solution to define the variable named as "HttpTlsCipherList". Thanks, Jiaxin > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, February 9, 2018 6:12 PM > To: Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; > edk2-devel@lists.01.org > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Ye, > Ting <ting...@intel.com> > Subject: Re: [Patch 0/2] NetworkPkg: Support the platform to configure TLS > CipherList. > > On 02/09/18 06:22, Fu, Siyuan wrote: > > Hi, Jiaxin > > > > I think we can remove the "TlsCipherList.h" to another name like > > "HttpTlsCipherListVariable.h" to highlight that the variable is only > > used for HTTP configuration. And also the variable name and GUID > > name. > If we are renaming gEfiTlsCaCertificateGuid, can we pick a generic term > as new name, something like "gHttpTlsVariableGuid"? And then put both > variables, the CA List and the Cipher List, in that (same) namespace GUID? > > It's not that we'll run out of GUIDs any time soon :) , but I think > these variables belong closely together. > > Thanks, > Laszlo > > >> -Original Message- > >> From: Wu, Jiaxin > >> Sent: Friday, February 9, 2018 12:00 PM > >> To: edk2-devel@lists.01.org > >> Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > >> <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; > >> Yao, Jiewen <jiewen@intel.com>; Ye, Ting <ting...@intel.com>; Fu, > >> Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com> > >> Subject: [Patch 0/2] NetworkPkg: Support the platform to configure TLS > >> CipherList. > >> > >> Cc: Laszlo Ersek <ler...@redhat.com> > >> Cc: Kinney Michael D <michael.d.kin...@intel.com> > >> Cc: Zimmer Vincent <vincent.zim...@intel.com> > >> Cc: Yao Jiewen <jiewen@intel.com> > >> Cc: Ye Ting <ting...@intel.com> > >> Cc: Fu Siyuan <siyuan...@intel.com> > >> Contributed-under: TianoCore Contribution Agreement 1.0 > >> Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> > >> > >> Jiaxin Wu (2): > >> NetworkPkg: Define one private variable for TLS CipherList > >> configuration. > >> NetworkPkg: Read TlsCipherList variable and configure it for HTTPS > >> session. > >> > >> NetworkPkg/HttpDxe/HttpDriver.h | 3 +- > >> NetworkPkg/HttpDxe/HttpDxe.inf | 3 +- > >> NetworkPkg/HttpDxe/HttpsSupport.c | 92 > >> - > >> NetworkPkg/Include/Guid/TlsCipherList.h | 38 ++ > >> NetworkPkg/NetworkPkg.dec | 3 ++ > >> 5 files changed, 136 insertions(+), 3 deletions(-) > >> create mode 100644 NetworkPkg/Include/Guid/TlsCipherList.h > >> > >> -- > >> 1.9.5.msysgit.1 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/2] NetworkPkg: Support the platform to configure TLS CipherList.
Sure, I will update the wiki once the patch is committed. Thanks Jiaxin > -Original Message- > From: Li, Ruth > Sent: Friday, February 9, 2018 3:08 PM > To: Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; > edk2-devel@lists.01.org > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Ye, Ting <ting...@intel.com>; Yao, Jiewen > <jiewen@intel.com> > Subject: RE: [Patch 0/2] NetworkPkg: Support the platform to configure TLS > CipherList. > > Jiaxin > > With this capability introduced, could you update Wiki page to notify platform > to configure that if needed? > https://github.com/tianocore/tianocore.github.io/wiki/HTTPS-Boot > > Thanks, > Ruth > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu, > Siyuan > Sent: Friday, February 9, 2018 1:23 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Ye, Ting <ting...@intel.com>; Laszlo Ersek > <ler...@redhat.com>; Yao, Jiewen <jiewen@intel.com> > Subject: Re: [edk2] [Patch 0/2] NetworkPkg: Support the platform to > configure TLS CipherList. > > Hi, Jiaxin > > I think we can remove the "TlsCipherList.h" to another name like > "HttpTlsCipherListVariable.h" to highlight that the variable is only used for > HTTP configuration. And also the variable name and GUID name. > > Siyuan > > > -Original Message- > > From: Wu, Jiaxin > > Sent: Friday, February 9, 2018 12:00 PM > > To: edk2-devel@lists.01.org > > Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > > <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; > > Yao, Jiewen <jiewen@intel.com>; Ye, Ting <ting...@intel.com>; Fu, > > Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com> > > Subject: [Patch 0/2] NetworkPkg: Support the platform to configure TLS > > CipherList. > > > > Cc: Laszlo Ersek <ler...@redhat.com> > > Cc: Kinney Michael D <michael.d.kin...@intel.com> > > Cc: Zimmer Vincent <vincent.zim...@intel.com> > > Cc: Yao Jiewen <jiewen@intel.com> > > Cc: Ye Ting <ting...@intel.com> > > Cc: Fu Siyuan <siyuan...@intel.com> > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> > > > > Jiaxin Wu (2): > > NetworkPkg: Define one private variable for TLS CipherList > > configuration. > > NetworkPkg: Read TlsCipherList variable and configure it for HTTPS > > session. > > > > NetworkPkg/HttpDxe/HttpDriver.h | 3 +- > > NetworkPkg/HttpDxe/HttpDxe.inf | 3 +- > > NetworkPkg/HttpDxe/HttpsSupport.c | 92 > > - > > NetworkPkg/Include/Guid/TlsCipherList.h | 38 ++ > > NetworkPkg/NetworkPkg.dec | 3 ++ > > 5 files changed, 136 insertions(+), 3 deletions(-) > > create mode 100644 NetworkPkg/Include/Guid/TlsCipherList.h > > > > -- > > 1.9.5.msysgit.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/2] NetworkPkg: Support the platform to configure TLS CipherList.
Thanks the comment, I will refine the series patch. > -Original Message- > From: Fu, Siyuan > Sent: Friday, February 9, 2018 1:23 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; Yao, Jiewen <jiewen@intel.com>; Ye, > Ting <ting...@intel.com> > Subject: RE: [Patch 0/2] NetworkPkg: Support the platform to configure TLS > CipherList. > > Hi, Jiaxin > > I think we can remove the "TlsCipherList.h" to another name like > "HttpTlsCipherListVariable.h" to highlight that the variable is only used for > HTTP configuration. And also the variable name and GUID name. > > Siyuan > > > -Original Message- > > From: Wu, Jiaxin > > Sent: Friday, February 9, 2018 12:00 PM > > To: edk2-devel@lists.01.org > > Cc: Laszlo Ersek <ler...@redhat.com>; Kinney, Michael D > > <michael.d.kin...@intel.com>; Zimmer, Vincent > <vincent.zim...@intel.com>; > > Yao, Jiewen <jiewen@intel.com>; Ye, Ting <ting...@intel.com>; Fu, > > Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com> > > Subject: [Patch 0/2] NetworkPkg: Support the platform to configure TLS > > CipherList. > > > > Cc: Laszlo Ersek <ler...@redhat.com> > > Cc: Kinney Michael D <michael.d.kin...@intel.com> > > Cc: Zimmer Vincent <vincent.zim...@intel.com> > > Cc: Yao Jiewen <jiewen@intel.com> > > Cc: Ye Ting <ting...@intel.com> > > Cc: Fu Siyuan <siyuan...@intel.com> > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> > > > > Jiaxin Wu (2): > > NetworkPkg: Define one private variable for TLS CipherList > > configuration. > > NetworkPkg: Read TlsCipherList variable and configure it for HTTPS > > session. > > > > NetworkPkg/HttpDxe/HttpDriver.h | 3 +- > > NetworkPkg/HttpDxe/HttpDxe.inf | 3 +- > > NetworkPkg/HttpDxe/HttpsSupport.c | 92 > > - > > NetworkPkg/Include/Guid/TlsCipherList.h | 38 ++ > > NetworkPkg/NetworkPkg.dec | 3 ++ > > 5 files changed, 136 insertions(+), 3 deletions(-) > > create mode 100644 NetworkPkg/Include/Guid/TlsCipherList.h > > > > -- > > 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] setting the TLS cipher list for HTTPS booting
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 <jiaxin...@intel.com>; Kinney, Michael D > <michael.d.kin...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, Ting > <ting...@intel.com>; Li, Ruth <ruth...@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 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 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. > > The variable approach sounds good to me, but with a small twist: > > Could we please leave it up to the platform whether the private variable > is non-volatile versus volatile? Because platform X might want to > configure the cipher suite list once, permanently, while platform Y > might want to configure the cipher suite list dynamically on each boot. > For platform Y, spending any flash space (and flash writing time) on the > variable is superfluous. > > For QEMU / OVMF specifically, I would prefer a volatile, boot-time only > variable. After setting this variable, I think OVMF platform code should > even lock it down with the edk2 variable lock protocol. In effect this > would behave like a "read only" PCD -- no flash impact at all. > > As long as HttpDxe only calls gRT->GetVariable() (or equivalent wrappers > from UefiLib) on the new variable, the variable's attributes should not > matter; they can be left to the platform. > > Thanks! > Laszlo > > > >> -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 H
Re: [edk2] setting the TLS cipher list for HTTPS booting
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
Re: [edk2] setting the TLS cipher list for HTTPS booting
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 s aved 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. Thanks, Jiaxin > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, January 25, 2018 12:13 AM > 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/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 NetworkPkg/HttpDxe was a UEFI_DRIVER! :) > > In that case, I think *neither* the LocateProtocol() call for an > edk2-specific protocol, *nor* a PcdGetPtr() call are appropriate. > UEFI_DRIVER modules should preferably only use facilities from the UEFI > spec, and the protocol for the dynamic PCDs comes from the PI spec, not > the UEFI spec. > > (This would be different if HttpDxe was a DXE_DRIVER -- in that case > both approaches would be valid. I assumed HttpDxe was a DXE_DRIVER, not > sure why.) > > (1) So, given that HttpDxe is a UEFI_DRIVER, I think the right approach > would be -- which I believe I also mentioned earlier -- to introduce > another UEFI variable for the list of cipher suites, similarly to > "TlsCaCertificate" (in a custom variable namespace GUID). This would > stay within the framework of the UEFI spec. > > > (2) Regarding the order between setting these UEFI variables in OVMF, > and consuming them in HttpDxe, I think your argument is good. We can set > the variables in some platform code (DXE_DRIVER) in OVMF, before > End-of-DXE, and HttpDxe will only read them later in BDS. > > "OvmfPkg/PlatformDxe" seems like a good candidate for setting these > variables (both considering PlatformDxe's purpose, and because it > already depends on "gEfiVariableWriteArchProtocolGuid"). > > > (3) Regardig the format (EFI_TLS_CIPHER): I agree with you. It seems we > can modify the host environment to pass QEMU (and OVMF) a cipher list > that is already in EFI_TLS_CIPHER format. > > > So I think the only remaining question is if you like a new UEFI > variable instead of the dynamic PCD, for the cipher list. > > Thanks! > Laszlo > > > > > > > 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:
Re: [edk2] setting the TLS cipher list for HTTPS booting
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 {
>
> ...
> 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
Re: [edk2] 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 {
...
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
Re: [edk2] setting the TLS cipher list for HTTPS booting
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 5246
> defined):
> CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
> CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
> The PCD can be configured by the corresponding platform as below,
> otherwise it will use the OpenSSL default one:
> gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35,
> >>> 0x00,0x3D }|VOID*|4
> what do you think?
>
> > Functionally, I agree that OVMF can make the feature work, without any
> > changes to the HttpDxe driver, *but* only for the following two
> > configuration items:
> >
> > - CA certificate, through the (already existing) non-volatile UEFI
> > variable
> >
> > - cipher suites (through the new dynamic PCD called
> > "PcdHttpsTlsCipherLists")
> >
> > What about the rest of the configuration items? Should we introduce
> > dynamic PCDs for those as well, individually?
> >
> > I cannot tell what other config items should be exposed right from the
> > start. That's why I'm suggesting HTTPS_CONFIG_PROTOCOL -- it looks
> > flexible and reasonably future-proof.
> >
> > BTW, I'm not asking that you write any code for this; I plan to submit
> > the patches myself (for HttpDxe as well). We just have to figure out the
> > direction first.
> >
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.
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
Re: [edk2] setting the TLS cipher list for HTTPS booting
> >> > >> 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 EFI_TLS_PROTOCOL.SetSessionData() -- in the file > >> "NetworkPkg/HttpDxe/HttpsSupport.c", -- but it never passes > >> "EfiTlsCipherList" as argument for the "DataType" parameter. > >> > > > > > > Jiaxin: Correct, currently, HttpDxe as a TLS protocol consumer doesn't > > set the its own preferred CipherList because it prefers to use the > > default CipherList, which has been configured by TLS driver by > > default. The TLS default setting was happened during the creation of > > new OpenSSL SSL_CTX object. The flow path is shown as below: > > TlsCtxNew -> SSL_CTX_new -> ssl_create_cipher_list. > > So, the default CipherList is: > > # define SSL_DEFAULT_CIPHER_LIST > "ALL:!COMPLEMENTOFDEFAULT:!eNULL" > > > > > >> Is there a way for platform code to control the list of ciphers? > > > > > > Jiaxin: Currently, not support yet. > > > > > >> > >> This is different from other "global" TLS aspects, such as > >> EFI_TLS_CONFIGURATION_PROTOCOL, because the latter is a singleton > >> "service" protocol, while EFI_TLS_PROTOCOL instances are created by > >> clients as-needed, via TLS service binding. So, I think if a platform > >> wanted to control this on the session level, then it would have to > >> "ask" HttpDxe somehow. > >> > > > > > > Jiaxin: EFI_TLS_CONFIGURATION_PROTOCOL provides the capability to set > > the client certificate/key pairs, different clients may use the > > different certificate/key Paris (so does OpenSSL). Based on this, it's > > not a singleton "service" protocol. So, in TlsDxe driver, we bind it > > to the same ChildHandle as TLS protocol. > > Status = gBS->InstallMultipleProtocolInterfaces ( > > ChildHandle, > > , > > >Tls, > > , > > >TlsConfig, > > NULL > > ); > > But above implementation also doesn't prevent all the clients use the > > same certificate/key Paris since they can use its own > > EFI_TLS_CONFIGURATION_PROTOCOL to configure the same "global" > > certificate/key pair (on the session level). That's depend on the TLS > > consumer. > > Thank you for the correction. > > Do I understand correctly that, consequently, these characteristics have > to be set in NetworkPkg/HttpDxe as well, similarly to the cipher list? > Yes. They should be set in HttpDxe driver since it's the TLS driver consumer. > If that's correct, what would be the best way for a platform to control > these settings? Introducing separate dynamic PCDs is perhaps overkill. > > Sometimes platform customization is implemented by the core module > calling out to an optional platform-provided protocol. > > For example, PciHostBridgeDxe calls EDKII_IOMMU_PROTOCOL, if the > platform provides one. > > Alternatively, PciBusDxe calls EFI_PCI_HOT_PLUG_INIT_PROTOCOL, if the > platform provides one. > > Can we introduce a similar protocol here, so that HttpDxe can ask the > platform about the TLS preferences, and then configure TLS accordingly? > > > Sticking with the IOMMU example: in OVMF, we don't *always* have an > IOMMU protocol, but when we do, then we want PciHostBridgeDxe to wait > for the protocol (with a depex). So what we do is, we have a very small > library instance, > > OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf > > with an empty constructor, and a DEPEX like this: > > [Depex] > gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid > > (The latter protocol is from OvmfPkg.dec.) > > Then, in the OVMF DSC files, we hook this library into PciHostBridgeDxe, > as a NULL class library. The end result is that PciHostBridgeDxe will > only be dispatched after OVMF platform code determines whether an IOMMU > is present or not. If not, then gIoMmuAbsentProtocolGuid is installed > (and PciHostBridgeDxe will be launched without an IOMMU). Otherwise > gEdkiiIoMmuProtocolGuid is installed by OVMF, and then PciHostBridgeDxe > is guaranteed to use the IOMMU. > > In the HTTPS boot case, I'd make HttpDxe wait for the platform TLS > settings similarly -- NetworkPkg/HttpDxe would only have to look up the > protocol, and use it (for configuring TLS) if the protocol is there. > > This looks more flexible than a large set of dynamic PCDs. > > ... We have such names already: > > EDKII_PLATFORM_LOGO_PROTOCOL > EDKII_PLATFORM_VTD_POLICY_PROTOCOL > > So we could introduce EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL, with the > following member functions: > > .GetData () > .GetSessionData () > > They would have similar signatures to > EFI_TLS_CONFIGURATION_PROTOCOL.GetData() and > EFI_TLS_PROTOCOL.GetSessionData(). > > "NetworkPkg/HttpDxe" could call each of these
Re: [edk2] AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
Please also report the issue on Bugzilla.
Thanks,
Jiaxin
From: Wu, Jiaxin
Sent: Saturday, January 20, 2018 2:37 PM
To: Karunakar P <karunak...@amiindia.co.in>; Ye, Ting <ting...@intel.com>; Fu,
Siyuan <siyuan...@intel.com>; 'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org>
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
You should sent out the attached patches for the review:).
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>
Thanks,
Jiaxin
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, January 17, 2018 6:29 PM
To: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>; 'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
[Patch] NetworkPkg\HttpBootDxe: AsciiPrint() in HttpBootDxe Corrupting the
Setup screen
NetworkPkg\HttpBootDxe\HttpBootSupport.c | 2
NetworkPkg\HttpBootDxe\HttpBootClient.c| 10
2 files changed, 10 insertions(+), 2 deletions(-)
NetworkPkg\HttpBootDxe\HttpBootSupport.c
NetworkPkg\HttpBootDxe\HttpBootClient.c
EFI_STATUS
HttpBootCheckUriScheme (
IN CHAR8 *Uri
)
{
UINTNIndex;
EFI_STATUS Status;.
.
.
//
// Return EFI_INVALID_PARAMETER if the URI is not HTTP or HTTPS.
//
if ((AsciiStrnCmp (Uri, "http://;, 7) != 0) && (AsciiStrnCmp (Uri,
"https://;, 8) != 0)) {
-AsciiPrint ("\n Error: Invalid URI address.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: Invalid Uri.\n"));
return EFI_INVALID_PARAMETER;
}
//
// HTTP is disabled, return EFI_ACCESS_DENIED if the URI is HTTP.
//
if (!PcdGetBool (PcdAllowHttpConnections) && (AsciiStrnCmp (Uri, "http://;,
7) == 0)) {
-AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: HTTP is disabled.\n"));
return EFI_ACCESS_DENIED;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp4ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP4_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP4_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;.
.
.
.
//
// Check the URI scheme.
//
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp4ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+ } else if (Status == EFI_ACCESS_DENIED) {
+AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp6ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP6_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP6_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;
.
.
.
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp6ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+} else if (Status == EFI_ACCESS_DENIED) {
+ AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
Please review the patch.
Thanks,
Karunakar
From: Karunakar P
Sent: Wednesday, January 17, 2018 2:44 PM
To: 'Wu, Jiaxin'; Ye, Ting; Fu, Siyuan; 'edk2-devel@lists.01.org'
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Jiaxin,
We'll send the formal patch for review and also could you please let me know if
you want to fill a bug in Bugzilla if needed.
Thank You,
Karunakar
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Thursday, January 11, 2018 6:21 AM
To: Karunakar P; Ye, Ting; Fu, Siyuan
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
I agree the fix, can you send out the formal patch for the review or need us to
follow that?
Thanks,
Jiaxin
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, January 10, 2018 4:48 PM
To: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>
Subject: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hello All,
[Issue]
1. On giving Invalid URI in Boot URI field in "HTTP Boot Configuration"
Page, doing AsciiPrint() in
Re: [edk2] AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
You should sent out the attached patches for the review:).
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
Thanks,
Jiaxin
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, January 17, 2018 6:29 PM
To: Wu, Jiaxin <jiaxin...@intel.com>; Ye, Ting <ting...@intel.com>; Fu, Siyuan
<siyuan...@intel.com>; 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
[Patch] NetworkPkg\HttpBootDxe: AsciiPrint() in HttpBootDxe Corrupting the
Setup screen
NetworkPkg\HttpBootDxe\HttpBootSupport.c | 2
NetworkPkg\HttpBootDxe\HttpBootClient.c| 10
2 files changed, 10 insertions(+), 2 deletions(-)
NetworkPkg\HttpBootDxe\HttpBootSupport.c
NetworkPkg\HttpBootDxe\HttpBootClient.c
EFI_STATUS
HttpBootCheckUriScheme (
IN CHAR8 *Uri
)
{
UINTNIndex;
EFI_STATUS Status;.
.
.
//
// Return EFI_INVALID_PARAMETER if the URI is not HTTP or HTTPS.
//
if ((AsciiStrnCmp (Uri, "http://;, 7) != 0) && (AsciiStrnCmp (Uri,
"https://;, 8) != 0)) {
-AsciiPrint ("\n Error: Invalid URI address.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: Invalid Uri.\n"));
return EFI_INVALID_PARAMETER;
}
//
// HTTP is disabled, return EFI_ACCESS_DENIED if the URI is HTTP.
//
if (!PcdGetBool (PcdAllowHttpConnections) && (AsciiStrnCmp (Uri, "http://;,
7) == 0)) {
-AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: HTTP is disabled.\n"));
return EFI_ACCESS_DENIED;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp4ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP4_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP4_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;.
.
.
.
//
// Check the URI scheme.
//
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp4ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+ } else if (Status == EFI_ACCESS_DENIED) {
+AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp6ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP6_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP6_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;
.
.
.
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp6ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+} else if (Status == EFI_ACCESS_DENIED) {
+ AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
Please review the patch.
Thanks,
Karunakar
From: Karunakar P
Sent: Wednesday, January 17, 2018 2:44 PM
To: 'Wu, Jiaxin'; Ye, Ting; Fu, Siyuan; 'edk2-devel@lists.01.org'
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Jiaxin,
We'll send the formal patch for review and also could you please let me know if
you want to fill a bug in Bugzilla if needed.
Thank You,
Karunakar
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Thursday, January 11, 2018 6:21 AM
To: Karunakar P; Ye, Ting; Fu, Siyuan
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
I agree the fix, can you send out the formal patch for the review or need us to
follow that?
Thanks,
Jiaxin
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, January 10, 2018 4:48 PM
To: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>
Subject: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hello All,
[Issue]
1. On giving Invalid URI in Boot URI field in "HTTP Boot Configuration"
Page, doing AsciiPrint() in TSE corrupting the Screen.
AsciiPrint ("\n Error: Invalid URI address.\n");
2. When HTTP connection are disabled using "PcdAllowHttpConnections"
On giving http URI in Boot URI field in "HTTP Boot Configuration" Page, doing
AsciiPrint() in TSE corrupting the Screen.
AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is allowed.\n");
[Fix]
1. I guess We've added this AsciiPrint() because HttpBootCheckUriScheme()
is common for both generic HTTP boot over IPv4/6 and "Http Boo
Re: [edk2] setting the TLS cipher list for HTTPS booting
>
> 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 EFI_TLS_PROTOCOL.SetSessionData() -- in the file
> "NetworkPkg/HttpDxe/HttpsSupport.c", -- but it never passes
> "EfiTlsCipherList" as argument for the "DataType" parameter.
>
Jiaxin: Correct, currently, HttpDxe as a TLS protocol consumer doesn't set the
its own preferred CipherList because it prefers to use the default CipherList,
which has been configured by TLS driver by default. The TLS default setting was
happened during the creation of new OpenSSL SSL_CTX object. The flow path is
shown as below:
TlsCtxNew -> SSL_CTX_new -> ssl_create_cipher_list.
So, the default CipherList is:
# define SSL_DEFAULT_CIPHER_LIST "ALL:!COMPLEMENTOFDEFAULT:!eNULL"
> Is there a way for platform code to control the list of ciphers?
Jiaxin: Currently, not support yet.
>
> This is different from other "global" TLS aspects, such as
> EFI_TLS_CONFIGURATION_PROTOCOL, because the latter is a singleton
> "service" protocol, while EFI_TLS_PROTOCOL instances are created by
> clients as-needed, via TLS service binding. So, I think if a platform
> wanted to control this on the session level, then it would have to "ask"
> HttpDxe somehow.
>
Jiaxin: EFI_TLS_CONFIGURATION_PROTOCOL provides the capability to set the
client certificate/key pairs, different clients may use the different
certificate/key Paris (so does OpenSSL). Based on this, it's not a singleton
"service" protocol. So, in TlsDxe driver, we bind it to the same ChildHandle as
TLS protocol.
Status = gBS->InstallMultipleProtocolInterfaces (
ChildHandle,
,
>Tls,
,
>TlsConfig,
NULL
);
But above implementation also doesn't prevent all the clients use the same
certificate/key Paris since they can use its own EFI_TLS_CONFIGURATION_PROTOCOL
to configure the same "global" certificate/key pair (on the session level).
That's depend on the TLS consumer.
> If you agree -- do you suggest a dynamic PCD, or an extension to the
> UEFI spec (at the HTTP level)?
>
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 5246 defined):
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
The PCD can be configured by the corresponding platform as below, otherwise it
will use the OpenSSL default one:
gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35,
0x00,0x3D }|VOID*|4
what do you think?
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Regression/Assert : MdeModulePkg: Did some code enhancement for DxeIpIoLib
Hi Joakim,
It has been fixed in EDK2 trunk. The commit log is shown as below:
SHA-1: 6478baf891524348451d75a37f4e4692b835a45b
* MdeModulePkg/DxeIpIoLib: Fixed the error ASSERT incorrectly used in
IpIoAddIp().
* In DxeIpIo, an ASSERT check is incorrectly used in IpIoAddIp(), which result
debug image hang when this API is called, this patch is to fix this issue.
Cc: Jiaxin Wu <jiaxin...@intel.com>
Cc: Fu Siyuan <siyuan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan <fan.w...@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
Thanks,
Jiaxin
From: Joakim Bech [mailto:joakim.b...@linaro.org]
Sent: Tuesday, January 16, 2018 6:59 PM
To: Wang, Fan <fan.w...@intel.com>
Cc: edk2-devel@lists.01.org; Wu, Jiaxin <jiaxin...@intel.com>; Fu, Siyuan
<siyuan...@intel.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>;
team-security-wg <team-security...@linaro.org>; Leif Lindholm
<leif.lindh...@linaro.org>
Subject: [edk2] Regression/Assert : MdeModulePkg: Did some code enhancement for
DxeIpIoLib
Hi,
With recent patches being merged in EDK2 we get an assert when booting:
--
...
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 7BA990A0
InstallProtocolInterface: 83F01464-99BD-45E5-B383-AF6305D8E9E6 7BA99B20
ASSERT [Udp4Dxe]
/mnt/sshd/devel/optee_projects/qemu_v8/edk2/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c(1750):
(IpInfo->IpVersion == 4) || (IpInfo->IpVersion == 6)
--
I've bisected it to this commit:
--
$ git bisect bad
2b2087478c861b967394f1ce31531d27ab541b02 is the first bad commit
commit 2b2087478c861b967394f1ce31531d27ab541b02
Author: Wang Fan <fan.w...@intel.com<mailto:fan.w...@intel.com>>
Date: Wed Jan 10 11:09:28 2018 +0800
MdeModulePkg: Did some code enhancement for DxeIpIoLib
* In DxeIpIo, there are several places use ASSERT() to check input
parameters without and descriptions or error handling. This patch
fixed this issue.
* Fixed some incorrect descriptions in code commence.
* Remove unneeded Exit tag in function IpIoOpen and IpIoConfigIp.
* Add EFIAPI tag for function IpIoRefreshNeighbor.
Cc: Jiaxin Wu <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>
Cc: Ye Ting <ting...@intel.com<mailto:ting...@intel.com>>
Cc: Fu Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan <fan.w...@intel.com<mailto:fan.w...@intel.com>>
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>
Reviewed-by: Fu Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>
:04 04 2c60fa2019178c75556b238dbf877927917531f0
080ccf675bf7ee498ec89f76bfd14fd61ff9 M MdeModulePkg
--
This EKD2 build is being used in a QEMU Arm v8 setup running AArch64
(aarch64-linux-gnu-) and for reference here are the build parameters:
--
make -j1 -C /mnt/sshd/devel/optee_projects/qemu_v8/build/../edk2/BaseTools && \
GCC49_AARCH64_PREFIX=/mnt/sshd/devel/optee_projects/qemu_v8/build/../toolchains/aarch64-legacy/bin/aarch64-linux-gnu-
make -j1 -C /mnt/sshd/devel/optee_projects/qemu_v8/build/../edk2 -f
ArmPlatformPkg/Scripts/Makefile EDK2_ARCH=AARCH64
EDK2_DSC=ArmVirtPkg/ArmVirtQemuKernel.dsc EDK2_TOOLCHAIN=GCC49 EDK2_BUILD=DEBUG
EDK2_MACROS="-n 6" all
--
Is this something an EDK2 developer could look into or give advice how to
resolve it? Set IP_VERSION_4 or IP_VERSION_6 somewhere?
Regards,
Joakim
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg/DxeIpIoLib: Fixed the error ASSERT incorrectly used in IpIoAddIp().
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wang Fan
> Sent: Tuesday, January 16, 2018 3:57 PM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>
> Subject: [edk2] [Patch] MdeModulePkg/DxeIpIoLib: Fixed the error ASSERT
> incorrectly used in IpIoAddIp().
>
> * In DxeIpIo, an ASSERT check is incorrectly used in IpIoAddIp(), which result
> debug image hang when this API is called, this patch is to fix this issue.
>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> index 0c6681d..66c7fec 100644
> --- a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> +++ b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> @@ -1740,16 +1740,16 @@ IpIoAddIp (
>EFI_STATUS Status;
>IP_IO_IP_INFO *IpInfo;
>EFI_EVENT Event;
>
>ASSERT (IpIo != NULL);
> + ASSERT ((IpIo->IpVersion == IP_VERSION_4) || (IpIo->IpVersion ==
> IP_VERSION_6));
>
>IpInfo = AllocatePool (sizeof (IP_IO_IP_INFO));
>if (IpInfo == NULL) {
> return NULL;
>}
> - ASSERT ((IpInfo->IpVersion == IP_VERSION_4) || (IpInfo->IpVersion ==
> IP_VERSION_6));
>
>//
>// Init this IpInfo, set the Addr and SubnetMask to 0 before we configure
> the IP
>// instance.
>//
> --
> 1.9.5.msysgit.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 1/2] MdeModulePkg: Freed the received packet buffer if it is not expected.
Series Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: Wang, Fan
> Sent: Wednesday, January 10, 2018 11:16 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin <jiaxin...@intel.com>; Ye, Ting <ting...@intel.com>; Fu,
> Siyuan <siyuan...@intel.com>
> Subject: [Patch 1/2] MdeModulePkg: Freed the received packet buffer if it is
> not expected.
>
> * When the packet is not normal packet or icmp error packet, the code
> does not recycle it by signal RecycleSignal event, and this will
> result some memory leak. This patch is to fix this issue.
>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> index a06c0b6..c7bc1aa 100644
> --- a/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> +++ b/MdeModulePkg/Library/DxeIpIoLib/DxeIpIoLib.c
> @@ -1037,16 +1037,26 @@ IpIoListenHandlerDpc (
> // The reception is actively aborted by the consumer, directly return.
> //
> return;
>}
>
> - if (((EFI_SUCCESS != Status) && (EFI_ICMP_ERROR != Status)) || (NULL ==
> RxData)) {
> + if ((EFI_SUCCESS != Status) && (EFI_ICMP_ERROR != Status)) {
> //
> -// @bug Only process the normal packets and the icmp error packets, if
> RxData is NULL
> -// @bug with Status == EFI_SUCCESS or EFI_ICMP_ERROR, just resume
> the receive although
> -// @bug this should be a bug of the low layer (IP).
> +// Only process the normal packets and the icmp error packets.
> //
> +if (RxData != NULL) {
> + goto CleanUp;
> +} else {
> + goto Resume;
> +}
> + }
> +
> + //
> + // if RxData is NULL with Status == EFI_SUCCESS or EFI_ICMP_ERROR, this
> should be a code issue in the low layer (IP).
> + //
> + ASSERT (RxData != NULL);
> + if (RxData == NULL) {
> goto Resume;
>}
>
>if (NULL == IpIo->PktRcvdNotify) {
> goto CleanUp;
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2] MdeModulePkg/DxeNetLib: Add array range check in NetIp6IsNetEqual().
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com> > -Original Message- > From: Wang, Fan > Sent: Thursday, January 11, 2018 6:14 PM > To: edk2-devel@lists.01.org > Cc: Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; Wu, > Hao A <hao.a...@intel.com> > Subject: [Patch v2] MdeModulePkg/DxeNetLib: Add array range check in > NetIp6IsNetEqual(). > > V2 > * Added an ASSERT check for the case PrefixLength equals to > IP6_PREFIX_MAX. > * Synced some code descriptions to head file. > > Cc: Fu Siyuan <siyuan...@intel.com> > Cc: Jiaxin Wu <jiaxin...@intel.com> > Cc: Hao Wu <hao.a...@intel.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Wang Fan <fan.w...@intel.com> > --- > MdeModulePkg/Include/Library/NetLib.h | 50 > +++--- > MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 8 +++-- > 2 files changed, 52 insertions(+), 6 deletions(-) > > diff --git a/MdeModulePkg/Include/Library/NetLib.h > b/MdeModulePkg/Include/Library/NetLib.h > index 7862df9..b0bbaf2 100644 > --- a/MdeModulePkg/Include/Library/NetLib.h > +++ b/MdeModulePkg/Include/Library/NetLib.h > @@ -1,10 +1,10 @@ > /** @file >This library is only intended to be used by UEFI network stack modules. >It provides basic functions for the UEFI network stack. > > -Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved. > +Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved. > This program and the accompanying materials > are licensed and made available under the terms and conditions of the BSD > License > which accompanies this distribution. The full text of the license may be > found at > http://opensource.org/licenses/bsd-license.php > > @@ -438,10 +438,12 @@ NetIp4IsUnicast ( >); > > /** >Check whether the incoming IPv6 address is a valid unicast address. > > + ASSERT if Ip6 is NULL. > + >If the address is a multicast address has binary 0xFF at the start, it is > not >a valid unicast address. If the address is unspecified ::, it is not a > valid >unicast address to be assigned to any node. If the address is loopback > address >::1, it is also not a valid unicast address to be assigned to any physical >interface. > @@ -459,10 +461,12 @@ NetIp6IsValidUnicast ( > > > /** >Check whether the incoming Ipv6 address is the unspecified address or not. > > + ASSERT if Ip6 is NULL. > + >@param[in] Ip6 - Ip6 address, in network order. > >@retval TRUE - Yes, incoming Ipv6 address is the unspecified address. >@retval FALSE- The incoming Ipv6 address is not the unspecified address > > @@ -474,10 +478,12 @@ NetIp6IsUnspecifiedAddr ( >); > > /** >Check whether the incoming Ipv6 address is a link-local address. > > + ASSERT if Ip6 is NULL. > + >@param[in] Ip6 - Ip6 address, in network order. > >@retval TRUE - The incoming Ipv6 address is a link-local address. >@retval FALSE - The incoming Ipv6 address is not a link-local address. > > @@ -489,10 +495,13 @@ NetIp6IsLinkLocalAddr ( >); > > /** >Check whether the Ipv6 address1 and address2 are on the connected > network. > > + ASSERT if Ip1 or Ip2 is NULL. > + ASSERT if PrefixLength exceeds or equals to IP6_PREFIX_MAX. > + >@param[in] Ip1 - Ip6 address1, in network order. >@param[in] Ip2 - Ip6 address2, in network order. >@param[in] PrefixLength - The prefix length of the checking net. > >@retval TRUE- Yes, the Ipv6 address1 and address2 are > connected. > @@ -508,10 +517,12 @@ NetIp6IsNetEqual ( >); > > /** >Switches the endianess of an IPv6 address. > > + ASSERT if Ip6 is NULL. > + >This function swaps the bytes in a 128-bit IPv6 address to switch the value >from little endian to big endian or vice versa. The byte swapped value is >returned. > >@param Ip6 Points to an IPv6 address. > @@ -542,10 +553,12 @@ extern EFI_IPv4_ADDRESS mZeroIp4Addr; > #define NET_RANDOM(Seed)((UINT32) ((UINT32) (Seed) * > 1103515245UL + 12345) % 4294967295UL) > > /** >Extract a UINT32 from a byte stream. > > + ASSERT if Buf is NULL. > + >This function copies a UINT32 from a byte stream, and then converts it from > Network >byte order to host byte order. Use this function to avoid alignment error. > >@param[in] Buf The buffer to extract the UINT32. > > @@ -559,10 +572,12 @@ NetGetUint32 ( >); > > /** >Puts a UINT32 into the byte stream in net
Re: [edk2] [Patch] MdeModulePkg/Ip4Dxe: Add an independent timer for reconfig checking
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: Wang, Fan
> Sent: Thursday, January 11, 2018 6:20 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin <jiaxin...@intel.com>; Ye, Ting <ting...@intel.com>; Fu,
> Siyuan <siyuan...@intel.com>
> Subject: [Patch] MdeModulePkg/Ip4Dxe: Add an independent timer for
> reconfig checking
>
> * Since wireless network can switch at very short time, the time interval
> of reconfig event checking is too long for this case. To achieve better
> performance and scalability, separate this task from Ip4 tick timer.
>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 28
> +-
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c | 47
> +++
> MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h | 30
> ---
> 3 files changed, 83 insertions(+), 22 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> index 49b7dc5..552c4e1 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
> @@ -1,9 +1,9 @@
> /** @file
>The driver binding and service binding protocol for IP4 driver.
>
> -Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
>
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> @@ -251,10 +251,11 @@ Ip4CreateService (
>IpSb->MnpConfigData.DisableBackgroundPolling = FALSE;
>
>ZeroMem (>SnpMode, sizeof (EFI_SIMPLE_NETWORK_MODE));
>
>IpSb->Timer = NULL;
> + IpSb->ReconfigCheckTimer = NULL;
>
>IpSb->ReconfigEvent = NULL;
>
>IpSb->Reconfig = FALSE;
>
> @@ -283,10 +284,22 @@ Ip4CreateService (
>if (EFI_ERROR (Status)) {
> goto ON_ERROR;
>}
>
>Status = gBS->CreateEvent (
> + EVT_NOTIFY_SIGNAL | EVT_TIMER,
> + TPL_CALLBACK,
> + Ip4TimerReconfigChecking,
> + IpSb,
> + >ReconfigCheckTimer
> + );
> +
> + if (EFI_ERROR (Status)) {
> +goto ON_ERROR;
> + }
> +
> + Status = gBS->CreateEvent (
>EVT_NOTIFY_SIGNAL,
>TPL_NOTIFY,
>Ip4AutoReconfigCallBack,
>IpSb,
>>ReconfigEvent
> @@ -408,10 +421,17 @@ Ip4CleanService (
> gBS->CloseEvent (IpSb->Timer);
>
> IpSb->Timer = NULL;
>}
>
> + if (IpSb->ReconfigCheckTimer != NULL) {
> +gBS->SetTimer (IpSb->ReconfigCheckTimer, TimerCancel, 0);
> +gBS->CloseEvent (IpSb->ReconfigCheckTimer);
> +
> +IpSb->ReconfigCheckTimer = NULL;
> + }
> +
>if (IpSb->DefaultInterface != NULL) {
> Status = Ip4FreeInterface (IpSb->DefaultInterface, NULL);
>
> if (EFI_ERROR (Status)) {
>return Status;
> @@ -628,10 +648,16 @@ Ip4DriverBindingStart (
>
>if (EFI_ERROR (Status)) {
> goto UNINSTALL_PROTOCOL;
>}
>
> + Status = gBS->SetTimer (IpSb->ReconfigCheckTimer, TimerPeriodic, 500 *
> TICKS_PER_MS);
> +
> + if (EFI_ERROR (Status)) {
> +goto UNINSTALL_PROTOCOL;
> + }
> +
>//
>// Initialize the IP4 ID
>//
>mIp4Id = (UINT16)NET_RANDOM (NetRandomInitSeed ());
>
> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> index ac48ad2..b5cd7b7 100644
> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
> @@ -1,8 +1,8 @@
> /** @file
>
> -Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> http://opensource.org/licenses/bsd-license.php
>
&g
Re: [edk2] [Patch] NetworkPkg: Fix incorrect parameter check in PXE.Mtftp() function.
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: Fu, Siyuan
> Sent: Thursday, January 11, 2018 5:19 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; Wang,
> Fan <fan.w...@intel.com>
> Subject: [Patch] NetworkPkg: Fix incorrect parameter check in PXE.Mtftp()
> function.
>
> According to UEFI spec, the PXE.Mtftp() should return invalid parameter if
> the
> BufferPtr parameter was NULL and the DontUseBuffer parameter was FALSE.
> The DontUseBuffer is only used when perform MTFTP/TFTP read operation.
>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Wu Jiaxin <jiaxin...@intel.com>
> Cc: Wang Fan <fan.w...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan <siyuan...@intel.com>
> ---
> NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c
> b/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c
> index 93f3bfa5ba..9068e0686c 100644
> --- a/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c
> +++ b/NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c
> @@ -855,11 +855,19 @@ EfiPxeBcMtftp (
>(Filename == NULL) ||
>(BufferSize == NULL) ||
>(ServerIp == NULL) ||
> - ((BufferPtr == NULL) && DontUseBuffer) ||
>((BlockSize != NULL) && (*BlockSize <
> PXE_MTFTP_DEFAULT_BLOCK_SIZE))) {
> return EFI_INVALID_PARAMETER;
>}
>
> + if (Operation == EFI_PXE_BASE_CODE_TFTP_READ_FILE ||
> + Operation == EFI_PXE_BASE_CODE_TFTP_READ_DIRECTORY ||
> + Operation == EFI_PXE_BASE_CODE_MTFTP_READ_FILE ||
> + Operation == EFI_PXE_BASE_CODE_MTFTP_READ_DIRECTORY) {
> +if (BufferPtr == NULL && !DontUseBuffer) {
> + return EFI_INVALID_PARAMETER;
> +}
> + }
> +
>Config= NULL;
>Status= EFI_DEVICE_ERROR;
>Private = PXEBC_PRIVATE_DATA_FROM_PXEBC (This);
> --
> 2.13.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg/DxeNetLib: Add array range check in NetIp6IsNetEqual().
Hi Fan,
I think we need to update the below ASSERT if apply you patch:
ASSERT ((Ip1 != NULL) && (Ip2 != NULL) && (PrefixLength <=
IP6_PREFIX_MAX));
Update To:
ASSERT ((Ip1 != NULL) && (Ip2 != NULL) && (PrefixLength <
IP6_PREFIX_MAX));
If PrefixLength is IP6_PREFIX_MAX(128), then the Byte can be 16:
Byte = (UINT8) (PrefixLength / 8);
So, it will conflict with your patch ASSERT:
ASSERT (Byte < 16);
Thanks,
Jiaxin
> -Original Message-
> From: Wang, Fan
> Sent: Thursday, January 11, 2018 10:39 AM
> To: edk2-devel@lists.01.org
> Cc: Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; Wu,
> Hao A <hao.a...@intel.com>
> Subject: [Patch] MdeModulePkg/DxeNetLib: Add array range check in
> NetIp6IsNetEqual().
>
> * The library API use array elements without any index range check, this
> patch is to fix this issue to avoid null pointer reference.
>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Hao Wu <hao.a...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> index cbce28f..34e11a8 100644
> --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> @@ -840,10 +840,14 @@ NetIp6IsNetEqual (
>}
>
>if (Bit > 0) {
> Mask = (UINT8) (0xFF << (8 - Bit));
>
> +ASSERT (Byte < 16);
> +if (Byte >= 16) {
> + return FALSE;
> +}
> if ((Ip1->Addr[Byte] & Mask) != (Ip2->Addr[Byte] & Mask)) {
>return FALSE;
> }
>}
>
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/4] Fix some issues in Udp6Dxe
Series Reviewed-by: Jiaxin Wu <jiaxin...@intel.com> > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > fanwang2 > Sent: Thursday, January 4, 2018 11:20 AM > To: edk2-devel@lists.01.org > Cc: Wang, Fan <fan.w...@intel.com> > Subject: [edk2] [Patch 0/4] Fix some issues in Udp6Dxe > > From: Wang Fan <fan.w...@intel.com> > > See descriptions in each patch. > > Wang Fan (4): > NetworkPkg: Add ASSERT error handling for UDP6 driver > NetworkPkg: Fix a memory leak issue in UDP6 driver > NetworkPkg: Fix some coding style issues in UDP6 driver > NetworkPkg: Add more parameter or return status check in UDP6 driver > > NetworkPkg/Udp6Dxe/Udp6Driver.c | 68 ++--- > > NetworkPkg/Udp6Dxe/Udp6Impl.c | 43 +++--- > NetworkPkg/Udp6Dxe/Udp6Main.c | 14 +++-- > 3 files changed, 86 insertions(+), 39 deletions(-) > > -- > 1.9.5.msysgit.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 2/2] MdeModulePkg: Freed packet buffer when error occurs to avoid memory leak.
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wang Fan
> Sent: Tuesday, January 9, 2018 9:19 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu,
> Jiaxin <jiaxin...@intel.com>
> Subject: [edk2] [Patch 2/2] MdeModulePkg: Freed packet buffer when error
> occurs to avoid memory leak.
>
> * In function Mtftp4WrqSendBlock(), when packet is not needed, function
> returns EFI_ABORTED but not freed the packet buffer. It results some
> memory leak and this patch is to fix this issue.
>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Wrq.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Wrq.c
> b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Wrq.c
> index e825714..438659a 100644
> --- a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Wrq.c
> +++ b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Wrq.c
> @@ -1,9 +1,9 @@
> /** @file
>Routines to process Wrq (upload).
>
> -Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> http://opensource.org/licenses/bsd-license.php
>
> @@ -92,10 +92,14 @@ Mtftp4WrqSendBlock (
> if (EFI_ERROR (Status) || (DataLen > Instance->BlkSize)) {
>if (DataBuf != NULL) {
> FreePool (DataBuf);
>}
>
> + if (UdpPacket != NULL) {
> +NetbufFree (UdpPacket);
> + }
> +
>Mtftp4SendError (
> Instance,
> EFI_MTFTP4_ERRORCODE_REQUEST_DENIED,
> (UINT8 *) "User aborted the transfer"
> );
> --
> 1.9.5.msysgit.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 1/2] MdeModulePkg: Fixed two issues when error occurs in Mtftp4Start.
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wang Fan
> Sent: Tuesday, January 9, 2018 9:19 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu,
> Jiaxin <jiaxin...@intel.com>
> Subject: [edk2] [Patch 1/2] MdeModulePkg: Fixed two issues when error
> occurs in Mtftp4Start.
>
> * This function sets returned status as token status and signal token
> when error occurs, and it results token status not compliance with
> spec definition. This patch fixed this issue.
> * This function restore Tpl twice when Mtftp4WrqStart() returns an
> error, this patch fixed this issue.
>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> .../Universal/Network/Mtftp4Dxe/Mtftp4Impl.c | 20
>
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> index 54384e1..f5f9e6d 100644
> --- a/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> +++ b/MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Impl.c
> @@ -1,10 +1,10 @@
> /** @file
>Interface routine for Mtftp4.
>
> (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> http://opensource.org/licenses/bsd-license.php
>
> @@ -407,31 +407,33 @@ Mtftp4Start (
>if (EFI_ERROR (Status)) {
> gBS->RestoreTPL (OldTpl);
> return Status;
>}
>
> + if ((Token->OverrideData != NULL) && !Mtftp4OverrideValid (Instance,
> Token->OverrideData)) {
> +Status = EFI_INVALID_PARAMETER;
> +gBS->RestoreTPL (OldTpl);
> +return Status;
> + }
> +
>//
>// Set the Operation now to prevent the application start other
>// operations.
>//
>Instance->Operation = Operation;
>Override= Token->OverrideData;
>
> - if ((Override != NULL) && !Mtftp4OverrideValid (Instance, Override)) {
> -Status = EFI_INVALID_PARAMETER;
> -goto ON_ERROR;
> - }
> -
>if (Token->OptionCount != 0) {
> Status = Mtftp4ParseOption (
> Token->OptionList,
> Token->OptionCount,
> TRUE,
> >RequestOption
> );
>
> if (EFI_ERROR (Status)) {
> + Status = EFI_DEVICE_ERROR;
>goto ON_ERROR;
> }
>}
>
>//
> @@ -482,10 +484,11 @@ Mtftp4Start (
>// Config the unicast UDP child to send initial request
>//
>Status = Mtftp4ConfigUnicastPort (Instance->UnicastPort, Instance);
>
>if (EFI_ERROR (Status)) {
> +Status = EFI_DEVICE_ERROR;
> goto ON_ERROR;
>}
>
>//
>// Set initial status.
> @@ -499,17 +502,17 @@ Mtftp4Start (
> Status = Mtftp4WrqStart (Instance, Operation);
>} else {
> Status = Mtftp4RrqStart (Instance, Operation);
>}
>
> - gBS->RestoreTPL (OldTpl);
> -
>if (EFI_ERROR (Status)) {
> +Status = EFI_DEVICE_ERROR;
> goto ON_ERROR;
>}
>
>if (Token->Event != NULL) {
> +gBS->RestoreTPL (OldTpl);
> return EFI_SUCCESS;
>}
>
>//
>// Return immediately for asynchronous operation or poll the
> @@ -517,10 +520,11 @@ Mtftp4Start (
>//
>while (Token->Status == EFI_NOT_READY) {
> This->Poll (This);
>}
>
> + gBS->RestoreTPL (OldTpl);
>return Token->Status;
>
> ON_ERROR:
>Mtftp4CleanOperation (Instance, Status);
>gBS->RestoreTPL (OldTpl);
> --
> 1.9.5.msysgit.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 3/3] MdeModulePkg/DxeNetLib: Fix an error in packet length counting.
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com> > -Original Message- > From: Wang, Fan > Sent: Wednesday, January 3, 2018 10:32 AM > To: edk2-devel@lists.01.org > Cc: Wang, Fan <fan.w...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, > Ting <ting...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com> > Subject: [Patch 3/3] MdeModulePkg/DxeNetLib: Fix an error in packet length > counting. > > From: Wang Fan <fan.w...@intel.com> > > * In old implementation, the operation len-- assumes AsciiSPrint() > has counted NULL terminator, and it's not correct. This patch is > to fix this issue. > > Cc: Fu Siyuan <siyuan...@intel.com> > Cc: Ye Ting <ting...@intel.com> > Cc: Jiaxin Wu <jiaxin...@intel.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Wang Fan <fan.w...@intel.com> > --- > MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > index 90f17b7..cbce28f 100644 > --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > @@ -401,22 +401,21 @@ SyslogBuildPacket ( > Time.Day, > Time.Hour, > Time.Minute, > Time.Second > ); > - Len--; > >Len += (UINT32) AsciiSPrint ( > Buf + Len, > BufLen - Len, > "Tiano %a: %a (Line: %d File: %a)", > Module, > Message, > Line, > File > ); > - Len--; > + Len ++; > >// >// OK, patch the IP length/checksum and UDP length fields. >// >Len += sizeof (EFI_UDP_HEADER); > -- > 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 1/3] MdeModulePkg/DxeNetLib: Fix a potential issue in macro definition.
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com> > -Original Message- > From: Wang, Fan > Sent: Wednesday, January 3, 2018 10:32 AM > To: edk2-devel@lists.01.org > Cc: Wang, Fan <fan.w...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, > Ting <ting...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com> > Subject: [Patch 1/3] MdeModulePkg/DxeNetLib: Fix a potential issue in > macro definition. > > From: Wang Fan <fan.w...@intel.com> > > The NIC_ITEM_CONFIG_SIZE macro in DxeNetLib is defined as: > sizeof (NIC_IP4_CONFIG_INFO) + sizeof (EFI_IP4_ROUTE_TABLE) * > MAX_IP4_CONFIG_IN_VARIABLE. This macro should be surrounded > with parenthesis to avoid being incorrectly used. > > Cc: Fu Siyuan <siyuan...@intel.com> > Cc: Ye Ting <ting...@intel.com> > Cc: Jiaxin Wu <jiaxin...@intel.com> > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Wang Fan <fan.w...@intel.com> > --- > MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > index 26a80a7..0f00f79 100644 > --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c > @@ -36,11 +36,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF > ANY KIND, EITHER EXPRESS OR IMPLIED. > #include > #include > #include > #include > > -#define NIC_ITEM_CONFIG_SIZE sizeof (NIC_IP4_CONFIG_INFO) + sizeof > (EFI_IP4_ROUTE_TABLE) * MAX_IP4_CONFIG_IN_VARIABLE > +#define NIC_ITEM_CONFIG_SIZE (sizeof (NIC_IP4_CONFIG_INFO) + sizeof > (EFI_IP4_ROUTE_TABLE) * MAX_IP4_CONFIG_IN_VARIABLE) > #define DEFAULT_ZERO_START ((UINTN) ~0) > > // > // All the supported IP4 maskes in host byte order. > // > -- > 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 2/3] MdeModulePkg/DxeNetLib: Add parameter check and ASSERT handling.
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: Wang, Fan
> Sent: Wednesday, January 3, 2018 10:32 AM
> To: edk2-devel@lists.01.org
> Cc: Wang, Fan <fan.w...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye,
> Ting <ting...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>
> Subject: [Patch 2/3] MdeModulePkg/DxeNetLib: Add parameter check and
> ASSERT handling.
>
> From: Wang Fan <fan.w...@intel.com>
>
> * Library API should check the input parameters before use, or
> ASSERT to tell it has to meet some requirements. But in DxeNetLib,
> not all functions follows this rule.
> * ASSERT shouldn't be used as error handling, add some handling code
> for errors.
> * Add some ASSERT commence in function notes.
>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 119
> +
> 1 file changed, 105 insertions(+), 14 deletions(-)
>
> diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> index 0f00f79..90f17b7 100644
> --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> @@ -1,9 +1,9 @@
> /** @file
>Network library.
>
> -Copyright (c) 2005 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> http://opensource.org/licenses/bsd-license.php
> @@ -196,10 +196,11 @@ SyslogLocateSnp (
>Transmit a syslog packet synchronously through SNP. The Packet
>already has the ethernet header prepended. This function should
>fill in the source MAC because it will try to locate a SNP each
>time it is called to avoid the problem if SNP is unloaded.
>This code snip is copied from MNP.
> + If Packet is NULL, then ASSERT().
>
>@param[in] Packet The Syslog packet
>@param[in] Length The length of the packet
>
>@retval EFI_DEVICE_ERROR Failed to locate a usable SNP protocol
> @@ -217,10 +218,12 @@ SyslogSendPacket (
>ETHER_HEAD *Ether;
>EFI_STATUS Status;
>EFI_EVENT TimeoutEvent;
>UINT8 *TxBuf;
>
> + ASSERT (Packet != NULL);
> +
>Snp = SyslogLocateSnp ();
>
>if (Snp == NULL) {
> return EFI_DEVICE_ERROR;
>}
> @@ -308,11 +311,11 @@ ON_EXIT:
>@param[in] Line The line of code in the File that contains the
> current log
>@param[in] Message The log message
>@param[in] BufLenThe lenght of the Buf
>@param[out] Buf The buffer to put the packet data
>
> - @return The length of the syslog packet built.
> + @return The length of the syslog packet built, 0 represents no packet is
> built.
>
> **/
> UINT32
> SyslogBuildPacket (
>IN UINT32Level,
> @@ -322,10 +325,11 @@ SyslogBuildPacket (
>IN UINT8 *Message,
>IN UINT32BufLen,
>OUT CHAR8 *Buf
>)
> {
> + EFI_STATUSStatus;
>ETHER_HEAD*Ether;
>IP4_HEAD *Ip4;
>EFI_UDP_HEADER*Udp4;
>EFI_TIME Time;
>UINT32Pri;
> @@ -377,12 +381,14 @@ SyslogBuildPacket (
>
>//
>// Build the syslog message body with Timestamp machine module
> Message
>//
>Pri = ((NET_SYSLOG_FACILITY & 31) << 3) | (Level & 7);
> - gRT->GetTime (, NULL);
> - ASSERT ((Time.Month <= 12) && (Time.Month >= 1));
> + Status = gRT->GetTime (, NULL);
> + if (EFI_ERROR (Status)) {
> +return 0;
> + }
>
>//
>// Use %a to format the ASCII strings, %s to format UNICODE strings
>//
>Len = 0;
> @@ -437,10 +443,12 @@ SyslogBuildPacket (
> __FILE__,
> __LINE__,
> NetDebugASPrint ("State transit to %a\n", Name)
> )
>
> + If Format is NULL, then ASSERT().
> +
>@param Format The ASCII format string.
>@param ... The variable length parameter whose format is
Re: [edk2] [Patch 0/5] Refine PXE driver code logic
Series Reviewed-by: Jiaxin Wu <jiaxin...@intel.com> > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu > Siyuan > Sent: Tuesday, January 2, 2018 1:28 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch 0/5] Refine PXE driver code logic > > See each patch file for details. > > Fu Siyuan (5): > NetworkPkg: Abort the PXE process if DHCP has been started by other > instance. > NetworkPkg: Check allocated buffer pointer before use. > NetworkPkg: Fix memory leak problem in PXE driver. > NetworkPkg: Add assert for buffer pointer from DHCP driver. > NetworkPkg: Update PXE driver to check for NULL pointer before use it. > > NetworkPkg/UefiPxeBcDxe/PxeBcDhcp4.c | 13 ++--- > NetworkPkg/UefiPxeBcDxe/PxeBcDhcp6.c | 32 > +--- > NetworkPkg/UefiPxeBcDxe/PxeBcDriver.c | 5 - > NetworkPkg/UefiPxeBcDxe/PxeBcImpl.c | 20 > 4 files changed, 43 insertions(+), 27 deletions(-) > > -- > 2.13.0.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] [Patch] MdeModulePkg: Add error handling when IP address is Class E
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
Please update the copyright before commit the patch.
Thanks,
Jiaxin
> -Original Message-
> From: Wang, Fan
> Sent: Tuesday, January 2, 2018 10:45 AM
> To: edk2-devel@lists.01.org
> Cc: Wang, Fan <fan.w...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>; Ye,
> Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>
> Subject: [Patch] [Patch] MdeModulePkg: Add error handling when IP
> address is Class E
>
> From: Wang Fan <fan.w...@intel.com>
>
> The Dhcp4.TransmitReceive() API should be able to use at any time according
> to UEFI spec. While in classless addressing network, the netmask must be
> explicitly provided together with the station address.
> But if the DHCP instance haven't be configured with a valid netmask, we
> need
> compute it according to the classful addressing rule. In such case, if the
> user configures with class E IP address, ASSERT will happen, we need to
> handle
> this case and return error status code.
>
> Cc: Jiaxin Wu <jiaxin...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Fu Siyuan <siyuan...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan <fan.w...@intel.com>
> ---
> MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c | 13
> +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> index aad6674..b95aede 100644
> --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c
> @@ -1184,12 +1184,14 @@ EfiDhcp4Build (
>Callback by UdpIoCreatePort() when creating UdpIo for this Dhcp4 instance.
>
>@param[in] UdpIo The UdpIo being created.
>@param[in] ContextDhcp4 instance.
>
> - @retval EFI_SUCCESS UdpIo is configured successfully.
> - @retval other Other error occurs.
> + @retval EFI_SUCCESS UdpIo is configured successfully.
> + @retval EFI_INVALID_PARAMETERClass E IP address is not supported or
> other parameters
> + are not valid.
> + @retval otherOther error occurs.
> **/
> EFI_STATUS
> EFIAPI
> Dhcp4InstanceConfigUdpIo (
>IN UDP_IO *UdpIo,
> @@ -1227,11 +1229,18 @@ Dhcp4InstanceConfigUdpIo (
> // provided together with the station address.
> // If the DHCP instance haven't be configured with a valid netmask, we
> could only
> // compute it according to the classful addressing rule.
> //
> Class = NetGetIpClass (ClientAddr);
> +//
> +// Class E IP address is not supported here!
> +//
> ASSERT (Class < IP4_ADDR_CLASSE);
> +if (Class >= IP4_ADDR_CLASSE) {
> + return EFI_INVALID_PARAMETER;
> +}
> +
> SubnetMask = gIp4AllMasks[Class << 3];
>} else {
> SubnetMask = DhcpSb->Netmask;
>}
>
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 2/4] NetworkPkg: Convert source file to DOS format
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Liming Gao
> Sent: Wednesday, December 27, 2017 11:23 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Jiaxin <jiaxin...@intel.com>
> Subject: [edk2] [Patch 2/4] NetworkPkg: Convert source file to DOS format
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao <liming@intel.com>
> Cc: Wu Jiaxin <jiaxin...@intel.com>
> ---
> NetworkPkg/HttpDxe/HttpProto.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> b/NetworkPkg/HttpDxe/HttpProto.c
> index 925281a9c0..d7fe271168 100644
> --- a/NetworkPkg/HttpDxe/HttpProto.c
> +++ b/NetworkPkg/HttpDxe/HttpProto.c
> @@ -867,7 +867,7 @@ HttpCleanProtocol (
>if (HttpInstance->TlsSb != NULL && HttpInstance->TlsChildHandle != NULL) {
> //
> // Destroy the TLS instance.
> -//
> +//
> HttpInstance->TlsSb->DestroyChild (HttpInstance->TlsSb, HttpInstance-
> >TlsChildHandle);
>}
>
> --
> 2.11.0.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 3/3] NetworkPkg/TcpDxe: Check TCP payload for release version.
After talked with Siyuan, we agree to use the int 0-1 value instead of Boolean
type so as to keep the same coding style in TcpInput.c.
Thanks,
Jiaxin
> -Original Message-
> From: Fu, Siyuan
> Sent: Wednesday, December 27, 2017 11:03 AM
> To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; Wang, Fan <fan.w...@intel.com>
> Subject: RE: [Patch 3/3] NetworkPkg/TcpDxe: Check TCP payload for release
> version.
>
> Hi, Jiaxin
>
> I think it's better to return a Boolean type than int 0-1 value in
> TcpTrimSegment().
> Other part of good to me.
>
>
> Reviewed-by: Fu Siyuan <siyuan...@intel.com>
>
>
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Tuesday, December 26, 2017 2:50 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wang,
> > Fan <fan.w...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com>
> > Subject: [Patch 3/3] NetworkPkg/TcpDxe: Check TCP payload for release
> > version.
> >
> > TCP payload check is implemented by TcpVerifySegment(), but all the
> > function
> > calls of TcpVerifySegment() are placed in ASSERT(), which is only valid
> > for
> > debug version:
> > ASSERT (TcpVerifySegment (Nbuf) != 0);
> >
> > This patch is to enable the check for release version.
> >
> > Cc: Ye Ting <ting...@intel.com>
> > Cc: Fu Siyuan <siyuan...@intel.com>
> > Cc: Wang Fan <fan.w...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com>
> > ---
> > NetworkPkg/TcpDxe/TcpInput.c | 125
> +
> > -
> > NetworkPkg/TcpDxe/TcpOutput.c | 29 +++---
> > 2 files changed, 122 insertions(+), 32 deletions(-)
> >
> > diff --git a/NetworkPkg/TcpDxe/TcpInput.c
> b/NetworkPkg/TcpDxe/TcpInput.c
> > index f8845dc..92a0ab8 100644
> > --- a/NetworkPkg/TcpDxe/TcpInput.c
> > +++ b/NetworkPkg/TcpDxe/TcpInput.c
> > @@ -279,12 +279,15 @@ TcpComputeRtt (
> >
> >@param[in] Nbuf The buffer that contains a received TCP segment
> > without an IP header.
> >@param[in] Left The sequence number of the window's left edge.
> >@param[in] RightThe sequence number of the window's right edge.
> >
> > + @retval 0The segment is broken.
> > + @retval 1The segment is in good shape.
> > +
> > **/
> > -VOID
> > +INTN
> > TcpTrimSegment (
> >IN NET_BUF *Nbuf,
> >IN TCP_SEQNO Left,
> >IN TCP_SEQNO Right
> >)
> > @@ -304,11 +307,11 @@ TcpTrimSegment (
> > TCP_CLEAR_FLG (Seg->Flag, TCP_FLG_SYN);
> > TCP_CLEAR_FLG (Seg->Flag, TCP_FLG_FIN);
> >
> > Seg->Seq = Seg->End;
> > NetbufTrim (Nbuf, Nbuf->TotalSize, NET_BUF_HEAD);
> > -return;
> > +return 1;
> >}
> >
> >//
> >// Adjust the buffer header
> >//
> > @@ -357,27 +360,30 @@ TcpTrimSegment (
> > if (Drop != 0) {
> >NetbufTrim (Nbuf, Drop, NET_BUF_TAIL);
> > }
> >}
> >
> > - ASSERT (TcpVerifySegment (Nbuf) != 0);
> > + return TcpVerifySegment (Nbuf);
> > }
> >
> > /**
> >Trim off the data outside the tcb's receive window.
> >
> >@param[in] Tcb Pointer to the TCP_CB of this TCP instance.
> >@param[in] Nbuf Pointer to the NET_BUF containing the received tcp
> > segment.
> >
> > + @retval 0The segment is broken.
> > + @retval 1The segment is in good shape.
> > +
> > **/
> > -VOID
> > +INTN
> > TcpTrimInWnd (
> >IN TCP_CB *Tcb,
> >IN NET_BUF *Nbuf
> >)
> > {
> > - TcpTrimSegment (Nbuf, Tcb->RcvNxt, Tcb->RcvWl2 + Tcb->RcvWnd);
> > + return TcpTrimSegment (Nbuf, Tcb->RcvNxt, Tcb->RcvWl2 + Tcb-
> >RcvWnd);
> > }
> >
> > /**
> >Process the data and FIN flag, and check whether to deliver
> >data to the socket layer.
> > @@ -419,11 +425,20 @@ TcpDeliverData (
> >
> >while (Entry != >RcvQue) {
> > Nbuf = NET_LIST_USER_STRUCT (Entry, NET_BUF, List);
> > Seg = TCPSEG_NETBUF (Nbuf);
> >
> > -ASSERT (TcpVerifySegment (Nbuf) != 0);
> > +if (TcpVerifySegment (Nbuf) == 0) {
> > + DEBUG (
> > +(EFI_D_ERROR,
> >
Re: [edk2] [Patch] NetworkPkg/IScsiDxe: Correct the DnsMode value according the target info.
Thanks, Siyuan I will refine the commit log before apply the patch.
> -Original Message-
> From: Fu, Siyuan
> Sent: Wednesday, December 27, 2017 11:01 AM
> To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; Karunakar P <karunak...@amiindia.co.in>
> Subject: RE: [Patch] NetworkPkg/IScsiDxe: Correct the DnsMode value
> according the target info.
>
> Reviewed-by: Fu Siyuan <siyuan...@intel.com>
> Please provide more information in the commit log.
>
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Monday, December 25, 2017 1:30 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>;
> > Karunakar P <karunak...@amiindia.co.in>; Wu, Jiaxin
> <jiaxin...@intel.com>
> > Subject: [Patch] NetworkPkg/IScsiDxe: Correct the DnsMode value
> according
> > the target info.
> >
> > This patch is to resolve the issue recorded @
> > https://bugzilla.tianocore.org/show_bug.cgi?id=823.
> >
> > Cc: Ye Ting <ting...@intel.com>
> > Cc: Fu Siyuan <siyuan...@intel.com>
> > Cc: Karunakar P <karunak...@amiindia.co.in>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com>
> > Tested-by: Karunakar P <karunak...@amiindia.co.in>
> > ---
> > NetworkPkg/IScsiDxe/IScsiDhcp.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/NetworkPkg/IScsiDxe/IScsiDhcp.c
> > b/NetworkPkg/IScsiDxe/IScsiDhcp.c
> > index e6f6972..e343523 100644
> > --- a/NetworkPkg/IScsiDxe/IScsiDhcp.c
> > +++ b/NetworkPkg/IScsiDxe/IScsiDhcp.c
> > @@ -132,10 +132,11 @@ IScsiDhcpExtractRootPath (
> >return EFI_INVALID_PARAMETER;
> > }
> > CopyMem (>TargetUrl, Field->Str, Field->Len);
> > ConfigNvData->TargetUrl[Field->Len + 1] = '\0';
> >} else {
> > +ConfigNvData->DnsMode = FALSE;
> > ZeroMem(ConfigNvData->TargetUrl, sizeof (ConfigNvData->TargetUrl));
> > Status = IScsiAsciiStrToIp (Field->Str, IpMode, );
> > CopyMem (>TargetIp, , sizeof (EFI_IP_ADDRESS));
> >
> > if (EFI_ERROR (Status)) {
> > --
> > 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 1/5] MdeModulePkg/DxeHttpLib: Add boundary condition check.
Thanks to catch that.
Best Regards!
Jiaxin
> -Original Message-
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Tuesday, December 26, 2017 9:56 AM
> To: Wu, Jiaxin <jiaxin...@intel.com>
> Cc: edk2-devel@lists.01.org; Ye, Ting <ting...@intel.com>; Wang, Fan
> <fan.w...@intel.com>; Fu, Siyuan <siyuan...@intel.com>
> Subject: Re: [edk2] [Patch 1/5] MdeModulePkg/DxeHttpLib: Add boundary
> condition check.
>
> On Tue, Dec 26, 2017 at 09:33:45AM +0800, Jiaxin Wu wrote:
> > This patch is to add the boundary condition check to make sure
> > the accessed buffer is valid.
> >
> > Cc: Ye Ting <ting...@intel.com>
> > Cc: Fu Siyuan <siyuan...@intel.com>
> > Cc: Wang Fan <fan.w...@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Wu Jiaxin <jiaxin...@intel.com>
> > ---
> > MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 39
>
> > 1 file changed, 34 insertions(+), 5 deletions(-)
> >
> > diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> > index caddbb7..4d353d7 100644
> > --- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> > +++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
> > @@ -33,11 +33,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> >@retval EFI_SUCCESSSuccessfully decoded the URI.
> >@retval EFI_INVALID_PARAMETER Buffer is not a valid percent-encoded
> string.
> >
> > **/
> > EFI_STATUS
> > -EFIAPI
> > UriPercentDecode (
> >IN CHAR8*Buffer,
> >IN UINT32BufferLength,
> > OUT CHAR8*ResultBuffer,
> > OUT UINT32 *ResultLength
> This change will break gcc build since EFIAPI is still declared in
> HttpLib.h.
>
> Gary Lin
>
> > @@ -54,11 +53,11 @@ UriPercentDecode (
> >Index = 0;
> >Offset = 0;
> >HexStr[2] = '\0';
> >while (Index < BufferLength) {
> > if (Buffer[Index] == '%') {
> > - if (!NET_IS_HEX_CHAR (Buffer[Index+1]) || !NET_IS_HEX_CHAR
> (Buffer[Index+2])) {
> > + if (Index + 1 >= BufferLength || Index + 2 >= BufferLength
> || !NET_IS_HEX_CHAR (Buffer[Index+1]) || !NET_IS_HEX_CHAR
> (Buffer[Index+2])) {
> > return EFI_INVALID_PARAMETER;
> >}
> >HexStr[0] = Buffer[Index+1];
> >HexStr[1] = Buffer[Index+2];
> >ResultBuffer[Offset] = (CHAR8) AsciiStrHexToUintn (HexStr);
> > @@ -1556,20 +1555,31 @@ HttpGetFieldNameAndValue (
> >)
> > {
> >CHAR8 *FieldNameStr;
> >CHAR8 *FieldValueStr;
> >CHAR8 *StrPtr;
> > + CHAR8 *EndofHeader;
> >
> >if (String == NULL || FieldName == NULL || FieldValue == NULL) {
> > return NULL;
> >}
> >
> >*FieldName= NULL;
> >*FieldValue = NULL;
> >FieldNameStr = NULL;
> >FieldValueStr = NULL;
> >StrPtr= NULL;
> > + EndofHeader = NULL;
> > +
> > +
> > + //
> > + // Check whether the raw HTTP header string is valid or not.
> > + //
> > + EndofHeader = AsciiStrStr (String, "\r\n\r\n");
> > + if (EndofHeader == NULL) {
> > +return NULL;
> > + }
> >
> >//
> >// Each header field consists of a name followed by a colon (":") and the
> field value.
> >//
> >FieldNameStr = String;
> > @@ -1583,17 +1593,36 @@ HttpGetFieldNameAndValue (
> >//
> >*(FieldValueStr - 1) = 0;
> >
> >//
> >// The field value MAY be preceded by any amount of LWS, though a
> single SP is preferred.
> > + // Note: LWS = [CRLF] 1*(SP|HT), it can be '\r\n ' or '\r\n\t' or ' '
> > or '\t'.
> > + // CRLF = '\r\n'.
> > + // SP = ' '.
> > + // HT = '\t' (Tab).
> >//
> >while (TRUE) {
> > if (*FieldValueStr == ' ' || *FieldValueStr == '\t') {
> > + //
> > + // Boundary condition check.
> > + //
> > + if ((UINTN)EndofHeader - (UINTN)(FieldValueStr) < 1) {
> > +return NULL;
> > + }
> > +
> >FieldValueStr ++;
> > -} else if (*FieldValueStr == '\r' && *(FieldValueStr + 1) == '\n' &&
> > - (*(FieldValueStr + 2) == ' ' || *(FieldValueStr + 2) ==
> > '\t')) {
> > - FieldValueStr = FieldValueStr + 3;
> > +} else if (*Field
Re: [edk2] [Patch] NetworkPkg: Recycle the ICMP error message in PXE driver.
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu,
> Siyuan
> Sent: Thursday, December 21, 2017 3:46 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting <ting...@intel.com>; Wang, Fan <fan.w...@intel.com>; Wu,
> Jiaxin <jiaxin...@intel.com>
> Subject: [edk2] [Patch] NetworkPkg: Recycle the ICMP error message in PXE
> driver.
>
> This patch updates PxeBcIcmpErrorDpcHandle() and
> PxeBcIcmp6ErrorDpcHandle() to
> recycle the ICMP packet after copy it to PXE mode data.
>
> Cc: Ye Ting <ting...@intel.com>
> Cc: Wu Jiaxin <jiaxin...@intel.com>
> Cc: Wang Fan <fan.w...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan <siyuan...@intel.com>
> ---
> NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c | 36 +++-
> --
> 1 file changed, 16 insertions(+), 20 deletions(-)
>
> diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
> b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
> index dfc79a067b..1e77929364 100644
> --- a/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
> +++ b/NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c
> @@ -257,8 +257,7 @@ PxeBcIcmpErrorDpcHandle (
> //
> // The return status should be recognized as EFI_ICMP_ERROR.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>if (EFI_IP4 (RxData->Header->SourceAddress) != 0 &&
> @@ -268,24 +267,21 @@ PxeBcIcmpErrorDpcHandle (
> //
> // The source address of the received packet should be a valid unicast
> address.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>if (!EFI_IP4_EQUAL (>Header->DestinationAddress,
> >StationIp.v4)) {
> //
> // The destination address of the received packet should be equal to the
> host address.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>if (RxData->Header->Protocol != EFI_IP_PROTO_ICMP) {
> //
> // The protocol value in the header of the receveid packet should be
> EFI_IP_PROTO_ICMP.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>Type = *((UINT8 *) RxData->FragmentTable[0].FragmentBuffer);
> @@ -298,8 +294,7 @@ PxeBcIcmpErrorDpcHandle (
> //
> // The type of the receveid ICMP message should be
> ICMP_ERROR_MESSAGE.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>//
> @@ -326,6 +321,9 @@ PxeBcIcmpErrorDpcHandle (
> IcmpError += CopiedLen;
>}
>
> +ON_RECYCLE:
> + gBS->SignalEvent (RxData->RecycleSignal);
> +
> ON_EXIT:
>Private->IcmpToken.Status = EFI_NOT_READY;
>Ip4->Receive (Ip4, >IcmpToken);
> @@ -395,16 +393,14 @@ PxeBcIcmp6ErrorDpcHandle (
> //
> // The return status should be recognized as EFI_ICMP_ERROR.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>if (!NetIp6IsValidUnicast (>Header->SourceAddress)) {
> //
> // The source address of the received packet should be a valid unicast
> address.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>if (!NetIp6IsUnspecifiedAddr (>StationIp.v6) &&
> @@ -412,16 +408,14 @@ PxeBcIcmp6ErrorDpcHandle (
> //
> // The destination address of the received packet should be equal to the
> host address.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>if (RxData->Header->NextHeader != IP6_ICMP) {
> //
> // The nextheader in the header of the receveid packet should be
> IP6_ICMP.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>Type = *((UINT8 *) RxData->FragmentTable[0].FragmentBuffer);
> @@ -433,8 +427,7 @@ PxeBcIcmp6ErrorDpcHandle (
> //
> // The type of the receveid packet should be an ICMP6 error message.
> //
> -gBS->SignalEvent (RxData->RecycleSignal);
> -goto ON_EXIT;
> +goto ON_RECYCLE;
>}
>
>//
> @@ -461,6 +454,9 @@ PxeBcIcmp6ErrorDpcHandle (
> Icmp6Error += CopiedLen;
>}
>
> +ON_RECYCLE:
> + gBS->SignalEvent (RxData->RecycleSignal);
> +
> ON_EXIT:
>Private->Icmp6Token.Status = EFI_NOT_READY;
>Ip6->Receive (Ip6, >Icmp6Token);
> --
> 2.13.0.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
