Date   

Re: Request for help understanding MemoryOverwriteRequestControl

Laszlo Ersek
 

On 09/29/20 15:57, Yao, Jiewen wrote:
Thanks Laszlo to explain that.

One minor comments:

TCG adopted Secure MOR in latest MOR 1.1 spec in 2019 - https://trustedcomputinggroup.org/resource/pc-client-work-group-platform-reset-attack-mitigation-specification/

So it is a TCG standard now.
Ah, thanks. :) I'll have to refresh my local PDF then!
Laszlo


Re: ESRT in OVMF

Tomas Pilar (tpilar)
 

Hi Sandeep,

You should probably discuss on this list what you want to add to the main
tree before sending patches, you might get good pointers. Otherwise, there
is a good guide as to how it works here:
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers
.

Cheers,
Tom


On Tue, Sep 22, 2020 at 6:23 AM Sandeep Dhanvada <
sandeep.dhanvada@xilinx.com> wrote:

Hi,

I am able to upgrade firmware using CaspsuleApp.efi with the help of Tomas
Pilar in other thread in this mailing list.

however, i have some modifications in edk2 source code for this to happen.
please let me know what is the process for sending patches to mailing list.

Thanks,
Sandeep






Re: how to fix compile warning: cannot find entry symbol _ModuleEntryPoint

wenyi,xie
 

Thanks, Andrew, Laszlo and liming, with your help I find the module which really own the warning.

As the compile is multithreading, the order in compile log is not right. The module which cause warning is written by ourselves.
In this module's inf file, MODULE_TYPE is set as USER_DEFINED, and UefiDriverEntryPoint is not set in [LibraryClasses].

On 2020/9/30 0:00, Andrew Fish wrote:
Wenyi,

If you look under the Build results   <Platform>/<DEBUG/RELEASE>_<COMPILER>/AArch64/Edk2/ArmPkg/Drivers/ArmGic/ (hopefully I got that right) and go down a little bit you will see the build generated GNUmakefile. You might want to take a look at that to try and figure out what is going on?

Thanks,

Andrew Fish


On Sep 29, 2020, at 7:23 AM, wenyi,xie via groups.io <http://groups.io> <xiewenyi2=huawei.com@groups.io <mailto:xiewenyi2=huawei.com@groups.io>> wrote:

I checked my platform DSC and there's UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf in the section [LibraryClasses.common].
I'm not sure why _ModuleEntryPoint can't be found when link the object.

Regards
Wenyi

On 2020/9/29 2:21, Laszlo Ersek wrote:
On 09/28/20 10:57, wenyi,xie via groups.io <http://groups.io> wrote:
Hi, all
I use edk2-stable201903 in my project and meet a compile warning like below,

/opt/buildtools/gcc-linaro-7.4.1-2019.02/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.4.1/../../../../aarch64-linux-gnu/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; not setting start address

It seems like the warning happens when building EDKII/Edk2/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
does anyone know how to fix it?
If need more info, please contact me, thanks!

here's some of my build option, 
Architecture(s)  = AARCH64
Build target     = RELEASE
Toolchain        = GCC5
The UefiDriverEntryPoint lib class in the [Sources] section in
"ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" should be resolved by your
platform DSC to
"MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf".

That's where the definition of _ModuleEntryPoint() should come from (see
"MdePkg/Library/UefiDriverEntryPoint/DriverEntryPoint.c").

Thanks
Laszlo


Re: how to fix compile warning: cannot find entry symbol _ModuleEntryPoint

wenyi,xie
 

I checked my platform DSC and there's UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf in the section [LibraryClasses.common].
I'm not sure why _ModuleEntryPoint can't be found when link the object.

Regards
Wenyi

On 2020/9/29 2:21, Laszlo Ersek wrote:
On 09/28/20 10:57, wenyi,xie via groups.io wrote:
Hi, all
I use edk2-stable201903 in my project and meet a compile warning like below,

/opt/buildtools/gcc-linaro-7.4.1-2019.02/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.4.1/../../../../aarch64-linux-gnu/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; not setting start address

It seems like the warning happens when building EDKII/Edk2/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
does anyone know how to fix it?
If need more info, please contact me, thanks!

here's some of my build option,
Architecture(s) = AARCH64
Build target = RELEASE
Toolchain = GCC5
The UefiDriverEntryPoint lib class in the [Sources] section in
"ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" should be resolved by your
platform DSC to
"MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf".

That's where the definition of _ModuleEntryPoint() should come from (see
"MdePkg/Library/UefiDriverEntryPoint/DriverEntryPoint.c").

Thanks
Laszlo


Re: Request for help understanding MemoryOverwriteRequestControl

Laszlo Ersek
 

+Jiewen, comments below

On 09/24/20 11:36, Martyn Welch wrote:
Hi,

We have a number of MinnowBoards (both Turbot and Max variants) here
that are used for various Linux development purposes, including having
a number that are used in our LAVA farm which among other things runs
Linux KernelCI jobs. The firmware on these devices is currently
"MNW2MAX1.X64.0101.R01.1908071815" as downloaded from the Intel site:

https://software.intel.com/content/www/us/en/develop/articles/minnowboard-maxturbot-uefi-firmware.html

We are seeing the following message during boot on *some* of the
boards, but not others:

Clear memory in MRC per MOR request Start, Please wait for some
minutes...
Side comment:

Wow! I very much suspected that the memory overwrite is performed on
physical platforms via proprietary DIMM or board access, not via plain
RAM writes. The above "MRC" reference confirms it.


We have "CONFIG_RESET_ATTACK_MITIGATION" set in the Linux kernel
configuration, which I understand will cause the
"MemoryOverwriteRequest" bit to be set during boot and hence trigger
this behaviour (unless explicitly cleared before the board is reset).
Yes, see commit ccc829ba3624 ("efi/libstub: Enable reset attack
mitigation", 2017-08-26).

(Side comment regarding historical Fedora kernels:
<https://bugzilla.redhat.com/show_bug.cgi?id=1498159>.)

The config knob's documentation was later extended in commit
a5c03c31af22 ("x86/efi: Clarify that reset attack mitigation needs
appropriate userspace", 2018-01-19).


Some of our boards seem to only be exposing the related
"MemoryOverwriteRequestControlLock" EFI variable:

Shell> dmpstore -guid e20939be-32d4-41be-a150-897f85d49829
dmpstore: No matching variables found. Guid E20939BE-32D4-41BE-
A150-897F85D49829
Shell> dmpstore -guid bb983ccf-151d-40e1-a07b-4a17be168292
Variable NV+RT+BS 'BB983CCF-151D-40E1-A07B-
4A17BE168292:MemoryOverwriteRequestControlLock' DataSize = 0x01
00000000: 00 *.*

Thus this behaviour isn't triggered. Others expose both
"MemoryOverwriteRequestControl" and
"MemoryOverwriteRequestControlLock":

Shell> dmpstore -guid e20939be-32d4-41be-a150-897f85d49829
Variable NV+RT+BS 'E20939BE-32D4-41BE-A150-
897F85D49829:MemoryOverwriteRequestControl' DataSize = 0x01
00000000: 01 *.*

Shell> dmpstore -guid bb983ccf-151d-40e1-a07b-4a17be168292
Variable NV+RT+BS 'BB983CCF-151D-40E1-A07B-
4A17BE168292:MemoryOverwriteRequestControlLock' DataSize = 0x01
00000000: 00 *.*
MemoryOverwriteRequestControlLock is a Microsoft- (not TCG-) originated
hardening:

https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-requirements

It's been a while since I last thought about it, but basically it's a
way to prevent the attacker from even attempting to clear the MOR bit in
the original MemoryOverwriteRequestControl variable, before they'd force
a platform reset.


The situation where you see MOR Control Lock variable but not the MOR
Control variable, was a bug in edk2. It has been fixed under

https://bugzilla.tianocore.org/show_bug.cgi?id=727

(We first encountered this issue in
<https://bugzilla.redhat.com/show_bug.cgi?id=1496170>.)

My understanding is that we should be seeing both these EFI variables
being exposed. I'm rather unfamiliar with the EDK codebase and have not
been able to work out how I would end up with
"MemoryOverwriteRequestControlLock" and not
"MemoryOverwriteRequestControl".
More precisely, the valid cases are:

- none of them present (= system doesn't support the Platform Reset
Attack Mitigation from the TCG)

- MOR Control is present, but MOR Control Lock is not (= the TCG spec is
supported, but the Microsoft-defined hardening is not)

- both MOR Control and MOR Control Lock are present (= both specs are
supported)


I've tried using `J7` to reset the NVRAM on a board just exposing
"MemoryOverwriteRequestControlLock", following the process described
here to see if it would have an effect and it hasn't:

https://uchan.hateblo.jp/entry/2018/01/09/075230
Yes, with the bug present, the firmware would re-create MOR Control
Lock. See TianoCore#727 (link above).

One of the boards in our LAVA instance was initially only exposing the
lock variable, but then seemingly randomly started to expose the other
variable and perform the erase at boot. I've not been able to determine
what triggered this change in behaviour.
This seems vaguely consistent with the OS kernel being buggy too (that
is, <https://bugzilla.redhat.com/show_bug.cgi?id=1498159>), *or else*
with your Linux userspace not clearing the MOR bit in the MOR Control
variable, as a part of the controlled OS shutdown.

Any help/pointers would be much appreciated.
I would suggest:

(1) Upgrade the platform firmware to a version that contains the edk2
commit range fixing TianoCore#727 (namely 35ac962b5473..fda8f631edbb).
This prevents the out-of-spec situation where only MOR Control Lock
exists. (While that situation is not your acute problem now, it's best
to get it solved too.)

(2) Make sure your kernel does not *create* MOR Control under any
circumstances, only modifies it if it exists.

(3) Either remove CONFIG_RESET_ATTACK_MITIGATION from your kernel
config, or verify that your userspace clears the MOR bit in MOR Control
before a controlled OS shutdown. (To be honest, I don't know what Linux
distributions satisfy the userspace requirement, as
CONFIG_RESET_ATTACK_MITIGATION is not enabled in RHEL8 for example, as
far as I can see.)

Thanks
Laszlo


Re: How to Add an USB device to the Emulator?

Guomin Jiang
 

Which emulator? Ovmf?
Which USB? Real or Virtual?

Thanks,
Guomin

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Rocky Liao
Sent: Tuesday, September 15, 2020 3:54 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] How to Add an USB device to the Emulator?

Hi,

I am wondering is there a way to expose an USB device to the emulator and
develop the usb driver over the emulator?




Request for help understanding MemoryOverwriteRequestControl

Martyn Welch <martyn.welch@...>
 

Hi,

We have a number of MinnowBoards (both Turbot and Max variants) here
that are used for various Linux development purposes, including having
a number that are used in our LAVA farm which among other things runs
Linux KernelCI jobs. The firmware on these devices is currently
"MNW2MAX1.X64.0101.R01.1908071815" as downloaded from the Intel site:

https://software.intel.com/content/www/us/en/develop/articles/minnowboard-maxturbot-uefi-firmware.html

We are seeing the following message during boot on *some* of the
boards, but not others:

Clear memory in MRC per MOR request Start, Please wait for some
minutes...

We have "CONFIG_RESET_ATTACK_MITIGATION" set in the Linux kernel
configuration, which I understand will cause the
"MemoryOverwriteRequest" bit to be set during boot and hence trigger
this behaviour (unless explicitly cleared before the board is reset).

Some of our boards seem to only be exposing the related
"MemoryOverwriteRequestControlLock" EFI variable:

Shell> dmpstore -guid e20939be-32d4-41be-a150-897f85d49829
dmpstore: No matching variables found. Guid E20939BE-32D4-41BE-
A150-897F85D49829
Shell> dmpstore -guid bb983ccf-151d-40e1-a07b-4a17be168292
Variable NV+RT+BS 'BB983CCF-151D-40E1-A07B-
4A17BE168292:MemoryOverwriteRequestControlLock' DataSize = 0x01
00000000: 00 *.*

Thus this behaviour isn't triggered. Others expose both
"MemoryOverwriteRequestControl" and
"MemoryOverwriteRequestControlLock":

Shell> dmpstore -guid e20939be-32d4-41be-a150-897f85d49829
Variable NV+RT+BS 'E20939BE-32D4-41BE-A150-
897F85D49829:MemoryOverwriteRequestControl' DataSize = 0x01
00000000: 01 *.*

Shell> dmpstore -guid bb983ccf-151d-40e1-a07b-4a17be168292
Variable NV+RT+BS 'BB983CCF-151D-40E1-A07B-
4A17BE168292:MemoryOverwriteRequestControlLock' DataSize = 0x01
00000000: 00 *.*

My understanding is that we should be seeing both these EFI variables
being exposed. I'm rather unfamiliar with the EDK codebase and have not
been able to work out how I would end up with
"MemoryOverwriteRequestControlLock" and not
"MemoryOverwriteRequestControl".

I've tried using `J7` to reset the NVRAM on a board just exposing
"MemoryOverwriteRequestControlLock", following the process described
here to see if it would have an effect and it hasn't:

https://uchan.hateblo.jp/entry/2018/01/09/075230

One of the boards in our LAVA instance was initially only exposing the
lock variable, but then seemingly randomly started to expose the other
variable and perform the erase at boot. I've not been able to determine
what triggered this change in behaviour.

Any help/pointers would be much appreciated.

Thanks in advance,

Martyn


Re: 答复: About edk2-platforms release

wanghuiqiang <wanghuiqiang@...>
 

Hi Leif,

Just want to make sure you received my previous mail, do you have any comments for the edk2-platform formal release? Waiting for you reply.

Thanks!

-----邮件原件-----
发件人: wanghuiqiang
发送时间: 2020年9月2日 13:54
收件人: Leif Lindholm <leif@nuviainc.com>
抄送: Michael D Kinney <michael.d.kinney@intel.com>; discuss@edk2.groups.io; ard.biesheuvel@linaro.org; Songdongkuang <songdongkuang@huawei.com>; Lidongzhan <lidongzhan@huawei.com>; qiuliangen <qiuliangen@huawei.com>; Shenlimei <shenlimei@huawei.com>; John Garry <john.garry@huawei.com>; Tangxingjiang <tangxingjiang@huawei.com>
主题: 答复: About edk2-platforms release

Hi Leif,

Do you think that we have formal release version for edk2-platform? just like Linux and other open source software.

Thanks!

-----邮件原件-----
发件人: Huangming (Mark)
发送时间: 2020年6月30日 20:50
收件人: Leif Lindholm <leif@nuviainc.com>
抄送: Michael D Kinney <michael.d.kinney@intel.com>; discuss@edk2.groups.io; ard.biesheuvel@linaro.org; Songdongkuang <songdongkuang@huawei.com>; Lidongzhan <lidongzhan@huawei.com>; wanghuiqiang <wanghuiqiang@huawei.com>; qiuliangen <qiuliangen@huawei.com>; Shenlimei <shenlimei@huawei.com>; John Garry <john.garry@huawei.com>
主题: Re: About edk2-platforms release



在 2020/6/30 19:56, Leif Lindholm 写道:
Hi Ming, (+Mike, -Martin)

(Apologies, I had last week off work.)

On Tue, Jun 23, 2020 at 14:02:59 +0000, Huangming (Mark) wrote:
Right now we are using edk2-platforms open source code as a part to
build our ARM platform UEFI implementations.
Due to our production development work flow, we need to upload a
formal edk2-platforms open source release tar ball to our company
database as a reference.

As edk2-platforms doesn't have release, it is hard for us to explain
to company audit office where the code comes from and why this open
source doesn't have release.
So - first of all, you can always reference a commit hash for your
upload. That will never change.

So is it possible to release edk2-platforms just like edk2 release
every three months?
We have discussed doing that. Realistically, I don't think we're going
to hit that for 2020.08, but having public requests for it like this
will certainly help push it higher up on the todo list.
As almost all of open source projects have release version, if possible we wish edk2-platforms can have released version for 2020.11.

Thanks,
Ming


Best Regards,

Leif

.


How to Add an USB device to the Emulator?

Rocky Liao <rjliao@...>
 

Hi,

I am wondering is there a way to expose an USB device to the emulator and develop the usb driver over the emulator?


回复: [edk2-discuss] how to fix compile warning: cannot find entry symbol _ModuleEntryPoint

gaoliming
 

ModuleEntryPoint is provided by EntryPointLib. This driver links MdePkg\Library\UefiDriverEntryPoint. Please check.

-----邮件原件-----
发件人: bounce+34241+373+4905953+8764802@groups.io
<bounce+34241+373+4905953+8764802@groups.io> 代表 wenyi,xie via
groups.io
发送时间: 2020年9月28日 16:57
收件人: discuss@edk2.groups.io
主题: [edk2-discuss] how to fix compile warning: cannot find entry symbol
_ModuleEntryPoint

Hi, all
I use edk2-stable201903 in my project and meet a compile warning like
below,

/opt/buildtools/gcc-linaro-7.4.1-2019.02/aarch64-linux-gnu/bin/../lib/gcc/aa
rch64-linux-gnu/7.4.1/../../../../aarch64-linux-gnu/bin/ld: warning: cannot
find entry symbol _ModuleEntryPoint; not setting start address

It seems like the warning happens when building
EDKII/Edk2/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
does anyone know how to fix it?
If need more info, please contact me, thanks!

here's some of my build option,
Architecture(s) = AARCH64
Build target = RELEASE
Toolchain = GCC5






回复: [edk2-discuss] GCD initialization and memory allocation HOBs

gaoliming
 

Jeff:

-----邮件原件-----
发件人: bounce+34241+372+4905953+8764802@groups.io
<bounce+34241+372+4905953+8764802@groups.io> 代表 Jeff Brasen
发送时间: 2020年9月26日 1:08
收件人: discuss@edk2.groups.io; lersek@redhat.com
主题: Re: [edk2-discuss] GCD initialization and memory allocation HOBs

#2 is the case we are in, we have data that is loaded by our pre-UEFI
bootloaders into memory that should behave as boot services memory (OS
can reclaim this) When we setup our HOB list we added a normal system
memory resource that covers both the HOB list and this other data. We then
add a memory allocation HOB to mark this memory as boot services data. We
are seeing cases where CoreInitializeMemoryServices Is selecting the region
that has this data and is both causing corruption as well as preventing the
memory allocation hob from being processed correctly as the memory is not
free when GCD parses it.
You mean the memory range specified by PHIT resource hob is selected by CoreInitializeMemoryServices().
This memory range includes PEI memory and the allocated memory. So, there is no
free memory in this memory range. After CoreInitializeMemoryServices(), do you meet with memory allocation failure?

Can you attach the failure boot log for further analysis?

Thanks
Liming
We can easily work around this particular issue by splitting the system
memory resource so that GCD then goes to look for space in the free region in
the hob or at the beginning of the resource that contains the HOB list. But if
we don't have enough space in those regions then it will look for other
memory regions and it doesn't seem like the best practice to design the HOB
producer with the specific implementation of GCD services.

It seems that if we have memory allocation data that is in outside the HOB list
itself we could hit this problem, and this seems valid per my reading of the PI
spec.

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Laszlo
Ersek
Sent: Friday, September 25, 2020 3:06 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com>
Cc: Jan Bobek <jbobek@nvidia.com>; Ashish Singhal
<ashishsingha@nvidia.com>
Subject: Re: [edk2-discuss] GCD initialization and memory allocation HOBs

External email: Use caution opening links or attachments


On 09/24/20 20:40, Jeff Brasen wrote:
It looks like CoreInitializeMemoryServices
(https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229
c
ec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116)
does not honor any memory allocations outside of the HOB list itself.
Should we add code to this function to make sure the region this
function select does not end up over a reserved region that the HOB
producer phase marked as already allocated? Either that or codify the
specific requirements a bit more on to make sure cases like this are
invalid. (producer might have to split up system resource entries,
etc)
Do you mean

(1) a physically reserved memory address range
(EFI_RESOURCE_MEMORY_RESERVED), or

(2) normal RAM (EFI_RESOURCE_SYSTEM_MEMORY) that is meant to be
"repurposed" (= pre-allocated) in PEI as a particular UEFI memory type?

EFI_HOB_RESOURCE_DESCRIPTOR "does not describe how memory is used
but instead describes the attributes of the physical memory present".

CoreInitializeMemoryServices() honors (1).

CoreInitializeMemoryServices() does not honor (2); however, the later
function CoreInitializeGcdServices() does honor (2).


* Regarding (1):

My understanding is that the HOB producer phase should describe "physically
reserved" memory regions with EFI_RESOURCE_MEMORY_RESERVED
resource descriptor HOBs, and these should not overlap normal memory
regions, which are described with EFI_RESOURCE_SYSTEM_MEMORY
descriptor HOBs.

Furthermore, whether (a part of) a memory resource is allocated or not, is
*orthogonal* to whether the memory resource is "physically reserved
memory" or "normal RAM". In my opinion, the diagram at

PI 1.7
Volume 2 (DXE Core Interface)
7.2.2 GCD Memory Resources
Figure 2. GCD Memory State Transitions

applies.

So the HOB producer phase should firstly describe the area in question as
EFI_RESOURCE_MEMORY_RESERVED (without overlapping any other
resource descriptor in memory address space).

Secondly, if the HOB producer phase wants to prevent DXE modules from
allocating reserved memory out of this resource, then the HOB producer
phase should *also* cover the entire range with a memalloc HOB that uses
EfiReservedMemoryType.

The first step above (= describing the area with an
EFI_RESOURCE_MEMORY_RESERVED HOB) will activate the following branch
in
CoreInitializeMemoryServices():

//
// Skip Resource Descriptor HOBs that do not describe tested system
memory
//
ResourceHob = Hob.ResourceDescriptor;
if (ResourceHob->ResourceType !=
EFI_RESOURCE_SYSTEM_MEMORY) {
continue;
}

* Regarding (2):

Normal (= not physically reserved) RAM that is allocated in PEI -- using
memalloc HOBs with various UEFI memory types, such as BS Data or AcpiNVS
-- is set aside in the CoreInitializeGcdServices() function.

Is that too late for your purpose? If so, why?

AIUI, CoreInitializeGcdServices() does make sure that DXE-phase calls to
gDS->AllocateMemorySpace(), gBS->AllocatePool(), and friends, will not
trample over the original memalloc HOBs.

Thanks,
Laszlo










Re: how to fix compile warning: cannot find entry symbol _ModuleEntryPoint

Laszlo Ersek
 

On 09/28/20 10:57, wenyi,xie via groups.io wrote:
Hi, all
I use edk2-stable201903 in my project and meet a compile warning like below,

/opt/buildtools/gcc-linaro-7.4.1-2019.02/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.4.1/../../../../aarch64-linux-gnu/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; not setting start address

It seems like the warning happens when building EDKII/Edk2/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
does anyone know how to fix it?
If need more info, please contact me, thanks!

here's some of my build option,
Architecture(s) = AARCH64
Build target = RELEASE
Toolchain = GCC5
The UefiDriverEntryPoint lib class in the [Sources] section in
"ArmPkg/Drivers/ArmGic/ArmGicDxe.inf" should be resolved by your
platform DSC to
"MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf".

That's where the definition of _ModuleEntryPoint() should come from (see
"MdePkg/Library/UefiDriverEntryPoint/DriverEntryPoint.c").

Thanks
Laszlo


Re: compile warning from BaseTools

Laszlo Ersek
 

On 09/28/20 16:10, wenyi,xie via groups.io wrote:
Hi all,
I meet some compile warning in BaseTools,the version of EDK2 is edk2-stable201903, as I am not familiar with Antlr grammer, I don't know how to fix it.
Could someone give me a hand, thanks!

VfrSyntax.g, line 2018: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 2023: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 3651: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3660: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3669: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3679: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3709: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3718: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
I think I've always just ignored these...

Laszlo


compile warning from BaseTools

wenyi,xie
 

Hi all,
I meet some compile warning in BaseTools,the version of EDK2 is edk2-stable201903, as I am not familiar with Antlr grammer, I don't know how to fix it.
Could someone give me a hand, thanks!

VfrSyntax.g, line 2018: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 2023: warning: predicate: LT(i) missing, bad, or with i=0; assuming i=1
VfrSyntax.g, line 3651: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3660: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3669: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3679: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3709: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )
VfrSyntax.g, line 3718: warning: alts 1 and 2 of {..} ambiguous upon ( ";" RefreshGuid GuidOp Locked Image EndIf InconsistentIf DisableIf SuppressIf Default GrayOutIf )


how to fix compile warning: cannot find entry symbol _ModuleEntryPoint

wenyi,xie
 

Hi, all
I use edk2-stable201903 in my project and meet a compile warning like below,

/opt/buildtools/gcc-linaro-7.4.1-2019.02/aarch64-linux-gnu/bin/../lib/gcc/aarch64-linux-gnu/7.4.1/../../../../aarch64-linux-gnu/bin/ld: warning: cannot find entry symbol _ModuleEntryPoint; not setting start address

It seems like the warning happens when building EDKII/Edk2/ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
does anyone know how to fix it?
If need more info, please contact me, thanks!

here's some of my build option,
Architecture(s) = AARCH64
Build target = RELEASE
Toolchain = GCC5


Re: GCD initialization and memory allocation HOBs

Jeff Brasen
 

#2 is the case we are in, we have data that is loaded by our pre-UEFI bootloaders into memory that should behave as boot services memory (OS can reclaim this) When we setup our HOB list we added a normal system memory resource that covers both the HOB list and this other data. We then add a memory allocation HOB to mark this memory as boot services data. We are seeing cases where CoreInitializeMemoryServices Is selecting the region that has this data and is both causing corruption as well as preventing the memory allocation hob from being processed correctly as the memory is not free when GCD parses it.

We can easily work around this particular issue by splitting the system memory resource so that GCD then goes to look for space in the free region in the hob or at the beginning of the resource that contains the HOB list. But if we don't have enough space in those regions then it will look for other memory regions and it doesn't seem like the best practice to design the HOB producer with the specific implementation of GCD services.

It seems that if we have memory allocation data that is in outside the HOB list itself we could hit this problem, and this seems valid per my reading of the PI spec.

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Laszlo Ersek
Sent: Friday, September 25, 2020 3:06 AM
To: discuss@edk2.groups.io; Jeff Brasen <jbrasen@nvidia.com>
Cc: Jan Bobek <jbobek@nvidia.com>; Ashish Singhal <ashishsingha@nvidia.com>
Subject: Re: [edk2-discuss] GCD initialization and memory allocation HOBs

External email: Use caution opening links or attachments


On 09/24/20 20:40, Jeff Brasen wrote:
It looks like CoreInitializeMemoryServices
(https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229c
ec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116)
does not honor any memory allocations outside of the HOB list itself.
Should we add code to this function to make sure the region this
function select does not end up over a reserved region that the HOB
producer phase marked as already allocated? Either that or codify the
specific requirements a bit more on to make sure cases like this are
invalid. (producer might have to split up system resource entries,
etc)
Do you mean

(1) a physically reserved memory address range (EFI_RESOURCE_MEMORY_RESERVED), or

(2) normal RAM (EFI_RESOURCE_SYSTEM_MEMORY) that is meant to be "repurposed" (= pre-allocated) in PEI as a particular UEFI memory type?

EFI_HOB_RESOURCE_DESCRIPTOR "does not describe how memory is used but instead describes the attributes of the physical memory present".

CoreInitializeMemoryServices() honors (1).

CoreInitializeMemoryServices() does not honor (2); however, the later function CoreInitializeGcdServices() does honor (2).


* Regarding (1):

My understanding is that the HOB producer phase should describe "physically reserved" memory regions with EFI_RESOURCE_MEMORY_RESERVED resource descriptor HOBs, and these should not overlap normal memory regions, which are described with EFI_RESOURCE_SYSTEM_MEMORY descriptor HOBs.

Furthermore, whether (a part of) a memory resource is allocated or not, is *orthogonal* to whether the memory resource is "physically reserved memory" or "normal RAM". In my opinion, the diagram at

PI 1.7
Volume 2 (DXE Core Interface)
7.2.2 GCD Memory Resources
Figure 2. GCD Memory State Transitions

applies.

So the HOB producer phase should firstly describe the area in question as EFI_RESOURCE_MEMORY_RESERVED (without overlapping any other resource descriptor in memory address space).

Secondly, if the HOB producer phase wants to prevent DXE modules from allocating reserved memory out of this resource, then the HOB producer phase should *also* cover the entire range with a memalloc HOB that uses EfiReservedMemoryType.

The first step above (= describing the area with an EFI_RESOURCE_MEMORY_RESERVED HOB) will activate the following branch in
CoreInitializeMemoryServices():

//
// Skip Resource Descriptor HOBs that do not describe tested system memory
//
ResourceHob = Hob.ResourceDescriptor;
if (ResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY) {
continue;
}

* Regarding (2):

Normal (= not physically reserved) RAM that is allocated in PEI -- using memalloc HOBs with various UEFI memory types, such as BS Data or AcpiNVS
-- is set aside in the CoreInitializeGcdServices() function.

Is that too late for your purpose? If so, why?

AIUI, CoreInitializeGcdServices() does make sure that DXE-phase calls to
gDS->AllocateMemorySpace(), gBS->AllocatePool(), and friends, will not
trample over the original memalloc HOBs.

Thanks,
Laszlo


Re: GCD initialization and memory allocation HOBs

Laszlo Ersek
 

On 09/24/20 20:40, Jeff Brasen wrote:
It looks like CoreInitializeMemoryServices
(https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229cec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116)
does not honor any memory allocations outside of the HOB list itself.
Should we add code to this function to make sure the region this
function select does not end up over a reserved region that the HOB
producer phase marked as already allocated? Either that or codify the
specific requirements a bit more on to make sure cases like this are
invalid. (producer might have to split up system resource entries,
etc)
Do you mean

(1) a physically reserved memory address range
(EFI_RESOURCE_MEMORY_RESERVED), or

(2) normal RAM (EFI_RESOURCE_SYSTEM_MEMORY) that is meant to be
"repurposed" (= pre-allocated) in PEI as a particular UEFI memory type?


EFI_HOB_RESOURCE_DESCRIPTOR "does not describe how memory is used but
instead describes the attributes of the physical memory present".

CoreInitializeMemoryServices() honors (1).

CoreInitializeMemoryServices() does not honor (2); however, the later
function CoreInitializeGcdServices() does honor (2).


* Regarding (1):

My understanding is that the HOB producer phase should describe
"physically reserved" memory regions with EFI_RESOURCE_MEMORY_RESERVED
resource descriptor HOBs, and these should not overlap normal memory
regions, which are described with EFI_RESOURCE_SYSTEM_MEMORY descriptor
HOBs.

Furthermore, whether (a part of) a memory resource is allocated or not,
is *orthogonal* to whether the memory resource is "physically reserved
memory" or "normal RAM". In my opinion, the diagram at

PI 1.7
Volume 2 (DXE Core Interface)
7.2.2 GCD Memory Resources
Figure 2. GCD Memory State Transitions

applies.

So the HOB producer phase should firstly describe the area in question
as EFI_RESOURCE_MEMORY_RESERVED (without overlapping any other resource
descriptor in memory address space).

Secondly, if the HOB producer phase wants to prevent DXE modules from
allocating reserved memory out of this resource, then the HOB producer
phase should *also* cover the entire range with a memalloc HOB
that uses EfiReservedMemoryType.

The first step above (= describing the area with an
EFI_RESOURCE_MEMORY_RESERVED HOB) will activate the following branch in
CoreInitializeMemoryServices():

//
// Skip Resource Descriptor HOBs that do not describe tested system memory
//
ResourceHob = Hob.ResourceDescriptor;
if (ResourceHob->ResourceType != EFI_RESOURCE_SYSTEM_MEMORY) {
continue;
}

* Regarding (2):

Normal (= not physically reserved) RAM that is allocated in PEI -- using
memalloc HOBs with various UEFI memory types, such as BS Data or AcpiNVS
-- is set aside in the CoreInitializeGcdServices() function.

Is that too late for your purpose? If so, why?

AIUI, CoreInitializeGcdServices() does make sure that DXE-phase calls to
gDS->AllocateMemorySpace(), gBS->AllocatePool(), and friends, will not
trample over the original memalloc HOBs.

Thanks,
Laszlo


GCD initialization and memory allocation HOBs

Jeff Brasen
 

It looks like CoreInitializeMemoryServices (https://github.com/tianocore/edk2/blob/dd5c7e3c5282b084daa5bbf0ec229cec699b2c17/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2116) does not honor any memory allocations outside of the HOB list itself. Should we add code to this function to make sure the region this function select does not end up over a reserved region that the HOB producer phase marked as already allocated? Either that or codify the specific requirements a bit more on to make sure cases like this are invalid. (producer might have to split up system resource entries, etc)

We can work on a change if we decide that we want to improve GCD but wanted to get feedback before we started on this.

Thanks,
Jeff


Build failure because of the new dependency

Zhiguang Liu
 

Hi, Matthew,
I notice the below change has broken Intel platform build or module build whichever uses OpensslLib(Crypto).inf, because it can't find the new dependency RngLib
I understand there may be many platforms to fix and may take some time. If you have time, could you please fix this issue? Thanks a lot.

Thanks
Zhiguang

SHA-1: b5701a4c7a0fb185e0c5b9db9525939c78664bfd

* CryptoPkg: OpensslLib: Use RngLib to generate entropy in rand_pool

Ref: https://github.com/tianocore/edk2/pull/845
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871

Changes OpenSSL to no longer depend on TimerLib and instead use RngLib.
This allows platforms to decide for themsevles what sort of entropy source
they provide to OpenSSL and TlsLib.

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>

Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>


Re: ESRT in OVMF

Sandeep Dhanvada
 

Hi,

I am able to upgrade firmware using CaspsuleApp.efi with the help of Tomas Pilar in other thread in this mailing list.

however, i have some modifications in edk2 source code for this to happen. please let me know what is the process for sending patches to mailing list.

Thanks,
Sandeep

481 - 500 of 862