date:20230817

Re: [edk2-devel] [PATCH V2 0/2] Add ProcessorUpgradeSocket definitions from SMBIOS 3.7.0

2023-08-17 Thread Zeng, Star

I have given review to both patches and Zhichao has given review to ShellPkg 
patch.
Liming, need your help to review and merge the patches. 


Thanks,
Star
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Eduardo Cuevas 
Farfan
Sent: Friday, August 11, 2023 12:32 AM
To: devel@edk2.groups.io
Cc: Cuevas Farfan, Eduardo 
Subject: [edk2-devel] [PATCH V2 0/2] Add ProcessorUpgradeSocket definitions 
from SMBIOS 3.7.0

Add ProcessorUpgradeSocket definitions from SMBIOS 3.7.0 to edk2 sources

Eduardo Cuevas Farfan (2):
  MdePkg: Add ProcessorUpgradeSocket definitions from SMBIOS 3.7.0
  ShellPkg: Add ProcessorUpgradeSocket definitions from SMBIOS 3.7.0

 MdePkg/Include/IndustryStandard/SmBios.h  | 12 +--
 .../SmbiosView/QueryTable.c   | 34 ++-
 2 files changed, 43 insertions(+), 3 deletions(-)

-- 
2.26.2.windows.1








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107842): https://edk2.groups.io/g/devel/message/107842
Mute This Topic: https://groups.io/mt/100667108/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] About EDK2 supports Self Modifying Code

2023-08-17 Thread Andrew Fish via groups.io



> On Aug 17, 2023, at 12:53 PM, Michael D Kinney  
> wrote:
> 
> How many different integer values are needed by FW for use of the csrrd 
> instruction?
>  

MIke,

I’m no expert on this and I just tried to site read a specification for the 1st 
time….
It looks to me the like the arch spec does not say something like mm0 - mm7 it 
seems to imply mm0 - mmN (N is implementation defined). Some of these resources 
seemed to be debug registers and performance counters, so things that make a 
lot of sense to have a variable number defined by the implementation? 

Thanks,

Andrew Fish

> There are examples of access functions on x86 for things like mm0, mm1, mm2, 
> …, mm7 and cs, ds, es, ss, fs, gs.  These are implemented as different 
> BaseLib APIs because they would also require SMC to do in a single API.
>  
> If there is a small number of csrrd index values that need to be accessed, 
> and they have standard names, then perhaps you could define a set of APIs to 
> access those registers.
>  
> Mike
>  
> From: devel@edk2.groups.io  
> mailto:devel@edk2.groups.io>> On Behalf Of Chao Li
> Sent: Wednesday, August 16, 2023 7:30 PM
> To: devel@edk2.groups.io ; 
> pedro.falc...@gmail.com 
> Cc: Andrew (EFI) Fish mailto:af...@apple.com>>; Gao, Liming 
> mailto:gaolim...@byosoft.com.cn>>; Feng, Bob C 
> mailto:bob.c.f...@intel.com>>; Chen, Christine 
> mailto:yuwei.c...@intel.com>>
> Subject: Re: [edk2-devel] About EDK2 supports Self Modifying Code
>  
> Hi Pedro,
> 
> Sorry for the late reply, I was a bit busy yesterday.
> 
> I think the better way is to use inline asm, because this issue must has to 
> be dealt with in preprocessing stage, because in other stages, it has no 
> chance to get immediate value except using SMC. But then we should ask to the 
> MdePkg maintainer if it is OK.
> 
>  
> Thanks,
> Chao
> 在 2023/8/15 23:35, Pedro Falcato 写道:
> On Tue, Aug 15, 2023 at 9:20 AM Chao Li  
>  wrote:
>  
> Hi Andrew,
>  
> Yes, you are right, I also think that SMC is a bit flawed in terms of 
> security, but can we use some security mechanism to protect the SMC, like 
> encryption and decryption? Sorry, I'm not consider mature enough about SMC 
> security.
>  
> There isn't any. Actual use cases in something like a kernel are
> heavily vetted and read-protected as soon as possible.
>  
>  
> I can tell you real problem, there are some CSR instructions in LoongArch64 
> that can only accept immediate value, for example: `csrrd $a0, 0x1`, the 0x1 
> is the selection of CSR register number, it can't use the registers to 
> select. This operation should be in the MdePkg base library.
>  
> I know that .c or .h files in MdePkg shouldn't depend on a single compiler 
> feature, so I can't use the GNU AT style inline ASM function(AT style 
> inline supports input parameters being immedite value, use "i" option). In 
> this case, I think using SMC can handle this, that is use register transfer 
> the CSR registers selection, and dynamically modify CSR instructions during 
> execution phase with reference to transfer register value, this way is depend 
> on the .text section or target memory is executable and writable.
>  
> FYI, poking instructions willy-nilly is unsafe and unreliable (except
> on x86 due to kludges, but then it's slow).
>  
>  
> The problem of immediate values can only be handled by preprocessing stage or 
> using SMC, otherwise I can only write a lot of similar functions and use 
> `switch case` to call them. This method will cause the program size to expand 
> a lot.
>  
> So, I think I have following choice:
>  
> Choice 1:
>  
> Use AT style inline function, and create a file named: CsrOperationGcc.c, 
> and other future compiler feature-dependent files will be named: 
> CsrOperationClang.c, CsrOperationXlang.c and so on.
>  
> If you're going to use inline assembly, just expose them directly? I
> don't see the problem there, I don't expect loongarch to be picked up
> by visual studio any time soon.
>  
>  
>  
> Choice 2:
>  
> Use SMC.
>  
>  
> Choice 3:
>  
> Write a lot of similar CSR functions.
>  
> You /could/ use a GAS macro.
>  
> .macro csr_write csr
> .global CsrWrite\csr
> CsrWrite\csr:
> csrw a0, \csr
> ret
>  
> (this is riscv pseudo-asm but I know your arch is similar enough)
>  
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107841): https://edk2.groups.io/g/devel/message/107841
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

2023-08-17 Thread Michael D Kinney

Hi Pedro,

I agree that compiler and static analysis absolutely do get false positive
results.

When we see these, we have a choice to make
* Document for all consumers that a specific tool has a false positive and
  we can all safely ignore the report. This is challenging to communicate
  these to all downstream consumers.
* Disable warnings/errors if the report is from a compiler.
* Do a small source code change to address the false positive.

We have a history of doing the last 2.

I would also point out that when these false positives are generated,
they tend to be in larger, more complex functions.  Another option 
to consider is to refactor the code into smaller parts so the code
is both easier to maintain/support and improve the static analysis
results with fewer false positives.

Each report needs to be handled on a case by case basis.

Mike

> -Original Message-
> From: Pedro Falcato 
> Sent: Thursday, August 17, 2023 1:18 PM
> To: devel@edk2.groups.io; Kinney, Michael D 
> Cc: Andrew (EFI) Fish ; wang...@iscas.ac.cn
> Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
> 
> On Thu, Aug 17, 2023 at 9:00 PM Michael D Kinney
>  wrote:
> >
> > I am surprised this same GCC error is not being seen for other CPU
> archs.
> >
> >
> >
> > The simple fix is to this specific issue is to initialize CommandLine
> to NULL at the beginning of the function.
> 
> The correct fix here is to -Wno-error=maybe-uninitialized. This
> warning is error prone and IIRC already disabled in the Linux kernel.
> Heck, Wno-error=uninitialized wouldn't be a bad idea either, we
> recently uncovered a GCC bug on it
> (https://lore.kernel.org/all/20230719190045.4007391-1-a...@kernel.org/).
> >
> > We have observed that compilers continue to add more and more static
> analysis like features over time.  Code that compiled without
> warnings/errors with an earlier compiler may generate warnings/errors on
> a newer compiler.  This looks like an example of this case.
> Well, in this case the static analysis is wrong :)
> 
> --
> Pedro

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107840): https://edk2.groups.io/g/devel/message/107840
Mute This Topic: https://groups.io/mt/100663199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

2023-08-17 Thread Pedro Falcato

On Thu, Aug 17, 2023 at 9:00 PM Michael D Kinney
 wrote:
>
> I am surprised this same GCC error is not being seen for other CPU archs.
>
>
>
> The simple fix is to this specific issue is to initialize CommandLine to NULL 
> at the beginning of the function.

The correct fix here is to -Wno-error=maybe-uninitialized. This
warning is error prone and IIRC already disabled in the Linux kernel.
Heck, Wno-error=uninitialized wouldn't be a bad idea either, we
recently uncovered a GCC bug on it
(https://lore.kernel.org/all/20230719190045.4007391-1-a...@kernel.org/).
>
> We have observed that compilers continue to add more and more static analysis 
> like features over time.  Code that compiled without warnings/errors with an 
> earlier compiler may generate warnings/errors on a newer compiler.  This 
> looks like an example of this case.
Well, in this case the static analysis is wrong :)

-- 
Pedro


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107839): https://edk2.groups.io/g/devel/message/107839
Mute This Topic: https://groups.io/mt/100663199/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

2023-08-17 Thread Michael D Kinney

I am surprised this same GCC error is not being seen for other CPU archs.

The simple fix is to this specific issue is to initialize CommandLine to NULL 
at the beginning of the function.

We have observed that compilers continue to add more and more static analysis 
like features over time.  Code that compiled without warnings/errors with an 
earlier compiler may generate warnings/errors on a newer compiler.  This looks 
like an example of this case.

Mike

From: Andrew (EFI) Fish 
Sent: Thursday, August 17, 2023 4:45 AM
To: devel@edk2.groups.io; wang...@iscas.ac.cn
Cc: Kinney, Michael D 
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

Can you add -Wno-maybe-uninitialized to compiler flags to work around the error?
On Aug 16, 2023, at 11:31 PM, 汪流 
mailto:wang...@iscas.ac.cn>> wrote:


This is the failed build log: 
https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:openEuler:Mainline/edk2/openEuler_Mainline_standard_riscv64_gcc/riscv64

arch:riscv64

gcc version： 10.3.1







-原始郵件-
發件人:"Kinney, Michael D" 
mailto:michael.d.kin...@intel.com>>
發送時間:2023-08-17 01:50:37 (星期四)
收件人: "Andrew (EFI) Fish" mailto:af...@apple.com>>, 
edk2-devel-groups-io mailto:devel@edk2.groups.io>>
抄送: "wang...@iscas.ac.cn" 
mailto:wang...@iscas.ac.cn>>, "Kinney, Michael D" 
mailto:michael.d.kin...@intel.com>>
主題: RE: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
Hi Andrew,

There are compiler flags we set to suppress some of these types of specific 
warnings to avoid disable warnings as errors.

For example, this commit to tools_def.template:

https://github.com/tianocore/edk2/commit/8e985ac3fdb2b117968ac1fa1f54666e166af8ac

I would like to see the compiler, version, arch, log info with the specific 
warning being flagged to see if we can apply the techniques we have been able 
to apply in the past.

Mike

From: Andrew (EFI) Fish mailto:af...@apple.com>>
Sent: Wednesday, August 16, 2023 10:41 AM
To: edk2-devel-groups-io mailto:devel@edk2.groups.io>>; 
Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: wang...@iscas.ac.cn
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

Mike,

I seem to remember it was a maybe-uninitialized compiler error. The DEBUG build 
did not hit it due to the NULL check in the ASSERT. The NULL check only exists 
if ASSERT() is enabled. So if ASSERT is disabled this code in the DXE Core will 
dereference a NULL pointer.

  ASSERT (Prot != NULL);
  //
  // EFI_ALREADY_STARTED is not an error for bus driver.
  // Return the corresponding protocol interface.
  //
  *Interface = Prot->Interface;

Thanks,

Andrew Fish



On Aug 16, 2023, at 10:02 AM, Michael D Kinney 
mailto:michael.d.kin...@intel.com>> wrote:

Can you provide the specific build error?

So far, we have not had to relax that flag for any RELEASE builds.

Thanks,

Mike

From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of ??
Sent: Wednesday, August 16, 2023 12:46 AM
To: Andrew (EFI) Fish mailto:af...@apple.com>>
Cc: edk2-devel-groups-io mailto:devel@edk2.groups.io>>
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？


Yes, the RELEASE build compiler flags should be relaxed, all error checks that 
the DEBUG target should do, it doesn't belong to the RELEASE's job.



---
OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc
index 28d9af4..ac3b5ec 100644
--- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc
+++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc
@@ -54,7 +54,7 @@
!include MdePkg/MdeLibs.dsc.inc

[BuildOptions]
-  GCC:RELEASE_*_*_CC_FLAGS   = -DMDEPKG_NDEBUG
+  GCC:RELEASE_*_*_CC_FLAGS   = -flto
!ifdef $(SOURCE_DEBUG_ENABLE)
  GCC:*_*_RISCV64_GENFW_FLAGS= --keepexceptiontable
!endif
--
2.39.1




I have added the LTO flag and dropped MDEPKG_NDEBUG in the .dsc file, it 
compiled successfully, the build 
log:https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:openEuler:Mainline/edk2/openEuler_Mainline_standard_riscv64_gcc/riscv64

Do you have other way to add LTO flag to compile that don't change the source 
code, i tried to use environment variable, like exported CFLAGS=-flto to 
compile, but the compiler doesn't work with it.







-原始郵件-
發件人:"Andrew (EFI) Fish" mailto:af...@apple.com>>
發送時間:2023-08-10 21:50:55 (星期四)
收件人: edk2-devel-groups-io mailto:devel@edk2.groups.io>>, 
wang...@iscas.ac.cn
抄送:
主題: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
I think that you are advocating that since we have code that error checks on 
DEBUG and not RELEASE builds we should relax the RELEASE build compiler flags?

Re: [edk2-devel] About EDK2 supports Self Modifying Code

2023-08-17 Thread Michael D Kinney

How many different integer values are needed by FW for use of the csrrd 
instruction?

There are examples of access functions on x86 for things like mm0, mm1, mm2, …, 
mm7 and cs, ds, es, ss, fs, gs.  These are implemented as different BaseLib 
APIs because they would also require SMC to do in a single API.

If there is a small number of csrrd index values that need to be accessed, and 
they have standard names, then perhaps you could define a set of APIs to access 
those registers.

Mike

From: devel@edk2.groups.io  On Behalf Of Chao Li
Sent: Wednesday, August 16, 2023 7:30 PM
To: devel@edk2.groups.io; pedro.falc...@gmail.com
Cc: Andrew (EFI) Fish ; Gao, Liming 
; Feng, Bob C ; Chen, Christine 

Subject: Re: [edk2-devel] About EDK2 supports Self Modifying Code


Hi Pedro,

Sorry for the late reply, I was a bit busy yesterday.

I think the better way is to use inline asm, because this issue must has to be 
dealt with in preprocessing stage, because in other stages, it has no chance to 
get immediate value except using SMC. But then we should ask to the MdePkg 
maintainer if it is OK.

Thanks,
Chao
在 2023/8/15 23:35, Pedro Falcato 写道:

On Tue, Aug 15, 2023 at 9:20 AM Chao Li 
 wrote:



Hi Andrew,



Yes, you are right, I also think that SMC is a bit flawed in terms of security, 
but can we use some security mechanism to protect the SMC, like encryption and 
decryption? Sorry, I'm not consider mature enough about SMC security.



There isn't any. Actual use cases in something like a kernel are

heavily vetted and read-protected as soon as possible.





I can tell you real problem, there are some CSR instructions in LoongArch64 
that can only accept immediate value, for example: `csrrd $a0, 0x1`, the 0x1 is 
the selection of CSR register number, it can't use the registers to select. 
This operation should be in the MdePkg base library.



I know that .c or .h files in MdePkg shouldn't depend on a single compiler 
feature, so I can't use the GNU AT style inline ASM function(AT style 
inline supports input parameters being immedite value, use "i" option). In this 
case, I think using SMC can handle this, that is use register transfer the CSR 
registers selection, and dynamically modify CSR instructions during execution 
phase with reference to transfer register value, this way is depend on the 
.text section or target memory is executable and writable.



FYI, poking instructions willy-nilly is unsafe and unreliable (except

on x86 due to kludges, but then it's slow).





The problem of immediate values can only be handled by preprocessing stage or 
using SMC, otherwise I can only write a lot of similar functions and use 
`switch case` to call them. This method will cause the program size to expand a 
lot.



So, I think I have following choice:



Choice 1:



Use AT style inline function, and create a file named: CsrOperationGcc.c, and 
other future compiler feature-dependent files will be named: 
CsrOperationClang.c, CsrOperationXlang.c and so on.



If you're going to use inline assembly, just expose them directly? I

don't see the problem there, I don't expect loongarch to be picked up

by visual studio any time soon.







Choice 2:



Use SMC.





Choice 3:



Write a lot of similar CSR functions.



You /could/ use a GAS macro.



.macro csr_write csr

.global CsrWrite\csr

CsrWrite\csr:

csrw a0, \csr

ret



(this is riscv pseudo-asm but I know your arch is similar enough)





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107837): https://edk2.groups.io/g/devel/message/107837
Mute This Topic: https://groups.io/mt/100751724/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: 回复: edk2-stable202308 Re: [edk2-devel][PATCH v1 1/1] MdeModulePkg: HeapGuard: Don't Assume Pool Head Allocated In First Page

2023-08-17 Thread Oliver Smith-Denny


On 8/15/2023 6:40 PM, gaoliming wrote:

Oliver:
   This change reverts the changes done in AdjustPoolHeadA(). It matches the 
allocation logic. I think this change is good. Reviewed-by: Liming Gao 
 I am also OK to merge this change for the stable tag 
202308.

   Besides, AdjustPoolHeadA() implementation has the extra logic " Size = 
ALIGN_VALUE (Size, 8);". Seemly, this logic is not required, because Size has 
aligned by ALIGN_VARIABLE before enter into AdjustPoolHeadA.
   
Thanks

Liming


Thanks for the review, Liming. Looking at the alignment code, I agree,
the ALIGN_VALUE doesn't seem to be needed. Do you want me to send a v2
with that dropped or take the patch as is? Looks like we have the
required reviewers and probably no further folks reviewing.

Thanks,
Oliver


-邮件原件-
发件人: devel@edk2.groups.io  代表 Leif Lindholm
发送时间: 2023年8月15日 18:58
收件人: Ard Biesheuvel ; Oliver Smith-Denny
; Liming Gao 
抄送: devel@edk2.groups.io; Jian J Wang ; Dandan
Bi ; Kinney, Michael D ;
'Andrew Fish' 
主题: edk2-stable202308 Re: [edk2-devel][PATCH v1 1/1] MdeModulePkg:
HeapGuard: Don't Assume Pool Head Allocated In First Page

On 2023-08-09 22:51, Ard Biesheuvel wrote:

On Wed, 9 Aug 2023 at 23:35, Oliver Smith-Denny
 wrote:


Currently, HeapGuard, when in the GuardAlignedToTail mode, assumes that
the pool head has been allocated in the first page of memory that was
allocated. This is not the case for ARM64 platforms when allocating
runtime pools, as RUNTIME_PAGE_ALLOCATION_GRANULARITY is 64k,

unlike

X64, which has RUNTIME_PAGE_ALLOCATION_GRANULARITY as 4k.

When a runtime pool is allocated on ARM64, the minimum number of

pages

allocated is 16, to match the runtime granularity. When a small pool is
allocated and GuardAlignedToTail is true, HeapGuard instructs the pool
head to be placed as (MemoryAllocated + EFI_PAGES_TO_SIZE(Number of

Pages)

- SizeRequiredForPool).

This gives this scenario:

|Head Guard|Large Free Number of Pages|PoolHead|TailGuard|

When this pool goes to be freed, HeapGuard instructs the pool code to
free from (PoolHead & ~EFI_PAGE_MASK). However, this assumes that the
PoolHead is in the first page allocated, which as shown above is not true
in this case. For the 4k granularity case (i.e. where the correct number of
pages are allocated for this pool), this logic does work.

In this failing case, HeapGuard then instructs the pool code to free 16
(or more depending) pages from the page the pool head was allocated on,
which as seen above means we overrun the pool and attempt to free

memory

far past the pool. We end up running into the tail guard and getting an
access flag fault.

This causes ArmVirtQemu to fail to boot with an access flag fault when
GuardAlignedToTail is set to true (and pool guard enabled for runtime
memory). It should also cause all ARM64 platforms to fail in this
configuration, for exactly the same reason, as this is core code making
the assumption.

This patch removes HeapGuard's assumption that the pool head is

allocated

on the first page and instead undoes the same logic that HeapGuard did
when allocating the pool head in the first place.

With this patch in place, ArmVirtQemu boots with GuardAlignedToTail
set to true (and when it is false, also).

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4521
Github PR: https://github.com/tianocore/edk2/pull/4731

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Dandan Bi 

Signed-off-by: Oliver Smith-Denny 


Thanks a lot for fixing this - I ran into this a while ago but didn't
quite figure out what exactly was going wrong, although the runtime
allocation granularity was obviously a factor here.

Reviewed-by: Ard Biesheuvel 

Can we include this in the stable tag please?


Bugfix, submitted during soft freeze. I think it can go in.
*but* this affects !AARCH64 also - need a reaction from MdeModulePkg
maintainers.

Acked-by: Leif Lindholm 


---
   MdeModulePkg/Core/Dxe/Mem/HeapGuard.h |  7 ++-
   MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 14 +++---
   MdeModulePkg/Core/Dxe/Mem/Pool.c  |  2 +-
   3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.h

b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.h

index 9a32b4dd51d5..24b4206c0e02 100644
--- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.h
+++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.h
@@ -378,12 +378,17 @@ AdjustPoolHeadA (
 Get the page base address according to pool head address.

 @param[in]  MemoryHead address of pool to free.
+  @param[in]  NoPages   Number of pages actually allocated.
+  @param[in]  Size  Size of memory requested.
+(plus pool head/tail overhead)

 @return Address of pool head.
   **/
   VOID *
   AdjustPoolHeadF (
-  IN EFI_PHYSICAL_ADDRESS  Memory
+  IN EFI_PHYSICAL_ADDRESS  Memory,
+  IN UINTN NoPages,
+  IN UINTN Size
 );

   /**
diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c

[edk2-devel] [PATCH v1 0/1] TCG MemoryOverwriteRequest Tests

2023-08-17 Thread Abhimanyu Singh

These tests support platform firmware that implement
 MemoryOverwriteRequestControl & MemoryOverwriteRequestControlLock 
UEFI variables in accordance with TCG PC Platform Reset Attack 
Mitigation Specification.

The first patch contains the Platform Reset Check Test that is
defined in the SCT spec. Based on feedback the remaining testcases
will be added in following patches.

BZ for SCT spec: https://bugzilla.tianocore.org/show_bug.cgi?id=4419

Pull Request: https://github.com/tianocore/edk2-test/pull/76 

Cc: G Edhaya Chandran edhaya.chand...@arm.com
Cc: Samer El-Haj-Mahmoud samer.el-haj-mahm...@arm.com
Cc: Barton Gao gao...@byosoft.com.cn
Cc: Carolyn Gjertsen 
Cc: Supreeth Venkatesh 

Abhi.Singh (1):
  uefi-sct/SctPkg: TCG MemoryOverwriteRequest

 uefi-sct/SctPkg/UEFI/UEFI_SCT.dsc  
|   1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTest.inf
   |  53 +++
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/Guid.h
| 276 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestMain.h
 | 138 +++
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/Guid.c
| 129 ++
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestFunction.c
 | 418 
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestMain.c
 | 115 ++
 uefi-sct/SctPkg/CommonGenFramework.sh  
|   1 +
 uefi-sct/SctPkg/Config/Data/Category.ini   
|   7 +
 9 files changed, 1138 insertions(+)
 create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTest.inf
 create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/Guid.h
 create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestMain.h
 create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/Guid.c
 create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestFunction.c
 create mode 100644 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestMain.c

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107835): https://edk2.groups.io/g/devel/message/107835
Mute This Topic: https://groups.io/mt/100803329/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 1/1] uefi-sct/SctPkg: TCG MemoryOverwriteRequest

2023-08-17 Thread Abhimanyu Singh

From: "Abhi.Singh" 

SCT Platform Reset Check Test

SCT spec: https://bugzilla.tianocore.org/show_bug.cgi?id=4374

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

-Implement initial test infrastructure for all test cases
 including updates to: CommonGenFramework.sh, UEFI_SCT.dsc,
 and Category.ini.
-Add Guid.c and Guid.h files to cover the assertions defined in
 the SCT spec
-Add TCGMemoryOverwriteRequestBBTestMain.h to enable any required
 macros that define states for MOR/MORLOCK
-Add Platform Reset Check Test
 -check if the platform creates the MOR & MORLOCK
  EFI variables as defined in the TCG Spec
 -sets MOR bit 0 and validate if the platform
  clears the MOR bit 0 upon reset.

Signed-off-by: Abhi Singh 
Change-Id: I774d5893e5aff47690dadf90c36c7b9e7e7ee584
---
 uefi-sct/SctPkg/UEFI/UEFI_SCT.dsc  
|   1 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTest.inf
   |  53 +++
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/Guid.h
| 276 +
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestMain.h
 | 138 +++
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/Guid.c
| 129 ++
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestFunction.c
 | 418 
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTestMain.c
 | 115 ++
 uefi-sct/SctPkg/CommonGenFramework.sh  
|   1 +
 uefi-sct/SctPkg/Config/Data/Category.ini   
|   7 +
 9 files changed, 1138 insertions(+)

diff --git a/uefi-sct/SctPkg/UEFI/UEFI_SCT.dsc 
b/uefi-sct/SctPkg/UEFI/UEFI_SCT.dsc
index 155490fa39d3..536d5f2ed37a 100644
--- a/uefi-sct/SctPkg/UEFI/UEFI_SCT.dsc
+++ b/uefi-sct/SctPkg/UEFI/UEFI_SCT.dsc
@@ -235,6 +235,7 @@ [Components]
 
SctPkg/TestCase/UEFI/EFI/RuntimeServices/MiscRuntimeServices/BlackBoxTest/MiscRuntimeServicesBBTest.inf
 
SctPkg/TestCase/UEFI/EFI/RuntimeServices/TimeServices/BlackBoxTest/TimeServicesBBTest.inf
 
SctPkg/TestCase/UEFI/EFI/RuntimeServices/VariableServices/BlackBoxTest/VariableServicesBBTest.inf
+SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTest.inf
 
 
SctPkg/TestCase/UEFI/EFI/Protocol/GraphicsOutput/BlackBoxTest/GraphicsOutputBBTest.inf
 SctPkg/TestCase/UEFI/EFI/Protocol/Bis/BlackBoxTest/BisBBTest.inf
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTest.inf
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTest.inf
new file mode 100644
index ..35d82043e2e7
--- /dev/null
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/RuntimeServices/TCGMemoryOverwriteRequest/BlackBoxTest/TCGMemoryOverwriteRequestBBTest.inf
@@ -0,0 +1,53 @@
+## @file
+#
+#  Copyright 2006 - 2015 Unified EFI, Inc.
+#  Copyright (c) 2013, Intel Corporation. All rights reserved.
+#  Copyright (c) 2023, Arm Inc. 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.
+#
+##
+#/*++
+#
+# Module Name:
+#
+#   TCGMemoryOverwriteRequestBBTest.inf
+#
+# Abstract:
+#
+#   Component description file for TCG MemoryOverwriteRequest UEFI variables 
Test.
+#
+#--*/
+
+[defines]
+  INF_VERSION  = 0x00010005
+  BASE_NAME= TCGMemoryOverwriteRequestBBTest
+  FILE_GUID= ACA989CD-4AEE-45A3-B80F-E9A523BB7164
+  MODULE_TYPE  = UEFI_DRIVER
+  VERSION_STRING   = 1.0
+  ENTRY_POINT  = InitializeTestTCGMemoryOverwriteRequest
+
+[sources.common]
+  TCGMemoryOverwriteRequestBBTestMain.c
+  TCGMemoryOverwriteRequestBBTestMain.h
+  TCGMemoryOverwriteRequestBBTestFunction.c
+  Guid.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  SctPkg/SctPkg.dec
+  SctPkg/UEFI/UEFI.dec
+
+[LibraryClasses]
+  UefiDriverEntryPoint
+  SctLib
+  EfiTestLib
+
+[Protocols]
+  gEfiTestRecoveryLibraryGuid
diff --git

Re: [edk2-devel] Error F001: Module SmmLockBox.inf NOT found

2023-08-17 Thread Andrew Fish via groups.io

I think I may have botched this message in moderation….

Andrew,

Did you update the submodule?
git submodule update —init
See Submodules under this section of the ReadMe.rst: 
https://github.com/tianocore/edk2

What were you trying to build?

Thanks,

Andrew Fish
> Subject: Error F001: Module SmmLockBox.inf NOT found
> 
> Hi,
> 
> I have cloned edk from git:
> 
> I have got an error:
> 
> Architecture(s): IA32 X64
> Build target = RELEASE
> Toolchain =GCC5
> 
> Error F001: Module SmmLockBox.inf NOT found in DSC file; Is it really a 
> binary module?
> 
> I did not make any changes, just trying to build.
> 
> How can I solve it?
> 
> Thank you in advance,
> Andrew
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107833): https://edk2.groups.io/g/devel/message/107833
Mute This Topic: https://groups.io/mt/100798668/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Error F001: Module SmmLockBox.inf NOT found

2023-08-17 Thread kamchatnikov via groups.io

Hi,

I have cloned edk from git:

I have got an error:

Error F001: Module SmmLockBox.inf NOT found in DSC file; Is it really a binary 
module?

I did not make any changes, just trying to build.

How can I solve it?

Thank you in advance,
Andrew


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107831): https://edk2.groups.io/g/devel/message/107831
Mute This Topic: https://groups.io/mt/100798667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based IRQ/GSI

2023-08-17 Thread Attar, AbdulLateef (Abdul Lateef) via groups.io

[AMD Official Use Only - General]

Gentle reminder, review please.

-Original Message-
From: Chang, Abner 
Sent: Thursday, August 3, 2023 12:12 PM
To: Attar, AbdulLateef (Abdul Lateef) ; 
devel@edk2.groups.io
Cc: Attar, AbdulLateef (Abdul Lateef) ; Sai Chaganty 
; Isaac Oram ; Nate 
DeSimone ; Liming Gao 
Subject: RE: [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based IRQ/GSI

[AMD Official Use Only - General]

Acked-by: Abner Chang 

> -Original Message-
> From: Abdul Lateef Attar 
> Sent: Thursday, August 3, 2023 2:35 PM
> To: devel@edk2.groups.io
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Sai
> Chaganty ; Isaac Oram
> ; Nate DeSimone
> ; Liming Gao
> ; Chang, Abner 
> Subject: [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based
> IRQ/GSI
>
> From: Abdul Lateef Attar 
>
> Create a new PCD to hold the IRQ or GSI number for SPCR, with default
> values of 4.
> Update the ACPI SPCR table's IRQ value based on PCD.
>
> Cc: Sai Chaganty 
> Cc: Isaac Oram 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Cc: Abner Chang 
> Signed-off-by: Abdul Lateef Attar 
>
> Change-Id: I7218903fa5572f8139ad45db598ab085f079713b
> ---
>  .../OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.dec  | 5 +
>  .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpiDxe.inf | 4 
>  .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.h  | 3 +++
>  .../SpcrFeaturePkg/SpcrAcpiDxe/SpcrAcpi.c  | 7 ---
>  4 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.d
> ec
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.d
> ec
> index b084fad89220..d69d650f3f20 100644
> ---
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.d
> ec
> +++
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrFeaturePkg.d
> ec
> @@ -7,6 +7,7 @@
>  # for the build infrastructure.
>  #
>  # Copyright (c) 2020, Intel Corporation. All rights reserved.
> +# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -24,6 +25,10 @@
> [Includes]  [Guids]
>gSpcrFeaturePkgTokenSpaceGuid = { 0xe978c988, 0xeeba, 0x4671, {
> 0xb8, 0x0d, 0xcc, 0x8b, 0x89, 0xb5, 0xd1, 0xef }}
>
> +[PcdsFixedAtBuild]
> +  # SPCR default IRQ set to 4
> +  gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrInterrupt|4|UINT8|0x0010
> +
>  [PcdsFeatureFlag]
>
> gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrFeatureEnable|FALSE|BOOLEAN|0x
> 0001
>
> diff --git
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> AcpiDxe.inf
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> AcpiDxe.inf
> index 9a4f95e86bbf..cd43afea5242 100644
> ---
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> AcpiDxe.inf
> +++
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> AcpiDxe.inf
> @@ -24,6 +24,7 @@ [LibraryClasses]
>UefiDriverEntryPoint
>UefiLib
>SpcrDeviceLib
> +  PcdLib
>
>  [Packages]
>MdePkg/MdePkg.dec
> @@ -51,5 +52,8 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio
>
> +[FixedPcd]
> +  gSpcrFeaturePkgTokenSpaceGuid.PcdSpcrInterrupt
> +
>  [Depex]
>TRUE
> diff --git
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.h
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.h
> index c11da439fcb8..245a847762c5 100644
> ---
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.h
> +++
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.h
> @@ -3,6 +3,8 @@
>SPCR is abbreviation of Serial Port Console Redirection Table (SPCR).
>
>Copyright (c) 2004 - 2020, Intel Corporation. All rights
> reserved.
> +  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
> +
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  **/
> @@ -23,6 +25,7 @@
>  #include 
>  #include   #include
> 
> +#include 
>
>  #include 
>  #include 
> diff --git
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.c
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.c
> index 51449d0fad9e..e92db96caaa9 100644
> ---
> a/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.c
> +++
> b/Features/Intel/OutOfBandManagement/SpcrFeaturePkg/SpcrAcpiDxe/Spcr
> Acpi.c
> @@ -3,7 +3,7 @@
>SPCR is abbreviation of Serial Port Console Redirection Table (SPCR).
>
>Copyright (c) 2004 - 2020, Intel Corporation. All rights
> reserved.
> -  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights
> reserved.
> +  Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  **/
> @@ -83,8 +83,8 @@
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE gSpcrInfo = {
>},
>
>0x03,   //INTERRUPT_TYPE,
>

[edk2-devel] Error F001: Module SmmLockBox.inf NOT found

2023-08-17 Thread kamchatnikov via groups.io

Hi,

I have cloned edk from git:

I have got an error:

Architecture(s): IA32 X64
Build target = RELEASE
Toolchain =GCC5

Error F001: Module SmmLockBox.inf NOT found in DSC file; Is it really a binary 
module?

I did not make any changes, just trying to build.

How can I solve it?

Thank you in advance,
Andrew


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107832): https://edk2.groups.io/g/devel/message/107832
Mute This Topic: https://groups.io/mt/100798668/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

2023-08-17 Thread Andrew Fish via groups.io

Can you add -Wno-maybe-uninitialized to compiler flags to work around the error?On Aug 16, 2023, at 11:31 PM, 汪流  wrote:
	This is the failed build log: https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:openEuler:Mainline/edk2/openEuler_Mainline_standard_riscv64_gcc/riscv64


	    arch:    riscv64


	gcc version： 10.3.1


	


	




	-原始郵件-
發件人:"Kinney, Michael D" 
發送時間:2023-08-17 01:50:37 (星期四)
收件人: "Andrew (EFI) Fish" , edk2-devel-groups-io 
抄送: "wang...@iscas.ac.cn" , "Kinney, Michael D" 
主題: RE: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

	

		
			

	Hi Andrew,


	 


	There are compiler flags we set to suppress some of these types of specific warnings to avoid disable warnings as errors.



	 


	For example, this commit to tools_def.template:


	 


	https://github.com/tianocore/edk2/commit/8e985ac3fdb2b117968ac1fa1f54666e166af8ac


	 


	I would like to see the compiler, version, arch, log info with the specific warning being flagged to see if we can apply the techniques we have been able to apply in the past.


	 


	Mike


	 


	
		
			
From: Andrew (EFI) Fish  
Sent: Wednesday, August 16, 2023 10:41 AM
To: edk2-devel-groups-io ; Kinney, Michael D 
Cc: wang...@iscas.ac.cn
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
			
		
	
	
		 
	
	
		Mike,
	
	
		
			 
		
	
	
		
			I seem to remember it was a maybe-uninitialized compiler error. The DEBUG build did not hit it due to the NULL check in the ASSERT. The NULL check
 only exists if ASSERT() is enabled. So if ASSERT is disabled this code in the DXE Core will dereference a NULL pointer. 
		
	
	
		
			 
		
	
	
		
			

	
		
			
      ASSERT (Prot != NULL);
			
		
	
	
		
			
      // 
			
		
	
	
		
			
      // EFI_ALREADY_STARTED is not an error for bus driver.
			
		
	
	
		
			
      // Return the corresponding protocol interface.
			
		
	
	
		
			
      // 
			
		
	
	
		
			
      *Interface = Prot->Interface;
			
		
	

			
		
	
	
		
			 
		
	
	
		
			Thanks,
		
	
	
		
			 
		
	
	
		
			Andrew Fish
		
		
			



			
			

	
		On Aug 16, 2023, at 10:02 AM, Michael D Kinney  wrote:
	


	 


	
		
			Can you provide the specific build error?
		
	
	
		
			 
		
	
	
		
			So far, we have not had to relax that flag for any RELEASE builds.
		
	
	
		
			 
		
	
	
		
			Thanks,
		
	
	
		
			 
		
	
	
		
			Mike
		
	
	
		
			 
		
	
	
		
			

	
		From: devel@edk2.groups.io  On
 Behalf Of ??
Sent: Wednesday, August 16, 2023 12:46 AM
To: Andrew (EFI) Fish 
Cc: edk2-devel-groups-io 
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？
	

			
		
		
			
 
			
		
		
			Yes, the RELEASE build compiler flags should be relaxed, all error checks that the DEBUG target should do, it doesn't belong to the RELEASE's job. 
		
		
			  
		
		
			--- 
OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 2 +- 
1 file changed, 1 insertion(+), 1 deletion(-) 

diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
index 28d9af4..ac3b5ec 100644 
--- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
+++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
@@ -54,7 +54,7 @@ 
!include MdePkg/MdeLibs.dsc.inc 

[BuildOptions] 
-  GCC:RELEASE_*_*_CC_FLAGS   = -DMDEPKG_NDEBUG 
+  GCC:RELEASE_*_*_CC_FLAGS   = -flto 
!ifdef $(SOURCE_DEBUG_ENABLE) 
  GCC:*_*_RISCV64_GENFW_FLAGS    = --keepexceptiontable 
!endif 
-- 
2.39.1


 
		
		
			I have added the LTO flag and dropped MDEPKG_NDEBUG in the .dsc file, it compiled successfully, the build

Re: [edk2-devel] [PATCH edk2-platforms v3 3/3] Platform/SbsaQemu: handle systems without GIC ITS

2023-08-17 Thread Marcin Juszkiewicz


W dniu 19.07.2023 o 14:08, Marcin Juszkiewicz via groups.io pisze:

If firmware is used with QEMU 8.0 or older then there will be no GIC ITS
support.

In such case we would not add information about it into MCFG and there
will be no IORT table.

Signed-off-by: Marcin Juszkiewicz 
---
  .../Qemu/SbsaQemu/AcpiTables/AcpiTables.inf   |   1 -
  .../SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf   |   1 +
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 218 +-
  Silicon/Qemu/SbsaQemu/AcpiTables/Iort.aslc| 135 ---
  4 files changed, 208 insertions(+), 147 deletions(-)
  delete mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Iort.aslc



diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c




+  // Initialize IORT ACPI Header
+  EFI_ACPI_6_0_IO_REMAPPING_TABLE Header = {
+SBSAQEMU_ACPI_HEADER(EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,
+ SBSA_IO_REMAPPING_STRUCTURE,
+ EFI_ACPI_IO_REMAPPING_TABLE_REVISION_00),
+1,


This should be 3 (ITS, SMMU, RC). I had code which bumped it to 3 and 
then removed it without checking.


Will send v4.


+sizeof(EFI_ACPI_6_0_IO_REMAPPING_TABLE),// NodeOffset
+0 };




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107828): https://edk2.groups.io/g/devel/message/107828
Mute This Topic: https://groups.io/mt/100798349/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/QemuSbsa: enlarge firmware offsets

2023-08-17 Thread Leif Lindholm

On Wed, Aug 16, 2023 at 18:33:33 +0200, Marcin Juszkiewicz wrote:
> GenFv: ERROR 3000: Invalid
>   the required fv image size 0x216510 exceeds the set fv image size 0x20
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 

Presumably caused by the openssl3 shenanigans. But regardless, this
was an arbitrarily low size to begin with.

Pushed as 0f0cafb5defb. Thanks!

/
Leif

> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> index 677cea6344dc..bc432cac6fc8 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> @@ -58,20 +58,20 @@ [FD.SBSA_FLASH0]
>  
>  [FD.SBSA_FLASH1]
>  BaseAddress   = 0x1000|gArmTokenSpaceGuid.PcdFdBaseAddress
> -Size  = 0x002C|gArmTokenSpaceGuid.PcdFdSize
> +Size  = 0x003C|gArmTokenSpaceGuid.PcdFdSize
>  ErasePolarity = 1
>  BlockSize = 0x1000
> -NumBlocks = 0x2C0
> +NumBlocks = 0x3C0
>  
>  ## Place for EFI (BL33)
>  # This offset (if any as it is 0x0 currently) + BaseAddress (0x1000) 
> must be set in PRELOADED_BL33_BASE at ATF
> -0x|0x0020
> +0x|0x0030
>  gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
>  FV = FVMAIN_COMPACT
>  
>  ## Place for Variables. They share flash1 with EFI
>  # Must be aligned to Flash Block size 0x4
> -0x0020|0x0004
> +0x0030|0x0004
>  
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
>  #NV_VARIABLE_STORE
>  DATA = {
> @@ -109,7 +109,7 @@ [FD.SBSA_FLASH1]
>0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>  }
>  
> -0x0024|0x0004
> +0x0034|0x0004
>  
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
>  #NV_FTW_WORKING
>  DATA = {
> @@ -123,7 +123,7 @@ [FD.SBSA_FLASH1]
>0xE0, 0xFF, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00
>  }
>  
> -0x0028|0x0004
> +0x0038|0x0004
>  
> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>  #NV_FTW_SPARE
>  
> -- 
> 2.41.0
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107827): https://edk2.groups.io/g/devel/message/107827
Mute This Topic: https://groups.io/mt/100783095/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-staging/crypto-new-api][PATCH] CryptoPkg/OpensslLib: Upgrade OpenSSL to 1.1.1u

2023-08-17 Thread Heng Luo

Reviewed-by: Heng Luo 

> -Original Message-
> From: Li, Yi1 
> Sent: Thursday, August 17, 2023 3:10 PM
> To: devel@edk2.groups.io
> Cc: Sheng, W ; Gao, Zhichao ;
> Luo, Heng ; Li, Yi1 
> Subject: [edk2-staging/crypto-new-api][PATCH] CryptoPkg/OpensslLib:
> Upgrade OpenSSL to 1.1.1u
> 
> From: Sheng Wei 
> 
> (cherry-pick from: master b2de9ec5a759aa4a7ac029cda9079dce077bf856)
> 
> Cc: Zhichao Gao 
> Cc: Heng Luo 
> Signed-off-by: Yi Li 
> ---
>  CryptoPkg/Library/OpensslLib/OpensslLib.inf | 1 -
>  CryptoPkg/Library/OpensslLib/OpensslLibFull.inf | 1 -
>  CryptoPkg/Library/OpensslLib/openssl| 2 +-
>  3 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> index eec497c7c4..2908bb62a4 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
> @@ -157,7 +157,6 @@
>$(OPENSSL_PATH)/crypto/bn/bn_srp.c
>$(OPENSSL_PATH)/crypto/bn/bn_word.c
>$(OPENSSL_PATH)/crypto/bn/bn_x931p.c
> -  $(OPENSSL_PATH)/crypto/bn/rsa_sup_mul.c
>$(OPENSSL_PATH)/crypto/buffer/buf_err.c
>$(OPENSSL_PATH)/crypto/buffer/buffer.c
>$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
> b/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
> index b07abec1af..4491b762d0 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
> @@ -157,7 +157,6 @@
>$(OPENSSL_PATH)/crypto/bn/bn_srp.c
>$(OPENSSL_PATH)/crypto/bn/bn_word.c
>$(OPENSSL_PATH)/crypto/bn/bn_x931p.c
> -  $(OPENSSL_PATH)/crypto/bn/rsa_sup_mul.c
>$(OPENSSL_PATH)/crypto/buffer/buf_err.c
>$(OPENSSL_PATH)/crypto/buffer/buffer.c
>$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
> diff --git a/CryptoPkg/Library/OpensslLib/openssl
> b/CryptoPkg/Library/OpensslLib/openssl
> index 830bf8e1e4..70c2912f63 16
> --- a/CryptoPkg/Library/OpensslLib/openssl
> +++ b/CryptoPkg/Library/OpensslLib/openssl
> @@ -1 +1 @@
> -Subproject commit 830bf8e1e4749ad65c51b6a1d0d769ae689404ba
> +Subproject commit 70c2912f635aac8ab28629a2b5ea0c09740d2bda
> --
> 2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107826): https://edk2.groups.io/g/devel/message/107826
Mute This Topic: https://groups.io/mt/100796057/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-staging/crypto-new-api][PATCH] CryptoPkg/OpensslLib: Upgrade OpenSSL to 1.1.1u

2023-08-17 Thread Li, Yi

From: Sheng Wei 

(cherry-pick from: master b2de9ec5a759aa4a7ac029cda9079dce077bf856)

Cc: Zhichao Gao 
Cc: Heng Luo 
Signed-off-by: Yi Li 
---
 CryptoPkg/Library/OpensslLib/OpensslLib.inf | 1 -
 CryptoPkg/Library/OpensslLib/OpensslLibFull.inf | 1 -
 CryptoPkg/Library/OpensslLib/openssl| 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index eec497c7c4..2908bb62a4 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -157,7 +157,6 @@
   $(OPENSSL_PATH)/crypto/bn/bn_srp.c
   $(OPENSSL_PATH)/crypto/bn/bn_word.c
   $(OPENSSL_PATH)/crypto/bn/bn_x931p.c
-  $(OPENSSL_PATH)/crypto/bn/rsa_sup_mul.c
   $(OPENSSL_PATH)/crypto/buffer/buf_err.c
   $(OPENSSL_PATH)/crypto/buffer/buffer.c
   $(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
index b07abec1af..4491b762d0 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibFull.inf
@@ -157,7 +157,6 @@
   $(OPENSSL_PATH)/crypto/bn/bn_srp.c
   $(OPENSSL_PATH)/crypto/bn/bn_word.c
   $(OPENSSL_PATH)/crypto/bn/bn_x931p.c
-  $(OPENSSL_PATH)/crypto/bn/rsa_sup_mul.c
   $(OPENSSL_PATH)/crypto/buffer/buf_err.c
   $(OPENSSL_PATH)/crypto/buffer/buffer.c
   $(OPENSSL_PATH)/crypto/cmac/cm_ameth.c
diff --git a/CryptoPkg/Library/OpensslLib/openssl 
b/CryptoPkg/Library/OpensslLib/openssl
index 830bf8e1e4..70c2912f63 16
--- a/CryptoPkg/Library/OpensslLib/openssl
+++ b/CryptoPkg/Library/OpensslLib/openssl
@@ -1 +1 @@
-Subproject commit 830bf8e1e4749ad65c51b6a1d0d769ae689404ba
+Subproject commit 70c2912f635aac8ab28629a2b5ea0c09740d2bda
-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#107825): https://edk2.groups.io/g/devel/message/107825
Mute This Topic: https://groups.io/mt/100796057/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

2023-08-17 Thread 汪流

This is the failed build log: 
https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:openEuler:Mainline/edk2/openEuler_Mainline_standard_riscv64_gcc/riscv64

arch:riscv64

gcc version： 10.3.1









-原始郵件-
發件人:"Kinney, Michael D" 
發送時間:2023-08-17 01:50:37 (星期四)
收件人: "Andrew (EFI) Fish" , edk2-devel-groups-io 

抄送: "wang...@iscas.ac.cn" , "Kinney, Michael D" 

主題: RE: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？



Hi Andrew,

 

There are compiler flags we set to suppress some of these types of specific 
warnings to avoid disable warnings as errors.

 

For example, this commit to tools_def.template:

 

https://github.com/tianocore/edk2/commit/8e985ac3fdb2b117968ac1fa1f54666e166af8ac

 

I would like to see the compiler, version, arch, log info with the specific 
warning being flagged to see if we can apply the techniques we have been able 
to apply in the past.

 

Mike

 

From: Andrew (EFI) Fish 
Sent: Wednesday, August 16, 2023 10:41 AM
To: edk2-devel-groups-io ; Kinney, Michael D 

Cc: wang...@iscas.ac.cn
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

 

Mike,

 

I seem to remember it was a maybe-uninitialized compiler error. The DEBUG build 
did not hit it due to the NULL check in the ASSERT. The NULL check only exists 
if ASSERT() is enabled. So if ASSERT is disabled this code in the DXE Core will 
dereference a NULL pointer. 

 

  ASSERT (Prot != NULL);

  // 

  // EFI_ALREADY_STARTED is not an error for bus driver.

  // Return the corresponding protocol interface.

  // 

  *Interface = Prot->Interface;

 

Thanks,

 

Andrew Fish





On Aug 16, 2023, at 10:02 AM, Michael D Kinney  
wrote:

 

Can you provide the specific build error?

 

So far, we have not had to relax that flag for any RELEASE builds.

 

Thanks,

 

Mike

 

From: devel@edk2.groups.io  On Behalf Of ??
Sent: Wednesday, August 16, 2023 12:46 AM
To: Andrew (EFI) Fish 
Cc: edk2-devel-groups-io 
Subject: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

 

Yes, the RELEASE build compiler flags should be relaxed, all error checks that 
the DEBUG target should do, it doesn't belong to the RELEASE's job.

 

--- 
OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 2 +- 
1 file changed, 1 insertion(+), 1 deletion(-) 

diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
index 28d9af4..ac3b5ec 100644 
--- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
+++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
@@ -54,7 +54,7 @@ 
!include MdePkg/MdeLibs.dsc.inc 

[BuildOptions] 
-  GCC:RELEASE_*_*_CC_FLAGS   = -DMDEPKG_NDEBUG 
+  GCC:RELEASE_*_*_CC_FLAGS   = -flto 
!ifdef $(SOURCE_DEBUG_ENABLE) 
  GCC:*_*_RISCV64_GENFW_FLAGS= --keepexceptiontable 
!endif 
-- 
2.39.1




I have added the LTO flag and dropped MDEPKG_NDEBUG in the .dsc file, it 
compiled successfully, the build 
log:https://build.tarsier-infra.com/package/live_build_log/home:ouuleilei:branches:openEuler:Mainline/edk2/openEuler_Mainline_standard_riscv64_gcc/riscv64

Do you have other way to add LTO flag to compile that don't change the source 
code, i tried to use environment variable, like exported CFLAGS=-flto to 
compile, but the compiler doesn't work with it.

 

 

 

 

-原始郵件-
發件人:"Andrew (EFI) Fish" 
發送時間:2023-08-10 21:50:55 (星期四)
收件人: edk2-devel-groups-io , wang...@iscas.ac.cn
抄送: 
主題: Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

I think that you are advocating that since we have code that error checks on 
DEBUG and not RELEASE builds we should relax the RELEASE build compiler flags?

 

/home/abuild/rpmbuild/BUILD/edk2-edk2-stable202305/MdeModulePkg/Core/Dxe/Hand/Handle.c:1183:24:
 error: ‘Prot’ may be used uninitialized [-Werror=maybe-uninitialized]

  ASSERT (Prot != NULL);

  // 

  // EFI_ALREADY_STARTED is not an error for bus driver.

  // Return the corresponding protocol interface.

  // 

  *Interface = Prot->Interface;

 

A given platform can add ASSERT into release builds if it wants. I’ve actually 
done that for power on before. If your compiler supports LTO you are not 
required to set MDEPKG_NDEBUG on RELEASE builds, and you can used a PCD to 
configure your debug level, per build type.  

 

Maybe we should just have the error checks in all paths?

 

Thanks, 

 

Andrew Fish 






On Aug 10, 2023, at 6:44 AM, 汪流  wrote:

 

I want to build a rpm package for edk2-stable202305 on riscv64, however I get 
some uninitialized variable error, I have found that the reason is -Werror flag.
My build target was release. I think the flag should used in the debug ,not in 
release.
My build command:  build -t GCC5 -n $NCPUS -b RELEASE -a RISCV64 -p 
OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc -D SECURE_BOOT_ENABLE=TRUE -D 
TPM_ENABLE=TRUE -D TPM_CONFIG_ENABLE=TRUE

This is my packet log:

Re: [edk2-devel] [PATCH V2 0/2] Add ProcessorUpgradeSocket definitions from SMBIOS 3.7.0

Re: [edk2-devel] About EDK2 supports Self Modifying Code

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

Re: [edk2-devel] About EDK2 supports Self Modifying Code

Re: 回复: edk2-stable202308 Re: [edk2-devel][PATCH v1 1/1] MdeModulePkg: HeapGuard: Don't Assume Pool Head Allocated In First Page

[edk2-devel] [PATCH v1 0/1] TCG MemoryOverwriteRequest Tests

[edk2-devel] [PATCH v1 1/1] uefi-sct/SctPkg: TCG MemoryOverwriteRequest

Re: [edk2-devel] Error F001: Module SmmLockBox.inf NOT found

[edk2-devel] Error F001: Module SmmLockBox.inf NOT found

Re: [edk2-devel] [PATCH 1/1] OutOfBandManagement/SpcrFeaturePkg: PCD based IRQ/GSI

[edk2-devel] Error F001: Module SmmLockBox.inf NOT found

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

Re: [edk2-devel] [PATCH edk2-platforms v3 3/3] Platform/SbsaQemu: handle systems without GIC ITS

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/QemuSbsa: enlarge firmware offsets

Re: [edk2-devel] [edk2-staging/crypto-new-api][PATCH] CryptoPkg/OpensslLib: Upgrade OpenSSL to 1.1.1u

[edk2-devel] [edk2-staging/crypto-new-api][PATCH] CryptoPkg/OpensslLib: Upgrade OpenSSL to 1.1.1u

Re: [edk2-devel] Can RELEASE target disable -Werror CC_FLAG？

19 matches

Site Navigation

Mail list logo

Footer information