Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
On 01/18/19 12:09, Ard Biesheuvel wrote:
> On Fri, 18 Jan 2019 at 06:38, Gao, Liming wrote:
>>
>> 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
Laszlo
>
>
>>> -Original Message-
>>> From: Wu, Jiaxin
>>> Sent: Friday, January 18, 2019 1:32 PM
>>> To: Fu, Siyuan ; Wu, Hao A ;
>>> edk2-devel@lists.01.org
>>> Cc: Ye, Ting ; Gao, Liming
>>> Subject: RE: [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
Re: [edk2] Unable to boot Linux with master EDK2
On Fri, 18 Jan 2019 at 19:39, Ard Biesheuvel wrote: > > On Fri, 18 Jan 2019 at 19:30, Julien Grall wrote: > > > > Hi all, > > > > I am trying to boot a Xen guest using the latest EDK2 master (cce9d76358 > > "BaseTools: Allow empty value for HiiPcd in Dsc"), GRUB and Linux 5.0-rc2. > > > > The last code executed by Linux is when installing the virtual address > > map in the EFI stub and then it seems to get stuck. I don't have much > > information from the console: > > > > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7E041040 > > Loading driver at 0x00068C7 EntryPoint=0x00069D65664 > > Loading driver at 0x00068C7 EntryPoint=0x00069D65664 > > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7DF6AB18 > > ProtectUefiImageCommon - 0x7E041040 > > - 0x68C7 - 0x02006000 > > SetUefiImageMemoryAttributes - 0x68C7 - 0x1000 > > (0x4008) > > SetUefiImageMemoryAttributes - 0x68C71000 - 0x011CD000 > > (0x00020008) > > SetUefiImageMemoryAttributes - 0x69E3E000 - 0x00E38000 > > (0x4008) > > EFI stub: Booting Linux Kernel... > > EFI stub: Using DTB from configuration table > > EFI stub: Exiting boot services and installing virtual address map... > > XenBus: Set state to 5 > > XenBus: Set state to 5, done > > XenPvBlk: waiting backend state 5, current: 4 > > XenStore: Watch event 7E957398 > > XenBus: Set state to 6 > > XenBus: Set state to 6, done > > XenPvBlk: waiting backend state 6, current: 5 > > XenStore: Watch event 7E957398 > > XenBus: Set state to 1 > > XenBus: Set state to 1, done > > Xen GrantTable, removing 38003 > > Xen GrantTable, removing 38002 > > Xen GrantTable, removing 38001 > > Xen GrantTable, removing 38000 > > SetUefiImageMemoryAttributes - 0x7F36 - 0x0004 > > (0x0008) > > SetUefiImageMemoryAttributes - 0x7BFF - 0x0004 > > (0x0008) > > SetUefiImageMemoryAttributes - 0x7BFA - 0x0004 > > (0x0008) > > SetUefiImageMemoryAttributes - 0x7BF0 - 0x0004 > > (0x0008) > > SetUefiImageMemoryAttributes - 0x7BE6 - 0x0004 > > (0x0008) > > SetUefiImageMemoryAttributes - 0x7BDC - 0x0004 > > (0x0008) > > > > The bisector pointed to the following commit: > > > > commit 2f4a5a9f4c17ed88aaa3114d1e161e42cb80a9bf > > Author: Dandan Bi > > Date: Thu Jan 3 15:31:23 2019 +0800 > > > > MdePkg/BasePeCoffLib: Add more check for relocation data > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426 > > > > V2: > > (1) Add NULL pointer check for the input parameters > > (2) Add check for the "Adjust" value before applying fix ups. > > > > In function PeCoffLoaderRelocateImageForRuntime, it doesn't > > do much check when do relocation. For API level consideration, > > it's not safe enough. > > So this patch is to replace the same code logic with function > > PeCoffLoaderImageAddress which will cover more validation. > > > > Cc: Michael D Kinney > > Cc: Liming Gao > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Dandan Bi > > Reviewed-by: Liming Gao > > > > Any ideas what could have gone wrong? > > Yes, that patch broke lots of platforms: OVMF, ArmVirtQemu and ARM Juno as well. You need the following patch to fix it https://lists.01.org/pipermail/edk2-devel/2019-January/035372.html ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Unable to boot Linux with master EDK2
On Fri, 18 Jan 2019 at 19:30, Julien Grall wrote: > > Hi all, > > I am trying to boot a Xen guest using the latest EDK2 master (cce9d76358 > "BaseTools: Allow empty value for HiiPcd in Dsc"), GRUB and Linux 5.0-rc2. > > The last code executed by Linux is when installing the virtual address > map in the EFI stub and then it seems to get stuck. I don't have much > information from the console: > > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7E041040 > Loading driver at 0x00068C7 EntryPoint=0x00069D65664 > Loading driver at 0x00068C7 EntryPoint=0x00069D65664 > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7DF6AB18 > ProtectUefiImageCommon - 0x7E041040 > - 0x68C7 - 0x02006000 > SetUefiImageMemoryAttributes - 0x68C7 - 0x1000 > (0x4008) > SetUefiImageMemoryAttributes - 0x68C71000 - 0x011CD000 > (0x00020008) > SetUefiImageMemoryAttributes - 0x69E3E000 - 0x00E38000 > (0x4008) > EFI stub: Booting Linux Kernel... > EFI stub: Using DTB from configuration table > EFI stub: Exiting boot services and installing virtual address map... > XenBus: Set state to 5 > XenBus: Set state to 5, done > XenPvBlk: waiting backend state 5, current: 4 > XenStore: Watch event 7E957398 > XenBus: Set state to 6 > XenBus: Set state to 6, done > XenPvBlk: waiting backend state 6, current: 5 > XenStore: Watch event 7E957398 > XenBus: Set state to 1 > XenBus: Set state to 1, done > Xen GrantTable, removing 38003 > Xen GrantTable, removing 38002 > Xen GrantTable, removing 38001 > Xen GrantTable, removing 38000 > SetUefiImageMemoryAttributes - 0x7F36 - 0x0004 > (0x0008) > SetUefiImageMemoryAttributes - 0x7BFF - 0x0004 > (0x0008) > SetUefiImageMemoryAttributes - 0x7BFA - 0x0004 > (0x0008) > SetUefiImageMemoryAttributes - 0x7BF0 - 0x0004 > (0x0008) > SetUefiImageMemoryAttributes - 0x7BE6 - 0x0004 > (0x0008) > SetUefiImageMemoryAttributes - 0x7BDC - 0x0004 > (0x0008) > > The bisector pointed to the following commit: > > commit 2f4a5a9f4c17ed88aaa3114d1e161e42cb80a9bf > Author: Dandan Bi > Date: Thu Jan 3 15:31:23 2019 +0800 > > MdePkg/BasePeCoffLib: Add more check for relocation data > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426 > > V2: > (1) Add NULL pointer check for the input parameters > (2) Add check for the "Adjust" value before applying fix ups. > > In function PeCoffLoaderRelocateImageForRuntime, it doesn't > do much check when do relocation. For API level consideration, > it's not safe enough. > So this patch is to replace the same code logic with function > PeCoffLoaderImageAddress which will cover more validation. > > Cc: Michael D Kinney > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Dandan Bi > Reviewed-by: Liming Gao > > Any ideas what could have gone wrong? > > Best regards, > > -- > Julien Grall ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Unable to boot Linux with master EDK2
Hi all, I am trying to boot a Xen guest using the latest EDK2 master (cce9d76358 "BaseTools: Allow empty value for HiiPcd in Dsc"), GRUB and Linux 5.0-rc2. The last code executed by Linux is when installing the virtual address map in the EFI stub and then it seems to get stuck. I don't have much information from the console: InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7E041040 Loading driver at 0x00068C7 EntryPoint=0x00069D65664 Loading driver at 0x00068C7 EntryPoint=0x00069D65664 InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7DF6AB18 ProtectUefiImageCommon - 0x7E041040 - 0x68C7 - 0x02006000 SetUefiImageMemoryAttributes - 0x68C7 - 0x1000 (0x4008) SetUefiImageMemoryAttributes - 0x68C71000 - 0x011CD000 (0x00020008) SetUefiImageMemoryAttributes - 0x69E3E000 - 0x00E38000 (0x4008) EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... XenBus: Set state to 5 XenBus: Set state to 5, done XenPvBlk: waiting backend state 5, current: 4 XenStore: Watch event 7E957398 XenBus: Set state to 6 XenBus: Set state to 6, done XenPvBlk: waiting backend state 6, current: 5 XenStore: Watch event 7E957398 XenBus: Set state to 1 XenBus: Set state to 1, done Xen GrantTable, removing 38003 Xen GrantTable, removing 38002 Xen GrantTable, removing 38001 Xen GrantTable, removing 38000 SetUefiImageMemoryAttributes - 0x7F36 - 0x0004 (0x0008) SetUefiImageMemoryAttributes - 0x7BFF - 0x0004 (0x0008) SetUefiImageMemoryAttributes - 0x7BFA - 0x0004 (0x0008) SetUefiImageMemoryAttributes - 0x7BF0 - 0x0004 (0x0008) SetUefiImageMemoryAttributes - 0x7BE6 - 0x0004 (0x0008) SetUefiImageMemoryAttributes - 0x7BDC - 0x0004 (0x0008) The bisector pointed to the following commit: commit 2f4a5a9f4c17ed88aaa3114d1e161e42cb80a9bf Author: Dandan Bi Date: Thu Jan 3 15:31:23 2019 +0800 MdePkg/BasePeCoffLib: Add more check for relocation data REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426 V2: (1) Add NULL pointer check for the input parameters (2) Add check for the "Adjust" value before applying fix ups. In function PeCoffLoaderRelocateImageForRuntime, it doesn't do much check when do relocation. For API level consideration, it's not safe enough. So this patch is to replace the same code logic with function PeCoffLoaderImageAddress which will cover more validation. Cc: Michael D Kinney Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi Reviewed-by: Liming Gao Any ideas what could have gone wrong? Best regards, -- Julien Grall ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
> On Jan 18, 2019, at 9:08 AM, Felix Polyudov wrote:
>
> Mike,
>
> I think EFI_GUID and EFI_STATUS should cover most of the use cases.
>
I think I missed a couple in my original mail
But here are the typedef and #define names that get remapped (or redone) in
MdePkg/Include/Uefi/UefiBaseType.h
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
typedef struct {
UINT8 Addr[4];
} IPv4_ADDRESS;
typedef struct {
UINT8 Addr[16];
} IPv6_ADDRESS;
typedef UINT64 PHYSICAL_ADDRESS;
typedef UINTN RETURN_STATUS;
#define ENCODE_ERROR(StatusCode) ((RETURN_STATUS)(MAX_BIT | (StatusCode)))
#define ENCODE_WARNING(StatusCode) ((RETURN_STATUS)(StatusCode))
#define RETURN_ERROR(StatusCode) (((INTN)(RETURN_STATUS)(StatusCode)) < 0)
#define RETURN_SUCCESS 0
#define RETURN_LOAD_ERRORENCODE_ERROR (1)
#define RETURN_INVALID_PARAMETER ENCODE_ERROR (2)
I think the cleanup would be as simple as moving things from
MdePkg/Include/Uefi/UefiBaseType.h to MdePkg/Include/Base.h.
So:
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
Becomes:
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID, EFI_GUID;
Thanks,
Andrew Fish
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, January 17, 2019 3:04 PM
> To: Felix Polyudov; 'Andrew Fish'; Kinney, Michael D
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] History question about Base.h and its alternate parallel
> name space Should we change it?
>
> Felix,
>
> Is there a specific set that would have the most benefit?
>
> Is EFI_GUID sufficient?
>
> Mike
>
>> -Original Message-
>> From: Felix Polyudov [mailto:fel...@ami.com]
>> Sent: Wednesday, January 16, 2019 3:10 PM
>> To: 'Andrew Fish' ; Kinney, Michael D
>>
>> Cc: edk2-devel@lists.01.org
>> Subject: RE: [edk2] History question about Base.h and
>> its alternate parallel name space Should we change
>> it?
>>
>> I agree with Andrew.
>> In my opinion, moving alias types to Base.h will help to
>> overcome certain practical inconveniences without
>> a significant impact on the ability to detect poorly
>> written Base libraries.
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-
>> boun...@lists.01.org] On Behalf Of Andrew Fish via edk2-
>> devel
>> Sent: Wednesday, January 16, 2019 5:18 PM
>> To: Mike Kinney
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] History question about Base.h and
>> its alternate parallel name space Should we change
>> it?
>>
>>
>>
>>> On Jan 16, 2019, at 1:19 PM, Kinney, Michael D
>> wrote:
>>>
>>> Hi Andrew,
>>>
>>> I though the reason was a bit more technical. We have
>> a
>>> MODULE_TYPE of BASE. Library instances that use the
>> BASE
>>> MODULE_TYPE are declaring that the library interfaces
>> are
>>> safe to be linked against a module of any other type
>> (SEC,
>>> PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP).
>>>
>>> We needed to make sure that a lib of type BASE that
>>> includes Base.h as its top level include file only has
>>> visibility to the types that are safe for all the
>> other
>>> module types. It is up to the top level include files
>>> for these other module types to provide the gasket to
>>> the types in Base.h.
>>>
>>> If we add aliases in Base.h, then we may not get build
>>> breaks when a lib of type BASE includes files that are
>>> not compatible with BASE.
>>>
>>
>> Mike,
>>
>> I don't think having aliases for return types really
>> helps Base code quality as RETURN_SUCCESS is almost
>> always just a comment in a header file, and only exists
>> in a .c file. Thus RETURN_* seem like a needless
>> duplication, best case it is a comment that the code is
>> Base.
>>
>> I will agree that not having EFI_GUID defined does case
>> all the PPI and Protocol files to blow up if you try to
>> include them. The failure case I was helping explain was
>> some one trying to include a PPI, that included a
>> Protocol that contained a data structure that was
>> needed. But I would posit that the definition of a
>> (EFI_)GUID is state agnostic. Having access to a PPI or
>> Protocol definition does not break Base code, what
>> breaks Base code is trying to access some service that
>> does not exist. To get more that EFI_GUID you are going
>> to need to include Uefi.h, PiPei.h, PiDxe.h, etc. and
>> that will block doing anything that is not Base.
>>
>> So I'm asking if redefining the name for EFI_GUID to
>> GUID for Base is really that helpful?
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>>> Thanks,
>>>
>>> Mike
>>>
-Original Message-
From: edk2-devel [mailto:edk2-devel-
boun...@lists.01.org] On Behalf Of Andrew Fish via
>> edk2-
devel
Sent: Wednesday, January 16, 2019 1:00 PM
To: edk2-devel
Subject: [edk2] History question about
Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
Mike, I think EFI_GUID and EFI_STATUS should cover most of the use cases. -Original Message- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Thursday, January 17, 2019 3:04 PM To: Felix Polyudov; 'Andrew Fish'; Kinney, Michael D Cc: edk2-devel@lists.01.org Subject: RE: [edk2] History question about Base.h and its alternate parallel name space Should we change it? Felix, Is there a specific set that would have the most benefit? Is EFI_GUID sufficient? Mike > -Original Message- > From: Felix Polyudov [mailto:fel...@ami.com] > Sent: Wednesday, January 16, 2019 3:10 PM > To: 'Andrew Fish' ; Kinney, Michael D > > Cc: edk2-devel@lists.01.org > Subject: RE: [edk2] History question about Base.h and > its alternate parallel name space Should we change > it? > > I agree with Andrew. > In my opinion, moving alias types to Base.h will help to > overcome certain practical inconveniences without > a significant impact on the ability to detect poorly > written Base libraries. > > -Original Message- > From: edk2-devel [mailto:edk2-devel- > boun...@lists.01.org] On Behalf Of Andrew Fish via edk2- > devel > Sent: Wednesday, January 16, 2019 5:18 PM > To: Mike Kinney > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] History question about Base.h and > its alternate parallel name space Should we change > it? > > > > > On Jan 16, 2019, at 1:19 PM, Kinney, Michael D > wrote: > > > > Hi Andrew, > > > > I though the reason was a bit more technical. We have > a > > MODULE_TYPE of BASE. Library instances that use the > BASE > > MODULE_TYPE are declaring that the library interfaces > are > > safe to be linked against a module of any other type > (SEC, > > PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP). > > > > We needed to make sure that a lib of type BASE that > > includes Base.h as its top level include file only has > > visibility to the types that are safe for all the > other > > module types. It is up to the top level include files > > for these other module types to provide the gasket to > > the types in Base.h. > > > > If we add aliases in Base.h, then we may not get build > > breaks when a lib of type BASE includes files that are > > not compatible with BASE. > > > > Mike, > > I don't think having aliases for return types really > helps Base code quality as RETURN_SUCCESS is almost > always just a comment in a header file, and only exists > in a .c file. Thus RETURN_* seem like a needless > duplication, best case it is a comment that the code is > Base. > > I will agree that not having EFI_GUID defined does case > all the PPI and Protocol files to blow up if you try to > include them. The failure case I was helping explain was > some one trying to include a PPI, that included a > Protocol that contained a data structure that was > needed. But I would posit that the definition of a > (EFI_)GUID is state agnostic. Having access to a PPI or > Protocol definition does not break Base code, what > breaks Base code is trying to access some service that > does not exist. To get more that EFI_GUID you are going > to need to include Uefi.h, PiPei.h, PiDxe.h, etc. and > that will block doing anything that is not Base. > > So I'm asking if redefining the name for EFI_GUID to > GUID for Base is really that helpful? > > Thanks, > > Andrew Fish > > > > Thanks, > > > > Mike > > > >> -Original Message- > >> From: edk2-devel [mailto:edk2-devel- > >> boun...@lists.01.org] On Behalf Of Andrew Fish via > edk2- > >> devel > >> Sent: Wednesday, January 16, 2019 1:00 PM > >> To: edk2-devel > >> Subject: [edk2] History question about Base.h and its > >> alternate parallel name space Should we change > it? > >> > >> I had some one ask me recently why EFI_GUID does not > >> work with #include . I explained they needed > to > >> use GUID vs. EFI_GUID. That prompted the question of > why > >> we have 2 names for the same thing. Well the > >> historical answer was kind of political as some team > >> wanted to use edk2, but not implement EFI. Thus we > have > >> EFI types without the EFI_ prefix in Base.h. > >> > >> So all this got me thinking Maybe it makes sense > to > >> move some of the renaming from > >> MdePkg/Include/Uefi/UefiBaseType.h to Base.h? > Removing > >> the Base.h duplicate types would potentially hit lots > of > >> code [1] and break merges with other code bases > (break > >> other peoples Base libs etc.). > >> > >> These lines in MdePkg/Include/Uefi/UefiBaseType.h > would > >> get moved to MdePkg/Include/Base.h: > >> typedef GUID EFI_GUID; > >> typedef RETURN_STATUS EFI_STATUS; > >> #define EFIERR(_a)ENCODE_ERROR(_a) > >> #define EFI_ERROR(A) RETURN_ERROR(A) > >> > >> #define EFI_SUCCESS RETURN_SUCCESS > >> #define EFI_LOAD_ERRORRETURN_LOAD_ERROR > >> #define EFI_INVALID_PARAMETER > >> RETURN_INVALID_PARAMETER > >> #define EFI_UNSUPPORTED
Re: [edk2] [PATCH v2 11/11] StandaloneMmPkg/Core: permit encapsulated firmware volumes
Add Mike Kinney.
Hi Mike
Do you have any suggestion on how to implement this in a self-contained
environment for gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress?
STATIC UINT64 mExtractGuidedSectionHandlerInfo[64];
PcdSet64 (PcdGuidedExtractHandlerTableAddress,
(UINT64)mExtractGuidedSectionHandlerInfo);
Maybe, we can consider below from secure coding perspective.
1) Define a MACRO for 64.
2) Add a check (somewhere) to see if there is overflow on 64, then stop and
report error.
Thank you
Yao Jiewen
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 18, 2019 7:42 AM
> To: Yao, Jiewen
> Cc: edk2-devel@lists.01.org; Achin Gupta ;
> Supreeth Venkatesh ; Leif Lindholm
> ; Jagadeesh Ujja ;
> Thomas Panakamattam Abraham ; Sami
> Mujawar
> Subject: Re: [PATCH v2 11/11] StandaloneMmPkg/Core: permit encapsulated
> firmware volumes
>
> On Fri, 18 Jan 2019 at 16:40, Yao, Jiewen wrote:
> >
> > The idea seems good.
> >
> > May I know if there is any restriction on 64 handlers?
> >
> > +STATIC UINT64 mExtractGuidedSectionHandlerInfo[64];
> >
> > If a system is configured with more handlers, what is expected behavior?
> >
>
> Good question. I wasn't really sure how to implement this. For any
> given platform configuration, I don't think you will ever need more
> than one handler, unless you are encapsulating a compressed FV inside
> a signed FV perhaps?
>
> Do you have any suggestions how to improve this code?
>
> >
> > > -Original Message-
> > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > Sent: Wednesday, January 16, 2019 12:23 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Ard Biesheuvel ; Achin Gupta
> > > ; Yao, Jiewen ;
> Supreeth
> > > Venkatesh ; Leif Lindholm
> > > ; Jagadeesh Ujja ;
> > > Thomas Panakamattam Abraham ; Sami
> > > Mujawar
> > > Subject: [PATCH v2 11/11] StandaloneMmPkg/Core: permit encapsulated
> > > firmware volumes
> > >
> > > Standalone MM requires 4 KB section alignment for all images, so that
> > > strict permissions can be applied. Unfortunately, this results in a
> > > lot of wasted space, which is usually costly in the secure world
> > > environment that standalone MM is expected to operate in.
> > >
> > > So let's permit the standalone MM drivers (but not the core) to be
> > > delivered in a compressed firmware volume.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel
> > > ---
> > > StandaloneMmPkg/Core/FwVol.c
> > > | 99 ++--
> > > StandaloneMmPkg/Core/StandaloneMmCore.inf
> > > | 1 +
> > >
> > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standal
> > > oneMmCoreEntryPoint.c | 5 +
> > >
> > >
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCo
> > > reEntryPoint.inf | 3 +
> > > 4 files changed, 99 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/StandaloneMmPkg/Core/FwVol.c
> > > b/StandaloneMmPkg/Core/FwVol.c
> > > index 5abf98c24797..8eb827dda5c4 100644
> > > --- a/StandaloneMmPkg/Core/FwVol.c
> > > +++ b/StandaloneMmPkg/Core/FwVol.c
> > > @@ -14,6 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> > > ANY KIND, EITHER EXPRESS OR IMPLIED.
> > >
> > > #include "StandaloneMmCore.h"
> > > #include
> > > +#include
> > >
> > > //
> > > // List of file types supported by dispatcher
> > > @@ -65,15 +66,25 @@ Returns:
> > >
> > > --*/
> > > {
> > > - EFI_STATUS Status;
> > > - EFI_STATUS DepexStatus;
> > > - EFI_FFS_FILE_HEADER *FileHeader;
> > > - EFI_FV_FILETYPE FileType;
> > > - VOID*Pe32Data;
> > > - UINTN Pe32DataSize;
> > > - VOID*Depex;
> > > - UINTN DepexSize;
> > > - UINTN Index;
> > > + EFI_STATUS Status;
> > > + EFI_STATUS DepexStatus;
> > > + EFI_FFS_FILE_HEADER *FileHeader;
> > > + EFI_FV_FILETYPE FileType;
> > > + VOID*Pe32Data;
> > > + UINTN Pe32DataSize;
> > > + VOID*Depex;
> > > + UINTN DepexSize;
> > > + UINTN Index;
> > > + EFI_COMMON_SECTION_HEADER *Section;
> > > + VOID*SectionData;
> > > + UINTN SectionDataSize;
> > > + UINT32 DstBufferSize;
> > > + VOID*ScratchBuffer;
> > > + UINT32 ScratchBufferSize;
> > > + VOID*DstBuffer;
> > > + UINT16 SectionAttribute;
> > > + UINT32
> AuthenticationStatus;
> > > + EFI_FIRMWARE_VOLUME_HEADER *InnerFvHeader;
> > >
> > >DEBUG
Re: [edk2] [PATCH v2 00/11] StandaloneMmPkg: assorted fixes and improvements
Thanks to remind me. I took a look at all patches. I skipped all ARM specific patches, and reviewed rest of them. All my feedback is provided in the individual patch. Thank you Yao Jiewen > -Original Message- > From: Achin Gupta [mailto:achin.gu...@arm.com] > Sent: Friday, January 18, 2019 1:27 AM > To: Ard Biesheuvel ; edk2-devel@lists.01.org; > Yao, Jiewen > Cc: Supreeth Venkatesh ; Leif Lindholm > ; Jagadeesh Ujja ; > Thomas Abraham ; Sami Mujawar > ; nd > Subject: Re: [PATCH v2 00/11] StandaloneMmPkg: assorted fixes and > improvements > > Hi Ard, > > For all the patches... > > Reviewed-by: Achin Gupta > > Jiewen. There are changes to the generic Standalone MM code in this series. > Do you want to have a look as well? > > cheers, > Achin > > From: Ard Biesheuvel > Sent: 16 January 2019 20:22 > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel; Achin Gupta; Jiewen Yao; Supreeth Venkatesh; Leif > Lindholm; Jagadeesh Ujja; Thomas Abraham; Sami Mujawar > Subject: [PATCH v2 00/11] StandaloneMmPkg: assorted fixes and > improvements > > This series addresses a number of issues I ran into while bringing up > the standalone MM based authenticated variable store on the SynQuacer > (AArch64) platform. > > Patches #1 - #3 are based on Jagadeesh's patch that imports some staging > code into StandaloneMmPkg, with the following changes: > - drop unused source files, GUID references are other unused bit, > - clean up comments referring to the MM core implementation. > > Patches #4 - #9 are obvious fixes/improvements. > > Patch #10 adds support for TE formatted MM_CORE_STANDALONE binaries. > This is useful given that the 4 KB section alignment we require in > AArch64 implementations of standalone MM (due to the strict separation > between code and date) results in 8 KB of wasted space at the start of > the firmware volume. This can be reduced to 4 KB when using a TE image > and the FIXED attribute in the associated [Rule] section, by leveraging > an existing optimization in the FFS generation code that aligns TE images > by reducing FFS padding rather than adding more. > > Patch #11 is another space optimization: it reuses the existing support > for encapsulated compressed firmware volumes in FFS files to shrink the > size of the primary standalone MM FV considerably. Again, due to > alignment requirements, there is significant bloat in the uncompressed > images (4 KB for the PE/COFF header, and up to 4 KB per section for the > .text, .data and .reloc sections), making the absolute minimum size of > any trivial MM_STANDALONE module 16 KB. > > Changes since v1: > - add patches #1 - #3 > - add Supreeth's ack to patches #4 - #7 > > Cc: Achin Gupta > Cc: Jiewen Yao > Cc: Supreeth Venkatesh > Cc: Leif Lindholm > Cc: Jagadeesh Ujja > Cc: Thomas Panakamattam Abraham > Cc: Sami Mujawar > > Ard Biesheuvel (11): > StandaloneMmPkg: add HobLib implementation for MM_STANDALONE > modules > StandaloneMmPkg: add MM_STANDALONE MemoryAllocationLib > implementation > StandaloneMmPkg/StandaloneMmCoreHobLib: restrict to > MM_CORE_STANDALONE > StandaloneMmPkg/StandaloneMmCpu: fix typo Standlone -> Standalone > StandaloneMmPkg/StandaloneMmCoreEntryPoint: add missing > SerialPortLib > ref > StandaloneMmPkg/StandaloneMmCoreEntryPoint: use %a modifier for > ASCII > strings > StandaloneMmPkg/StandaloneMmCoreEntryPoint: remove bogus > ASSERT_EFI_ERROR()s > StandaloneMmPkg/StandaloneMmPeCoffExtraActionLib: ignore runtime > attribute > StandaloneMmPkg/Core/Dispatcher: don't copy dispatched image twice > StandaloneMmPkg/StandaloneMmCoreEntryPoint: permit the use of TE > images > StandaloneMmPkg/Core: permit encapsulated firmware volumes > > StandaloneMmPkg/Core/Dispatcher.c | 30 +- > StandaloneMmPkg/Core/FwVol.c | 99 ++- > StandaloneMmPkg/Core/StandaloneMmCore.inf | 1 + > .../StandaloneMmCpu/AArch64/EventHandle.c | 2 +- > .../StandaloneMmCpu/AArch64/StandaloneMmCpu.c | 6 +- > .../StandaloneMmCpu/AArch64/StandaloneMmCpu.h | 8 +- > .../AArch64/StandaloneMmCpu.inf | 4 +- > .../AArch64/SetPermissions.c | 109 +-- > .../AArch64/StandaloneMmCoreEntryPoint.c | 7 +- > .../StandaloneMmCoreEntryPoint.inf| 4 + > .../StandaloneMmCoreHobLib.inf| 2 +- > .../StandaloneMmHobLib/StandaloneMmHobLib.c | 649 > ++ > .../StandaloneMmHobLib/StandaloneMmHobLib.inf | 45 + > .../StandaloneMmMemoryAllocationLib.c | 822 > ++ > .../StandaloneMmMemoryAllocationLib.inf | 42 + > .../StandaloneMmPeCoffExtraActionLib.c| 9 +- > 16 files changed, 1716 insertions(+), 123 deletions(-) > create mode 100644 > StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c > create mode 100644 > StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf > create mode 100644 >
Re: [edk2] [PATCH v2 11/11] StandaloneMmPkg/Core: permit encapsulated firmware volumes
On Fri, 18 Jan 2019 at 16:40, Yao, Jiewen wrote:
>
> The idea seems good.
>
> May I know if there is any restriction on 64 handlers?
>
> +STATIC UINT64 mExtractGuidedSectionHandlerInfo[64];
>
> If a system is configured with more handlers, what is expected behavior?
>
Good question. I wasn't really sure how to implement this. For any
given platform configuration, I don't think you will ever need more
than one handler, unless you are encapsulating a compressed FV inside
a signed FV perhaps?
Do you have any suggestions how to improve this code?
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Wednesday, January 16, 2019 12:23 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Achin Gupta
> > ; Yao, Jiewen ; Supreeth
> > Venkatesh ; Leif Lindholm
> > ; Jagadeesh Ujja ;
> > Thomas Panakamattam Abraham ; Sami
> > Mujawar
> > Subject: [PATCH v2 11/11] StandaloneMmPkg/Core: permit encapsulated
> > firmware volumes
> >
> > Standalone MM requires 4 KB section alignment for all images, so that
> > strict permissions can be applied. Unfortunately, this results in a
> > lot of wasted space, which is usually costly in the secure world
> > environment that standalone MM is expected to operate in.
> >
> > So let's permit the standalone MM drivers (but not the core) to be
> > delivered in a compressed firmware volume.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > StandaloneMmPkg/Core/FwVol.c
> > | 99 ++--
> > StandaloneMmPkg/Core/StandaloneMmCore.inf
> > | 1 +
> >
> > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standal
> > oneMmCoreEntryPoint.c | 5 +
> >
> > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCo
> > reEntryPoint.inf | 3 +
> > 4 files changed, 99 insertions(+), 9 deletions(-)
> >
> > diff --git a/StandaloneMmPkg/Core/FwVol.c
> > b/StandaloneMmPkg/Core/FwVol.c
> > index 5abf98c24797..8eb827dda5c4 100644
> > --- a/StandaloneMmPkg/Core/FwVol.c
> > +++ b/StandaloneMmPkg/Core/FwVol.c
> > @@ -14,6 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> > ANY KIND, EITHER EXPRESS OR IMPLIED.
> >
> > #include "StandaloneMmCore.h"
> > #include
> > +#include
> >
> > //
> > // List of file types supported by dispatcher
> > @@ -65,15 +66,25 @@ Returns:
> >
> > --*/
> > {
> > - EFI_STATUS Status;
> > - EFI_STATUS DepexStatus;
> > - EFI_FFS_FILE_HEADER *FileHeader;
> > - EFI_FV_FILETYPE FileType;
> > - VOID*Pe32Data;
> > - UINTN Pe32DataSize;
> > - VOID*Depex;
> > - UINTN DepexSize;
> > - UINTN Index;
> > + EFI_STATUS Status;
> > + EFI_STATUS DepexStatus;
> > + EFI_FFS_FILE_HEADER *FileHeader;
> > + EFI_FV_FILETYPE FileType;
> > + VOID*Pe32Data;
> > + UINTN Pe32DataSize;
> > + VOID*Depex;
> > + UINTN DepexSize;
> > + UINTN Index;
> > + EFI_COMMON_SECTION_HEADER *Section;
> > + VOID*SectionData;
> > + UINTN SectionDataSize;
> > + UINT32 DstBufferSize;
> > + VOID*ScratchBuffer;
> > + UINT32 ScratchBufferSize;
> > + VOID*DstBuffer;
> > + UINT16 SectionAttribute;
> > + UINT32 AuthenticationStatus;
> > + EFI_FIRMWARE_VOLUME_HEADER *InnerFvHeader;
> >
> >DEBUG ((DEBUG_INFO, "MmCoreFfsFindMmDriver - 0x%x\n",
> > FwVolHeader));
> >
> > @@ -83,6 +94,71 @@ Returns:
> >
> >FvIsBeingProcesssed (FwVolHeader);
> >
> > + //
> > + // First check for encapsulated compressed firmware volumes
> > + //
> > + FileHeader = NULL;
> > + do {
> > +Status = FfsFindNextFile
> > (EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE,
> > + FwVolHeader, );
> > +if (EFI_ERROR (Status)) {
> > + break;
> > +}
> > +Status = FfsFindSectionData (EFI_SECTION_GUID_DEFINED,
> > FileHeader,
> > + , );
> > +if (EFI_ERROR (Status)) {
> > + break;
> > +}
> > +Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
> > +Status = ExtractGuidedSectionGetInfo (Section, ,
> > + , );
> > +if (EFI_ERROR (Status)) {
> > + break;
> > +}
> > +
> > +//
> > +// Allocate scratch buffer
> > +//
> > +ScratchBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
> > (ScratchBufferSize));
> > +if (ScratchBuffer == NULL) {
> > + return EFI_OUT_OF_RESOURCES;
> > +}
> > +
> > +
Re: [edk2] [PATCH v2 11/11] StandaloneMmPkg/Core: permit encapsulated firmware volumes
The idea seems good.
May I know if there is any restriction on 64 handlers?
+STATIC UINT64 mExtractGuidedSectionHandlerInfo[64];
If a system is configured with more handlers, what is expected behavior?
Thank you
Yao Jiewen
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, January 16, 2019 12:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Achin Gupta
> ; Yao, Jiewen ; Supreeth
> Venkatesh ; Leif Lindholm
> ; Jagadeesh Ujja ;
> Thomas Panakamattam Abraham ; Sami
> Mujawar
> Subject: [PATCH v2 11/11] StandaloneMmPkg/Core: permit encapsulated
> firmware volumes
>
> Standalone MM requires 4 KB section alignment for all images, so that
> strict permissions can be applied. Unfortunately, this results in a
> lot of wasted space, which is usually costly in the secure world
> environment that standalone MM is expected to operate in.
>
> So let's permit the standalone MM drivers (but not the core) to be
> delivered in a compressed firmware volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> StandaloneMmPkg/Core/FwVol.c
> | 99 ++--
> StandaloneMmPkg/Core/StandaloneMmCore.inf
> | 1 +
>
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standal
> oneMmCoreEntryPoint.c | 5 +
>
> StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCo
> reEntryPoint.inf | 3 +
> 4 files changed, 99 insertions(+), 9 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/FwVol.c
> b/StandaloneMmPkg/Core/FwVol.c
> index 5abf98c24797..8eb827dda5c4 100644
> --- a/StandaloneMmPkg/Core/FwVol.c
> +++ b/StandaloneMmPkg/Core/FwVol.c
> @@ -14,6 +14,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "StandaloneMmCore.h"
> #include
> +#include
>
> //
> // List of file types supported by dispatcher
> @@ -65,15 +66,25 @@ Returns:
>
> --*/
> {
> - EFI_STATUS Status;
> - EFI_STATUS DepexStatus;
> - EFI_FFS_FILE_HEADER *FileHeader;
> - EFI_FV_FILETYPE FileType;
> - VOID*Pe32Data;
> - UINTN Pe32DataSize;
> - VOID*Depex;
> - UINTN DepexSize;
> - UINTN Index;
> + EFI_STATUS Status;
> + EFI_STATUS DepexStatus;
> + EFI_FFS_FILE_HEADER *FileHeader;
> + EFI_FV_FILETYPE FileType;
> + VOID*Pe32Data;
> + UINTN Pe32DataSize;
> + VOID*Depex;
> + UINTN DepexSize;
> + UINTN Index;
> + EFI_COMMON_SECTION_HEADER *Section;
> + VOID*SectionData;
> + UINTN SectionDataSize;
> + UINT32 DstBufferSize;
> + VOID*ScratchBuffer;
> + UINT32 ScratchBufferSize;
> + VOID*DstBuffer;
> + UINT16 SectionAttribute;
> + UINT32 AuthenticationStatus;
> + EFI_FIRMWARE_VOLUME_HEADER *InnerFvHeader;
>
>DEBUG ((DEBUG_INFO, "MmCoreFfsFindMmDriver - 0x%x\n",
> FwVolHeader));
>
> @@ -83,6 +94,71 @@ Returns:
>
>FvIsBeingProcesssed (FwVolHeader);
>
> + //
> + // First check for encapsulated compressed firmware volumes
> + //
> + FileHeader = NULL;
> + do {
> +Status = FfsFindNextFile
> (EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE,
> + FwVolHeader, );
> +if (EFI_ERROR (Status)) {
> + break;
> +}
> +Status = FfsFindSectionData (EFI_SECTION_GUID_DEFINED,
> FileHeader,
> + , );
> +if (EFI_ERROR (Status)) {
> + break;
> +}
> +Section = (EFI_COMMON_SECTION_HEADER *)(FileHeader + 1);
> +Status = ExtractGuidedSectionGetInfo (Section, ,
> + , );
> +if (EFI_ERROR (Status)) {
> + break;
> +}
> +
> +//
> +// Allocate scratch buffer
> +//
> +ScratchBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
> (ScratchBufferSize));
> +if (ScratchBuffer == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +
> +//
> +// Allocate destination buffer
> +//
> +DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
> (DstBufferSize));
> +if (DstBuffer == NULL) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +
> +//
> +// Call decompress function
> +//
> +Status = ExtractGuidedSectionDecode (Section, ,
> ScratchBuffer,
> + );
> +FreePages (ScratchBuffer, EFI_SIZE_TO_PAGES (ScratchBufferSize));
> +if (EFI_ERROR (Status)) {
> + goto FreeDstBuffer;
> +}
> +
> +DEBUG ((DEBUG_INFO,
> +
Re: [edk2] [PATCH v2 09/11] StandaloneMmPkg/Core/Dispatcher: don't copy dispatched image twice
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, January 16, 2019 12:23 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Achin Gupta
> ; Yao, Jiewen ; Supreeth
> Venkatesh ; Leif Lindholm
> ; Jagadeesh Ujja ;
> Thomas Panakamattam Abraham ; Sami
> Mujawar
> Subject: [PATCH v2 09/11] StandaloneMmPkg/Core/Dispatcher: don't copy
> dispatched image twice
>
> The dispatcher uses the PE/COFF loader to load images into the heap,
> but only does so after copying the entire image first, leading to
> two copies being made for no good reason.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> StandaloneMmPkg/Core/Dispatcher.c | 30 +---
> 1 file changed, 1 insertion(+), 29 deletions(-)
>
> diff --git a/StandaloneMmPkg/Core/Dispatcher.c
> b/StandaloneMmPkg/Core/Dispatcher.c
> index 8d009b4f80c1..8a2ad5118d92 100644
> --- a/StandaloneMmPkg/Core/Dispatcher.c
> +++ b/StandaloneMmPkg/Core/Dispatcher.c
> @@ -294,7 +294,6 @@ MmLoadImage (
>IN OUT EFI_MM_DRIVER_ENTRY *DriverEntry
>)
> {
> - VOID *Buffer;
>UINTN PageCount;
>EFI_STATUS Status;
>EFI_PHYSICAL_ADDRESS DstBuffer;
> @@ -302,17 +301,12 @@ MmLoadImage (
>
>DEBUG ((DEBUG_INFO, "MmLoadImage - %g\n",
> >FileName));
>
> - Buffer = AllocateCopyPool (DriverEntry->Pe32DataSize,
> DriverEntry->Pe32Data);
> - if (Buffer == NULL) {
> -return EFI_OUT_OF_RESOURCES;
> - }
> -
>Status = EFI_SUCCESS;
>
>//
>// Initialize ImageContext
>//
> - ImageContext.Handle = Buffer;
> + ImageContext.Handle = DriverEntry->Pe32Data;
>ImageContext.ImageRead = PeCoffLoaderImageReadFromMemory;
>
>//
> @@ -320,9 +314,6 @@ MmLoadImage (
>//
>Status = PeCoffLoaderGetImageInfo ();
>if (EFI_ERROR (Status)) {
> -if (Buffer != NULL) {
> - MmFreePool (Buffer);
> -}
> return Status;
>}
>
> @@ -336,9 +327,6 @@ MmLoadImage (
>
> );
>if (EFI_ERROR (Status)) {
> -if (Buffer != NULL) {
> - MmFreePool (Buffer);
> -}
> return Status;
>}
>
> @@ -355,9 +343,6 @@ MmLoadImage (
>//
>Status = PeCoffLoaderLoadImage ();
>if (EFI_ERROR (Status)) {
> -if (Buffer != NULL) {
> - MmFreePool (Buffer);
> -}
> MmFreePages (DstBuffer, PageCount);
> return Status;
>}
> @@ -367,9 +352,6 @@ MmLoadImage (
>//
>Status = PeCoffLoaderRelocateImage ();
>if (EFI_ERROR (Status)) {
> -if (Buffer != NULL) {
> - MmFreePool (Buffer);
> -}
> MmFreePages (DstBuffer, PageCount);
> return Status;
>}
> @@ -393,9 +375,6 @@ MmLoadImage (
>(VOID
> **)>LoadedImage
>);
> if (EFI_ERROR (Status)) {
> - if (Buffer != NULL) {
> -MmFreePool (Buffer);
> - }
>MmFreePages (DstBuffer, PageCount);
>return Status;
> }
> @@ -482,13 +461,6 @@ MmLoadImage (
>
>DEBUG_CODE_END ();
>
> - //
> - // Free buffer allocated by Fv->ReadSection.
> - //
> - // The UEFI Boot Services FreePool() function must be used because
> Fv->ReadSection
> - // used the UEFI Boot Services AllocatePool() function
> - //
> - MmFreePool (Buffer);
>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 v2 05/11] StandaloneMmPkg/StandaloneMmCoreEntryPoint: add missing SerialPortLib ref
That would be even better. Thanks Ard. > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, January 18, 2019 7:32 AM > To: Yao, Jiewen > Cc: edk2-devel@lists.01.org; Achin Gupta ; > Supreeth Venkatesh ; Leif Lindholm > ; Jagadeesh Ujja ; > Thomas Panakamattam Abraham ; Sami > Mujawar > Subject: Re: [PATCH v2 05/11] > StandaloneMmPkg/StandaloneMmCoreEntryPoint: add missing SerialPortLib > ref > > On Fri, 18 Jan 2019 at 16:27, Yao, Jiewen wrote: > > > > Usually, we do not encourage to use SerialPortLib directly in a hardware > independent environment. > > I do not suggest we bring an architecture dependency on the existence of > SerialPort in a common code. > > > > However, if ARCH64 has some specific code that must use SerialPortLib > explicitly, I am OK. > > Can we move SerialPortLib under [LibraryClasses.AARCH64] ? > > > > I am happy to remove the SerialPortInitialize call, and instead rely > on DebugLib to pull in SerialPortLIb if it wants to (and rely on the > constructor to be invoked implicitly) > > > > > > > > > > > > -Original Message- > > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > > Sent: Wednesday, January 16, 2019 12:23 PM > > > To: edk2-devel@lists.01.org > > > Cc: Ard Biesheuvel ; Achin Gupta > > > ; Yao, Jiewen ; > Supreeth > > > Venkatesh ; Leif Lindholm > > > ; Jagadeesh Ujja ; > > > Thomas Panakamattam Abraham ; Sami > > > Mujawar > > > Subject: [PATCH v2 05/11] > StandaloneMmPkg/StandaloneMmCoreEntryPoint: > > > add missing SerialPortLib ref > > > > > > StandaloneMmCoreEntryPoint calls SerialPortInitialize() explicitly, > > > so add SerialPortLib to its list of LibraryClasses. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Ard Biesheuvel > > > Reviewed-by: Supreeth Venkatesh > > > --- > > > > > > > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCo > > > reEntryPoint.inf | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git > > > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > > CoreEntryPoint.inf > > > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > > CoreEntryPoint.inf > > > index 3222cd359f3e..769eaeeefbea 100644 > > > --- > > > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > > CoreEntryPoint.inf > > > +++ > > > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > > CoreEntryPoint.inf > > > @@ -43,6 +43,7 @@ [Packages.AARCH64] > > > [LibraryClasses] > > >BaseLib > > >DebugLib > > > + SerialPortLib > > > > > > [LibraryClasses.AARCH64] > > >StandaloneMmMmuLib > > > -- > > > 2.17.1 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 05/11] StandaloneMmPkg/StandaloneMmCoreEntryPoint: add missing SerialPortLib ref
On Fri, 18 Jan 2019 at 16:27, Yao, Jiewen wrote: > > Usually, we do not encourage to use SerialPortLib directly in a hardware > independent environment. > I do not suggest we bring an architecture dependency on the existence of > SerialPort in a common code. > > However, if ARCH64 has some specific code that must use SerialPortLib > explicitly, I am OK. > Can we move SerialPortLib under [LibraryClasses.AARCH64] ? > I am happy to remove the SerialPortInitialize call, and instead rely on DebugLib to pull in SerialPortLIb if it wants to (and rely on the constructor to be invoked implicitly) > > > > > -Original Message- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: Wednesday, January 16, 2019 12:23 PM > > To: edk2-devel@lists.01.org > > Cc: Ard Biesheuvel ; Achin Gupta > > ; Yao, Jiewen ; Supreeth > > Venkatesh ; Leif Lindholm > > ; Jagadeesh Ujja ; > > Thomas Panakamattam Abraham ; Sami > > Mujawar > > Subject: [PATCH v2 05/11] StandaloneMmPkg/StandaloneMmCoreEntryPoint: > > add missing SerialPortLib ref > > > > StandaloneMmCoreEntryPoint calls SerialPortInitialize() explicitly, > > so add SerialPortLib to its list of LibraryClasses. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > Reviewed-by: Supreeth Venkatesh > > --- > > > > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCo > > reEntryPoint.inf | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > CoreEntryPoint.inf > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > CoreEntryPoint.inf > > index 3222cd359f3e..769eaeeefbea 100644 > > --- > > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > CoreEntryPoint.inf > > +++ > > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > > CoreEntryPoint.inf > > @@ -43,6 +43,7 @@ [Packages.AARCH64] > > [LibraryClasses] > >BaseLib > >DebugLib > > + SerialPortLib > > > > [LibraryClasses.AARCH64] > >StandaloneMmMmuLib > > -- > > 2.17.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 05/11] StandaloneMmPkg/StandaloneMmCoreEntryPoint: add missing SerialPortLib ref
Usually, we do not encourage to use SerialPortLib directly in a hardware independent environment. I do not suggest we bring an architecture dependency on the existence of SerialPort in a common code. However, if ARCH64 has some specific code that must use SerialPortLib explicitly, I am OK. Can we move SerialPortLib under [LibraryClasses.AARCH64] ? > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Wednesday, January 16, 2019 12:23 PM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel ; Achin Gupta > ; Yao, Jiewen ; Supreeth > Venkatesh ; Leif Lindholm > ; Jagadeesh Ujja ; > Thomas Panakamattam Abraham ; Sami > Mujawar > Subject: [PATCH v2 05/11] StandaloneMmPkg/StandaloneMmCoreEntryPoint: > add missing SerialPortLib ref > > StandaloneMmCoreEntryPoint calls SerialPortInitialize() explicitly, > so add SerialPortLib to its list of LibraryClasses. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > Reviewed-by: Supreeth Venkatesh > --- > > StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMmCo > reEntryPoint.inf | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > CoreEntryPoint.inf > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > CoreEntryPoint.inf > index 3222cd359f3e..769eaeeefbea 100644 > --- > a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > CoreEntryPoint.inf > +++ > b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/StandaloneMm > CoreEntryPoint.inf > @@ -43,6 +43,7 @@ [Packages.AARCH64] > [LibraryClasses] >BaseLib >DebugLib > + SerialPortLib > > [LibraryClasses.AARCH64] >StandaloneMmMmuLib > -- > 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 03/11] StandaloneMmPkg/StandaloneMmCoreHobLib: restrict to MM_CORE_STANDALONE
Reviewed-by: jiewen@intel.com > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Wednesday, January 16, 2019 12:22 PM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel ; Achin Gupta > ; Yao, Jiewen ; Supreeth > Venkatesh ; Leif Lindholm > ; Jagadeesh Ujja ; > Thomas Panakamattam Abraham ; Sami > Mujawar > Subject: [PATCH v2 03/11] StandaloneMmPkg/StandaloneMmCoreHobLib: > restrict to MM_CORE_STANDALONE > > Remove MM_STANDALONE from the list of permitted modules for this > library. > It should only be used by the standalone MM core. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Jagadeesh Ujja > Signed-off-by: Ard Biesheuvel > --- > > StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCore > HobLib.inf | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCor > eHobLib.inf > b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCor > eHobLib.inf > index db19d3c926e8..ac036e31cf5e 100644 > --- > a/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCor > eHobLib.inf > +++ > b/StandaloneMmPkg/Library/StandaloneMmCoreHobLib/StandaloneMmCor > eHobLib.inf > @@ -24,7 +24,7 @@ [Defines] >MODULE_TYPE= MM_CORE_STANDALONE >VERSION_STRING = 1.0 >PI_SPECIFICATION_VERSION = 0x00010032 > - LIBRARY_CLASS = > HobLib|MM_CORE_STANDALONE MM_STANDALONE > + LIBRARY_CLASS = > HobLib|MM_CORE_STANDALONE > > # > # VALID_ARCHITECTURES = AARCH64 > -- > 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 01/11] StandaloneMmPkg: add HobLib implementation for MM_STANDALONE modules
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, January 16, 2019 12:22 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Achin Gupta
> ; Yao, Jiewen ; Supreeth
> Venkatesh ; Leif Lindholm
> ; Jagadeesh Ujja ;
> Thomas Panakamattam Abraham ; Sami
> Mujawar
> Subject: [PATCH v2 01/11] StandaloneMmPkg: add HobLib implementation
> for MM_STANDALONE modules
>
> This HobLib code is based on the staging implementation of
> StandaloneMmPkg, with the following changes:
> - drop the unused AArch64/StandaloneMmCoreHobLibInternal.c source file
> - remove hack from HobLibConstructor()
> - update code comments referring the MM core
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja
> Signed-off-by: Ard Biesheuvel
> ---
> StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> | 649
>
> StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
> | 45 ++
> 2 files changed, 694 insertions(+)
>
> diff --git
> a/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> new file mode 100644
> index ..cc1a08166470
> --- /dev/null
> +++
> b/StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c
> @@ -0,0 +1,649 @@
> +/** @file
> + HOB Library implementation for Standalone MM Core.
> +
> +Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
> +Copyright (c) 2017 - 2018, ARM Limited. All rights reserved.
> +Copyright (c) 2018, Linaro, Ltd. 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.
> +
> +**/
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +//
> +// Cache copy of HobList pointer.
> +//
> +STATIC VOID *gHobList = NULL;
> +
> +/**
> + The constructor function caches the pointer to HOB list.
> +
> + The constructor function gets the start address of HOB list from system
> configuration table.
> + It will ASSERT() if that operation fails and it will always return
> EFI_SUCCESS.
> +
> + @param ImageHandle The firmware allocated handle for the
> image.
> + @param MmSystemTable A pointer to the MM System Table.
> +
> + @retval EFI_SUCCESS The constructor successfully gets HobList.
> + @retval Other value The constructor can't get HobList.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +HobLibConstructor (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_MM_SYSTEM_TABLE*MmSystemTable
> + )
> +{
> + UINTN Index;
> +
> + for (Index = 0; Index < gMmst->NumberOfTableEntries; Index++) {
> +if (CompareGuid (,
> >MmConfigurationTable[Index].VendorGuid)) {
> + gHobList = gMmst->MmConfigurationTable[Index].VendorTable;
> + break;
> +}
> + }
> + return EFI_SUCCESS;
> +}
> +
> +/**
> + Returns the pointer to the HOB list.
> +
> + This function returns the pointer to first HOB in the list.
> + If the pointer to the HOB list is NULL, then ASSERT().
> +
> + @return The pointer to the HOB list.
> +
> +**/
> +VOID *
> +EFIAPI
> +GetHobList (
> + VOID
> + )
> +{
> + UINTN Index;
> +
> + if (gHobList == NULL) {
> +for (Index = 0; Index < gMmst->NumberOfTableEntries; Index++) {
> + if (CompareGuid (,
> >MmConfigurationTable[Index].VendorGuid)) {
> +gHobList = gMmst->MmConfigurationTable[Index].VendorTable;
> +break;
> + }
> +}
> + }
> + ASSERT (gHobList != NULL);
> + return gHobList;
> +}
> +
> +/**
> + Returns the next instance of a HOB type from the starting HOB.
> +
> + This function searches the first instance of a HOB type from the starting
> HOB pointer.
> + If there does not exist such HOB type from the starting HOB pointer, it
> will return NULL.
> + In contrast with macro GET_NEXT_HOB(), this function does not skip the
> starting HOB pointer
> + unconditionally: it returns HobStart back if HobStart itself meets the
> requirement;
> + caller is required to use GET_NEXT_HOB() if it wishes to skip current
> HobStart.
> +
> + If HobStart is NULL, then ASSERT().
> +
> + @param Type The HOB type to return.
> + @param HobStart The starting HOB pointer to search from.
> +
> + @return The next instance of a HOB type from the starting HOB.
> +
> +**/
> +VOID *
> +EFIAPI
> +GetNextHob (
> + IN UINT16 Type,
> + IN CONST VOID *HobStart
> + )
> +{
> + EFI_PEI_HOB_POINTERS Hob;
> +
> + ASSERT (HobStart != NULL);
> +
> + Hob.Raw = (UINT8 *) HobStart;
> + //
> + //
Re: [edk2] [PATCH v2 02/11] StandaloneMmPkg: add MM_STANDALONE MemoryAllocationLib implementation
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, January 16, 2019 12:22 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel ; Achin Gupta
> ; Yao, Jiewen ; Supreeth
> Venkatesh ; Leif Lindholm
> ; Jagadeesh Ujja ;
> Thomas Panakamattam Abraham ; Sami
> Mujawar
> Subject: [PATCH v2 02/11] StandaloneMmPkg: add MM_STANDALONE
> MemoryAllocationLib implementation
>
> This MemoryAllocationLib code is based on the staging implementation of
> StandaloneMmPkg, with the following changes:
> - use correct MODULE_TYPE
> - include MmServicesTableLib instead of declaring gMmst directly
> - update code comments referring to the MM core
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jagadeesh Ujja
> Signed-off-by: Ard Biesheuvel
> ---
>
> StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/Standalone
> MmMemoryAllocationLib.c | 822
>
> StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/Standalone
> MmMemoryAllocationLib.inf | 42 +
> 2 files changed, 864 insertions(+)
>
> diff --git
> a/StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/Standalo
> neMmMemoryAllocationLib.c
> b/StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/Standalo
> neMmMemoryAllocationLib.c
> new file mode 100644
> index ..c7c1282babff
> --- /dev/null
> +++
> b/StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/Standalo
> neMmMemoryAllocationLib.c
> @@ -0,0 +1,822 @@
> +/** @file
> + Support routines for memory allocation routines based on Standalone
> MM Core internal functions.
> +
> + Copyright (c) 2015, Intel Corporation. All rights reserved.
> + Copyright (c) 2016 - 2018, ARM Limited. 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.
> +
> +**/
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + Allocates one or more 4KB pages of a certain memory type.
> +
> + Allocates the number of 4KB pages of a certain memory type and returns
> a pointer to the allocated
> + buffer. The buffer returned is aligned on a 4KB boundary. If Pages is 0,
> then NULL is returned.
> + If there is not enough memory remaining to satisfy the request, then
> NULL is returned.
> +
> + @param MemoryTypeThe type of memory to allocate.
> + @param Pages The number of 4 KB pages to
> allocate.
> +
> + @return A pointer to the allocated buffer or NULL if allocation fails.
> +
> +**/
> +VOID *
> +InternalAllocatePages (
> + IN EFI_MEMORY_TYPE MemoryType,
> + IN UINTNPages
> + )
> +{
> + EFI_STATUSStatus;
> + EFI_PHYSICAL_ADDRESS Memory;
> +
> + if (Pages == 0) {
> +return NULL;
> + }
> +
> + Status = gMmst->MmAllocatePages (AllocateAnyPages, MemoryType,
> Pages, );
> + if (EFI_ERROR (Status)) {
> +return NULL;
> + }
> + return (VOID *)(UINTN)Memory;
> +}
> +
> +/**
> + Allocates one or more 4KB pages of type EfiBootServicesData.
> +
> + Allocates the number of 4KB pages of type EfiBootServicesData and
> returns a pointer to the
> + allocated buffer. The buffer returned is aligned on a 4KB boundary. If
> Pages is 0, then NULL
> + is returned. If there is not enough memory remaining to satisfy the
> request, then NULL is
> + returned.
> +
> + @param Pages The number of 4 KB pages to
> allocate.
> +
> + @return A pointer to the allocated buffer or NULL if allocation fails.
> +
> +**/
> +VOID *
> +EFIAPI
> +AllocatePages (
> + IN UINTN Pages
> + )
> +{
> + return InternalAllocatePages (EfiRuntimeServicesData, Pages);
> +}
> +
> +/**
> + Allocates one or more 4KB pages of type EfiRuntimeServicesData.
> +
> + Allocates the number of 4KB pages of type EfiRuntimeServicesData and
> returns a pointer to the
> + allocated buffer. The buffer returned is aligned on a 4KB boundary. If
> Pages is 0, then NULL
> + is returned. If there is not enough memory remaining to satisfy the
> request, then NULL is
> + returned.
> +
> + @param Pages The number of 4 KB pages to
> allocate.
> +
> + @return A pointer to the allocated buffer or NULL if allocation fails.
> +
> +**/
> +VOID *
> +EFIAPI
> +AllocateRuntimePages (
> + IN UINTN Pages
> + )
> +{
> + return InternalAllocatePages (EfiRuntimeServicesData, Pages);
> +}
> +
> +/**
> + Allocates one or more 4KB pages of type EfiReservedMemoryType.
> +
> + Allocates the number of 4KB pages of type EfiReservedMemoryType and
> returns a pointer to the
> + allocated
Re: [edk2] [PATCH 2/4] SecurityPkg/PlatformSecureLibNull: permit use by MM_STANDALONE modules
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, January 18, 2019 3:13 AM
> To: Wang, Jian J
> Cc: edk2-devel@lists.01.org; Kinney, Michael D
> ; Gao, Liming ; Ye,
> Ting ; Wei, Gang ; Zhang, Chao B
> ; Yao, Jiewen ; Wu, Hao
> A ; Zeng, Star ; Achin Gupta
> ; Jagadeesh Ujja
> Subject: Re: [PATCH 2/4] SecurityPkg/PlatformSecureLibNull: permit use by
> MM_STANDALONE modules
>
> On Fri, 18 Jan 2019 at 08:06, Wang, Jian J wrote:
> >
> >
> >
> > Reviewed-by: Jian J Wang
> >
>
> Chao, Jiewen, do you have any objections to this patch?
>
> >
> > > -Original Message-
> > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > > Sent: Thursday, January 17, 2019 5:22 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Ard Biesheuvel ; Kinney, Michael D
> > > ; Gao, Liming ; Ye,
> Ting
> > > ; Wei, Gang ; Wang, Jian J
> > > ; Zhang, Chao B ;
> Yao,
> > > Jiewen ; Wu, Hao A ;
> Zeng, Star
> > > ; Achin Gupta ;
> Jagadeesh Ujja
> > >
> > > Subject: [PATCH 2/4] SecurityPkg/PlatformSecureLibNull: permit use by
> > > MM_STANDALONE modules
> > >
> > > Add MM_STANDALONE to the list of module types that are permitted to
> > > link to this library. Also, since the constructor prototype is
> > > different between MM_STANDALONE and DXE_DRIVER type libraries,
> > > convert the library into BASE type.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel
> > > ---
> > > SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> | 9 +-
> > > ---
> > > SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf |
> 4 ++--
> > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > >
> > > diff --git
> a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > > b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > > index 0c6ded22f3e6..b2493a029393 100644
> > > --- a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > > +++
> b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > > @@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY
> > > KIND, EITHER EXPRESS OR IMPLIED.
> > >
> > > **/
> > >
> > > +#include
> > > +
> > > BOOLEAN mUserPhysicalPresence = FALSE;
> > >
> > > /**
> > > @@ -53,15 +55,14 @@ UserPhysicalPresent (
> > >@retval EFI_SUCCESS PcdUserPhysicalPresence is got
> successfully.
> > >
> > > **/
> > > -EFI_STATUS
> > > +RETURN_STATUS
> > > EFIAPI
> > > PlatformSecureLibNullConstructor (
> > > - IN EFI_HANDLEImageHandle,
> > > - IN EFI_SYSTEM_TABLE *SystemTable
> > > + VOID
> > >)
> > > {
> > >
> > >mUserPhysicalPresence = PcdGetBool(PcdUserPhysicalPresence);
> > >
> > > - return EFI_SUCCESS;
> > > + return RETURN_SUCCESS;
> > > }
> > > diff --git
> a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > > b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > > index 979a33705de0..70051a27a0a9 100644
> > > ---
> a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > > +++
> b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > > @@ -21,9 +21,9 @@ [Defines]
> > >BASE_NAME = PlatformSecureLibNull
> > >MODULE_UNI_FILE= PlatformSecureLibNull.uni
> > >FILE_GUID =
> 7FA68D82-10A4-4e71-9524-D3D9500D3CDF
> > > - MODULE_TYPE= DXE_DRIVER
> > > + MODULE_TYPE= BASE
> > >VERSION_STRING = 1.0
> > > - LIBRARY_CLASS =
> PlatformSecureLib|DXE_RUNTIME_DRIVER
> > > DXE_SMM_DRIVER DXE_DRIVER
> > > + LIBRARY_CLASS =
> PlatformSecureLib|DXE_RUNTIME_DRIVER
> > > DXE_SMM_DRIVER DXE_DRIVER MM_STANDALONE
> > >CONSTRUCTOR=
> PlatformSecureLibNullConstructor
> > >
> > > #
> > > --
> > > 2.17.1
> >
___
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.
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/LICENSE) > -* > [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 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.v1_1_0.json) > +* > [ComputerSystemCollection](https://redfish.dmtf.org/schemas/ComputerSystemCollection.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/BootOptionCollection.json) > +*
Re: [edk2] [PATCH 2/4] SecurityPkg/PlatformSecureLibNull: permit use by MM_STANDALONE modules
On Fri, 18 Jan 2019 at 08:06, Wang, Jian J wrote:
>
>
>
> Reviewed-by: Jian J Wang
>
Chao, Jiewen, do you have any objections to this patch?
>
> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Thursday, January 17, 2019 5:22 AM
> > To: edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Kinney, Michael D
> > ; Gao, Liming ; Ye, Ting
> > ; Wei, Gang ; Wang, Jian J
> > ; Zhang, Chao B ; Yao,
> > Jiewen ; Wu, Hao A ; Zeng, Star
> > ; Achin Gupta ; Jagadeesh Ujja
> >
> > Subject: [PATCH 2/4] SecurityPkg/PlatformSecureLibNull: permit use by
> > MM_STANDALONE modules
> >
> > Add MM_STANDALONE to the list of module types that are permitted to
> > link to this library. Also, since the constructor prototype is
> > different between MM_STANDALONE and DXE_DRIVER type libraries,
> > convert the library into BASE type.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> > ---
> > SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c | 9
> > +-
> > ---
> > SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf | 4
> > ++--
> > 2 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git
> > a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > index 0c6ded22f3e6..b2493a029393 100644
> > --- a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > +++ b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.c
> > @@ -15,6 +15,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> > KIND, EITHER EXPRESS OR IMPLIED.
> >
> > **/
> >
> > +#include
> > +
> > BOOLEAN mUserPhysicalPresence = FALSE;
> >
> > /**
> > @@ -53,15 +55,14 @@ UserPhysicalPresent (
> >@retval EFI_SUCCESS PcdUserPhysicalPresence is got
> > successfully.
> >
> > **/
> > -EFI_STATUS
> > +RETURN_STATUS
> > EFIAPI
> > PlatformSecureLibNullConstructor (
> > - IN EFI_HANDLEImageHandle,
> > - IN EFI_SYSTEM_TABLE *SystemTable
> > + VOID
> >)
> > {
> >
> >mUserPhysicalPresence = PcdGetBool(PcdUserPhysicalPresence);
> >
> > - return EFI_SUCCESS;
> > + return RETURN_SUCCESS;
> > }
> > diff --git
> > a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > index 979a33705de0..70051a27a0a9 100644
> > --- a/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > +++ b/SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > @@ -21,9 +21,9 @@ [Defines]
> >BASE_NAME = PlatformSecureLibNull
> >MODULE_UNI_FILE= PlatformSecureLibNull.uni
> >FILE_GUID = 7FA68D82-10A4-4e71-9524-D3D9500D3CDF
> > - MODULE_TYPE= DXE_DRIVER
> > + MODULE_TYPE= BASE
> >VERSION_STRING = 1.0
> > - LIBRARY_CLASS = PlatformSecureLib|DXE_RUNTIME_DRIVER
> > DXE_SMM_DRIVER DXE_DRIVER
> > + LIBRARY_CLASS = PlatformSecureLib|DXE_RUNTIME_DRIVER
> > DXE_SMM_DRIVER DXE_DRIVER MM_STANDALONE
> >CONSTRUCTOR= PlatformSecureLibNullConstructor
> >
> > #
> > --
> > 2.17.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/4] CryptoPkg/SmmCryptLib: permit use by MM_STANDALONE modules
On Fri, 18 Jan 2019 at 08:08, Wang, Jian J wrote: > > > > Reviewed-by: Jian J Wang > Ting, do you have any objections to this patch? > > > -Original Message- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: Thursday, January 17, 2019 5:22 AM > > To: edk2-devel@lists.01.org > > Cc: Ard Biesheuvel ; Kinney, Michael D > > ; Gao, Liming ; Ye, Ting > > ; Wei, Gang ; Wang, Jian J > > ; Zhang, Chao B ; Yao, > > Jiewen ; Wu, Hao A ; Zeng, Star > > ; Achin Gupta ; Jagadeesh Ujja > > > > Subject: [PATCH 1/4] CryptoPkg/SmmCryptLib: permit use by MM_STANDALONE > > modules > > > > Permit SmmCryptLib to be used by MM_STANDALONE modules > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > --- > > CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > > b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > > index c34699cd62bf..a681fe2f36b8 100644 > > --- a/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > > +++ b/CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf > > @@ -30,7 +30,7 @@ [Defines] > >MODULE_TYPE= DXE_SMM_DRIVER > >VERSION_STRING = 1.0 > >PI_SPECIFICATION_VERSION = 0x0001000A > > - LIBRARY_CLASS = BaseCryptLib|DXE_SMM_DRIVER SMM_CORE > > + LIBRARY_CLASS = BaseCryptLib|DXE_SMM_DRIVER SMM_CORE > > MM_STANDALONE > > > > # > > # The following information is for reference only and not required by the > > build > > tools. > > -- > > 2.17.1 > ___ 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.
On Fri, 18 Jan 2019 at 06:38, Gao, Liming wrote:
>
> 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.
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Friday, January 18, 2019 1:32 PM
> > To: Fu, Siyuan ; Wu, Hao A ;
> > edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Gao, Liming
> > Subject: RE: [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 4/4] MdePkg/UefiDevicePathLib: permit use by MM_STANDALONE modules
On Wed, 16 Jan 2019 at 22:22, Ard Biesheuvel wrote: > > Add MM_STANDALONE to the list of module types that are permitted to > link to this library. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf > b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf > index d5f7bfa6af39..89ee87e15d0e 100644 > --- a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf > +++ b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf > @@ -22,7 +22,7 @@ [Defines] >FILE_GUID = 91c1677a-e57f-4191-8b8e-eb7711a716e0 >MODULE_TYPE= UEFI_DRIVER >VERSION_STRING = 1.0 > - LIBRARY_CLASS = DevicePathLib|DXE_CORE DXE_DRIVER > DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER SMM_CORE > + LIBRARY_CLASS = DevicePathLib|DXE_CORE DXE_DRIVER > DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER SMM_CORE > MM_STANDALONE > > Liming, Mike: do you have any objections? ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/4] MdeModulePkg/VarCheckLib: permit use by MM_STANDALONE modules
Anther, the parameters of constructor are removed, so their descriptions in
function header also need to be cleaned up. Same comment to patch 2. With them
fixed, Reviewed-by: Star Zeng to the series.
Thanks,
Star
-Original Message-
From: Zeng, Star
Sent: Friday, January 18, 2019 4:15 PM
To: Ard Biesheuvel ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming
; Ye, Ting ; Wei, Gang
; Wang, Jian J ; Zhang, Chao B
; Yao, Jiewen ; Wu, Hao A
; Achin Gupta ; Jagadeesh Ujja
; Zeng, Star
Subject: RE: [PATCH 3/4] MdeModulePkg/VarCheckLib: permit use by MM_STANDALONE
modules
This patch does not touch VarCheckLib at all, but only touch VarCheckUefiLib,
so the title and commit message need be updated.
With them updated correctly, Reviewed-by: Star Zeng .
Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, January 17, 2019 5:22 AM
To: edk2-devel@lists.01.org
Cc: Ard Biesheuvel ; Kinney, Michael D
; Gao, Liming ; Ye, Ting
; Wei, Gang ; Wang, Jian J
; Zhang, Chao B ; Yao, Jiewen
; Wu, Hao A ; Zeng, Star
; Achin Gupta ; Jagadeesh Ujja
Subject: [PATCH 3/4] MdeModulePkg/VarCheckLib: permit use by MM_STANDALONE
modules
Permit VarCheckLib and VarCheckUefiLib to be used by MM_STANDALONE modules.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf| 4 ++--
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c | 9 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
index 128c44d695e1..8873fd51a02a 100644
--- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
@@ -19,9 +19,9 @@ [Defines]
BASE_NAME = VarCheckUefiLib
MODULE_UNI_FILE= VarCheckUefiLib.uni
FILE_GUID = AC24A4C7-F845-4665-90E5-6431D6E28DC0
- MODULE_TYPE= DXE_RUNTIME_DRIVER
+ MODULE_TYPE= BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
+ LIBRARY_CLASS = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
MM_STANDALONE
CONSTRUCTOR= VarCheckUefiLibNullClassConstructor
#
diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
index 80dc6341adcf..5e419831e8cc 100644
--- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
+++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
@@ -12,6 +12,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
**/
+#include
+
#include
#include
#include
@@ -927,15 +929,14 @@ VariablePropertySetUefiDefined (
@retval EFI_SUCCESS The constructor executed correctly.
**/
-EFI_STATUS
+RETURN_STATUS
EFIAPI
VarCheckUefiLibNullClassConstructor (
- IN EFI_HANDLE ImageHandle,
- IN EFI_SYSTEM_TABLE *SystemTable
+ VOID
)
{
VariablePropertySetUefiDefined ();
VarCheckLibRegisterSetVariableCheckHandler
(SetVariableCheckHandlerUefiDefined);
- return EFI_SUCCESS;
+ return RETURN_SUCCESS;
}
--
2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [staging/UEFI_Redfish][PATCH v1] Announce to create "UEFI_Redfish" branch in edk2-staging.
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/LICENSE) -* [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 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.v1_1_0.json) +* [ComputerSystemCollection](https://redfish.dmtf.org/schemas/ComputerSystemCollection.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/BootOptionCollection.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
Re: [edk2] [PATCH v2 00/11] StandaloneMmPkg: assorted fixes and improvements
Hi Ard, For all the patches... Reviewed-by: Achin Gupta Jiewen. There are changes to the generic Standalone MM code in this series. Do you want to have a look as well? cheers, Achin From: Ard Biesheuvel Sent: 16 January 2019 20:22 To: edk2-devel@lists.01.org Cc: Ard Biesheuvel; Achin Gupta; Jiewen Yao; Supreeth Venkatesh; Leif Lindholm; Jagadeesh Ujja; Thomas Abraham; Sami Mujawar Subject: [PATCH v2 00/11] StandaloneMmPkg: assorted fixes and improvements This series addresses a number of issues I ran into while bringing up the standalone MM based authenticated variable store on the SynQuacer (AArch64) platform. Patches #1 - #3 are based on Jagadeesh's patch that imports some staging code into StandaloneMmPkg, with the following changes: - drop unused source files, GUID references are other unused bit, - clean up comments referring to the MM core implementation. Patches #4 - #9 are obvious fixes/improvements. Patch #10 adds support for TE formatted MM_CORE_STANDALONE binaries. This is useful given that the 4 KB section alignment we require in AArch64 implementations of standalone MM (due to the strict separation between code and date) results in 8 KB of wasted space at the start of the firmware volume. This can be reduced to 4 KB when using a TE image and the FIXED attribute in the associated [Rule] section, by leveraging an existing optimization in the FFS generation code that aligns TE images by reducing FFS padding rather than adding more. Patch #11 is another space optimization: it reuses the existing support for encapsulated compressed firmware volumes in FFS files to shrink the size of the primary standalone MM FV considerably. Again, due to alignment requirements, there is significant bloat in the uncompressed images (4 KB for the PE/COFF header, and up to 4 KB per section for the .text, .data and .reloc sections), making the absolute minimum size of any trivial MM_STANDALONE module 16 KB. Changes since v1: - add patches #1 - #3 - add Supreeth's ack to patches #4 - #7 Cc: Achin Gupta Cc: Jiewen Yao Cc: Supreeth Venkatesh Cc: Leif Lindholm Cc: Jagadeesh Ujja Cc: Thomas Panakamattam Abraham Cc: Sami Mujawar Ard Biesheuvel (11): StandaloneMmPkg: add HobLib implementation for MM_STANDALONE modules StandaloneMmPkg: add MM_STANDALONE MemoryAllocationLib implementation StandaloneMmPkg/StandaloneMmCoreHobLib: restrict to MM_CORE_STANDALONE StandaloneMmPkg/StandaloneMmCpu: fix typo Standlone -> Standalone StandaloneMmPkg/StandaloneMmCoreEntryPoint: add missing SerialPortLib ref StandaloneMmPkg/StandaloneMmCoreEntryPoint: use %a modifier for ASCII strings StandaloneMmPkg/StandaloneMmCoreEntryPoint: remove bogus ASSERT_EFI_ERROR()s StandaloneMmPkg/StandaloneMmPeCoffExtraActionLib: ignore runtime attribute StandaloneMmPkg/Core/Dispatcher: don't copy dispatched image twice StandaloneMmPkg/StandaloneMmCoreEntryPoint: permit the use of TE images StandaloneMmPkg/Core: permit encapsulated firmware volumes StandaloneMmPkg/Core/Dispatcher.c | 30 +- StandaloneMmPkg/Core/FwVol.c | 99 ++- StandaloneMmPkg/Core/StandaloneMmCore.inf | 1 + .../StandaloneMmCpu/AArch64/EventHandle.c | 2 +- .../StandaloneMmCpu/AArch64/StandaloneMmCpu.c | 6 +- .../StandaloneMmCpu/AArch64/StandaloneMmCpu.h | 8 +- .../AArch64/StandaloneMmCpu.inf | 4 +- .../AArch64/SetPermissions.c | 109 +-- .../AArch64/StandaloneMmCoreEntryPoint.c | 7 +- .../StandaloneMmCoreEntryPoint.inf| 4 + .../StandaloneMmCoreHobLib.inf| 2 +- .../StandaloneMmHobLib/StandaloneMmHobLib.c | 649 ++ .../StandaloneMmHobLib/StandaloneMmHobLib.inf | 45 + .../StandaloneMmMemoryAllocationLib.c | 822 ++ .../StandaloneMmMemoryAllocationLib.inf | 42 + .../StandaloneMmPeCoffExtraActionLib.c| 9 +- 16 files changed, 1716 insertions(+), 123 deletions(-) create mode 100644 StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.c create mode 100644 StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf create mode 100644 StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.c create mode 100644 StandaloneMmPkg/Library/StandaloneMmMemoryAllocationLib/StandaloneMmMemoryAllocationLib.inf -- 2.17.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] MdePkg/BasePeCoffLib: Correct the address of RelocBaseEnd
On Fri, Jan 18, 2019 at 04:08:57PM +0800, Dandan Bi wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426
>
> When calculating the address of RelocBaseEnd,
> the RelocBase address is ImageBase + RelocDir->VirtualAddress,
> the size of RelocDir is RelocDir->Size.
> So the RelocBaseEnd address is:
> ImageBase + RelocDir->VirtualAddress + RelocDir->Size - 1
> not
> ImageBase + RelocDir->VirtualAddress + RelocDir->Size
>
> This patch is to fix this issue when call PeCoffLoaderImageAddress
> function to calculate the address of RelocBaseEnd.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi
Thanks for the patch.
Tested-by: Gary Lin
> ---
> MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> index d9c94b89bd..1bd079ad6a 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> @@ -1741,11 +1741,11 @@ PeCoffLoaderRelocateImageForRuntime (
>//
>if (NumberOfRvaAndSizes > EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC) {
> RelocDir = DataDirectory + EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC;
> RelocBase = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress
> (, RelocDir->VirtualAddress, 0);
> RelocBaseEnd = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress
> (,
> -
> RelocDir->VirtualAddress + RelocDir->Size,
> +
> RelocDir->VirtualAddress + RelocDir->Size - 1,
> 0
>
> );
>} else {
> //
> // Cannot find relocations, cannot continue to relocate the image,
> ASSERT for this invalid image.
> --
> 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] MdeModulePkg/VarCheckLib: permit use by MM_STANDALONE modules
This patch does not touch VarCheckLib at all, but only touch VarCheckUefiLib,
so the title and commit message need be updated.
With them updated correctly, Reviewed-by: Star Zeng .
Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, January 17, 2019 5:22 AM
To: edk2-devel@lists.01.org
Cc: Ard Biesheuvel ; Kinney, Michael D
; Gao, Liming ; Ye, Ting
; Wei, Gang ; Wang, Jian J
; Zhang, Chao B ; Yao, Jiewen
; Wu, Hao A ; Zeng, Star
; Achin Gupta ; Jagadeesh Ujja
Subject: [PATCH 3/4] MdeModulePkg/VarCheckLib: permit use by MM_STANDALONE
modules
Permit VarCheckLib and VarCheckUefiLib to be used by MM_STANDALONE modules.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf| 4 ++--
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c | 9 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
index 128c44d695e1..8873fd51a02a 100644
--- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
@@ -19,9 +19,9 @@ [Defines]
BASE_NAME = VarCheckUefiLib
MODULE_UNI_FILE= VarCheckUefiLib.uni
FILE_GUID = AC24A4C7-F845-4665-90E5-6431D6E28DC0
- MODULE_TYPE= DXE_RUNTIME_DRIVER
+ MODULE_TYPE= BASE
VERSION_STRING = 1.0
- LIBRARY_CLASS = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
+ LIBRARY_CLASS = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER
MM_STANDALONE
CONSTRUCTOR= VarCheckUefiLibNullClassConstructor
#
diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
index 80dc6341adcf..5e419831e8cc 100644
--- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
+++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c
@@ -12,6 +12,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
**/
+#include
+
#include
#include
#include
@@ -927,15 +929,14 @@ VariablePropertySetUefiDefined (
@retval EFI_SUCCESS The constructor executed correctly.
**/
-EFI_STATUS
+RETURN_STATUS
EFIAPI
VarCheckUefiLibNullClassConstructor (
- IN EFI_HANDLE ImageHandle,
- IN EFI_SYSTEM_TABLE *SystemTable
+ VOID
)
{
VariablePropertySetUefiDefined ();
VarCheckLibRegisterSetVariableCheckHandler
(SetVariableCheckHandlerUefiDefined);
- return EFI_SUCCESS;
+ return RETURN_SUCCESS;
}
--
2.17.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [patch] MdePkg/BasePeCoffLib: Correct the address of RelocBaseEnd
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426
When calculating the address of RelocBaseEnd,
the RelocBase address is ImageBase + RelocDir->VirtualAddress,
the size of RelocDir is RelocDir->Size.
So the RelocBaseEnd address is:
ImageBase + RelocDir->VirtualAddress + RelocDir->Size - 1
not
ImageBase + RelocDir->VirtualAddress + RelocDir->Size
This patch is to fix this issue when call PeCoffLoaderImageAddress
function to calculate the address of RelocBaseEnd.
Cc: Michael D Kinney
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi
---
MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
index d9c94b89bd..1bd079ad6a 100644
--- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
+++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
@@ -1741,11 +1741,11 @@ PeCoffLoaderRelocateImageForRuntime (
//
if (NumberOfRvaAndSizes > EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC) {
RelocDir = DataDirectory + EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC;
RelocBase = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress
(, RelocDir->VirtualAddress, 0);
RelocBaseEnd = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress
(,
-
RelocDir->VirtualAddress + RelocDir->Size,
+
RelocDir->VirtualAddress + RelocDir->Size - 1,
0
);
} else {
//
// Cannot find relocations, cannot continue to relocate the image, ASSERT
for this invalid image.
--
2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
