Re: [edk2-devel] [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit assignment

[Chiu, Chasel]

Thanks for fixing this issue! Reviewed-by: Chasel Chiu 

> -Original Message-
> From: Benjamin Doron 
> Sent: Friday, July 23, 2021 10:27 AM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Desimone, Nathaniel L
> ; Liming Gao
> ; Dong, Eric 
> Subject: [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit
> assignment
> 
> In the case where the root bridge's Mem.Limit is the base address of PCIe
> MMIO, subtract one to make a valid end address.
> 
> This fixes an issue where CpuDxe returns "Length(0x5001) is not
> aligned!" when PciHostBridgeDxe attempts to make this range uncacheable.
> 
> Cc: Chasel Chiu 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Signed-off-by: Benjamin Doron 
> ---
> 
> Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostB
> ridgeLibSimple.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHos
> tBridgeLibSimple.c
> b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHos
> tBridgeLibSimple.c
> index e231f747019e..0e3fee28b5d1 100644
> ---
> a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHos
> tBridgeLibSimple.c
> +++ b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/P
> +++ ciHostBridgeLibSimple.c
> @@ -90,7 +90,7 @@ PciHostBridgeGetRootBridges (
>if (PcdGet32(PcdPciReservedMemLimit) != 0)
> { mRootBridgeTemplate.Mem.Limit = PcdGet32
> (PcdPciReservedMemLimit);   } else {-mRootBridgeTemplate.Mem.Limit =
> (UINT32) PcdGet64 (PcdPciExpressBaseAddress);+
> mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64
> (PcdPciExpressBaseAddress) - 1;   }
> mRootBridgeTemplate.MemAbove4G.Base = PcdGet64
> (PcdPciReservedMemAbove4GBBase);--
> 2.31.1



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

Re: [edk2-devel] RFC: EXT4 filesystem driver

[Andrew Fish via groups.io]

> On Jul 22, 2021, at 7:07 PM, Desimone, Nathaniel L 
>  wrote:
> 
> Hi Pedro,
> 
>> -Original Message-
>> From: devel@edk2.groups.io  
>> mailto:devel@edk2.groups.io>> On Behalf Of Pedro
>> Falcato
>> Sent: Thursday, July 22, 2021 9:54 AM
>> To: Andrew Fish mailto:af...@apple.com>>
>> Cc: edk2-devel-groups-io > >; mhaeu...@posteo.de 
>> ;
>> r...@edk2.groups.io 
>> Subject: Re: [edk2-devel] RFC: EXT4 filesystem driver
>> 
>> Hi Andrew, Marvin,
>> 
>> RE: The package name: It doesn't sound like a bad idea to have something
>> like a FileSystemPkg and have a bunch of different filesystems inside of it,
>> but I'll defer to you and my mentors' judgement; we could also drop that
>> issue for now and take care of it afterwards, since it may need further
>> changes that are not a part of GSoC and would just delay the process.
>> 
>> With respect to the write capabilities of the driver, I'm not entirely sure
>> whether or not it's useful. I've been thinking about it today, and it seems 
>> like
>> there's not much that could go wrong? The write path isn't excessively
>> complex. Except of course in the event of an untimely power cut, but those
>> /should/ be easily detected by the checksums. My initial idea was to have it
>> up to speed with FatPkg and other filesystems by implementing all of
>> EFI_FILE_PROTOCOL, including the write portions. If Apple's HFS+ and APFS
>> drivers don't have those, it may be a decent idea to reduce the scope of the
>> ext4 driver as well. I don't see a big need for write support; on the other
>> hand, I've only worked on UEFI bootloaders before, which may be an outlier
>> in that regard. Further feedback is appreciated.
> 
> The most commonly used reason to for writing to the filesystem in a 
> production environment is capsule updates. Most capsule update 
> implementations will stage the capsule on the EFI System Partition and then 
> reset the system to unlock flash. The second most useful is the UEFI Shell 
> and all the many applications that run within it will write to the filesystem 
> for a large variety of reasons. I think it would be a useful feature to have 
> as one could conceivably start using EFI System Partitions formatted as ext4.
> 

The EFI System Partition is defined to be FAT32 by the UEFI Spec for 
interoperability. It defines the file system drivers required for the firmware 
and OS. So changing that is not really an option. 

You can still install the UEFI Shell to a read only file system, you just need 
to do it from the OS :). We actually do this on Macs quite often. You just run 
the macOS bless command and reboot to the UEFI Shell. 

Thanks,

Andrew Fish

>> 
>> As for the tests, UEFI SCTs already seem to have some tests on
>> EFI_FILE_PROTOCOL's. Further testing may require some sort of fuzzing,
>> which is what I want to, although in a simplified way. With fuzzing we could
>> hammer the filesystem code with all sorts of different calls in different
>> orders, we could also mutate the disk structures to test if the driver is 
>> secure
>> and can handle corruption in a nice, safe way. A future (GSoC or not) project
>> could also attempt to use compiler-generated coverage instrumentation (see
>> LLVM's LibFuzzer and SanitizerCoverage for an example).
>> 
>> I'm not sure about all OSes, but at least Linux ext2/3/4 drivers are very 
>> robust
>> and can handle and work around any corrupted FS I
>> (accidentally) throw at them. However, running fsck is the best way to detect
>> corruption; note that licensing may be an issue as, for example, ext4's fsck 
>> is
>> GPL2 licensed.
>> 
>> Best Regards,
>> Pedro
>> 
>> On Thu, 22 Jul 2021 at 16:58, Andrew Fish  wrote:
>>> 
>>> 
>>> 
>>> On Jul 22, 2021, at 3:24 AM, Marvin Häuser  wrote:
>>> 
>>> On 22.07.21 01:12, Pedro Falcato wrote:
>>> 
>>> EXT4 (fourth extended filesystem) is a filesystem developed for Linux
>>> that has been in wide use (desktops, servers, smartphones) since 2008.
>>> 
>>> The Ext4Pkg implements the Simple File System Protocol for a partition
>>> that is formatted with the EXT4 file system. This allows UEFI Drivers,
>>> UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
>>> on an EXT4 partition and supports booting a UEFI OS Loader from an
>>> EXT4 partition.
>>> This project is one of the TianoCore Google Summer of Code projects.
>>> 
>>> Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
>>> UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
>>> I/O 2 Protocols, and produces the Simple File System protocol. It
>>> allows mounting ext4 filesystems exclusively.
>>> 
>>> Brief overhead of EXT4:
>>> Layout of an EXT2/3/4 filesystem:
>>> (note: this driver has been developed using
>>> https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
>>> documentation).
>>> 
>>> An ext2/3/4 filesystem (here on 

[edk2-devel] Adding HTTP boot IO timeout programmability from PcdHttpIoTimeout

[Clark-williams, Zachary]

Hello,

Please review the attached filed EDK2 tracker for feature enablement of 
programmable timeout of the HTTP boot IO timer.

NetworkPkg-HttpBoot: Making the HTTP IO timeout value programmable with PCD.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3507

HTTP boot has a default set forced timeout value of 5 seconds for getting the 
recovery image from a remote source. This change allows the HTTP boot flow to 
get the IO timeout value from the PcdHttpIoTimeout. PcdHttpIoTimeout value is 
set in the OneClickRecovery driver from the value provided by CSME.

PcdHttpIoTimeout minimum value 0.5 seconds

PcdHttpIoTimeout maximum value 120 seconds

PcdHttpIoTimeout default value 5 seconds

Thank you,
Zack


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

Re: [edk2-devel] [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte Page Granularity

[Ni, Ray]

Ashraf,
Thanks for the summary. Can you send a V2 patch which only take cares the 1G 
page table assembly logic?

Thanks,
Ray

> -Original Message-
> From: S, Ashraf Ali 
> Sent: Friday, July 23, 2021 12:58 AM
> To: Ni, Ray ; Dov Murik ; Ard 
> Biesheuvel ; Brijesh Singh
> ; James Bottomley ; Erdem Aktas 
> ; Tom Lendacky
> ; Xu, Min M 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Justen, 
> Jordan L ;
> Agyeman, Prince ; Kumar, Rahul1 
> ; De, Debkumar
> ; Han, Harry ; West, Catharine 
> ; V, Sangeetha
> 
> Subject: RE: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte 
> Page Granularity
> 
> Hi. Ray
> Based on Dov Murik  Comments to take the python 
> script changes separately,
> I have filed the Bugzilla for that separately.
> https://bugzilla.tianocore.org/show_bug.cgi?id=3506
> 
> verified the binary. More details are in Bugzilla.
> 
> Regards,
> Ashraf Ali S
> Intel Technology India Pvt. Ltd.
> 
> -Original Message-
> From: Ni, Ray 
> Sent: Wednesday, July 21, 2021 3:00 PM
> To: Dov Murik ; Ard Biesheuvel ; 
> Brijesh Singh ; James
> Bottomley ; Erdem Aktas ; Tom 
> Lendacky ; Xu,
> Min M 
> Cc: S, Ashraf Ali ; devel@edk2.groups.io; Ard 
> Biesheuvel ; Justen, Jordan
> L ; Agyeman, Prince ; 
> Kumar, Rahul1 ; De,
> Debkumar ; Han, Harry ; West, 
> Catharine ; V,
> Sangeetha 
> Subject: RE: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte 
> Page Granularity
> 
> OVMF's ResetVector is including the UefiCpuPkg's ResetVector. So, OVMF owners 
> please do evaluate the impact.
> 
> I think this change assumes platform owner knows which format of page table 
> should be chosen in build time.
> 
> -Original Message-
> From: Dov Murik 
> Sent: Tuesday, July 20, 2021 4:02 AM
> To: Ard Biesheuvel ; Ni, Ray ; Brijesh 
> Singh ; James Bottomley
> ; Erdem Aktas ; Tom Lendacky 
> 
> Cc: S, Ashraf Ali ; devel@edk2.groups.io; Ard 
> Biesheuvel ; Justen, Jordan
> L ; Agyeman, Prince ; 
> Kumar, Rahul1 ; De,
> Debkumar ; Han, Harry ; West, 
> Catharine ; V,
> Sangeetha 
> Subject: Re: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte 
> Page Granularity
> 
> 
> 
> On 19/07/2021 10:09, Ard Biesheuvel wrote:
> > On Mon, 19 Jul 2021 at 05:14, Ni, Ray  wrote:
> >>
> >> This change generates the reset vector binary which only contains 1G page 
> >> table. If a platform doesn't support 1G page table,
> this will cause system hang.
> >>
> >> To Ard and Jordan,
> >> Can you evaluate whether this change impacts OVMF?
> >>
> >
> > I don't have a clue, sorry, and I wouldn't know where to begin looking.
> >
> > Brijesh, Dov, James, Erdem: after Laszlo's sudden departure, I will be
> > needing help reviewing OVMF patches that are highly specific to
> > SEV/SNP or x86 in general.
> 
> Adding Tom too - I think he modified the OVMF reset vector lately and might 
> know.
> 
> >
> > Please take a look.
> 
> 
> I'm not an expert, but I think that OVMF has its own reset vector in 
> OvmfPkg/ResetVector, and therefore the changes in
> uefiCpuPkg will not affect OVMF.
> 
> 
> Regarding the patch itself:
> 
> (1) I suggest separating the python tooling changes to one patch, verifying 
> that the new python scripts generate the same binary
> files as the original python scripts.  Then add another patch which 
> introduces the reset vector changes.
> 
> (2) Do all x64 CPUs support 1 GB pages? Is it always enabled? Do we need to 
> check this capability somewhere?
> 
> 
> -Dov
> 
> 
> >
> >
> >> To Prince,
> >> Can you evaluate whether this change impacts SimicsOpenBoardPkg?
> >>
> >> Thanks,
> >> Ray
> >>
> >> -Original Message-
> >> From: S, Ashraf Ali 
> >> Sent: Friday, July 2, 2021 8:25 PM
> >> To: devel@edk2.groups.io
> >> Cc: S, Ashraf Ali ; Ni, Ray
> >> ; Kumar, Rahul1 ; De,
> >> Debkumar ; Han, Harry ;
> >> West, Catharine ; V, Sangeetha
> >> 
> >> Subject: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte
> >> Page Granularity
> >>
> >> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3473
> >>
> >> X64 Reset Vector Code can access the memory range till 4GB using the 
> >> Linear-Address Translation to a 2-MByte Page, when
> user wants to use more than 4G using 2M Page it will leads to use more number 
> of Page table entries. using the 1-GByte Page
> table user can use more than 4G Memory by reducing the page table entries 
> using 1-GByte Page, this patch attached can access
> memory range till 512GByte.
> >> Build Scrips for Reset Vector currently based on Python 2 which is already 
> >> EOL, needs to modify the build script based on
> Python 3, update the Binary accordingly.
> >>
> >> Cc: Ray Ni 
> >> Cc: Rahul Kumar 
> >> Cc: Debkumar De 
> >> Cc: Harry Han 
> >> Cc: Catharine West 
> >> Cc: Sangeetha V 
> >> Signed-off-by: Ashraf Ali S 
> >> ---
> >>  .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
> >>  .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
> >>  .../Vtf0/Bin/ResetVector.ia32.serial.raw  | 

Re: [edk2-devel] [PATCH V2 3/4] UefiCpuPkg/ResetVector: Add Main32 entry point in Main.asm

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Xu, Min M 
> Sent: Thursday, July 22, 2021 1:52 PM
> To: devel@edk2.groups.io
> Cc: Xu, Min M ; Dong, Eric ; Ni, Ray 
> ; Yao, Jiewen
> 
> Subject: [PATCH V2 3/4] UefiCpuPkg/ResetVector: Add Main32 entry point in 
> Main.asm
> 
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> In Tdx all CPUs "reset" to run on 32-bit protected mode with flat
> descriptor (paging disabled). Main32 entry point is added in
> UefiCpuPkg/ResetVector/Vtf0/Main.asm so that Main.asm can support
> the 32-bit protected mode.
> 
> Init32.asm is the 32-bit initialization code. It is a null stub in
> UefiCpuPkg. The actual initialization can be implemented in the platform
> (OvmfPkg/ResetVector/Ia32/Init32.asm is the example.)
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Jiewen Yao 
> Signed-off-by: Min Xu 
> ---
>  UefiCpuPkg/ResetVector/Vtf0/Ia32/Init32.asm | 13 +
>  UefiCpuPkg/ResetVector/Vtf0/Main.asm| 14 ++
>  UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb  |  2 +-
>  3 files changed, 28 insertions(+), 1 deletion(-)
>  create mode 100644 UefiCpuPkg/ResetVector/Vtf0/Ia32/Init32.asm
> 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Ia32/Init32.asm 
> b/UefiCpuPkg/ResetVector/Vtf0/Ia32/Init32.asm
> new file mode 100644
> index ..0cdae4a4a84a
> --- /dev/null
> +++ b/UefiCpuPkg/ResetVector/Vtf0/Ia32/Init32.asm
> @@ -0,0 +1,13 @@
> +;--
> +; @file
> +;   32-bit initialization code.
> +; Copyright (c) 2021, Intel Corporation. All rights reserved.
> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> +;
> +;--
> +
> +BITS 32
> +
> +Init32:
> +nop
> +OneTimeCallRet Init32
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Main.asm 
> b/UefiCpuPkg/ResetVector/Vtf0/Main.asm
> index 19d08482f831..4920c6937e1b 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Main.asm
> +++ b/UefiCpuPkg/ResetVector/Vtf0/Main.asm
> @@ -36,6 +36,20 @@ Main16:
> 
>  BITS32
> 
> +%ifdef ARCH_X64
> +
> +jmp SearchBfv
> +
> +;
> +; Entry point of Main32
> +;
> +Main32:
> +
> +OneTimeCall Init32
> +
> +%endif
> +
> +SearchBfv:
>  ;
>  ; Search for the Boot Firmware Volume (BFV)
>  ;
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb 
> b/UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb
> index 493738c79c1c..6493b9863c48 100644
> --- a/UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb
> +++ b/UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb
> @@ -51,7 +51,7 @@
>  %include "Ia32/SearchForSecEntry.asm"
> 
>  %ifdef ARCH_X64
> -%include "Ia32/Flat32ToFlat64.asm"
> +%include "Ia32/Init32.asm"
>  %include "Ia32/PageTables64.asm"
>  %endif
> 
> --
> 2.29.2.windows.2



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

Re: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3

[Ni, Ray]

Ashraf,
I assume that your previous ResetVector patch can be dropped, and we just 
review this one that supports python3 first, right?
Since this patch is for the feedbacks of patch separation, can you help to do 
it further?
1. only do minimal update to the python script to make it python3 capable. No 
additional printing.
2. add additional printing in 2nd patch
3. submit new .raw binary in a new patch serial because this binary update is 
not because of python3 but the out-of-dated binary.

To make it clear, 1 and 2 are two patches that belong to the same patch set.
3 is a separate patch.

Thanks,
Ray


> -Original Message-
> From: S, Ashraf Ali 
> Sent: Friday, July 23, 2021 12:41 AM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Ni, Ray ; 
> Kumar, Rahul1 ; De,
> Debkumar ; Han, Harry ; West, 
> Catharine ; V,
> Sangeetha 
> Subject: [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3
> 
> [edk2-devel] [PATCH]
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506
> 
> Build Scrips for Reset Vector currently based on Python 2
> which is already EOL, needs to modify the build script based on
> Python 3, update the Binary accordingly.
> 
> Change-Id: I2cfef08177951f2f29ee168ac4a9de9b10769ea1
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Debkumar De 
> Cc: Harry Han 
> Cc: Catharine West 
> Cc: Sangeetha V 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
>  .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
>  .../Vtf0/Bin/ResetVector.ia32.serial.raw  | Bin 884 -> 868 bytes
>  .../Vtf0/Bin/ResetVector.x64.port80.raw   | Bin 28676 -> 28676 bytes
>  .../ResetVector/Vtf0/Bin/ResetVector.x64.raw  | Bin 28676 -> 28676 bytes
>  .../Vtf0/Bin/ResetVector.x64.serial.raw   | Bin 28676 -> 28676 bytes
>  UefiCpuPkg/ResetVector/Vtf0/Build.py  |  11 +++
>  .../Vtf0/Tools/FixupForRawSection.py  |   4 ++--
>  8 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> index 
> 2c6ff655ded2a5855ca8f4428d559a7727eb6983..79b23c047bdc6e552d77d5c9e9aeae21ff04d91d
>  100644
> GIT binary patch
> delta 410
> zcmZo+dBQ9-0SF8a=rRZ}FxWCMF#Invo+zYJ-&~=>PEYMB8#X*^*s
> zI*-2o*Lifq#%B#L{TUe;3~zVd>wJ;c9c#dNqsaO-vqOwyxZ<^$|Sx+*`qBE-KP
> zRw#MZ?IF_m@c;k+44fxR?lK-MVJf=bP$9%z%Jy2m^*||G=ZV*+3=ec3YyDQrw
> zhLV39>OTT4_yTke(6spG0}_@eiX$2-m<39tfuvB0QMW|nV~~MBTOFDYFc(>?{CR!5
> z`2b5=qlIr@Ka2ph)3jn)CK3=F06%+4CG<$;o!=g(0n4LMA4`}djk7m=n
> z@tSo9&>Du9B|zggh&^lgwVUBX-))iIZU6Ps_!-61b|^D2IPfbSNPCqzIiFFU^R?Xs
> zd4>r<#gi8>%0vL2z`!uOpJBgKz-zAkjsdS((>jm5W_tbeb@R)JfB*l#TmvLJAN+p?
> a3S}hl`Z9zAvN|lpjbXxs*L#qpCjbB+6v6TU
> 
> delta 442
> zcmX9)O-lk%6n)b;mb6f61Fgs7G?G=i3EW`h#0jTXjjt=xN`<_@e*RfKhRH@
> zRthehQp z2#|b@Yi!yt8wAow*Da-71;Y*UMJdG%{oGQ>0fSK3#P_%@6n3VVmKY~2sF%gXydlkT
> zz2J+}fsf;~_pRoa+J(fR`Ut;~>qat}3#muERkA!QyT~Xg^M>rg%^bM|McBYs`8V0A
> zcP(O;ogKlFmCBIg5bqJ
> zBhR=?>3OE6Mw4r>-vk>Al5t4>DR50tqp6HM5M^V1To7n?Y1=u`A{@A7c!=ymHGRlZ
> zJ}anuVpcRdDYzN0P#%MY-J^!^vR_OvBRp9GvF1f*Ah$29X~lhJI8j|qcKWL;$
> mb+{6FrzA&7=!a5r41gb~Ws5tejhbe+Ol`#xF!g`tAAbQ#M!vED
> 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw 
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
> index 
> e34780a3a2c9b22bd10a1d5a405e344faaff94f3..ce7faa502b858e99908bcdb397b776258205e1d5
>  100644
> GIT binary patch
> delta 421
> zcmaFDe1%zP0uUG;&}9%{V6bIiVEA8TJW)uczPUn$q4ZSeVde;h(!;MgckBm(
> zbsl}`)Ec)Rmn=Zm!NSOdlzMb@vG9g56a50n@+A7C%iRr%2sA^z>KLdmOc50S=)
> z|NsAI;5=D!m+@c;Q_=N?3L)lFw%6jV2TIvGPrN>5c%buG>$g&-l7BD10Br{v65o74
> z!m|EEaYRD}vp|V7kQ6F0>XvAH3^E94n?v<|1pAKd)~$A7DvqwD658)#cwFVZ(U1
> z(K^7DfuU5M*;(VYJW#Upa9X2vSX3z=volBY0S*4`(QKMGUbF51+Qaa&258)`-3%Z4
> zZtt%9ub0NpD4w=MnSsH9U+F;FtJKNSjMDY5-6qI0OaQ6_1rZE@G=l)pF$@fo_h
> zFuI>%zf-_#uKkVyuUXSNkGy7j{quG6%Zz{j|G(S NFyZwchzJ{m0sv1?z^?!R
> 
> literal 484
> zcmX9*OG_g`5Uz2YXi!K{AwfI@4Wb8^4I;k92Z}6+5k#W02QLkK9j9Rq9_
> zqIePigaaNjIzCSdixLS)RFt&2cybqA?5!~cU5~H6s_N>tZQD+`9S{Z>1OTb`GBa#G
> zt*_G(GaClinx^RkGo#yGe2LyNvnlO${H9mTj3XK78TZswjJl#0BPWZ(PsE3m63x5<
> zkjV2pUL={H-<6y`Ayi}y>qBYR=+mmu*E{2X*HV!;FJ=@olMU=1D z>r@*9G|11z5fTzEKTW^U3gc6Jd}Rz>i=xwezWi&|RKrFLb)7MgiLyt(A5Nap
> z{K@){_&;%jkXDHiVLej|v^%t)8c;mepB%?^+SRc((Td402KNZ-pIe~y>R7ebhG=Mi
> zG0>h98oCZ15CogOAHb`XKiHDrNJxngrv+CGHM`_x1(RWLh67mGTp&(0SUJnJ3Rcm&
> z65UvCM_?B@w(a-w1uqM*d0DnQmyjJzmTIyi$x?vuV|+aEM~V$8raq+ TrM$1pedcB-0FmP|Qr7 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw
> index 
> 6dfa68eabb48a44bc50a0b7fe678f80b5cdadfd5..6503a988abdac06f9aa88f0a65f2525e12233b0a
>  100644
> GIT binary patch
> delta 426
> zcmeyu_JnPMtNJIm{T
> zoku68$xYtMs2t$H#K2&9yYpV>i?r@o1I8OgcCVQoiY!|Xl$bUjU@tOI`Oy_2{_U_r
> z$*XP;k;aGr|Nm#;JXvy=@n8v4(e;K3A?8xfm(zi^wH_#C>pb!L_+($k?)of7kU%
> 

[edk2-devel] [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit assignment

[Benjamin Doron]

In the case where the root bridge's Mem.Limit is the base address of
PCIe MMIO, subtract one to make a valid end address.

This fixes an issue where CpuDxe returns "Length(0x5001) is not
aligned!" when PciHostBridgeDxe attempts to make this range uncacheable.

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Eric Dong 
Signed-off-by: Benjamin Doron 
---
 
Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
index e231f747019e..0e3fee28b5d1 100644
--- 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
+++ 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
@@ -90,7 +90,7 @@ PciHostBridgeGetRootBridges (
   if (PcdGet32(PcdPciReservedMemLimit) != 0) {
 mRootBridgeTemplate.Mem.Limit = PcdGet32 (PcdPciReservedMemLimit);
   } else {
-mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64 
(PcdPciExpressBaseAddress);
+mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64 
(PcdPciExpressBaseAddress) - 1;
   }
 
   mRootBridgeTemplate.MemAbove4G.Base = PcdGet64 
(PcdPciReservedMemAbove4GBBase);
-- 
2.31.1



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

Re: [edk2-devel] RFC: EXT4 filesystem driver

[Nate DeSimone]

Hi Pedro,

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Pedro
> Falcato
> Sent: Thursday, July 22, 2021 9:54 AM
> To: Andrew Fish 
> Cc: edk2-devel-groups-io ; mhaeu...@posteo.de;
> r...@edk2.groups.io
> Subject: Re: [edk2-devel] RFC: EXT4 filesystem driver
> 
> Hi Andrew, Marvin,
> 
> RE: The package name: It doesn't sound like a bad idea to have something
> like a FileSystemPkg and have a bunch of different filesystems inside of it,
> but I'll defer to you and my mentors' judgement; we could also drop that
> issue for now and take care of it afterwards, since it may need further
> changes that are not a part of GSoC and would just delay the process.
> 
> With respect to the write capabilities of the driver, I'm not entirely sure
> whether or not it's useful. I've been thinking about it today, and it seems 
> like
> there's not much that could go wrong? The write path isn't excessively
> complex. Except of course in the event of an untimely power cut, but those
> /should/ be easily detected by the checksums. My initial idea was to have it
> up to speed with FatPkg and other filesystems by implementing all of
> EFI_FILE_PROTOCOL, including the write portions. If Apple's HFS+ and APFS
> drivers don't have those, it may be a decent idea to reduce the scope of the
> ext4 driver as well. I don't see a big need for write support; on the other
> hand, I've only worked on UEFI bootloaders before, which may be an outlier
> in that regard. Further feedback is appreciated.

The most commonly used reason to for writing to the filesystem in a production 
environment is capsule updates. Most capsule update implementations will stage 
the capsule on the EFI System Partition and then reset the system to unlock 
flash. The second most useful is the UEFI Shell and all the many applications 
that run within it will write to the filesystem for a large variety of reasons. 
I think it would be a useful feature to have as one could conceivably start 
using EFI System Partitions formatted as ext4.

> 
> As for the tests, UEFI SCTs already seem to have some tests on
> EFI_FILE_PROTOCOL's. Further testing may require some sort of fuzzing,
> which is what I want to, although in a simplified way. With fuzzing we could
> hammer the filesystem code with all sorts of different calls in different
> orders, we could also mutate the disk structures to test if the driver is 
> secure
> and can handle corruption in a nice, safe way. A future (GSoC or not) project
> could also attempt to use compiler-generated coverage instrumentation (see
> LLVM's LibFuzzer and SanitizerCoverage for an example).
> 
> I'm not sure about all OSes, but at least Linux ext2/3/4 drivers are very 
> robust
> and can handle and work around any corrupted FS I
> (accidentally) throw at them. However, running fsck is the best way to detect
> corruption; note that licensing may be an issue as, for example, ext4's fsck 
> is
> GPL2 licensed.
> 
> Best Regards,
> Pedro
> 
> On Thu, 22 Jul 2021 at 16:58, Andrew Fish  wrote:
> >
> >
> >
> > On Jul 22, 2021, at 3:24 AM, Marvin Häuser  wrote:
> >
> > On 22.07.21 01:12, Pedro Falcato wrote:
> >
> > EXT4 (fourth extended filesystem) is a filesystem developed for Linux
> > that has been in wide use (desktops, servers, smartphones) since 2008.
> >
> > The Ext4Pkg implements the Simple File System Protocol for a partition
> > that is formatted with the EXT4 file system. This allows UEFI Drivers,
> > UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
> > on an EXT4 partition and supports booting a UEFI OS Loader from an
> > EXT4 partition.
> > This project is one of the TianoCore Google Summer of Code projects.
> >
> > Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
> > UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
> > I/O 2 Protocols, and produces the Simple File System protocol. It
> > allows mounting ext4 filesystems exclusively.
> >
> > Brief overhead of EXT4:
> > Layout of an EXT2/3/4 filesystem:
> > (note: this driver has been developed using
> > https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
> > documentation).
> >
> > An ext2/3/4 filesystem (here on out referred to as simply an ext4
> > filesystem, due to the similarities) is composed of various concepts:
> >
> > 1) Superblock
> > The superblock is the structure near (1024 bytes offset from the
> > start) the start of the partition, and describes the filesystem in general.
> > Here, we get to know the size of the filesystem's blocks, which
> > features it supports or not, whether it's been cleanly unmounted, how
> > many blocks we have, etc.
> >
> > 2) Block groups
> > EXT4 filesystems are divided into block groups, and each block group
> > covers
> > s_blocks_per_group(8 * Block Size) blocks. Each block group has an
> > associated block group descriptor; these are present directly after
> > the superblock. Each block group descriptor contains the location of

[edk2-devel] [RFC] MemoryProtectionLib for Dynamic Memory Guard Settings

[Taylor Beebe]

Current memory protection settings rely on FixedAtBuild PCD values 
(minus PcdSetNxForStack). Because of this, the memory protection 
configuration interface is fixed in nature. Cases arise in which memory 
protections might need to be adjusted between boots (if platform design 
allows) to avoid disabling a system. For example, platforms might choose 
to allow the user to control their protection policies such as allow 
execution of critical 3rd party software that might violate memory 
protections.


This RFC seeks your feedback regarding introducing an interface that 
allows dynamic configuration of memory protection settings.


I would like to propose two options:
1. Describing the memory protection setting configuration in a HOB that 
is produced by the platform.
2. Introducing a library class (e.g. MemoryProtectionLib) that allows 
abstraction of the memory protection setting configuration data source.


In addition, I would like to know if the memory protection FixedAtBuild 
PCDs currently in MdeModulePkg can be removed so we can move the 
configuration interface entirely to an option above.


In any case, I would like the settings to be visible to environments 
such as Standalone MM where dynamic PCDs are not accessible.


I am seeking your feedback on this proposal in preparation for sending 
an edk2 patch series.


--
Taylor Beebe
Software Engineer @ Microsoft


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

[edk2-devel] [PATCH v1] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit assignment

[Benjamin Doron]

In the case where the root bridge's Mem.Limit is the base address of
PCIe MMIO, subtract one to make a valid end address.

This fixes an issue where CpuDxe returns "Length(0x5001) is not
aligned!" when PciHostBridgeDxe attempts to make this range uncacheable.

Signed-off-by: Benjamin Doron 
---
 
Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
index e231f747019e..0e3fee28b5d1 100644
--- 
a/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
+++ 
b/Platform/Intel/MinPlatformPkg/Pci/Library/PciHostBridgeLibSimple/PciHostBridgeLibSimple.c
@@ -90,7 +90,7 @@ PciHostBridgeGetRootBridges (
   if (PcdGet32(PcdPciReservedMemLimit) != 0) {
 mRootBridgeTemplate.Mem.Limit = PcdGet32 (PcdPciReservedMemLimit);
   } else {
-mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64 
(PcdPciExpressBaseAddress);
+mRootBridgeTemplate.Mem.Limit = (UINT32) PcdGet64 
(PcdPciExpressBaseAddress) - 1;
   }
 
   mRootBridgeTemplate.MemAbove4G.Base = PcdGet64 
(PcdPciReservedMemAbove4GBBase);
-- 
2.31.1



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

Re: [edk2-devel] [PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx

[Min Xu]

On July 23, 2021 1:08 AM, Tom Lendacky wrote:
> On 7/22/21 12:52 AM, Min Xu wrote:
> > RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> >
> > diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> > b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> > index c6d0d898bcd1..2206ca719593 100644
> > --- a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> > +++ b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> > @@ -17,6 +17,9 @@ Transition32FlatTo64Flat:
> >
> >  OneTimeCall SetCr3ForPageTables64
> >
> > +cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
> > +jz  TdxTransition32FlatTo64Flat
> > +
> 
> Is the memory area guaranteed to be zeroed for legacy guests? Hopefully,
> this won't trip up a non-TDX guest with a false match (highly unlikely, 
> though).
>
TDX_WORK_AREA is piece of TdxMailbox which is located in the MEMFD started
from PcdOvmfSecGhcbBackupBase. In Td guest, this memory region is initialized
to all-0 by host VMM. In legacy guests, I am not sure what's the initialized 
value
it is. So 'TDXG' is checked to guarantee it is Td-guest or not. 
Since Tdx re-use the memory region (PcdOvmfSecGhcbBackupBase) as the
TDX_WORK_AREA, and @Tom Lendacky you should be the original owner of
PcdOvmfSecGhcbBackupBase, can this area be cleared in the beginning of
ResetVector in legacy guests? Or I should better create a TDX specific work
area in MEMFD to guarantee the Td And Non-Td check?
>
>
> >  mov eax, cr4
> >  bts eax, 5  ; enable PAE
> >  mov cr4, eax
> > @@ -65,10 +68,54 @@ EnablePaging:
> >  bts eax, 31 ; set PG
> >  mov cr0, eax; enable paging
> >
> > +jmp _jumpTo64Bit
> > +
> > +;
> > +; Tdx Transition from 32Flat to 64Flat ;
> > +TdxTransition32FlatTo64Flat:
> > +
> > +mov eax, cr4
> > +bts eax, 5  ; enable PAE
> > +
> > +;
> > +; byte[TDX_WORK_AREA_PAGELEVEL5] holds the indicator whether
> 52bit is supported.
> > +; if it is the case, need to set LA57 and use 5-level paging
> > +;
> > +cmp byte[TDX_WORK_AREA_PAGELEVEL5], 0
> > +jz  .set_cr4
> > +bts eax, 12
> > +.set_cr4:
> > +mov cr4, eax
> > +mov ebx, cr3
> > +
> > +;
> > +; if la57 is not set, we are ok
> > +; if using 5-level paging, adjust top-level page directory
> > +;
> > +bt  eax, 12
> > +jnc .set_cr3
> > +mov ebx, TDX_PT_ADDR (0)
> > +.set_cr3:
> > +mov cr3, ebx
> > +
> > +mov eax, cr0
> > +bts eax, 31 ; set PG
> > +mov cr0, eax; enable paging
> 
> If you clear ebx here...
>
> > +
> > +_jumpTo64Bit:
> >  jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
> > +
> >  BITS64
> >  jumpTo64BitAndLandHere:
> >
> > +;
> > +; For Td guest we are done and jump to the end
> > +;
> > +mov eax, TDX_WORK_AREA
> > +cmp dword [eax], 0x47584454 ; 'TDXG'
> > +jz  GoodCompare
> > +
> 
> ... you can remove these instructions. You'll jump to InsnCompare and that
> check should succeed, right?
>
Ah, I see. Thanks for reminder. I will update it in next version.
>
> Thanks,
> Tom
> 
> >  ;
> >  ; Check if the second step of the SEV-ES mitigation is to be performed.
> >  ;


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

Re: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3

[Michael D Kinney]

According to the logs, the .raw file binaries were committed 10 years ago.

This commit in 2014 make a change to how the build defines are processed.  It 
also switches from using ASM to NASM for the assembler.


https://github.com/tianocore/edk2/commit/5a1f324d946cb1be2dc1226752b1965d6633232f#

I think one interesting test to make sure the binaries produced before and 
after your change produce the same binaries.  

That would at least confirm that the Python script changes are not introducing 
any changes and allow this update to move forward without the binary files.

A detailed review and testing of the binary differences needs to be done before 
committing any new .raw file.

Mike




> -Original Message-
> From: S, Ashraf Ali 
> Sent: Thursday, July 22, 2021 10:10 AM
> To: Kinney, Michael D ; devel@edk2.groups.io
> Cc: Ni, Ray ; Kumar, Rahul1 ; De, 
> Debkumar ; Han, Harry
> ; West, Catharine ; V, 
> Sangeetha 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for 
> Python 3
> 
> Hi., Michael
> 
> Even If we generate the binaries using the Python2 also, it's getting changed.
> 
> Can you confirm from your end by generating the binaries using the build.py 
> in Python2
> 
> 
> Regards,
> Ashraf Ali S
> Intel Technology India Pvt. Ltd.
> 
> -Original Message-
> From: Kinney, Michael D 
> Sent: Thursday, July 22, 2021 10:15 PM
> To: devel@edk2.groups.io; S, Ashraf Ali 
> Cc: Ni, Ray ; Kumar, Rahul1 ; De, 
> Debkumar ; Han, Harry
> ; West, Catharine ; V, 
> Sangeetha 
> Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for 
> Python 3
> 
> Hi Ashraf,
> 
> Why would an update to the Python script to Python3 cause any changes to the 
> binary images the script produces.
> 
> If they are different, then that would seem to imply that the change was not 
> compatible from a behavior perspective.
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Ashraf
> > Ali S
> > Sent: Thursday, July 22, 2021 9:41 AM
> > To: devel@edk2.groups.io
> > Cc: S, Ashraf Ali ; Ni, Ray
> > ; Kumar, Rahul1 ; De,
> > Debkumar ; Han, Harry ;
> > West, Catharine ; V, Sangeetha
> > 
> > Subject: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for
> > Python 3
> >
> > [edk2-devel] [PATCH]
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506
> >
> > Build Scrips for Reset Vector currently based on Python 2 which is
> > already EOL, needs to modify the build script based on Python 3,
> > update the Binary accordingly.
> >
> > Change-Id: I2cfef08177951f2f29ee168ac4a9de9b10769ea1
> > Cc: Ray Ni 
> > Cc: Rahul Kumar 
> > Cc: Debkumar De 
> > Cc: Harry Han 
> > Cc: Catharine West 
> > Cc: Sangeetha V 
> > Signed-off-by: Ashraf Ali S 
> > ---
> >  .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
> >  .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
> >  .../Vtf0/Bin/ResetVector.ia32.serial.raw  | Bin 884 -> 868 bytes
> >  .../Vtf0/Bin/ResetVector.x64.port80.raw   | Bin 28676 -> 28676 bytes
> >  .../ResetVector/Vtf0/Bin/ResetVector.x64.raw  | Bin 28676 -> 28676 bytes
> >  .../Vtf0/Bin/ResetVector.x64.serial.raw   | Bin 28676 -> 28676 bytes
> >  UefiCpuPkg/ResetVector/Vtf0/Build.py  |  11 +++
> >  .../Vtf0/Tools/FixupForRawSection.py  |   4 ++--
> >  8 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git
> > a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> > b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> > index
> > 2c6ff655ded2a5855ca8f4428d559a7727eb6983..79b23c047bdc6e552d77d5c9e9ae
> > ae21ff04d91d 100644 GIT binary patch delta 410
> > zcmZo+dBQ9-0SF8a=rRZ}FxWCMF#Invo+zYJ-&~=>PEYMB8#X*^*s
> > zI*-2o*Lifq#%B#L{TUe;3~zVd>wJ;c9c#dNqsaO-vqOwyxZ<^$|Sx+*`qBE-KP
> > zRw#MZ?IF_m@c;k+44fxR?lK-MVJf=bP$9%z%Jy2m^*||G=ZV*+3=ec3YyDQrw
> > zhLV39>OTT4_yTke(6spG0}_@eiX$2-m<39tfuvB0QMW|nV~~MBTOFDYFc(>?{CR!5
> > z`2b5=qlIr@Ka2ph)3jn)CK3=F06%+4CG<$;o!=g(0n4LMA4`}djk7m=n
> > z@tSo9&>Du9B|zggh&^lgwVUBX-))iIZU6Ps_!-61b|^D2IPfbSNPCqzIiFFU^R?Xs
> > zd4>r<#gi8>%0vL2z`!uOpJBgKz-zAkjsdS((>jm5W_tbeb@R)JfB*l#TmvLJAN+p?
> > a3S}hl`Z9zAvN|lpjbXxs*L#qpCjbB+6v6TU
> >
> > delta 442
> > zcmX9)O-lk%6n)b;mb6f61Fgs7G?G=i3EW`h#0jTXjjt=xN`<_@e*RfKhRH@
> > zRthehQp > z2#|b@Yi!yt8wAow*Da-71;Y*UMJdG%{oGQ>0fSK3#P_%@6n3VVmKY~2sF%gXydlkT
> > zz2J+}fsf;~_pRoa+J(fR`Ut;~>qat}3#muERkA!QyT~Xg^M>rg%^bM|McBYs`8V0A
> > zcP(O;ogKlFmCBIg5bqJ
> > zBhR=?>3OE6Mw4r>-vk>Al5t4>DR50tqp6HM5M^V1To7n?Y1=u`A{@A7c!=ymHGRlZ
> > zJ}anuVpcRdDYzN0P#%MY-J^!^vR_OvBRp9GvF1f*Ah$29X~lhJI8j|qcKWL;$
> > mb+{6FrzA&7=!a5r41gb~Ws5tejhbe+Ol`#xF!g`tAAbQ#M!vED
> >
> > diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
> > b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
> > index
> > e34780a3a2c9b22bd10a1d5a405e344faaff94f3..ce7faa502b858e99908bcdb397b7
> > 76258205e1d5 100644 GIT binary patch delta 421
> > 

Re: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3

[Ashraf Ali S]

Hi., Michael

Even If we generate the binaries using the Python2 also, it's getting changed.

Can you confirm from your end by generating the binaries using the build.py in 
Python2


Regards,
Ashraf Ali S
Intel Technology India Pvt. Ltd. 

-Original Message-
From: Kinney, Michael D  
Sent: Thursday, July 22, 2021 10:15 PM
To: devel@edk2.groups.io; S, Ashraf Ali 
Cc: Ni, Ray ; Kumar, Rahul1 ; De, 
Debkumar ; Han, Harry ; West, 
Catharine ; V, Sangeetha 
Subject: RE: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for 
Python 3

Hi Ashraf,

Why would an update to the Python script to Python3 cause any changes to the 
binary images the script produces.

If they are different, then that would seem to imply that the change was not 
compatible from a behavior perspective.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ashraf 
> Ali S
> Sent: Thursday, July 22, 2021 9:41 AM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Ni, Ray 
> ; Kumar, Rahul1 ; De, 
> Debkumar ; Han, Harry ; 
> West, Catharine ; V, Sangeetha 
> 
> Subject: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for 
> Python 3
> 
> [edk2-devel] [PATCH]
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506
> 
> Build Scrips for Reset Vector currently based on Python 2 which is 
> already EOL, needs to modify the build script based on Python 3, 
> update the Binary accordingly.
> 
> Change-Id: I2cfef08177951f2f29ee168ac4a9de9b10769ea1
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Debkumar De 
> Cc: Harry Han 
> Cc: Catharine West 
> Cc: Sangeetha V 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
>  .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
>  .../Vtf0/Bin/ResetVector.ia32.serial.raw  | Bin 884 -> 868 bytes
>  .../Vtf0/Bin/ResetVector.x64.port80.raw   | Bin 28676 -> 28676 bytes
>  .../ResetVector/Vtf0/Bin/ResetVector.x64.raw  | Bin 28676 -> 28676 bytes
>  .../Vtf0/Bin/ResetVector.x64.serial.raw   | Bin 28676 -> 28676 bytes
>  UefiCpuPkg/ResetVector/Vtf0/Build.py  |  11 +++
>  .../Vtf0/Tools/FixupForRawSection.py  |   4 ++--
>  8 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git 
> a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> index 
> 2c6ff655ded2a5855ca8f4428d559a7727eb6983..79b23c047bdc6e552d77d5c9e9ae
> ae21ff04d91d 100644 GIT binary patch delta 410
> zcmZo+dBQ9-0SF8a=rRZ}FxWCMF#Invo+zYJ-&~=>PEYMB8#X*^*s
> zI*-2o*Lifq#%B#L{TUe;3~zVd>wJ;c9c#dNqsaO-vqOwyxZ<^$|Sx+*`qBE-KP
> zRw#MZ?IF_m@c;k+44fxR?lK-MVJf=bP$9%z%Jy2m^*||G=ZV*+3=ec3YyDQrw
> zhLV39>OTT4_yTke(6spG0}_@eiX$2-m<39tfuvB0QMW|nV~~MBTOFDYFc(>?{CR!5
> z`2b5=qlIr@Ka2ph)3jn)CK3=F06%+4CG<$;o!=g(0n4LMA4`}djk7m=n
> z@tSo9&>Du9B|zggh&^lgwVUBX-))iIZU6Ps_!-61b|^D2IPfbSNPCqzIiFFU^R?Xs
> zd4>r<#gi8>%0vL2z`!uOpJBgKz-zAkjsdS((>jm5W_tbeb@R)JfB*l#TmvLJAN+p?
> a3S}hl`Z9zAvN|lpjbXxs*L#qpCjbB+6v6TU
> 
> delta 442
> zcmX9)O-lk%6n)b;mb6f61Fgs7G?G=i3EW`h#0jTXjjt=xN`<_@e*RfKhRH@
> zRthehQp z2#|b@Yi!yt8wAow*Da-71;Y*UMJdG%{oGQ>0fSK3#P_%@6n3VVmKY~2sF%gXydlkT
> zz2J+}fsf;~_pRoa+J(fR`Ut;~>qat}3#muERkA!QyT~Xg^M>rg%^bM|McBYs`8V0A
> zcP(O;ogKlFmCBIg5bqJ
> zBhR=?>3OE6Mw4r>-vk>Al5t4>DR50tqp6HM5M^V1To7n?Y1=u`A{@A7c!=ymHGRlZ
> zJ}anuVpcRdDYzN0P#%MY-J^!^vR_OvBRp9GvF1f*Ah$29X~lhJI8j|qcKWL;$
> mb+{6FrzA&7=!a5r41gb~Ws5tejhbe+Ol`#xF!g`tAAbQ#M!vED
> 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw 
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
> index 
> e34780a3a2c9b22bd10a1d5a405e344faaff94f3..ce7faa502b858e99908bcdb397b7
> 76258205e1d5 100644 GIT binary patch delta 421 
> zcmaFDe1%zP0uUG;&}9%{V6bIiVEA8TJW)uczPUn$q4ZSeVde;h(!;MgckBm(
> zbsl}`)Ec)Rmn=Zm!NSOdlzMb@vG9g56a50n@+A7C%iRr%2sA^z>KLdmOc50S=)
> z|NsAI;5=D!m+@c;Q_=N?3L)lFw%6jV2TIvGPrN>5c%buG>$g&-l7BD10Br{v65o74
> z!m|EEaYRD}vp|V7kQ6F0>XvAH3^E94n?v<|1pAKd)~$A7DvqwD658)#cwFVZ(U1
> z(K^7DfuU5M*;(VYJW#Upa9X2vSX3z=volBY0S*4`(QKMGUbF51+Qaa&258)`-3%Z4
> zZtt%9ub0NpD4w=MnSsH9U+F;FtJKNSjMDY5-6qI0OaQ6_1rZE@G=l)pF$@fo_h
> zFuI>%zf-_#uKkVyuUXSNkGy7j{quG6%Zz{j|G(S NFyZwchzJ{m0sv1?z^?!R
> 
> literal 484
> zcmX9*OG_g`5Uz2YXi!K{AwfI@4Wb8^4I;k92Z}6+5k#W02QLkK9j9Rq9_
> zqIePigaaNjIzCSdixLS)RFt&2cybqA?5!~cU5~H6s_N>tZQD+`9S{Z>1OTb`GBa#G
> zt*_G(GaClinx^RkGo#yGe2LyNvnlO${H9mTj3XK78TZswjJl#0BPWZ(PsE3m63x5<
> zkjV2pUL={H-<6y`Ayi}y>qBYR=+mmu*E{2X*HV!;FJ=@olMU=1D z>r@*9G|11z5fTzEKTW^U3gc6Jd}Rz>i=xwezWi&|RKrFLb)7MgiLyt(A5Nap
> z{K@){_&;%jkXDHiVLej|v^%t)8c;mepB%?^+SRc((Td402KNZ-pIe~y>R7ebhG=Mi
> zG0>h98oCZ15CogOAHb`XKiHDrNJxngrv+CGHM`_x1(RWLh67mGTp&(0SUJnJ3Rcm&
> z65UvCM_?B@w(a-w1uqM*d0DnQmyjJzmTIyi$x?vuV|+aEM~V$8raq+ TrM$1pedcB-0FmP|Qr7 
> diff --git 
> a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw
> index 
> 6dfa68eabb48a44bc50a0b7fe678f80b5cdadfd5..6503a988abdac06f9aa88f0a65f2
> 525e12233b0a 100644 GIT binary patch 

Re: [edk2-devel] [edk2-rfc] RFC: EXT4 filesystem driver

[Michael D Kinney]

> -Original Message-
> From: r...@edk2.groups.io  On Behalf Of gaoliming
> Sent: Wednesday, July 21, 2021 6:21 PM
> To: r...@edk2.groups.io; pedro.falc...@gmail.com; devel@edk2.groups.io
> Subject: 回复: [edk2-rfc] RFC: EXT4 filesystem driver
> 
> 
> 
> > -邮件原件-
> > 发件人: r...@edk2.groups.io  代表 Pedro Falcato
> > 发送时间: 2021年7月22日 7:12
> > 收件人: devel@edk2.groups.io
> > 抄送: r...@edk2.groups.io
> > 主题: [edk2-rfc] RFC: EXT4 filesystem driver
> >
> > EXT4 (fourth extended filesystem) is a filesystem developed for Linux
> > that has been in wide use (desktops, servers, smartphones) since 2008.
> >
> > The Ext4Pkg implements the Simple File System Protocol for a partition
> > that is formatted with the EXT4 file system. This allows UEFI Drivers,
> > UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
> > on an EXT4 partition and supports booting a UEFI OS Loader from an
> > EXT4 partition.
> > This project is one of the TianoCore Google Summer of Code projects.
> >
> > Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
> > UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
> > I/O 2 Protocols, and produces the Simple File System protocol. It
> > allows mounting ext4 filesystems exclusively.
> >
> > Brief overhead of EXT4:
> > Layout of an EXT2/3/4 filesystem:
> > (note: this driver has been developed using
> > https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
> > documentation).
> >
> > An ext2/3/4 filesystem (here on out referred to as simply an ext4 
> > filesystem,
> > due to the similarities) is composed of various concepts:
> >
> > 1) Superblock
> > The superblock is the structure near (1024 bytes offset from the start)
> > the start of the partition, and describes the filesystem in general.
> > Here, we get to know the size of the filesystem's blocks, which features
> > it supports or not, whether it's been cleanly unmounted, how many blocks
> > we have, etc.
> >
> > 2) Block groups
> > EXT4 filesystems are divided into block groups, and each block group covers
> > s_blocks_per_group(8 * Block Size) blocks. Each block group has an
> > associated block group descriptor; these are present directly after the
> > superblock. Each block group descriptor contains the location of the
> > inode table, and the inode and block bitmaps (note these bitmaps are only
> > a block long, which gets us the 8 * Block Size formula covered previously).
> >
> > 3) Blocks
> > The ext4 filesystem is divided into blocks, of size s_log_block_size ^ 1024.
> > Blocks can be allocated using individual block groups's bitmaps. Note
> > that block 0 is invalid and its presence on extents/block tables means
> > it's part of a file hole, and that particular location must be read as
> > a block full of zeros.
> >
> > 4) Inodes
> > The ext4 filesystem divides files/directories into inodes (originally
> > index nodes). Each file/socket/symlink/directory/etc (here on out referred
> > to as a file, since there is no distinction under the ext4 filesystem) is
> > stored as a /nameless/ inode, that is stored in some block group's inode
> > table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
> > an old filesystem), and holds various metadata about the file. Since the
> > largest inode structure right now is ~160 bytes, the rest of the inode
> > contains inline extended attributes. Inodes' data is stored using either
> > data blocks (under ext2/3) or extents (under ext4).
> >
> > 5) Extents
> > Ext4 inodes store data in extents. These let N contiguous logical blocks
> > that are represented by N contiguous physical blocks be represented by a
> > single extent structure, which minimizes filesystem metadata bloat and
> > speeds up block mapping (particularly due to the fact that high-quality
> > ext4 implementations like linux's try /really/ hard to make the file
> > contiguous, so it's common to have files with almost 0 fragmentation).
> > Inodes that use extents store them in a tree, and the top of the tree
> > is stored on i_data. The tree's leaves always start with an
> > EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0
> > and
> > EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
> > block.
> >
> > 6) Directories
> > Ext4 directories are files that store name -> inode mappings for the
> > logical directory; this is where files get their names, which means ext4
> > inodes do not themselves have names, since they can be linked (present)
> > multiple times with different names. Directories can store entries in two
> > different ways:
> > 1) Classical linear directories: They store entries as a mostly-linked
> > mostly-list of EXT4_DIR_ENTRY.
> > 2) Hash tree directories: These are used for larger directories, with
> > hundreds of entries, and are designed in a backwards-compatible way.
> > These are not yet implemented in the Ext4Dxe driver.
> >
> > 7) Journal
> > Ext3/4 filesystems have a journal to 

Re: [edk2-devel] [PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx

[Lendacky, Thomas via groups.io]

On 7/22/21 12:52 AM, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
> 
> In Tdx all CPUs "reset" to run on 32-bit protected mode with flat
> descriptor (paging disabled). But in Non-Td guest the initial state of
> CPUs is 16-bit real mode. To resolve this conflict, BITS 16/32 is used
> in the very beginning of ResetVector. It will check the 32-bit protected
> mode or 16-bit real mode, then jump to the corresponding entry point.
> This is done in OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm.
> 
> ReloadFlat32.asm load the GDT and set the CR0, then jump to Flat-32 mode.
> 
> InitTdx.asm is called to record the Tdx signature ('TDXG') and other tdx
> information in a TDX_WORK_AREA which can be used by the other routines in
> ResetVector.
> 
> Init32.asm is 32-bit initialization code in OvmfPkg. It puts above
> ReloadFlat32 and InitTdx together to do the initializaiton for Tdx.
> 
> After that Tdx jumps to 64-bit long mode by doing following tasks:
> 1. SetCr3ForPageTables64
>For OVMF, some initial page tables is built at:
>  PcdOvmfSecPageTablesBase - (PcdOvmfSecPageTablesBase + 0x6000)
>This page table supports the 4-level page table.
>But Tdx support 4-level and 5-level page table based on the CPU GPA width.
>48bit is 4-level paging, 52-bit is 5-level paging.
>If 5-level page table is supported (GPAW is 52), then a top level
>page directory pointers (1 * 256TB entry) is generated in the
>TdxPageTable.
> 2. Set Cr4
>Enable PAE.
> 3. Adjust Cr3
>If GPAW is 48, then Cr3 is PT_ADDR (0). If GPAW is 52, then Cr3 is
>TDX_PT_ADDR (0).
> 
> Tdx MailBox [0x10, 0x800] is reserved for OS. So we initialize piece of this
> area ([0x10, 0x20]) to record the Tdx flag ('TDXG') and other Tdx info so that
> they can be used in the following flow.
> 
> After all above is successfully done, Tdx jump to SecEntry.
> 
> Cc: Ard Biesheuvel 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Tom Lendacky 
> Signed-off-by: Min Xu 
> ---
>  OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 21 
>  OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm  | 47 
>  OvmfPkg/ResetVector/Ia32/Init32.asm  | 34 
>  OvmfPkg/ResetVector/Ia32/InitTdx.asm | 57 
>  OvmfPkg/ResetVector/Ia32/PageTables64.asm| 41 ++
>  OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm| 44 +++
>  OvmfPkg/ResetVector/ResetVector.nasmb| 18 +++
>  7 files changed, 262 insertions(+)
>  create mode 100644 OvmfPkg/ResetVector/Ia32/Init32.asm
>  create mode 100644 OvmfPkg/ResetVector/Ia32/InitTdx.asm
>  create mode 100644 OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm
> 
> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm 
> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> index ac86ce69ebe8..a390ed81d021 100644
> --- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> @@ -155,10 +155,31 @@ resetVector:
>  ;
>  ; This is where the processor will begin execution
>  ;
> +; In IA32 we follow the standard reset vector flow. While in X64, Td guest
> +; may be supported. Td guest requires the startup mode to be 32-bit
> +; protected mode but the legacy VM startup mode is 16-bit real mode.
> +; To make NASM generate such shared entry code that behaves correctly in
> +; both 16-bit and 32-bit mode, more BITS directives are added.
> +;
> +%ifdef ARCH_IA32
> +
>  nop
>  nop
>  jmp EarlyBspInitReal16
>  
> +%else
> +
> +smswax
> +testal, 1
> +jz  .Real
> +BITS 32
> +jmp Main32
> +BITS 16
> +.Real:
> +jmp EarlyBspInitReal16
> +
> +%endif
> +
>  ALIGN   16
>  
>  fourGigabytes:
> diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm 
> b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> index c6d0d898bcd1..2206ca719593 100644
> --- a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> +++ b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
> @@ -17,6 +17,9 @@ Transition32FlatTo64Flat:
>  
>  OneTimeCall SetCr3ForPageTables64
>  
> +cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
> +jz  TdxTransition32FlatTo64Flat
> +

Is the memory area guaranteed to be zeroed for legacy guests? Hopefully,
this won't trip up a non-TDX guest with a false match (highly unlikely,
though).

>  mov eax, cr4
>  bts eax, 5  ; enable PAE
>  mov cr4, eax
> @@ -65,10 +68,54 @@ EnablePaging:
>  bts eax, 31 ; set PG
>  mov cr0, eax; enable paging
>  
> +jmp _jumpTo64Bit
> +
> +;
> +; Tdx Transition from 32Flat to 64Flat
> +;
> +TdxTransition32FlatTo64Flat:
> +
> +mov eax, cr4
> +bts eax, 5  ; enable PAE
> +
> +;
> +; byte[TDX_WORK_AREA_PAGELEVEL5] holds the indicator whether 52bit is 
> supported.
> +; if it is the case, need to set LA57 and use 5-level 

Re: [edk2-devel] [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte Page Granularity

[Ashraf Ali S]

Hi. Ray
Based on Dov Murik  Comments to take the python script 
changes separately, 
I have filed the Bugzilla for that separately.
https://bugzilla.tianocore.org/show_bug.cgi?id=3506

verified the binary. More details are in Bugzilla.

Regards,
Ashraf Ali S
Intel Technology India Pvt. Ltd. 

-Original Message-
From: Ni, Ray  
Sent: Wednesday, July 21, 2021 3:00 PM
To: Dov Murik ; Ard Biesheuvel ; 
Brijesh Singh ; James Bottomley ; 
Erdem Aktas ; Tom Lendacky ; 
Xu, Min M 
Cc: S, Ashraf Ali ; devel@edk2.groups.io; Ard 
Biesheuvel ; Justen, Jordan L 
; Agyeman, Prince ; Kumar, 
Rahul1 ; De, Debkumar ; Han, 
Harry ; West, Catharine ; V, 
Sangeetha 
Subject: RE: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte Page 
Granularity

OVMF's ResetVector is including the UefiCpuPkg's ResetVector. So, OVMF owners 
please do evaluate the impact.

I think this change assumes platform owner knows which format of page table 
should be chosen in build time.

-Original Message-
From: Dov Murik  
Sent: Tuesday, July 20, 2021 4:02 AM
To: Ard Biesheuvel ; Ni, Ray ; Brijesh Singh 
; James Bottomley ; Erdem Aktas 
; Tom Lendacky 
Cc: S, Ashraf Ali ; devel@edk2.groups.io; Ard 
Biesheuvel ; Justen, Jordan L 
; Agyeman, Prince ; Kumar, 
Rahul1 ; De, Debkumar ; Han, 
Harry ; West, Catharine ; V, 
Sangeetha 
Subject: Re: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte Page 
Granularity



On 19/07/2021 10:09, Ard Biesheuvel wrote:
> On Mon, 19 Jul 2021 at 05:14, Ni, Ray  wrote:
>>
>> This change generates the reset vector binary which only contains 1G page 
>> table. If a platform doesn't support 1G page table, this will cause system 
>> hang.
>>
>> To Ard and Jordan,
>> Can you evaluate whether this change impacts OVMF?
>>
> 
> I don't have a clue, sorry, and I wouldn't know where to begin looking.
> 
> Brijesh, Dov, James, Erdem: after Laszlo's sudden departure, I will be 
> needing help reviewing OVMF patches that are highly specific to 
> SEV/SNP or x86 in general.

Adding Tom too - I think he modified the OVMF reset vector lately and might 
know.

> 
> Please take a look.


I'm not an expert, but I think that OVMF has its own reset vector in 
OvmfPkg/ResetVector, and therefore the changes in uefiCpuPkg will not affect 
OVMF.


Regarding the patch itself:

(1) I suggest separating the python tooling changes to one patch, verifying 
that the new python scripts generate the same binary files as the original 
python scripts.  Then add another patch which introduces the reset vector 
changes.

(2) Do all x64 CPUs support 1 GB pages? Is it always enabled? Do we need to 
check this capability somewhere?


-Dov


> 
> 
>> To Prince,
>> Can you evaluate whether this change impacts SimicsOpenBoardPkg?
>>
>> Thanks,
>> Ray
>>
>> -Original Message-
>> From: S, Ashraf Ali 
>> Sent: Friday, July 2, 2021 8:25 PM
>> To: devel@edk2.groups.io
>> Cc: S, Ashraf Ali ; Ni, Ray 
>> ; Kumar, Rahul1 ; De, 
>> Debkumar ; Han, Harry ; 
>> West, Catharine ; V, Sangeetha 
>> 
>> Subject: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte 
>> Page Granularity
>>
>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3473
>>
>> X64 Reset Vector Code can access the memory range till 4GB using the 
>> Linear-Address Translation to a 2-MByte Page, when user wants to use more 
>> than 4G using 2M Page it will leads to use more number of Page table 
>> entries. using the 1-GByte Page table user can use more than 4G Memory by 
>> reducing the page table entries using 1-GByte Page, this patch attached can 
>> access memory range till 512GByte.
>> Build Scrips for Reset Vector currently based on Python 2 which is already 
>> EOL, needs to modify the build script based on Python 3, update the Binary 
>> accordingly.
>>
>> Cc: Ray Ni 
>> Cc: Rahul Kumar 
>> Cc: Debkumar De 
>> Cc: Harry Han 
>> Cc: Catharine West 
>> Cc: Sangeetha V 
>> Signed-off-by: Ashraf Ali S 
>> ---
>>  .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
>>  .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
>>  .../Vtf0/Bin/ResetVector.ia32.serial.raw  | Bin 884 -> 868 bytes
>>  .../Vtf0/Bin/ResetVector.x64.port80.raw   | Bin 28676 -> 12292 bytes
>>  .../ResetVector/Vtf0/Bin/ResetVector.x64.raw  | Bin 28676 -> 12292 bytes
>>  .../Vtf0/Bin/ResetVector.x64.serial.raw   | Bin 28676 -> 12292 bytes
>>  UefiCpuPkg/ResetVector/Vtf0/Build.py  |  11 +--
>>  .../ResetVector/Vtf0/Ia32/PageTables64.asm|   2 +-
>>  UefiCpuPkg/ResetVector/Vtf0/ReadMe.txt|   2 +-
>>  .../Vtf0/Tools/FixupForRawSection.py  |   4 +-
>>  UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb|   4 +-
>>  .../ResetVector/Vtf0/X64/1GPageTables.asm |  64 ++
>>  .../X64/{PageTables.asm => 2MPageTables.asm}  |   0
>>  13 files changed, 77 insertions(+), 10 deletions(-)  create mode 
>> 100644 UefiCpuPkg/ResetVector/Vtf0/X64/1GPageTables.asm
>>  rename 

Re: [edk2-devel] RFC: EXT4 filesystem driver

[Pedro Falcato]

Hi Andrew, Marvin,

RE: The package name: It doesn't sound like a bad idea to have
something like a FileSystemPkg and have a bunch of different
filesystems inside of it, but I'll defer to you
and my mentors' judgement; we could also drop that issue for now and
take care of it afterwards, since it may need further changes that are
not a part of GSoC and would just delay the process.

With respect to the write capabilities of the driver, I'm not entirely
sure whether or not it's useful. I've been thinking about it today,
and it seems like there's not much that could go wrong? The write path
isn't excessively complex. Except of course in the event of an
untimely power cut, but those /should/ be easily detected by the
checksums. My initial idea was to have it up to speed with FatPkg and
other filesystems by implementing all of EFI_FILE_PROTOCOL, including
the write portions. If Apple's HFS+ and APFS drivers don't have those,
it may be a decent idea to reduce the scope of the ext4 driver as
well. I don't see a big need for write support; on the other hand,
I've only worked on UEFI bootloaders before, which may be an outlier
in that regard. Further feedback is appreciated.

As for the tests, UEFI SCTs already seem to have some tests on
EFI_FILE_PROTOCOL's. Further testing may require some sort of fuzzing,
which is what I want to, although in a
simplified way. With fuzzing we could hammer the filesystem code with
all sorts of different calls in different orders, we could also mutate
the disk structures to test if the driver is secure and
can handle corruption in a nice, safe way. A future (GSoC or not)
project could also attempt to use compiler-generated coverage
instrumentation (see LLVM's LibFuzzer and SanitizerCoverage for an
example).

I'm not sure about all OSes, but at least Linux ext2/3/4 drivers are
very robust and can handle and work around any corrupted FS I
(accidentally) throw at them. However, running fsck is the best way to
detect corruption; note that licensing may be an issue as, for
example, ext4's fsck is GPL2 licensed.

Best Regards,
Pedro

On Thu, 22 Jul 2021 at 16:58, Andrew Fish  wrote:
>
>
>
> On Jul 22, 2021, at 3:24 AM, Marvin Häuser  wrote:
>
> On 22.07.21 01:12, Pedro Falcato wrote:
>
> EXT4 (fourth extended filesystem) is a filesystem developed for Linux
> that has been in wide use (desktops, servers, smartphones) since 2008.
>
> The Ext4Pkg implements the Simple File System Protocol for a partition
> that is formatted with the EXT4 file system. This allows UEFI Drivers,
> UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
> on an EXT4 partition and supports booting a UEFI OS Loader from an
> EXT4 partition.
> This project is one of the TianoCore Google Summer of Code projects.
>
> Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
> UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
> I/O 2 Protocols, and produces the Simple File System protocol. It
> allows mounting ext4 filesystems exclusively.
>
> Brief overhead of EXT4:
> Layout of an EXT2/3/4 filesystem:
> (note: this driver has been developed using
> https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
> documentation).
>
> An ext2/3/4 filesystem (here on out referred to as simply an ext4 filesystem,
> due to the similarities) is composed of various concepts:
>
> 1) Superblock
> The superblock is the structure near (1024 bytes offset from the start)
> the start of the partition, and describes the filesystem in general.
> Here, we get to know the size of the filesystem's blocks, which features
> it supports or not, whether it's been cleanly unmounted, how many blocks
> we have, etc.
>
> 2) Block groups
> EXT4 filesystems are divided into block groups, and each block group covers
> s_blocks_per_group(8 * Block Size) blocks. Each block group has an
> associated block group descriptor; these are present directly after the
> superblock. Each block group descriptor contains the location of the
> inode table, and the inode and block bitmaps (note these bitmaps are only
> a block long, which gets us the 8 * Block Size formula covered previously).
>
> 3) Blocks
> The ext4 filesystem is divided into blocks, of size s_log_block_size ^ 1024.
> Blocks can be allocated using individual block groups's bitmaps. Note
> that block 0 is invalid and its presence on extents/block tables means
> it's part of a file hole, and that particular location must be read as
> a block full of zeros.
>
> 4) Inodes
> The ext4 filesystem divides files/directories into inodes (originally
> index nodes). Each file/socket/symlink/directory/etc (here on out referred
> to as a file, since there is no distinction under the ext4 filesystem) is
> stored as a /nameless/ inode, that is stored in some block group's inode
> table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
> an old filesystem), and holds various metadata about the file. Since the
> largest inode structure right 

Re: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3

[Michael D Kinney]

Hi Ashraf,

Why would an update to the Python script to Python3 cause any changes to the 
binary images the script produces.

If they are different, then that would seem to imply that the change was
not compatible from a behavior perspective.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ashraf Ali S
> Sent: Thursday, July 22, 2021 9:41 AM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Ni, Ray ; 
> Kumar, Rahul1 ; De,
> Debkumar ; Han, Harry ; West, 
> Catharine ; V,
> Sangeetha 
> Subject: [edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 
> 3
> 
> [edk2-devel] [PATCH]
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506
> 
> Build Scrips for Reset Vector currently based on Python 2
> which is already EOL, needs to modify the build script based on
> Python 3, update the Binary accordingly.
> 
> Change-Id: I2cfef08177951f2f29ee168ac4a9de9b10769ea1
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Debkumar De 
> Cc: Harry Han 
> Cc: Catharine West 
> Cc: Sangeetha V 
> Signed-off-by: Ashraf Ali S 
> ---
>  .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
>  .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
>  .../Vtf0/Bin/ResetVector.ia32.serial.raw  | Bin 884 -> 868 bytes
>  .../Vtf0/Bin/ResetVector.x64.port80.raw   | Bin 28676 -> 28676 bytes
>  .../ResetVector/Vtf0/Bin/ResetVector.x64.raw  | Bin 28676 -> 28676 bytes
>  .../Vtf0/Bin/ResetVector.x64.serial.raw   | Bin 28676 -> 28676 bytes
>  UefiCpuPkg/ResetVector/Vtf0/Build.py  |  11 +++
>  .../Vtf0/Tools/FixupForRawSection.py  |   4 ++--
>  8 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
> index 
> 2c6ff655ded2a5855ca8f4428d559a7727eb6983..79b23c047bdc6e552d77d5c9e9aeae21ff04d91d
>  100644
> GIT binary patch
> delta 410
> zcmZo+dBQ9-0SF8a=rRZ}FxWCMF#Invo+zYJ-&~=>PEYMB8#X*^*s
> zI*-2o*Lifq#%B#L{TUe;3~zVd>wJ;c9c#dNqsaO-vqOwyxZ<^$|Sx+*`qBE-KP
> zRw#MZ?IF_m@c;k+44fxR?lK-MVJf=bP$9%z%Jy2m^*||G=ZV*+3=ec3YyDQrw
> zhLV39>OTT4_yTke(6spG0}_@eiX$2-m<39tfuvB0QMW|nV~~MBTOFDYFc(>?{CR!5
> z`2b5=qlIr@Ka2ph)3jn)CK3=F06%+4CG<$;o!=g(0n4LMA4`}djk7m=n
> z@tSo9&>Du9B|zggh&^lgwVUBX-))iIZU6Ps_!-61b|^D2IPfbSNPCqzIiFFU^R?Xs
> zd4>r<#gi8>%0vL2z`!uOpJBgKz-zAkjsdS((>jm5W_tbeb@R)JfB*l#TmvLJAN+p?
> a3S}hl`Z9zAvN|lpjbXxs*L#qpCjbB+6v6TU
> 
> delta 442
> zcmX9)O-lk%6n)b;mb6f61Fgs7G?G=i3EW`h#0jTXjjt=xN`<_@e*RfKhRH@
> zRthehQp z2#|b@Yi!yt8wAow*Da-71;Y*UMJdG%{oGQ>0fSK3#P_%@6n3VVmKY~2sF%gXydlkT
> zz2J+}fsf;~_pRoa+J(fR`Ut;~>qat}3#muERkA!QyT~Xg^M>rg%^bM|McBYs`8V0A
> zcP(O;ogKlFmCBIg5bqJ
> zBhR=?>3OE6Mw4r>-vk>Al5t4>DR50tqp6HM5M^V1To7n?Y1=u`A{@A7c!=ymHGRlZ
> zJ}anuVpcRdDYzN0P#%MY-J^!^vR_OvBRp9GvF1f*Ah$29X~lhJI8j|qcKWL;$
> mb+{6FrzA&7=!a5r41gb~Ws5tejhbe+Ol`#xF!g`tAAbQ#M!vED
> 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw 
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
> index 
> e34780a3a2c9b22bd10a1d5a405e344faaff94f3..ce7faa502b858e99908bcdb397b776258205e1d5
>  100644
> GIT binary patch
> delta 421
> zcmaFDe1%zP0uUG;&}9%{V6bIiVEA8TJW)uczPUn$q4ZSeVde;h(!;MgckBm(
> zbsl}`)Ec)Rmn=Zm!NSOdlzMb@vG9g56a50n@+A7C%iRr%2sA^z>KLdmOc50S=)
> z|NsAI;5=D!m+@c;Q_=N?3L)lFw%6jV2TIvGPrN>5c%buG>$g&-l7BD10Br{v65o74
> z!m|EEaYRD}vp|V7kQ6F0>XvAH3^E94n?v<|1pAKd)~$A7DvqwD658)#cwFVZ(U1
> z(K^7DfuU5M*;(VYJW#Upa9X2vSX3z=volBY0S*4`(QKMGUbF51+Qaa&258)`-3%Z4
> zZtt%9ub0NpD4w=MnSsH9U+F;FtJKNSjMDY5-6qI0OaQ6_1rZE@G=l)pF$@fo_h
> zFuI>%zf-_#uKkVyuUXSNkGy7j{quG6%Zz{j|G(S NFyZwchzJ{m0sv1?z^?!R
> 
> literal 484
> zcmX9*OG_g`5Uz2YXi!K{AwfI@4Wb8^4I;k92Z}6+5k#W02QLkK9j9Rq9_
> zqIePigaaNjIzCSdixLS)RFt&2cybqA?5!~cU5~H6s_N>tZQD+`9S{Z>1OTb`GBa#G
> zt*_G(GaClinx^RkGo#yGe2LyNvnlO${H9mTj3XK78TZswjJl#0BPWZ(PsE3m63x5<
> zkjV2pUL={H-<6y`Ayi}y>qBYR=+mmu*E{2X*HV!;FJ=@olMU=1D z>r@*9G|11z5fTzEKTW^U3gc6Jd}Rz>i=xwezWi&|RKrFLb)7MgiLyt(A5Nap
> z{K@){_&;%jkXDHiVLej|v^%t)8c;mepB%?^+SRc((Td402KNZ-pIe~y>R7ebhG=Mi
> zG0>h98oCZ15CogOAHb`XKiHDrNJxngrv+CGHM`_x1(RWLh67mGTp&(0SUJnJ3Rcm&
> z65UvCM_?B@w(a-w1uqM*d0DnQmyjJzmTIyi$x?vuV|+aEM~V$8raq+ TrM$1pedcB-0FmP|Qr7 
> diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw
> b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.serial.raw
> index 
> 6dfa68eabb48a44bc50a0b7fe678f80b5cdadfd5..6503a988abdac06f9aa88f0a65f2525e12233b0a
>  100644
> GIT binary patch
> delta 426
> zcmeyu_JnPMtNJIm{T
> zoku68$xYtMs2t$H#K2&9yYpV>i?r@o1I8OgcCVQoiY!|Xl$bUjU@tOI`Oy_2{_U_r
> z$*XP;k;aGr|Nm#;JXvy=@n8v4(e;K3A?8xfm(zi^wH_#C>pb!L_+($k?)of7kU%
> z^8pFV6U7k?70d!9(m+zE#Hd@M@iE8{piK_V2bhbjRsOub-F$#0t z;YRBKR|bYsd1hyg*YZHg)?rble9X=q%?C92w@0%Rm4A|KIhO
> z`OON2k{`Q%FmEt?H#v*RP`Ks4UK&56c-jtS1_lRyr2}cNv?s4)imrd{GC`hU0?-K)
> zzyM?f2mqbLz%cndgq{tf`x*8-1-$0n?-=l!Bdznu%Ljj6Grj)ylK211_kaHXf4Teb
> e|Nos2{y&2l1two#MwlBG;>Ivx!s|Uq(h~riBD@{|
> 
> delta 425
> 

[edk2-devel] [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3

[Ashraf Ali S]

[edk2-devel] [PATCH]
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506

Build Scrips for Reset Vector currently based on Python 2
which is already EOL, needs to modify the build script based on
Python 3, update the Binary accordingly.

Change-Id: I2cfef08177951f2f29ee168ac4a9de9b10769ea1
Cc: Ray Ni 
Cc: Rahul Kumar 
Cc: Debkumar De 
Cc: Harry Han 
Cc: Catharine West 
Cc: Sangeetha V 
Signed-off-by: Ashraf Ali S 
---
 .../Vtf0/Bin/ResetVector.ia32.port80.raw  | Bin 516 -> 484 bytes
 .../ResetVector/Vtf0/Bin/ResetVector.ia32.raw | Bin 484 -> 468 bytes
 .../Vtf0/Bin/ResetVector.ia32.serial.raw  | Bin 884 -> 868 bytes
 .../Vtf0/Bin/ResetVector.x64.port80.raw   | Bin 28676 -> 28676 bytes
 .../ResetVector/Vtf0/Bin/ResetVector.x64.raw  | Bin 28676 -> 28676 bytes
 .../Vtf0/Bin/ResetVector.x64.serial.raw   | Bin 28676 -> 28676 bytes
 UefiCpuPkg/ResetVector/Vtf0/Build.py  |  11 +++
 .../Vtf0/Tools/FixupForRawSection.py  |   4 ++--
 8 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw 
b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.port80.raw
index 
2c6ff655ded2a5855ca8f4428d559a7727eb6983..79b23c047bdc6e552d77d5c9e9aeae21ff04d91d
 100644
GIT binary patch
delta 410
zcmZo+dBQ9-0SF8a=rRZ}FxWCMF#Invo+zYJ-&~=>PEYMB8#X*^*s
zI*-2o*Lifq#%B#L{TUe;3~zVd>wJ;c9c#dNqsaO-vqOwyxZ<^$|Sx+*`qBE-KP
zRw#MZ?IF_m@c;k+44fxR?lK-MVJf=bP$9%z%Jy2m^*||G=ZV*+3=ec3YyDQrw
zhLV39>OTT4_yTke(6spG0}_@eiX$2-m<39tfuvB0QMW|nV~~MBTOFDYFc(>?{CR!5
z`2b5=qlIr@Ka2ph)3jn)CK3=F06%+4CG<$;o!=g(0n4LMA4`}djk7m=n
z@tSo9&>Du9B|zggh&^lgwVUBX-))iIZU6Ps_!-61b|^D2IPfbSNPCqzIiFFU^R?Xs
zd4>r<#gi8>%0vL2z`!uOpJBgKz-zAkjsdS((>jm5W_tbeb@R)JfB*l#TmvLJAN+p?
a3S}hl`Z9zAvN|lpjbXxs*L#qpCjbB+6v6TU

delta 442
zcmX9)O-lk%6n)b;mb6f61Fgs7G?G=i3EW`h#0jTXjjt=xN`<_@e*RfKhRH@
zRthehQp0fSK3#P_%@6n3VVmKY~2sF%gXydlkT
zz2J+}fsf;~_pRoa+J(fR`Ut;~>qat}3#muERkA!QyT~Xg^M>rg%^bM|McBYs`8V0A
zcP(O;ogKlFmCBIg5bqJ
zBhR=?>3OE6Mw4r>-vk>Al5t4>DR50tqp6HM5M^V1To7n?Y1=u`A{@A7c!=ymHGRlZ
zJ}anuVpcRdDYzN0P#%MY-J^!^vR_OvBRp9GvF1f*Ah$29X~lhJI8j|qcKWL;$
mb+{6FrzA&7=!a5r41gb~Ws5tejhbe+Ol`#xF!g`tAAbQ#M!vED

diff --git a/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw 
b/UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.ia32.raw
index 
e34780a3a2c9b22bd10a1d5a405e344faaff94f3..ce7faa502b858e99908bcdb397b776258205e1d5
 100644
GIT binary patch
delta 421
zcmaFDe1%zP0uUG;&}9%{V6bIiVEA8TJW)uczPUn$q4ZSeVde;h(!;MgckBm(
zbsl}`)Ec)Rmn=Zm!NSOdlzMb@vG9g56a50n@+A7C%iRr%2sA^z>KLdmOc50S=)
z|NsAI;5=D!m+@c;Q_=N?3L)lFw%6jV2TIvGPrN>5c%buG>$g&-l7BD10Br{v65o74
z!m|EEaYRD}vp|V7kQ6F0>XvAH3^E94n?v<|1pAKd)~$A7DvqwD658)#cwFVZ(U1
z(K^7DfuU5M*;(VYJW#Upa9X2vSX3z=volBY0S*4`(QKMGUbF51+Qaa&258)`-3%Z4
zZtt%9ub0NpD4w=MnSsH9U+F;FtJKNSjMDY5-6qI0OaQ6_1rZE@G=l)pF$@fo_h
zFuI>%zf-_#uKkVyuUXSNkGy7j{quG6%Zz{j|G(StZQD+`9S{Z>1OTb`GBa#G
zt*_G(GaClinx^RkGo#yGe2LyNvnlO${H9mTj3XK78TZswjJl#0BPWZ(PsE3m63x5<
zkjV2pUL={H-<6y`Ayi}y>qBYR=+mmu*E{2X*HV!;FJ=@olMU=1Dr@*9G|11z5fTzEKTW^U3gc6Jd}Rz>i=xwezWi&|RKrFLb)7MgiLyt(A5Nap
z{K@){_&;%jkXDHiVLej|v^%t)8c;mepB%?^+SRc((Td402KNZ-pIe~y>R7ebhG=Mi
zG0>h98oCZ15CogOAHb`XKiHDrNJxngrv+CGHM`_x1(RWLh67mGTp&(0SUJnJ3Rcm&
z65UvCM_?B@w(a-w1uqM*d0DnQmyjJzmTIyi$x?vuV|+aEM~V$8raq+JIm{T
zoku68$xYtMs2t$H#K2&9yYpV>i?r@o1I8OgcCVQoiY!|Xl$bUjU@tOI`Oy_2{_U_r
z$*XP;k;aGr|Nm#;JXvy=@n8v4(e;K3A?8xfm(zi^wH_#C>pb!L_+($k?)of7kU%
z^8pFV6U7k?70d!9(m+zE#Hd@M@iE8{piK_V2bhbjRsOub-F$#0tIvx!s|Uq(h~riBD@{|

delta 425
zcmaFD_JwVNtbi=D;Q?I+0R{$J1_p-zMV1qFRYV|Y(?nnIjZR54`jN@+Ky@
zv%mcP|NsBaqZ1S4CZ1G|2xMYlFudJ)uk%G(cdP;9jUu;~%s_<>MRu(RN~~Dff$Sn<

Re: [edk2-devel] RFC: EXT4 filesystem driver

[Marvin Häuser]

On 22.07.21 17:58, Andrew Fish wrote:



On Jul 22, 2021, at 3:24 AM, Marvin Häuser > wrote:


On 22.07.21 01:12, Pedro Falcato wrote:

EXT4 (fourth extended filesystem) is a filesystem developed for Linux
that has been in wide use (desktops, servers, smartphones) since 2008.

The Ext4Pkg implements the Simple File System Protocol for a partition
that is formatted with the EXT4 file system. This allows UEFI Drivers,
UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
on an EXT4 partition and supports booting a UEFI OS Loader from an
EXT4 partition.
This project is one of the TianoCore Google Summer of Code projects.

Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
I/O 2 Protocols, and produces the Simple File System protocol. It
allows mounting ext4 filesystems exclusively.

Brief overhead of EXT4:
Layout of an EXT2/3/4 filesystem:
(note: this driver has been developed using
https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html 
 as

documentation).

An ext2/3/4 filesystem (here on out referred to as simply an ext4 
filesystem,

due to the similarities) is composed of various concepts:

1) Superblock
The superblock is the structure near (1024 bytes offset from the start)
the start of the partition, and describes the filesystem in general.
Here, we get to know the size of the filesystem's blocks, which features
it supports or not, whether it's been cleanly unmounted, how many blocks
we have, etc.

2) Block groups
EXT4 filesystems are divided into block groups, and each block group 
covers

s_blocks_per_group(8 * Block Size) blocks. Each block group has an
associated block group descriptor; these are present directly after the
superblock. Each block group descriptor contains the location of the
inode table, and the inode and block bitmaps (note these bitmaps are 
only
a block long, which gets us the 8 * Block Size formula covered 
previously).


3) Blocks
The ext4 filesystem is divided into blocks, of size s_log_block_size 
^ 1024.

Blocks can be allocated using individual block groups's bitmaps. Note
that block 0 is invalid and its presence on extents/block tables means
it's part of a file hole, and that particular location must be read as
a block full of zeros.

4) Inodes
The ext4 filesystem divides files/directories into inodes (originally
index nodes). Each file/socket/symlink/directory/etc (here on out 
referred
to as a file, since there is no distinction under the ext4 
filesystem) is

stored as a /nameless/ inode, that is stored in some block group's inode
table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
an old filesystem), and holds various metadata about the file. Since the
largest inode structure right now is ~160 bytes, the rest of the inode
contains inline extended attributes. Inodes' data is stored using either
data blocks (under ext2/3) or extents (under ext4).

5) Extents
Ext4 inodes store data in extents. These let N contiguous logical blocks
that are represented by N contiguous physical blocks be represented by a
single extent structure, which minimizes filesystem metadata bloat and
speeds up block mapping (particularly due to the fact that high-quality
ext4 implementations like linux's try /really/ hard to make the file
contiguous, so it's common to have files with almost 0 fragmentation).
Inodes that use extents store them in a tree, and the top of the tree
is stored on i_data. The tree's leaves always start with an
EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0 and
EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
block.

6) Directories
Ext4 directories are files that store name -> inode mappings for the
logical directory; this is where files get their names, which means ext4
inodes do not themselves have names, since they can be linked (present)
multiple times with different names. Directories can store entries 
in two

different ways:
1) Classical linear directories: They store entries as a mostly-linked
mostly-list of EXT4_DIR_ENTRY.
2) Hash tree directories: These are used for larger directories, with
hundreds of entries, and are designed in a backwards-compatible way.
These are not yet implemented in the Ext4Dxe driver.

7) Journal
Ext3/4 filesystems have a journal to help protect the filesystem against
system crashes. This is not yet implemented in Ext4Dxe but is described
in detail in the Linux kernel's documentation.

The EDK2 implementation of ext4 is based only on the public 
documentation
available at 
https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html 


and
the FreeBSD ext2fs driver (available at
https://github.com/freebsd/freebsd-src/tree/main/sys/fs/ext2fs 

Re: [edk2-devel] RFC: EXT4 filesystem driver

[Andrew Fish via groups.io]

> On Jul 22, 2021, at 3:24 AM, Marvin Häuser  wrote:
> 
> On 22.07.21 01:12, Pedro Falcato wrote:
>> EXT4 (fourth extended filesystem) is a filesystem developed for Linux
>> that has been in wide use (desktops, servers, smartphones) since 2008.
>> 
>> The Ext4Pkg implements the Simple File System Protocol for a partition
>> that is formatted with the EXT4 file system. This allows UEFI Drivers,
>> UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
>> on an EXT4 partition and supports booting a UEFI OS Loader from an
>> EXT4 partition.
>> This project is one of the TianoCore Google Summer of Code projects.
>> 
>> Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
>> UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
>> I/O 2 Protocols, and produces the Simple File System protocol. It
>> allows mounting ext4 filesystems exclusively.
>> 
>> Brief overhead of EXT4:
>> Layout of an EXT2/3/4 filesystem:
>> (note: this driver has been developed using
>> https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
>> documentation).
>> 
>> An ext2/3/4 filesystem (here on out referred to as simply an ext4 filesystem,
>> due to the similarities) is composed of various concepts:
>> 
>> 1) Superblock
>> The superblock is the structure near (1024 bytes offset from the start)
>> the start of the partition, and describes the filesystem in general.
>> Here, we get to know the size of the filesystem's blocks, which features
>> it supports or not, whether it's been cleanly unmounted, how many blocks
>> we have, etc.
>> 
>> 2) Block groups
>> EXT4 filesystems are divided into block groups, and each block group covers
>> s_blocks_per_group(8 * Block Size) blocks. Each block group has an
>> associated block group descriptor; these are present directly after the
>> superblock. Each block group descriptor contains the location of the
>> inode table, and the inode and block bitmaps (note these bitmaps are only
>> a block long, which gets us the 8 * Block Size formula covered previously).
>> 
>> 3) Blocks
>> The ext4 filesystem is divided into blocks, of size s_log_block_size ^ 1024.
>> Blocks can be allocated using individual block groups's bitmaps. Note
>> that block 0 is invalid and its presence on extents/block tables means
>> it's part of a file hole, and that particular location must be read as
>> a block full of zeros.
>> 
>> 4) Inodes
>> The ext4 filesystem divides files/directories into inodes (originally
>> index nodes). Each file/socket/symlink/directory/etc (here on out referred
>> to as a file, since there is no distinction under the ext4 filesystem) is
>> stored as a /nameless/ inode, that is stored in some block group's inode
>> table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
>> an old filesystem), and holds various metadata about the file. Since the
>> largest inode structure right now is ~160 bytes, the rest of the inode
>> contains inline extended attributes. Inodes' data is stored using either
>> data blocks (under ext2/3) or extents (under ext4).
>> 
>> 5) Extents
>> Ext4 inodes store data in extents. These let N contiguous logical blocks
>> that are represented by N contiguous physical blocks be represented by a
>> single extent structure, which minimizes filesystem metadata bloat and
>> speeds up block mapping (particularly due to the fact that high-quality
>> ext4 implementations like linux's try /really/ hard to make the file
>> contiguous, so it's common to have files with almost 0 fragmentation).
>> Inodes that use extents store them in a tree, and the top of the tree
>> is stored on i_data. The tree's leaves always start with an
>> EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0 and
>> EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
>> block.
>> 
>> 6) Directories
>> Ext4 directories are files that store name -> inode mappings for the
>> logical directory; this is where files get their names, which means ext4
>> inodes do not themselves have names, since they can be linked (present)
>> multiple times with different names. Directories can store entries in two
>> different ways:
>> 1) Classical linear directories: They store entries as a mostly-linked
>> mostly-list of EXT4_DIR_ENTRY.
>> 2) Hash tree directories: These are used for larger directories, with
>> hundreds of entries, and are designed in a backwards-compatible way.
>> These are not yet implemented in the Ext4Dxe driver.
>> 
>> 7) Journal
>> Ext3/4 filesystems have a journal to help protect the filesystem against
>> system crashes. This is not yet implemented in Ext4Dxe but is described
>> in detail in the Linux kernel's documentation.
>> 
>> The EDK2 implementation of ext4 is based only on the public documentation
>> available at 
>> https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html
>> and
>> the FreeBSD ext2fs driver (available at
>> https://github.com/freebsd/freebsd-src/tree/main/sys/fs/ext2fs,

Re: [edk2-devel] ArmVirt and Self-Updating Code

[Ard Biesheuvel]

On Thu, 22 Jul 2021 at 16:54, Bret Barkelew  wrote:
>
> Expanding audience to the full dev list…
>
> See below…
>
>
>
> - Bret
>
>
>
> From: Thomas Abraham
> Sent: Wednesday, July 7, 2021 11:07 PM
> To: Bret Barkelew; Ard Biesheuvel (TianoCore); Lindholm, Leif; Laszlo Ersek; 
> Marvin Häuser; Sami Mujawar
> Cc: nd
> Subject: [EXTERNAL] RE: ArmVirt and Self-Updating Code
>
>
>
> + Sami
>
>
>
> From: Bret Barkelew 
> Sent: Thursday, July 8, 2021 11:05 AM
> To: Thomas Abraham ; Ard Biesheuvel (TianoCore) 
> ; Lindholm, Leif ; Laszlo Ersek 
> ; Marvin Häuser 
> Subject: ArmVirt and Self-Updating Code
>
>
>
> All,
>
>
>
> Marvin asked me a question on the UEFI Talkbox Discord that’s a little beyond 
> my ken…
>
>
>
> “There is self-relocating code in ArmVirtPkg:
>
> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165
>
> According to comments in the ASM, it seems like this is for Linux-based RAM 
> boot (I saw further stuff for KVM, so it makes sense I guess?). It seems 
> unfortunate it cannot be mapped into a known address range so that 
> self-relocation is not necessary, but that's out of my scope to understand.
>

"Mapping" implies that the MMU is on, but this code boots with the MMU
off. Unlike x86, ARM does not define any physical address ranges that
are guaranteed to be backed by DRAM, so a portable image either needs
to be fully position independent, or carry the metadata it needs to
relocate itself as it is invoked.

>
>
> “Now, StandaloneMmPkg has similar (self-)relocation code too: 
> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386
>
> Because I cannot find such elsewhere, I assume it must be for the same ARM 
> virtualised environment as above.

No.

> The binary it applies the Relocations to is documented to be the Standalone 
> MM core, but in fact SecCore is located:
>
> https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c#L131-L158
>
>
>
> “This yields the following questions to me:
>
> 1) What even invokes Standalone MM on ARM? It is documented it is spawned 
> during SEC, but I could not find any actual invocation.
>

It is not spawned by the normal world code that runs UEFI. It is a
secure world component that runs in a completely different execution
context (TrustZone). The code does run with the MMU enabled from the
start, but running from an a priori fixed offset was considered to be
a security hazard, so we added self relocation support.

The alternative would have been to add metadata to the StMmCore
component that can be interpreted by the secure world component that
loads it, but this would go beyond any existing specs, and make
portability more problematic.

> 2) Why does Standalone MM (self-)relocation locate SecCore? Should it not 
> already have been relocated with the code from ArmPlatformPkg? Is Standalone 
> MM embedded into ARM SecCore?
>

No and no. Standalone MM has nothing to do with the code that runs as
part of UEFI itself. ArmPlatformPkg is completely separate from
StandaloneMmPkg.

> 3) Why is SecCore the only module relocated? Are all others guaranteed to be 
> "properly" loaded?
>

SecCore contains a PE/COFF loader, so all subsequent modules are
loaded normally. This is similar to the ArmVirtQemuKernel
self-relocating SEC module, which only relocates itself in this
manner, and relies on standard PE/COFF metadata for loading other
modules.


> 4) Is there maybe some high-level documented about the ARM boot flow? It 
> seems to be significantly different from the x86 routes quite vastly.”
>

trustedfirmware.org may have some useful documentation.

>
>
> Hoping that one of you could get me closer to an answer for him. Also happy 
> to take this to the greater mailing list, but thought I’d avoid churn.
>
>
>
> Thanks in advance!
>
> - Bret
>
>
>
>


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

Re: [edk2-devel] [staging/edk2-redfish-client Tools PATCH 6/6] RedfishClientPkg/Redfish-Profile-Simulator: Add requirements

[Nickle Wang]

Reviewed-by: Nickle Wang 

Thanks,
Nickle

From: Chang, Abner (HPS SW/FW Technologist) 
Sent: Thursday, July 22, 2021 14:08
To: devel@edk2.groups.io 
Cc: Wang, Nickle (HPS SW) ; Liming Gao 

Subject: [staging/edk2-redfish-client Tools PATCH 6/6] 
RedfishClientPkg/Redfish-Profile-Simulator: Add requirements

add requirements.txt for the required python module

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../Tools/Redfish-Profile-Simulator/requirements.txt| 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt

diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt
new file mode 100644
index 00..88807d87c2
--- /dev/null
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt
@@ -0,0 +1,2 @@
+flask==1.1.1
+pyOpenSSL
--
2.17.1



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

Re: [edk2-devel] [staging/edk2-redfish-client Tools PATCH 5/6] RedfishClientPkg/Redfish-Profile-Simulator: Add ETAG on memory resource

[Nickle Wang]

Reviewed-by: Nickle Wang 

Thanks,
Nickle

From: Chang, Abner (HPS SW/FW Technologist) 
Sent: Thursday, July 22, 2021 14:08
To: devel@edk2.groups.io 
Cc: Wang, Nickle (HPS SW) ; Liming Gao 

Subject: [staging/edk2-redfish-client Tools PATCH 5/6] 
RedfishClientPkg/Redfish-Profile-Simulator: Add ETAG on memory resource

Add ETAG support on Memory resource.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../Redfish-Profile-Simulator/v1sim/systems.py  | 13 +
 1 file changed, 13 insertions(+)

diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
index 690101fb10..de4b839aeb 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
@@ -18,6 +18,7 @@ from .resource import RfResource, RfCollection
 from .storage import RfSimpleStorageCollection, RfSmartStorage
 import flask
 import json
+import hashlib
 from collections import OrderedDict

 class RfSystemsCollection(RfCollection):
@@ -142,13 +143,25 @@ class RfMemoryCollection(RfCollection):
 self.res_data["Members"].append({"@odata.id":newMemoryUrl})

 post_data["@odata.id"] = newMemoryUrl
+
+md5 = hashlib.md5()
+md5.update(json.dumps(post_data).encode("utf-8"))
+etag_str = 'W/"' + md5.hexdigest() + '"'
+post_data["@odata.etag"] = etag_str
 self.elements[str(newMemoryIdx)] = post_data

 resp = flask.Response(json.dumps(post_data,indent=4))
 resp.headers["Location"] = newMemoryUrl
+resp.headers["ETag"] = etag_str
+
 return 0, 200, None, resp

 def patch_memory(self, Idx, patch_data):
+md5 = hashlib.md5()
+md5.update(json.dumps(patch_data).encode("utf-8"))
+etag_str = 'W/"' + md5.hexdigest() + '"'
+patch_data["@odata.etag"] = etag_str
+
 self.elements[str(Idx)] = {**self.elements[str(Idx)], **patch_data}
 resp = flask.Response(json.dumps(self.elements[str(Idx)],indent=4))
 return 0, 200, None, resp
--
2.17.1



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

Re: [edk2-devel] [staging/edk2-redfish-client Tools PATCH 4/6] RedfishClientPkg/Redfish-Profile-Simulator: HTTP methods on Memory Collection

[Nickle Wang]

Reviewed-by: Nickle Wang 

Thanks,
Nickle

From: Chang, Abner (HPS SW/FW Technologist) 
Sent: Thursday, July 22, 2021 14:08
To: devel@edk2.groups.io 
Cc: Wang, Nickle (HPS SW) ; Liming Gao 

Subject: [staging/edk2-redfish-client Tools PATCH 4/6] 
RedfishClientPkg/Redfish-Profile-Simulator: HTTP methods on Memory Collection

Add POST and PATCH methods on Memory collection and resource.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../v1sim/redfishURIs.py  | 25 +++
 .../v1sim/systems.py  | 43 +++
 2 files changed, 68 insertions(+)

diff --git 
a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
index 3c912f7ce1..35d3794cc6 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
@@ -1,6 +1,7 @@
 #
 # Copyright Notice:
 # Copyright (c) 2019, Intel Corporation. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 # Copyright Notice:
@@ -308,6 +309,30 @@ def rfApi_SimpleServer(root, versions, host="127.0.0.1", 
port=5000, cert="", key
 else:
 return err_string, status_code

+@app.route("/redfish/v1/Systems//Memory", 
methods=['POST'])
+@auth.rfAuthRequired
+def rf_computer_memory_post(system_id):
+print ("in POST memory collection")
+rdata = json.loads(request.data,object_pairs_hook=OrderedDict)
+print("rdata:{}".format(rdata))
+rc, status_code, err_string, resp = 
root.components['Systems'].get_element(system_id).components['Memory'].post_resource(rdata)
+if rc == 0:
+return resp, status_code
+else:
+return err_string, status_code
+
+
@app.route("/redfish/v1/Systems//Memory/", 
methods=['PATCH'])
+@auth.rfAuthRequired
+def rf_computer_memory_patch(system_id, MemoryIdx):
+print ("in PATCH memory[%s] resource" % MemoryIdx)
+rdata = json.loads(request.data,object_pairs_hook=OrderedDict)
+print("rdata:{}".format(rdata))
+rc, status_code, err_string, resp = 
root.components['Systems'].get_element(system_id).components['Memory'].patch_memory(MemoryIdx,
 rdata)
+if rc == 0:
+return resp, status_code
+else:
+return err_string, status_code
+
 def resolve_path(service, path):
 parts = path.split('/')
 result = service
diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
index b8b3788054..690101fb10 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
@@ -2,6 +2,7 @@
 # Copyright Notice:
 #
 # Copyright (c) 2019, Intel Corporation. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 # Copyright Notice:
@@ -123,9 +124,50 @@ class RfSystemObj(RfResource):

 # subclass Logs Collection
 class RfMemoryCollection(RfCollection):
+def final_init_processing(self, base_path, rel_path):
+self.maxIdx = self.res_data["Members@odata.count"]
+
 def element_type(self):
 return RfMemory

+def post_resource(self, post_data):
+
print("Members@odata.count:{}".format(self.res_data["Members@odata.count"]))
+print("Members:{}".format(self.res_data["Members"]))
+print("post_data:{}".format(post_data))
+
+self.res_data["Members@odata.count"] = 
self.res_data["Members@odata.count"] + 1
+self.maxIdx = self.maxIdx + 1
+newMemoryIdx = self.maxIdx
+newMemoryUrl = self.res_data["@odata.id"] + "/" + str(newMemoryIdx)
+self.res_data["Members"].append({"@odata.id":newMemoryUrl})
+
+post_data["@odata.id"] = newMemoryUrl
+self.elements[str(newMemoryIdx)] = post_data
+
+resp = flask.Response(json.dumps(post_data,indent=4))
+resp.headers["Location"] = newMemoryUrl
+return 0, 200, None, resp
+
+def patch_memory(self, Idx, patch_data):
+self.elements[str(Idx)] = {**self.elements[str(Idx)], **patch_data}
+resp = flask.Response(json.dumps(self.elements[str(Idx)],indent=4))
+return 0, 200, None, resp
+
+def get_memory(self, Idx):
+return json.dumps(self.elements[Idx],indent=4)
+
+def delete_memory(self, Idx):
+print("in delete_memory")
+
+resp = flask.Response(json.dumps(self.elements[Idx],indent=4))
+
+self.elements.pop(Idx)
+self.res_data["Members@odata.count"] = 
self.res_data["Members@odata.count"] - 1
+
+newMemoryUrl = self.res_data["@odata.id"] + "/" + str(Idx)
+

Re: [edk2-devel] ArmVirt and Self-Updating Code

[Bret Barkelew via groups.io]

Expanding audience to the full dev list…
See below…

- Bret

From: Thomas Abraham
Sent: Wednesday, July 7, 2021 11:07 PM
To: Bret Barkelew; Ard Biesheuvel 
(TianoCore); Lindholm, 
Leif; Laszlo Ersek; Marvin 
Häuser; Sami Mujawar
Cc: nd
Subject: [EXTERNAL] RE: ArmVirt and Self-Updating Code

+ Sami

From: Bret Barkelew 
Sent: Thursday, July 8, 2021 11:05 AM
To: Thomas Abraham ; Ard Biesheuvel (TianoCore) 
; Lindholm, Leif ; Laszlo Ersek 
; Marvin Häuser 
Subject: ArmVirt and Self-Updating Code

All,

Marvin asked me a question on the UEFI Talkbox Discord that’s a little beyond 
my ken…

“There is self-relocating code in ArmVirtPkg:
https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/ArmVirtPkg/PrePi/PrePi.c#L133-L165
According to comments in the ASM, it seems like this is for Linux-based RAM 
boot (I saw further stuff for KVM, so it makes sense I guess?). It seems 
unfortunate it cannot be mapped into a known address range so that 
self-relocation is not necessary, but that's out of my scope to understand.

“Now, StandaloneMmPkg has similar (self-)relocation code too: 
https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386
Because I cannot find such elsewhere, I assume it must be for the same ARM 
virtualised environment as above. The binary it applies the Relocations to is 
documented to be the Standalone MM core, but in fact SecCore is located:
https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/SetPermissions.c#L131-L158

“This yields the following questions to me:
1) What even invokes Standalone MM on ARM? It is documented it is spawned 
during SEC, but I could not find any actual invocation.
2) Why does Standalone MM (self-)relocation locate SecCore? Should it not 
already have been relocated with the code from ArmPlatformPkg? Is Standalone MM 
embedded into ARM SecCore?
3) Why is SecCore the only module relocated? Are all others guaranteed to be 
"properly" loaded?
4) Is there maybe some high-level documented about the ARM boot flow? It seems 
to be significantly different from the x86 routes quite vastly.”

Hoping that one of you could get me closer to an answer for him. Also happy to 
take this to the greater mailing list, but thought I’d avoid churn.

Thanks in advance!
- Bret




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

Re: [edk2-devel] [PATCH v1 6/6] UefiPayloadPkg: LinuxBoot: use a text format for the configuration block.

[Cheng-Chieh Huang via groups.io]

Here is the documentation:
https://github.com/osresearch/kexec-load/blob/main/README.md

On Thu, Jul 22, 2021 at 1:09 AM Marvin Häuser  wrote:

>
>
> On 21.07.21 15:23, Cheng-Chieh Huang via groups.io wrote:
> > From: Trammell Hudson 
> >
> > This adds a text command line for the UefiPayloadPkg that uses
> > a textual magic number 'LnxBoot1' and a series of white-space
> > separated key=value[,value...] pairs for the parameters.
> >
> > The v1 binary configuration structure is used if it is present instead
> > for backwards compatability.
> >
> > Currently supported text command line arguments are are:
> >
> > * `serial=baud,base,width,type,hz,pci`
> > (only `baud` needs to be specified, the rest have reasonable
> > defaults)
> >
> > * `mem=start,end,type`
> > Types are based on `/sys/firmware/memmaps/*/types`:
> >  1 == "System RAM"
> >  3 == "ACPI Tables"
> >  4 == "ACPI Non-volatile Storage"
> >  5 == "Reserved"
> >
> > * `ACPI20=base` pointer to RDSP (from `/sys/firmware/efi/systab`)
> >
> > * `SMBIOS=base` pointer to the SMBIOS table (also from the EFI table)
> >
> > Signed-off-by: Cheng-Chieh Huang 
> > ---
> >   UefiPayloadPkg/Include/Linuxboot.h |  17 +-
> >   UefiPayloadPkg/Library/LbParseLib/LbParseLib.c | 252
> +---
> >   2 files changed, 230 insertions(+), 39 deletions(-)
> >
> > diff --git a/UefiPayloadPkg/Include/Linuxboot.h
> b/UefiPayloadPkg/Include/Linuxboot.h
> > index 34ca18069983..56b39b5a09ff 100644
> > --- a/UefiPayloadPkg/Include/Linuxboot.h
> > +++ b/UefiPayloadPkg/Include/Linuxboot.h
> > @@ -24,8 +24,7 @@ typedef struct MemoryMapEntryStruct {
> > UINT32 Type;
> >   } MemoryMapEntry;
> >
> > -typedef struct UefiPayloadConfigStruct {
> > -  UINT64 Version;
> > +typedef struct {
> > UINT64 AcpiBase;
> > UINT64 AcpiSize;
> > UINT64 SmbiosBase;
> > @@ -33,10 +32,22 @@ typedef struct UefiPayloadConfigStruct {
> > SerialPortConfig SerialConfig;
> > UINT32 NumMemoryMapEntries;
> > MemoryMapEntry MemoryMapEntries[0];
> > +} UefiPayloadConfigV1;
> > +
> > +typedef struct UefiPayloadConfigStruct {
> > +  UINT64 Version;
> > +  union {
> > +UefiPayloadConfigV1 v1;
> > +struct {
> > +  char cmdline[0]; // up to 64 KB
> > +} v2;
> > +  } config;
> >   } UefiPayloadConfig;
> >   #pragma pack()
> >
> > -#define UEFI_PAYLOAD_CONFIG_VERSION 1
> > +// magic version config is "LnxBoot1"
> > +#define UEFI_PAYLOAD_CONFIG_VERSION1 1
> > +#define UEFI_PAYLOAD_CONFIG_VERSION2 0x31746f6f42786e4cULL
> >
> >   #define LINUXBOOT_MEM_RAM 1
> >   #define LINUXBOOT_MEM_DEFAULT 2
> > diff --git a/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
> b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
> > index 34bfb6a1073f..5e68091cac91 100644
> > --- a/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
> > +++ b/UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
> > @@ -1,13 +1,12 @@
> >   /** @file
> > -  This library will parse the linuxboot table in memory and extract
> those required
> > -  information.
> > +  This library will parse the linuxboot table in memory and extract
> those
> > +required information.
> >
> > Copyright (c) 2021, the u-root Authors. All rights reserved.
> > SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >   **/
> >
> > -
> >   #include 
> >   #include 
> >   #include 
> > @@ -18,17 +17,42 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> > +#include 
> > +//#include 
> > +//#include 
> > +
> > +#define strncmp(a, b, n) AsciiStrnCmp((a), (b), (n))
> > +
> > +static uint64_t parse_int(const char* s, char** end) {
> > +  UINT64 x;
> > +
> > +  if (s[0] == '0' && s[1] == 'x')
> > +AsciiStrHexToUint64S(s, end, );
> > +  else
> > +AsciiStrDecimalToUint64S(s, end, );
> > +
> > +  return x;
> > +}
> > +
> > +static int isspace(const char c) { return c == ' ' || c == '\t' || c ==
> '\n'; }
> >
> >   // Retrieve UefiPayloadConfig from Linuxboot's uefiboot
> > -UefiPayloadConfig* GetUefiPayLoadConfig() {
> > -  UefiPayloadConfig* config =
> > +const UefiPayloadConfig* GetUefiPayLoadConfig() {
> > +  const UefiPayloadConfig* config =
> > (UefiPayloadConfig*)(UINTN)(PcdGet32(PcdPayloadFdMemBase) -
> SIZE_64KB);
> > -  if (config->Version != UEFI_PAYLOAD_CONFIG_VERSION) {
> > -DEBUG((DEBUG_ERROR, "Expect payload config version: %d, but get
> %d\n",
> > -   UEFI_PAYLOAD_CONFIG_VERSION, config->Version));
> > -CpuDeadLoop ();
> > -  }
> > -  return config;
> > +
> > +  if (config->Version == UEFI_PAYLOAD_CONFIG_VERSION1 ||
> > +  config->Version == UEFI_PAYLOAD_CONFIG_VERSION2)
> > +return config;
> > +
> > +  DEBUG((DEBUG_ERROR,
> > + "Expect payload config version %016lx or %016lx, but get
> %016lx\n",
> > + UEFI_PAYLOAD_CONFIG_VERSION1, UEFI_PAYLOAD_CONFIG_VERSION2,
> > + config->Version));
> > +  CpuDeadLoop();
> > +  while (1)
> > +;
> >   }
> >
> >   // Align the address and add memory rang to MemInfoCallback
> > @@ -54,6 

[edk2-devel] Cancelled Event: TianoCore Design Meeting - APAC/NAMO - Friday, July 23, 2021 #cal-cancelled

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCELLED
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Shanghai
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Shanghai
X-LIC-LOCATION:Asia/Shanghai
BEGIN:STANDARD
TZNAME:CST
TZOFFSETFROM:+0800
TZOFFSETTO:+0800
DTSTART:19700101T00
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1138145 
UID:ccyo.1615368347866508187.a...@groups.io
DTSTAMP:20210722T122207Z
ORGANIZER;CN=Ray Ni:mailto:ray...@intel.com
DTSTART:20210723T013000Z
DTEND:20210723T023000Z
SUMMARY:TianoCore Design Meeting - APAC/NAMO
DESCRIPTION:## TOPIC\n\n1. NA\n\nFor more info\, see here: https://www.ti
 anocore.org/design-meeting/\n\n---\n## Microsoft Teams meeting\n\n### Joi
 n on your computer or mobile app\n\n[Click here to join the meeting](http
 s://teams.microsoft.com/l/meetup-join/19%3ameeting_OTNmZTNhMWEtOWQwNi00ZT
 dkLWI5NDgtYTFmYjNkOWI0ZDg4%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d
 88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%2255d36a50-78be-4ced-bc2
 7-3d06c576cc19%22%7d)\n\n### Join with a video conferencing device\n\ntea
 m...@conf.intel.com\n\nVideo Conference ID: 119 715 416 0\n\n[Alternate VTC
  dialing instructions](https://conf.intel.com/teams/?conf=1197154160=
 teams=conf.intel.com=test_call)\n\n[Learn More](https://aka.ms/Joi
 nTeamsMeeting) | [Meeting options](https://teams.microsoft.com/meetingOpt
 ions/?organizerId=55d36a50-78be-4ced-bc27-3d06c576cc19=46c98d88-
 e344-4ed4-8496-4ed7712e255d=19_meeting_OTNmZTNhMWEtOWQwNi00ZTdkL
 WI5NDgtYTFmYjNkOWI0ZDg4@thread.v2=0=en-US)
LOCATION:Microsoft Teams
SEQUENCE:999
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

[edk2-devel] [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0

[Digant H Solanki]

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

- There are many OpRegion fields obsoleted in MBOX1
- MBOX2 is re-purposed for Backlight related fields for dual LFP.
- Backlight related fields moved to MBOX2 from MBOX3
and some fields are obsoleted in MBOX3.

Signed-off-by: Digant H Solanki 
Cc: Ray Ni 
Cc: Rangasai V Chaganty 
Cc: Ashraf Ali S 
---
 Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h | 101 
+
 1 file changed, 101 insertions(+)

diff --git 
a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h 
b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
new file mode 100644
index 00..c9948ab55f
--- /dev/null
+++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h
@@ -0,0 +1,101 @@
+/** @file
+  IGD OpRegion definition from Intel Integrated Graphics Device OpRegion
+  Specification based on version 3.0.
+
+  Copyright (c) 2021, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+#ifndef _IGD_OPREGION_3_0_H_
+#define _IGD_OPREGION_3_0_H_
+
+#include "IgdOpRegion.h"
+
+#define IGD_OPREGION_HEADER_MBOX2_VER_3_0 BIT5
+
+#pragma pack(1)
+///
+/// OpRegion Mailbox 1 - Public ACPI Methods
+/// Offset 0x100, Size 0x100
+///
+typedef struct {
+  UINT32 DRDY;  ///< Offset 0x100 Driver Readiness
+  UINT32 CSTS;  ///< Offset 0x104 Status
+  UINT32 CEVT;  ///< Offset 0x108 Current Event
+  UINT8  RM11[0x14];///< Offset 0x10C Reserved Must be Zero
+  UINT32 DIDL[8];   ///< Offset 0x120 Supported Display Devices ID List
+  UINT32 CPDL[8];   ///< Offset 0x140 obsolete
+  UINT32 CADL[8];   ///< Offset 0x160 obsolete
+  UINT32 NADL[8];   ///< Offset 0x180 obsolete
+  UINT32 ASLP;  ///< Offset 0x1A0 ASL Sleep Time Out
+  UINT32 TIDX;  ///< Offset 0x1A4 obsolete
+  UINT32 CHPD;  ///< Offset 0x1A8 obsolete
+  UINT32 CLID;  ///< Offset 0x1AC Current Lid State Indicator
+  UINT32 CDCK;  ///< Offset 0x1B0 Current Docking State Indicator
+  UINT32 SXSW;  ///< Offset 0x1B4 obsolete
+  UINT32 EVTS;  ///< Offset 0x1B8 obsolete
+  UINT32 CNOT;  ///< Offset 0x1BC obsolete
+  UINT32 NRDY;  ///< Offset 0x1C0 Driver Status
+  UINT8  DID2[0x1C];///< Offset 0x1C4 Extended Supported Devices ID List 
(DOD)
+  UINT8  CPD2[0x1C];///< Offset 0x1E0 obsolete
+  UINT8  RM12[4];   ///< Offset 0x1FC - 0x1FF Reserved Must be zero
+} IGD_OPREGION_MBOX1_VER_3_0;
+
+///
+/// OpRegion Mailbox 2 - Backlight communication
+/// Offset 0x200, Size 0x100
+///
+typedef struct {
+  UINT32 BCL1;  ///< Offset 0x200 Backlight Brightness for LFP1
+  UINT32 BCL2;  ///< Offset 0x204 Backlight Brightness for LFP2
+  UINT32 CBL1;  ///< Offset 0x208 Current User Brightness Level for 
LFP1
+  UINT32 CBL2;  ///< Offset 0x20C Current User Brightness Level for 
LFP2
+  UINT32 BCM1[0x1E];///< Offset 0x210 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP1
+  UINT32 BCM2[0x1E];///< Offset 0x288 Backlight Brightness Levels Duty 
Cycle Mapping Table for LFP2
+} IGD_OPREGION_MBOX2_VER_3_0;
+
+///
+/// OpRegion Mailbox 3 - BIOS/Driver Notification - ASLE Support
+/// Offset 0x300, Size 0x100
+///
+typedef struct {
+  UINT32 ARDY;  ///< Offset 0x300 obsolete
+  UINT32 ASLC;  ///< Offset 0x304 obsolete
+  UINT32 TCHE;  ///< Offset 0x308 obsolete
+  UINT32 ALSI;  ///< Offset 0x30C obsolete
+  UINT32 BCLP;  ///< Offset 0x310 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 PFIT;  ///< Offset 0x314 obsolete
+  UINT32 CBLV;  ///< Offset 0x318 obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT16 BCLM[0x14];///< Offset 0x31C obsoleted in ver 3.0, moved to 
Mailbox 2.
+  UINT32 CPFM;  ///< Offset 0x344 obsolete
+  UINT32 EPFM;  ///< Offset 0x348 obsolete
+  UINT8  PLUT[0x4A];///< Offset 0x34C obsolete
+  UINT32 PFMB;  ///< Offset 0x396 obsolete
+  UINT32 CCDV;  ///< Offset 0x39A obsolete
+  UINT32 PCFT;  ///< Offset 0x39E obsolete
+  UINT32 SROT;  ///< Offset 0x3A2 obsolete
+  UINT32 IUER;  ///< Offset 0x3A6 obsolete
+  UINT64 FDSS;  ///< Offset 0x3AA obsolete
+  UINT32 FDSP;  ///< Offset 0x3B2 obsolete
+  UINT32 STAT;  ///< Offset 0x3B6 obsolete
+  UINT64 RVDA;  ///< Offset 0x3BA Physical address of Raw VBT data. 
Added from Spec Version 0.90 to support VBT greater than 6KB.
+  UINT32 RVDS;  ///< Offset 0x3C2 Size of Raw VBT data. Added from 
Spec Version 0.90 to support VBT greater than 6KB.
+  UINT8  VRSR;  ///< Offset 0x3C6 Video RAM Self Refresh
+  UINT64 DLHP;  ///< Offset 0x3C7 Dual LFP Hinge Alignment Parameters
+  UINT8  RM32[0x31];///< Offset 0x3CF - 0x3FF  Reserved Must be 

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platform/RaspberryPi/RPi4: Fix non-standard ACPI HIDs

[Ard Biesheuvel]

On Wed, 21 Jul 2021 at 22:39, Andrei Warkentin  wrote:
>
> Reviewed-by: Andrei Warkentin 

Pushed as d549e39ca1a9..194269223294

Thanks all,

> 
> From: Ard Biesheuvel 
> Sent: Tuesday, July 20, 2021 10:37 AM
> To: Samer El-Haj-Mahmoud 
> Cc: edk2-devel-groups-io ; Leif Lindholm 
> ; Ard Biesheuvel ; Pete Batard 
> ; Andrei Warkentin ; Mario Bălănică 
> 
> Subject: Re: [edk2-platform][PATCH v1 1/1] Platform/RaspberryPi/RPi4: Fix 
> non-standard ACPI HIDs
>
> On Mon, 19 Jul 2021 at 22:45, Samer El-Haj-Mahmoud
>  wrote:
> >
> > Remove non-standard RPI ACPI _CIDs that are not needed.
> > This also fixes the FWTS failure reported in
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpftf%2FRPi4%2Fissues%2F67data=04%7C01%7Cawarkentin%40vmware.com%7Cbfd9e47da54c40ef9c5408d94b51486a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637623634750321947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=YO4V6pksRlNqfPlMwO0VPKNVcp4npeP%2BN%2BpigTFfZnM%3Dreserved=0
> >
> > The windows drivers at 
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fraspberrypi%2Fwindows-driversdata=04%7C01%7Cawarkentin%40vmware.com%7Cbfd9e47da54c40ef9c5408d94b51486a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637623634750321947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=PMkBX%2F6vHaAoUC5tkCA7aAldaYEKFgh9w3yFYsgNrPQ%3Dreserved=0
> > are still able to match the ACPI objects using the HIDs which
> > are supported in the drivers, with these two recent changes needed:
> > 469702898789e555c6947e50216a3f79e0ddeb9
> > and
> > 5c5e2742b4c983b3001c473b168b0dae2fcba0c2
> >
> > Cc: Leif Lindholm 
> > Cc: Ard Biesheuvel 
> > Cc: Pete Batard 
> > Cc: Andrei Warkentin 
> > Cc: Mario Bălănică 
> > Signed-off-by: Samer El-Haj-Mahmoud 
> > Tested-by: Mario Bălănică 
>
> Glad to see this getting cleaned up.
>
> Anyone care to ack?
>
>
> > ---
> >  Platform/RaspberryPi/AcpiTables/GpuDevs.asl | 26 +++-
> >  Platform/RaspberryPi/AcpiTables/Sdhc.asl|  4 +--
> >  Platform/RaspberryPi/AcpiTables/Uart.asl|  2 +-
> >  3 files changed, 18 insertions(+), 14 deletions(-)
> >
> > diff --git a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl 
> > b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
> > index 966a94cdb5b5..9750dc25c07c 100644
> > --- a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
> > +++ b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
> > @@ -13,7 +13,11 @@
> >  Device (USB0)
> >  {
> >Name (_HID, "BCM2848")
> > -  Name (_CID, Package() { "DWC_OTG", "DWC2_OTG" })
> > +#if (RPI_MODEL == 3)
> > +  Name (_CID, "DWC_OTG")
> > +#elif (RPI_MODEL == 4)
> > +  Name (_CID, "BCM2848")
> > +#endif
> >Name (_UID, 0x0)
> >Name (_CCA, 0x0)
> >Method (_STA)
> > @@ -36,7 +40,7 @@ Device (USB0)
> >  Device (GPU0)
> >  {
> >Name (_HID, "BCM2850")
> > -  Name (_CID, "VC4")
> > +  Name (_CID, "BCM2850")
> >Name (_UID, 0x0)
> >Name (_CCA, 0x0)
> >Method (_STA)
> > @@ -140,7 +144,7 @@ Device (GPU0)
> >  Device (RPIQ)
> >  {
> >Name (_HID, "BCM2849")
> > -  Name (_CID, "RPIQ")
> > +  Name (_CID, "BCM2849")
> >Name (_UID, 0)
> >Name (_CCA, 0x0)
> >Method (_STA)
> > @@ -164,7 +168,7 @@ Device (RPIQ)
> >  Device (VCIQ)
> >  {
> >Name (_HID, "BCM2835")
> > -  Name (_CID, "VCIQ")
> > +  Name (_CID, "BCM2835")
> >Name (_UID, 0)
> >Name (_CCA, 0x0)
> >Name (_DEP, Package() { \_SB.GDV0.RPIQ })
> > @@ -189,7 +193,7 @@ Device (VCIQ)
> >  Device (VCSM)
> >  {
> >Name (_HID, "BCM2856")
> > -  Name (_CID, "VCSM")
> > +  Name (_CID, "BCM2856")
> >Name (_UID, 0)
> >Name (_CCA, 0x0)
> >Name (_DEP, Package() { \_SB.GDV0.VCIQ })
> > @@ -203,7 +207,7 @@ Device (VCSM)
> >  Device (GPI0)
> >  {
> >Name (_HID, "BCM2845")
> > -  Name (_CID, "BCMGPIO")
> > +  Name (_CID, "BCM2845")
> >Name (_UID, 0x0)
> >Name (_CCA, 0x0)
> >Method (_STA)
> > @@ -230,7 +234,7 @@ Device (GPI0)
> >  Device (I2C1)
> >  {
> >Name (_HID, "BCM2841")
> > -  Name (_CID, "BCMI2C")
> > +  Name (_CID, "BCM2841")
> >Name (_UID, 0x1)
> >Name (_CCA, 0x0)
> >Method (_STA)
> > @@ -254,7 +258,7 @@ Device (I2C1)
> >  Device (I2C2)
> >  {
> >Name (_HID, "BCM2841")
> > -  Name (_CID, "BCMI2C")
> > +  Name (_CID, "BCM2841")
> >Name (_UID, 0x2)
> >Name (_CCA, 0x0)
> >Method (_STA)
> > @@ -278,7 +282,7 @@ Device (I2C2)
> >  Device (SPI0)
> >  {
> >Name (_HID, "BCM2838")
> > -  Name (_CID, "BCMSPI0")
> > +  Name (_CID, "BCM2838")
> >Name (_UID, 0x0)
> >Name (_CCA, 0x0)
> >Method (_STA)
> > @@ -304,7 +308,7 @@ Device (SPI0)
> >  Device (SPI1)
> >  {
> >Name (_HID, "BCM2839")
> > -  Name (_CID, "BCMAUXSPI")
> > +  Name (_CID, "BCM2839")
> >Name (_UID, 0x1)
> >Name (_CCA, 0x0)
> >Name (_DEP, Package() { \_SB.GDV0.RPIQ })
> > @@ -331,7 +335,7 @@ Device (SPI1)
> >  // Device 

Re: [edk2-devel] RFC: EXT4 filesystem driver

[Marvin Häuser]

On 22.07.21 01:12, Pedro Falcato wrote:

EXT4 (fourth extended filesystem) is a filesystem developed for Linux
that has been in wide use (desktops, servers, smartphones) since 2008.

The Ext4Pkg implements the Simple File System Protocol for a partition
that is formatted with the EXT4 file system. This allows UEFI Drivers,
UEFI Applications, UEFI OS Loaders, and the UEFI Shell to access files
on an EXT4 partition and supports booting a UEFI OS Loader from an
EXT4 partition.
This project is one of the TianoCore Google Summer of Code projects.

Right now, Ext4Pkg only contains a single member, Ext4Dxe, which is a
UEFI driver that consumes Block I/O, Disk I/O and (optionally) Disk
I/O 2 Protocols, and produces the Simple File System protocol. It
allows mounting ext4 filesystems exclusively.

Brief overhead of EXT4:
Layout of an EXT2/3/4 filesystem:
(note: this driver has been developed using
https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html as
documentation).

An ext2/3/4 filesystem (here on out referred to as simply an ext4 filesystem,
due to the similarities) is composed of various concepts:

1) Superblock
The superblock is the structure near (1024 bytes offset from the start)
the start of the partition, and describes the filesystem in general.
Here, we get to know the size of the filesystem's blocks, which features
it supports or not, whether it's been cleanly unmounted, how many blocks
we have, etc.

2) Block groups
EXT4 filesystems are divided into block groups, and each block group covers
s_blocks_per_group(8 * Block Size) blocks. Each block group has an
associated block group descriptor; these are present directly after the
superblock. Each block group descriptor contains the location of the
inode table, and the inode and block bitmaps (note these bitmaps are only
a block long, which gets us the 8 * Block Size formula covered previously).

3) Blocks
The ext4 filesystem is divided into blocks, of size s_log_block_size ^ 1024.
Blocks can be allocated using individual block groups's bitmaps. Note
that block 0 is invalid and its presence on extents/block tables means
it's part of a file hole, and that particular location must be read as
a block full of zeros.

4) Inodes
The ext4 filesystem divides files/directories into inodes (originally
index nodes). Each file/socket/symlink/directory/etc (here on out referred
to as a file, since there is no distinction under the ext4 filesystem) is
stored as a /nameless/ inode, that is stored in some block group's inode
table. Each inode has s_inode_size size (or GOOD_OLD_INODE_SIZE if it's
an old filesystem), and holds various metadata about the file. Since the
largest inode structure right now is ~160 bytes, the rest of the inode
contains inline extended attributes. Inodes' data is stored using either
data blocks (under ext2/3) or extents (under ext4).

5) Extents
Ext4 inodes store data in extents. These let N contiguous logical blocks
that are represented by N contiguous physical blocks be represented by a
single extent structure, which minimizes filesystem metadata bloat and
speeds up block mapping (particularly due to the fact that high-quality
ext4 implementations like linux's try /really/ hard to make the file
contiguous, so it's common to have files with almost 0 fragmentation).
Inodes that use extents store them in a tree, and the top of the tree
is stored on i_data. The tree's leaves always start with an
EXT4_EXTENT_HEADER and contain EXT4_EXTENT_INDEX on eh_depth != 0 and
EXT4_EXTENT on eh_depth = 0; these entries are always sorted by logical
block.

6) Directories
Ext4 directories are files that store name -> inode mappings for the
logical directory; this is where files get their names, which means ext4
inodes do not themselves have names, since they can be linked (present)
multiple times with different names. Directories can store entries in two
different ways:
1) Classical linear directories: They store entries as a mostly-linked
mostly-list of EXT4_DIR_ENTRY.
2) Hash tree directories: These are used for larger directories, with
hundreds of entries, and are designed in a backwards-compatible way.
These are not yet implemented in the Ext4Dxe driver.

7) Journal
Ext3/4 filesystems have a journal to help protect the filesystem against
system crashes. This is not yet implemented in Ext4Dxe but is described
in detail in the Linux kernel's documentation.

The EDK2 implementation of ext4 is based only on the public documentation
available at https://www.kernel.org/doc/html/latest/filesystems/ext4/index.html
and
the FreeBSD ext2fs driver (available at
https://github.com/freebsd/freebsd-src/tree/main/sys/fs/ext2fs,
BSD-2-Clause-FreeBSD licensed). It is licensed as
SPDX-License-Identifier: BSD-2-Clause-Patent.

After a brief discussion with the community, the proposed package
location is edk2-platform/Features/Ext4Pkg
(relevant discussion: https://edk2.groups.io/g/devel/topic/83060185).

I was the main contributor and I would like to maintain the 

Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

[Ard Biesheuvel]

On Wed, 21 Jul 2021 at 20:04, Kinney, Michael D 
wrote:

> Hi Jeff,
>
>
>
> I see.  I missed the file rename line in the git patch.
>
>
>
> I think the description needs to be expanded to clearly describe the
> production and consumption of this device path with this GUID.
>
>
>
>1. What component creates the UEFI handle with the Device Path
>Protocol and the LoadFile2 Protocol with the initrd image?  Is it the
>platform FW or the OS Loader?  If it is the platform FW, then how does
>the platform FW know which initrd image to publish if there are
>multiple Linux OSes installed?
>
>
This is really the firmware/loader's problem. In the ARM / RISC-V world,
the distinction between firmware and pre-OS loader is not as clear cut, and
for instance, U-boot in EFI mode can either boot the kernel directly (and
expose the initrd via this method), or invoke GRUB as an EFI app using
LoadImage/StartImage, in which case GRUB can load the kernel and/or initrd
via whichever interface it desires.

It is therefore also the platform FW's problem to decide which initrd goes
with which kernel - it is highly platform dependent whether a certain
initrd is compatible with only a single kernel, or can be combined with any
kernel (e.g., when the kernel has all drivers builtin, and the initrd only
contains the user space)


>
>1.
>2. What component locates the UEFI handle with the Device Path
>Protocol and the LoadFile2 Protocol with the initrd image?  It is
>another stage of the OS Loader or the OS Kernel?  Given that these
>handles are only available before ExitBootServices, I think this means
>that the component that locates the initrd image has to do so before
>ExitBootServices is called.
>
>
>

The consumer of the protocol is the EFI stub loader in Linux, i.e., the OS
loader that is built into the OS kernel. It is the agent that calls
ExitBootServices(), and it indeed consumes the protocol beforehand.

In summary, I think it should be sufficient to describe the consumer's
expectations with respect to the API. I don't think it makes sense to be
normative about how platform firmware or intermediate loaders keep track of
which file to expose, as long as it complies with the consumer's
requirements.



> *To:* Kinney, Michael D ; Ard Biesheuvel <
> a...@kernel.org>
> *Cc:* devel@edk2.groups.io; ardb+tianoc...@kernel.org; Justen, Jordan L <
> jordan.l.jus...@intel.com>; gaolim...@byosoft.com.cn; Liu, Zhiguang <
> zhiguang@intel.com>; Samer El-Haj-Mahmoud <
> samer.el-haj-mahm...@arm.com>
> *Subject:* Re: [edk2-devel] [PATCH 1/1] MdePkg: add definition of
> LINUX_EFI_INITRD_MEDIA_GUID
>
>
>
> Does this look good for text to add
>
>
>
> "Linux distro boot generally relies on an initial ramdisk (initrd)
> which is provided by the loader, and which contains additional kernel
> modules (for storage and network, for instance), and the initial user
> space startup code, i.e., the code which brings up the user space side
> of the entire OS.
>
> In order to provide a standard method to locate this file,
>
> the GUID defined in this file is used to describe the device path
>
> for a LoadFile2 Protocol instance that is responsible for loading the
> initrd file"
>
>
>
>
>
> Also, the patch does have
>
>  {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h | 0
>  3 files changed, 5 insertions(+), 1 deletion(-)
>  rename {OvmfPkg => MdePkg}/Include/Guid/LinuxEfiInitrdMedia.h (100%)
> [snip]
> diff --git a/OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
> b/MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
> similarity index 100%
> rename from OvmfPkg/Include/Guid/LinuxEfiInitrdMedia.h
> rename to MdePkg/Include/Guid/LinuxEfiInitrdMedia.h
>
>
>
>
>
> Thanks,
>
> Jeff
> --
>
> *From:* Kinney, Michael D 
> *Sent:* Wednesday, July 21, 2021 9:38 AM
> *To:* Jeff Brasen ; Ard Biesheuvel ;
> Kinney, Michael D 
> *Cc:* devel@edk2.groups.io ;
> ardb+tianoc...@kernel.org ; Justen, Jordan L <
> jordan.l.jus...@intel.com>; gaolim...@byosoft.com.cn <
> gaolim...@byosoft.com.cn>; Liu, Zhiguang ; Samer
> El-Haj-Mahmoud 
> *Subject:* RE: [edk2-devel] [PATCH 1/1] MdePkg: add definition of
> LINUX_EFI_INITRD_MEDIA_GUID
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> Hi Ard,
>
>
>
> If this device path node is considered as part of the standard interface
> between the Linux kernel and
>
> firmware, then it does make sense for it to be in the MdePkg.  We usually
> try to reference a public
>
> specification in the include file that defines the interface.
>
>
>
> In this case, since there is no public document, but it is part of the
> Linux kernel assumptions,
>
> can the include file for the GUID provide pointers to the Linux kernel
> that uses the GUID and
>
> describe how the GUID is produced by the FW and consumed by the Linux
> kernel?
>
>
>
> I also see that this patch appears to be incomplete.  There is an OvmfPkg
> /Include/Guid/LinuxEfiInitrdMedia.h
>
> file in the 

Re: [edk2-devel] [PATCH v4 10/11] OvmfPkg: add BlobVerifierLibSevHashes

[Dov Murik]

Here's the diff from the v3 of this patch. It's supposed to catch
more cases of bad length fields overflowing the reserved MEMFD space or
the declared length of the table.



diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
index 797d63d18067..372ae6f469e7 100644
--- a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
@@ -94,7 +94,7 @@ VerifyBlob (
   )
 {
   CONST GUID *Guid;
-  INT32 Len;
+  INT32 Remaining;
   HASH_TABLE *Entry;

   if (mHashesTable == NULL || mHashesTableSize == 0) {
@@ -111,9 +111,13 @@ VerifyBlob (
 return EFI_ACCESS_DENIED;
   }

-  for (Entry = mHashesTable, Len = 0;
-   Len < (INT32)mHashesTableSize;
-   Len += Entry->Len,
+  //
+  // Remaining is INT32 to catch underflow in case Entry->Len has a
+  // very high UINT16 value
+  //
+  for (Entry = mHashesTable, Remaining = mHashesTableSize;
+   Remaining >= sizeof *Entry && Remaining >= Entry->Len;
+   Remaining -= Entry->Len,
Entry = (HASH_TABLE *)((UINT8 *)Entry + Entry->Len)) {
 UINTN EntrySize;
 EFI_STATUS Status;
@@ -125,7 +129,7 @@ VerifyBlob (

 DEBUG ((DEBUG_INFO, "%a: Found GUID %g in table\n", __FUNCTION__,
Guid));

-EntrySize = Entry->Len - sizeof (Entry->Guid) - sizeof (Entry->Len);
+EntrySize = Entry->Len - sizeof Entry->Guid - sizeof Entry->Len;
 if (EntrySize != SHA256_DIGEST_SIZE) {
   DEBUG ((DEBUG_ERROR, "%a: Hash has the wrong size %d != %d\n",
 __FUNCTION__, EntrySize, SHA256_DIGEST_SIZE));
@@ -161,7 +165,8 @@ VerifyBlob (
   This function always returns success, even if the table can't be
found.  The
   subsequent VerifyBlob calls will fail if no table was found.

-  @retval RETURN_SUCCESS   The verifier tables were set up correctly
+  @retval RETURN_SUCCESS   The hashes table is set up correctly, or
there is no
+   hashes table
 **/
 RETURN_STATUS
 EFIAPI
@@ -175,15 +180,9 @@ BlobVerifierLibSevHashesConstructor (
   mHashesTable = NULL;
   mHashesTableSize = 0;

-  if (Ptr == NULL || Size == 0) {
-return RETURN_SUCCESS;
-  }
-
-  if (!CompareGuid (>Guid, _HASH_TABLE_GUID)) {
-return RETURN_SUCCESS;
-  }
-
-  if (Ptr->Len < (sizeof Ptr->Guid + sizeof Ptr->Len)) {
+  if (Ptr == NULL || Size < sizeof *Ptr ||
+  !CompareGuid (>Guid, _HASH_TABLE_GUID) ||
+  Ptr->Len < sizeof *Ptr || Ptr->Len > Size) {
 return RETURN_SUCCESS;
   }





On 22/07/2021 11:43, Dov Murik wrote:
> Add an implementation for BlobVerifierLib that locates the SEV hashes
> table and verifies that the calculated hashes of the kernel, initrd, and
> cmdline blobs indeed match the expected hashes stated in the hashes
> table.
> 
> If there's a missing hash or a hash mismatch then EFI_ACCESS_DENIED is
> returned which will cause a failure to load a kernel image.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Ashish Kalra 
> Cc: Brijesh Singh 
> Cc: Erdem Aktas 
> Cc: James Bottomley 
> Cc: Jiewen Yao 
> Cc: Min Xu 
> Cc: Tom Lendacky 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
> Co-developed-by: James Bottomley 
> Signed-off-by: James Bottomley 
> Signed-off-by: Dov Murik 
> ---
>  OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf |  37 
>  OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c  | 199 
> 
>  2 files changed, 236 insertions(+)
> 
> diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf 
> b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
> new file mode 100644
> index ..76ca0b8154ce
> --- /dev/null
> +++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
> @@ -0,0 +1,37 @@
> +## @file
> 
> +#
> 
> +#  Blob verifier library that uses SEV hashes table.  The hashes table holds 
> the
> 
> +#  allowed hashes of the kernel, initrd, and cmdline blobs.
> 
> +#
> 
> +#  Copyright (C) 2021, IBM Corp
> 
> +#
> 
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +#
> 
> +##
> 
> +
> 
> +[Defines]
> 
> +  INF_VERSION= 1.29
> 
> +  BASE_NAME  = BlobVerifierLibSevHashes
> 
> +  FILE_GUID  = 59e713b5-eff3-46a7-8d8b-46f4c004ad7b
> 
> +  MODULE_TYPE= BASE
> 
> +  VERSION_STRING = 1.0
> 
> +  LIBRARY_CLASS  = BlobVerifierLib
> 
> +  CONSTRUCTOR= BlobVerifierLibSevHashesConstructor
> 
> +
> 
> +[Sources]
> 
> +  BlobVerifierSevHashes.c
> 
> +
> 
> +[Packages]
> 
> +  CryptoPkg/CryptoPkg.dec
> 
> +  MdePkg/MdePkg.dec
> 
> +  OvmfPkg/OvmfPkg.dec
> 
> +
> 
> +[LibraryClasses]
> 
> +  BaseCryptLib
> 
> +  BaseMemoryLib
> 
> +  DebugLib
> 
> +  PcdLib
> 
> +
> 
> +[FixedPcd]
> 
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
> 
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
> 
> diff --git 

[edk2-devel] [PATCH v4 02/11] OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev builds

[Dov Murik]

Newer kernels support efistub and therefore don't need all the legacy
stuff in X86QemuLoadImageLib, which are harder to secure.  Specifically
the verification of kernel/initrd/cmdline blobs will be added only to
the GenericQemuLoadImageLib implementation, so use that for SEV builds.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: Dov Murik 
Reviewed-by: Brijesh Singh 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index 1d487befae08..a2f1324c40a6 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -368,7 +368,7 @@ [LibraryClasses.common.DXE_DRIVER]
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
-  QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
+  
QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
 !if $(TPM_ENABLE) == TRUE
   Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.inf
   Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
-- 
2.25.1



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

[edk2-devel] [PATCH v4 10/11] OvmfPkg: add BlobVerifierLibSevHashes

[Dov Murik]

Add an implementation for BlobVerifierLib that locates the SEV hashes
table and verifies that the calculated hashes of the kernel, initrd, and
cmdline blobs indeed match the expected hashes stated in the hashes
table.

If there's a missing hash or a hash mismatch then EFI_ACCESS_DENIED is
returned which will cause a failure to load a kernel image.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Co-developed-by: James Bottomley 
Signed-off-by: James Bottomley 
Signed-off-by: Dov Murik 
---
 OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf |  37 
 OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c  | 199 

 2 files changed, 236 insertions(+)

diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf 
b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
new file mode 100644
index ..76ca0b8154ce
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
@@ -0,0 +1,37 @@
+## @file
+#
+#  Blob verifier library that uses SEV hashes table.  The hashes table holds 
the
+#  allowed hashes of the kernel, initrd, and cmdline blobs.
+#
+#  Copyright (C) 2021, IBM Corp
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 1.29
+  BASE_NAME  = BlobVerifierLibSevHashes
+  FILE_GUID  = 59e713b5-eff3-46a7-8d8b-46f4c004ad7b
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = BlobVerifierLib
+  CONSTRUCTOR= BlobVerifierLibSevHashesConstructor
+
+[Sources]
+  BlobVerifierSevHashes.c
+
+[Packages]
+  CryptoPkg/CryptoPkg.dec
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  BaseCryptLib
+  BaseMemoryLib
+  DebugLib
+  PcdLib
+
+[FixedPcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c 
b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
new file mode 100644
index ..372ae6f469e7
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierSevHashes.c
@@ -0,0 +1,199 @@
+/** @file
+
+  Blob verifier library that uses SEV hashes table.  The hashes table holds the
+  allowed hashes of the kernel, initrd, and cmdline blobs.
+
+  Copyright (C) 2021, IBM Corporation
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+  The SEV Hashes table must be in encrypted memory and has the table
+  and its entries described by
+
+  |UINT16 |
+
+  With the whole table GUID being 9438d606-4f22-4cc9-b479-a793d411fd21
+
+  The current possible table entries are for the kernel, the initrd
+  and the cmdline:
+
+  4de79437-abd2-427f-b835-d5b172d2045b  kernel
+  44baf731-3a2f-4bd7-9af1-41e29169781d  initrd
+  97d02dd8-bd20-4c94-aa78-e7714d36ab2a  cmdline
+
+  The size of the entry is used to identify the hash, but the
+  expectation is that it will be 32 bytes of SHA-256.
+**/
+
+#define SEV_HASH_TABLE_GUID \
+  (GUID) { 0x9438d606, 0x4f22, 0x4cc9, { 0xb4, 0x79, 0xa7, 0x93, 0xd4, 0x11, 
0xfd, 0x21 } }
+#define SEV_KERNEL_HASH_GUID \
+  (GUID) { 0x4de79437, 0xabd2, 0x427f, { 0xb8, 0x35, 0xd5, 0xb1, 0x72, 0xd2, 
0x04, 0x5b } }
+#define SEV_INITRD_HASH_GUID \
+  (GUID) { 0x44baf731, 0x3a2f, 0x4bd7, { 0x9a, 0xf1, 0x41, 0xe2, 0x91, 0x69, 
0x78, 0x1d } }
+#define SEV_CMDLINE_HASH_GUID \
+  (GUID) { 0x97d02dd8, 0xbd20, 0x4c94, { 0xaa, 0x78, 0xe7, 0x71, 0x4d, 0x36, 
0xab, 0x2a } }
+
+STATIC CONST EFI_GUID mSevKernelHashGuid = SEV_KERNEL_HASH_GUID;
+STATIC CONST EFI_GUID mSevInitrdHashGuid = SEV_INITRD_HASH_GUID;
+STATIC CONST EFI_GUID mSevCmdlineHashGuid = SEV_CMDLINE_HASH_GUID;
+
+#pragma pack (1)
+typedef struct {
+  GUID   Guid;
+  UINT16 Len;
+  UINT8  Data[];
+} HASH_TABLE;
+#pragma pack ()
+
+STATIC HASH_TABLE *mHashesTable;
+STATIC UINT16 mHashesTableSize;
+
+STATIC
+CONST GUID*
+FindBlobEntryGuid (
+  IN  CONST CHAR16*BlobName
+  )
+{
+  if (StrCmp (BlobName, L"kernel") == 0) {
+return 
+  } else if (StrCmp (BlobName, L"initrd") == 0) {
+return 
+  } else if (StrCmp (BlobName, L"cmdline") == 0) {
+return 
+  } else {
+return NULL;
+  }
+}
+
+/**
+  Verify blob from an external source.
+
+  @param[in] BlobName   The name of the blob
+  @param[in] BufThe data of the blob
+  @param[in] BufSizeThe size of the blob in bytes
+
+  @retval EFI_SUCCESS   The blob was verified successfully.
+  @retval EFI_ACCESS_DENIED The blob could not be verified, and therefore
+should be considered non-secure.
+**/
+EFI_STATUS
+EFIAPI
+VerifyBlob (
+  IN  CONST CHAR16*BlobName,
+  IN  CONST VOID  

[edk2-devel] [PATCH v4 04/11] OvmfPkg: add library class BlobVerifierLib with null implementation

[Dov Murik]

BlobVerifierLib will be used to verify blobs fetching them from QEMU's
firmware config (fw_cfg) in platforms that enable such verification.

The null implementation BlobVerifierLibNull treats all blobs as valid.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: Dov Murik 
Reviewed-by: Tom Lendacky 
---
 OvmfPkg/OvmfPkg.dec |  3 ++
 OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf | 24 +
 OvmfPkg/Include/Library/BlobVerifierLib.h   | 38 

 OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c  | 33 +
 4 files changed, 98 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 6ae733f6e39f..f82228d69cc2 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -23,6 +23,9 @@ [LibraryClasses]
   ##  @libraryclass  Access bhyve's firmware control interface.
   BhyveFwCtlLib|Include/Library/BhyveFwCtlLib.h
 
+  ##  @libraryclass  Verify blobs read from the VMM
+  BlobVerifierLib|Include/Library/BlobVerifierLib.h
+
   ##  @libraryclass  Loads and boots a Linux kernel image
   #
   LoadLinuxLib|Include/Library/LoadLinuxLib.h
diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf 
b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
new file mode 100644
index ..850d398e65a4
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
@@ -0,0 +1,24 @@
+## @file
+#
+#  Null implementation of the blob verifier library.
+#
+#  Copyright (C) 2021, IBM Corp
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 1.29
+  BASE_NAME  = BlobVerifierLibNull
+  FILE_GUID  = b1b5533e-e01a-43bb-9e54-414f00ca036e
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = BlobVerifierLib
+
+[Sources]
+  BlobVerifierNull.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
diff --git a/OvmfPkg/Include/Library/BlobVerifierLib.h 
b/OvmfPkg/Include/Library/BlobVerifierLib.h
new file mode 100644
index ..db122684f76c
--- /dev/null
+++ b/OvmfPkg/Include/Library/BlobVerifierLib.h
@@ -0,0 +1,38 @@
+/** @file
+
+  Blob verification library
+
+  This library class allows verifiying whether blobs from external sources
+  (such as QEMU's firmware config) are trusted.
+
+  Copyright (C) 2021, IBM Corporation
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef BLOB_VERIFIER_LIB_H__
+#define BLOB_VERIFIER_LIB_H__
+
+#include 
+#include 
+
+/**
+  Verify blob from an external source.
+
+  @param[in] BlobName   The name of the blob
+  @param[in] BufThe data of the blob
+  @param[in] BufSizeThe size of the blob in bytes
+
+  @retval EFI_SUCCESS   The blob was verified successfully.
+  @retval EFI_ACCESS_DENIED The blob could not be verified, and therefore
+should be considered non-secure.
+**/
+EFI_STATUS
+EFIAPI
+VerifyBlob (
+  IN  CONST CHAR16*BlobName,
+  IN  CONST VOID  *Buf,
+  IN  UINT32  BufSize
+  );
+
+#endif
diff --git a/OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c 
b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c
new file mode 100644
index ..975d4dd52f80
--- /dev/null
+++ b/OvmfPkg/Library/BlobVerifierLib/BlobVerifierNull.c
@@ -0,0 +1,33 @@
+/** @file
+
+  Null implementation of the blob verifier library.
+
+  Copyright (C) 2021, IBM Corporation
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+
+/**
+  Verify blob from an external source.
+
+  @param[in] BlobName   The name of the blob
+  @param[in] BufThe data of the blob
+  @param[in] BufSizeThe size of the blob in bytes
+
+  @retval EFI_SUCCESS   The blob was verified successfully.
+  @retval EFI_ACCESS_DENIED The blob could not be verified, and therefore
+should be considered non-secure.
+**/
+EFI_STATUS
+EFIAPI
+VerifyBlob (
+  IN  CONST CHAR16*BlobName,
+  IN  CONST VOID  *Buf,
+  IN  UINT32  BufSize
+  )
+{
+  return EFI_SUCCESS;
+}
-- 
2.25.1



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

[edk2-devel] [PATCH v4 11/11] OvmfPkg/AmdSev: Enforce hash verification of kernel blobs

[Dov Murik]

In the AmdSevX64 build, use BlobVerifierLibSevHashes to enforce
verification of hashes of the kernel/initrd/cmdline blobs fetched from
firmware config.

This allows for secure (measured) boot of SEV guests with QEMU's
-kernel/-initrd/-append switches (with the corresponding QEMU support
for injecting the hashes table into initial measured guest memory).

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: Dov Murik 
Reviewed-by: Tom Lendacky 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index b2cc96cc5a97..c01599ea354f 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -173,7 +173,7 @@ [LibraryClasses]
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
-  BlobVerifierLib|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  BlobVerifierLib|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
 
 !if $(SOURCE_DEBUG_ENABLE) == TRUE
   
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
@@ -696,7 +696,7 @@ [Components]
   }
   OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
 
-  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibSevHashes.inf
   }
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/Virtio10Dxe/Virtio10.inf
-- 
2.25.1



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

[edk2-devel] [PATCH v4 03/11] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg

[Dov Murik]

From: James Bottomley 

Support QEMU's -kernel option.

Create a QemuKernel.c for PlatformBootManagerLibGrub
which is an exact copy of the file
PlatformBootManagerLib/QemuKernel.c .

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: James Bottomley 
Reviewed-by: Brijesh Singh 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc   
 |  1 +
 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf  
 |  2 ++
 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h   
 | 11 +++
 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c   
 |  5 +
 OvmfPkg/Library/{PlatformBootManagerLib => 
PlatformBootManagerLibGrub}/QemuKernel.c |  0
 5 files changed, 19 insertions(+)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index a2f1324c40a6..aefdcf881c99 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -281,6 +281,7 @@ [LibraryClasses.common.PEIM]
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
+  
QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
   PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
   QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
 
diff --git 
a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf 
b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
index 9a806d17ec45..5f6f73d18470 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf
@@ -23,6 +23,7 @@ [Defines]
 
 [Sources]
   BdsPlatform.c
+  QemuKernel.c
   PlatformData.c
   BdsPlatform.h
 
@@ -46,6 +47,7 @@ [LibraryClasses]
   BootLogoLib
   DevicePathLib
   PciLib
+  QemuLoadImageLib
   UefiLib
   PlatformBmPrintScLib
   Tcg2PhysicalPresenceLib
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h 
b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
index 748c63081920..f1d3a2906c00 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h
@@ -172,4 +172,15 @@ PlatformInitializeConsole (
   IN PLATFORM_CONSOLE_CONNECT_ENTRY   *PlatformConsole
   );
 
+/**
+  Loads and boots UEFI Linux via the FwCfg interface.
+
+  @retvalEFI_NOT_FOUND - The Linux kernel was not found
+
+**/
+EFI_STATUS
+TryRunningQemuKernel (
+  VOID
+  );
+
 #endif // _PLATFORM_SPECIFIC_BDS_PLATFORM_H_
diff --git a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
index 5c92d4fc2b09..7cceeea4879c 100644
--- a/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c
@@ -1315,6 +1315,11 @@ PlatformBootManagerAfterConsole (
   //
   Tcg2PhysicalPresenceLibProcessRequest (NULL);
 
+  //
+  // Process QEMU's -kernel command line option
+  //
+  TryRunningQemuKernel ();
+
   //
   // Perform some platform specific connect sequence
   //
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c 
b/OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c
similarity index 100%
copy from OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c
copy to OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c
-- 
2.25.1



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

[edk2-devel] [PATCH v4 06/11] ArmVirtPkg: add BlobVerifierLibNull to DSC

[Dov Murik]

This prepares the ground for calling VerifyBlob() in
QemuKernelLoaderFsDxe.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: Dov Murik 
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 5 -
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 7ef5e7297bc7..bf8bb1ec9578 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -440,7 +440,10 @@ [Components.common]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
   }
-  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+
+  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  }
 
   #
   # Networking stack
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index a542fcb157e9..af34cb47a12d 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -376,7 +376,10 @@ [Components.common]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
   }
-  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+
+  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  }
 
   #
   # Networking stack
-- 
2.25.1



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

[edk2-devel] [PATCH v4 09/11] OvmfPkg/AmdSev: reserve MEMFD space for for firmware config hashes

[Dov Murik]

From: James Bottomley 

Split the existing 4KB page reserved for SEV launch secrets into two
parts: first 3KB for SEV launch secrets and last 1KB for firmware
config hashes.

The area of the firmware config hashes will be attested (measured) by
the PSP and thus the untrusted VMM can't pass in different files from
what the guest owner allows.

Declare this in the Reset Vector table using GUID
7255371f-3a3b-4b04-927b-1da6efa8d454 and a uint32_t table of a base
and size value (similar to the structure used to declare the launch
secret block).

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Co-developed-by: Dov Murik 
Signed-off-by: Dov Murik 
Signed-off-by: James Bottomley 
Reviewed-by: Tom Lendacky 
Reviewed-by: Brijesh Singh 
---
 OvmfPkg/OvmfPkg.dec  |  6 ++
 OvmfPkg/AmdSev/AmdSevX64.fdf |  5 -
 OvmfPkg/ResetVector/ResetVector.inf  |  2 ++
 OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 20 
 OvmfPkg/ResetVector/ResetVector.nasmb|  2 ++
 5 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index f82228d69cc2..2ab27f0c73c2 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -324,6 +324,12 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|0x0|UINT32|0x42
   gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize|0x0|UINT32|0x43
 
+  ## The base address and size of a hash table confirming allowed
+  #  parameters to be passed in via the Qemu firmware configuration
+  #  device
+  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|0x0|UINT32|0x47
+  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize|0x0|UINT32|0x48
+
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/AmdSev/AmdSevX64.fdf b/OvmfPkg/AmdSev/AmdSevX64.fdf
index 9977b0f00a18..0a89749700c3 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.fdf
+++ b/OvmfPkg/AmdSev/AmdSevX64.fdf
@@ -59,9 +59,12 @@ [FD.MEMFD]
 0x00B000|0x001000
 
gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
 
-0x00C000|0x001000
+0x00C000|0x000C00
 
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
 
+0x00CC00|0x000400
+gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
+
 0x00D000|0x001000
 
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
 
diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf
index dc38f68919cd..d028c92d8cfa 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -47,3 +47,5 @@ [Pcd]
 [FixedPcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase
   gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdQemuHashTableSize
diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm 
b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
index 9c0b5853a46f..7ec3c6e980c3 100644
--- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
+++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
@@ -47,7 +47,27 @@ TIMES (15 - ((guidedStructureEnd - guidedStructureStart + 
15) % 16)) DB 0
 ;
 guidedStructureStart:
 
+; SEV Hash Table Block
 ;
+; This describes the guest ram area where the hypervisor should
+; install a table describing the hashes of certain firmware configuration
+; device files that would otherwise be passed in unchecked.  The current
+; use is for the kernel, initrd and command line values, but others may be
+; added.  The data format is:
+;
+; base physical address (32 bit word)
+; table length (32 bit word)
+;
+; GUID (SEV FW config hash block): 7255371f-3a3b-4b04-927b-1da6efa8d454
+;
+sevFwHashBlockStart:
+DD  SEV_FW_HASH_BLOCK_BASE
+DD  SEV_FW_HASH_BLOCK_SIZE
+DW  sevFwHashBlockEnd - sevFwHashBlockStart
+DB  0x1f, 0x37, 0x55, 0x72, 0x3b, 0x3a, 0x04, 0x4b
+DB  0x92, 0x7b, 0x1d, 0xa6, 0xef, 0xa8, 0xd4, 0x54
+sevFwHashBlockEnd:
+
 ; SEV Secret block
 ;
 ; This describes the guest ram area where the hypervisor should
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb
index 5fbacaed5f9d..8d0bab02f8cb 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -88,5 +88,7 @@
   %define SEV_ES_AP_RESET_IP  FixedPcdGet32 (PcdSevEsWorkAreaBase)
   %define SEV_LAUNCH_SECRET_BASE  FixedPcdGet32 (PcdSevLaunchSecretBase)
   %define SEV_LAUNCH_SECRET_SIZE  FixedPcdGet32 (PcdSevLaunchSecretSize)
+  %define SEV_FW_HASH_BLOCK_BASE  FixedPcdGet32 (PcdQemuHashTableBase)
+  %define 

[edk2-devel] [PATCH v4 08/11] OvmfPkg/AmdSev/SecretPei: build hob for full page

[Dov Murik]

Round up the size of the SEV launch secret area to a whole page, as
required by BuildMemoryAllocationHob.  This will allow the secret
area defined in the MEMFD to take less than a whole 4KB page.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: Dov Murik 
Reviewed-by: Tom Lendacky 
Reviewed-by: Brijesh Singh 
---
 OvmfPkg/AmdSev/SecretPei/SecretPei.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/AmdSev/SecretPei/SecretPei.c 
b/OvmfPkg/AmdSev/SecretPei/SecretPei.c
index ad491515dd5d..db94c26b54d1 100644
--- a/OvmfPkg/AmdSev/SecretPei/SecretPei.c
+++ b/OvmfPkg/AmdSev/SecretPei/SecretPei.c
@@ -4,6 +4,7 @@
   Copyright (C) 2020 James Bottomley, IBM Corporation.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
+#include 
 #include 
 #include 
 #include 
@@ -17,7 +18,7 @@ InitializeSecretPei (
 {
   BuildMemoryAllocationHob (
 PcdGet32 (PcdSevLaunchSecretBase),
-PcdGet32 (PcdSevLaunchSecretSize),
+ALIGN_VALUE (PcdGet32 (PcdSevLaunchSecretSize), EFI_PAGE_SIZE),
 EfiBootServicesData
 );
 
-- 
2.25.1



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

[edk2-devel] [PATCH v4 07/11] OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg

[Dov Murik]

In QemuKernelLoaderFsDxeEntrypoint we use FetchBlob to read the content
of the kernel/initrd/cmdline from the QEMU fw_cfg interface.  Insert a
call to VerifyBlob after fetching to allow BlobVerifierLib
implementations to add a verification step for these blobs.

This will allow confidential computing OVMF builds to add verification
mechanisms for these blobs that originate from an untrusted source
(QEMU).

The null implementation of BlobVerifierLib does nothing in VerifyBlob,
and therefore no functional change is expected.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Co-developed-by: James Bottomley 
Signed-off-by: James Bottomley 
Signed-off-by: Dov Murik 
Reviewed-by: Brijesh Singh 
Reviewed-by: Tom Lendacky 
---
 OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c 
b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
index c7ddd86f5c75..6832d563bcb0 100644
--- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
+++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1039,6 +1040,14 @@ QemuKernelLoaderFsDxeEntrypoint (
 if (EFI_ERROR (Status)) {
   goto FreeBlobs;
 }
+Status = VerifyBlob (
+   CurrentBlob->Name,
+   CurrentBlob->Data,
+   CurrentBlob->Size
+   );
+if (EFI_ERROR (Status)) {
+  goto FreeBlobs;
+}
 mTotalBlobBytes += CurrentBlob->Size;
   }
   KernelBlob  = [KernelBlobTypeKernel];
-- 
2.25.1



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

[edk2-devel] [PATCH v4 05/11] OvmfPkg: add BlobVerifierLibNull to DSC

[Dov Murik]

This prepares the ground for calling VerifyBlob() in
QemuKernelLoaderFsDxe.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: Dov Murik 
Reviewed-by: Tom Lendacky 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 6 +-
 OvmfPkg/OvmfPkgIa32.dsc  | 5 -
 OvmfPkg/OvmfPkgIa32X64.dsc   | 5 -
 OvmfPkg/OvmfPkgX64.dsc   | 5 -
 4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index aefdcf881c99..b2cc96cc5a97 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -173,6 +173,7 @@ [LibraryClasses]
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
+  BlobVerifierLib|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
 
 !if $(SOURCE_DEBUG_ENABLE) == TRUE
   
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
@@ -693,7 +694,10 @@ [Components]
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
   }
-  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+
+  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  }
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/Virtio10Dxe/Virtio10.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index f53efeae7986..7613abab6a7f 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -786,7 +786,10 @@ [Components]
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
-  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+
+  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  }
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/Virtio10Dxe/Virtio10.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index b3662e17f256..8b35aaf4b44c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -800,7 +800,10 @@ [Components.X64]
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
-  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+
+  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  }
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/Virtio10Dxe/Virtio10.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0a237a905866..0c95c74ad1a8 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -798,7 +798,10 @@ [Components]
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
-  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
+  OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf {
+
+  NULL|OvmfPkg/Library/BlobVerifierLib/BlobVerifierLibNull.inf
+  }
   OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
   OvmfPkg/Virtio10Dxe/Virtio10.inf
   OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
-- 
2.25.1



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

[edk2-devel] [PATCH v4 00/11] Measured SEV boot with kernel/initrd/cmdline

[Dov Murik]

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

Booting with SEV prevented the loading of kernel, initrd, and kernel
command-line via QEMU fw_cfg interface because they arrive from the VMM
which is untrusted in SEV.

However, in some cases the kernel, initrd, and cmdline are not secret
but should not be modified by the host.  In such a case, we want to
verify inside the trusted VM that the kernel, initrd, and cmdline are
indeed the ones expected by the Guest Owner, and only if that is the
case go on and boot them up (removing the need for grub inside OVMF in
that mode).

This patch series reserves an area in MEMFD (previously the last 1KB of
the launch secret page) which will contain the hashes of these three
blobs (kernel, initrd, cmdline), each under its own GUID entry.  This
tables of hashes is populated by QEMU before launch, and encrypted as
part of the initial VM memory; this makes sure these hashes are part of
the SEV measurement (which has to be approved by the Guest Owner for
secret injection, for example).  Note that populating the hashes table
requires QEMU support [1].

OVMF parses the table of hashes populated by QEMU (patch 10), and as it
reads the fw_cfg blobs from QEMU, it will verify each one against the
expected hash.  This is all done inside the trusted VM context.  If all
the hashes are correct, boot of the kernel is allowed to continue.

Any attempt by QEMU to modify the kernel, initrd, cmdline (including
dropping one of them), or to modify the OVMF code that verifies those
hashes, will cause the initial SEV measurement to change and therefore
will be detectable by the Guest Owner during launch before secret
injection.

Relevant part of OVMF serial log during boot with AmdSevX86 build and
QEMU with -kernel/-initrd/-append:

  ...
  BlobVerifierLibSevHashesConstructor: Found injected hashes table in secure 
location
  Select Item: 0x17
  Select Item: 0x8
  FetchBlob: loading 7379328 bytes for "kernel"
  Select Item: 0x18
  Select Item: 0x11
  VerifyBlob: Found GUID 4DE79437-ABD2-427F-B835-D5B172D2045B in table
  VerifyBlob: Hash comparison succeeded for "kernel"
  Select Item: 0xB
  FetchBlob: loading 12483878 bytes for "initrd"
  Select Item: 0x12
  VerifyBlob: Found GUID 44BAF731-3A2F-4BD7-9AF1-41E29169781D in table
  VerifyBlob: Hash comparison succeeded for "initrd"
  Select Item: 0x14
  FetchBlob: loading 86 bytes for "cmdline"
  Select Item: 0x15
  VerifyBlob: Found GUID 97D02DD8-BD20-4C94-AA78-E7714D36AB2A in table
  VerifyBlob: Hash comparison succeeded for "cmdline"
  ...

The patch series is organized as follows:

1: Simple comment fix in adjacent area in the code.
2: Use GenericQemuLoadImageLib to gain one location for fw_cfg blob
   fetching.
3: Allow the (previously blocked) usage of -kernel in AmdSevX64.
4-7:   Add BlobVerifierLib with null implementation and use it in the correct
   location in QemuKernelLoaderFsDxe.
8-9:   Reserve memory for hashes table, declare this area in the reset vector.
10-11: Add the secure implementation BlobVerifierLibSevHashes and use it in
   AmdSevX64 builds.

[1] 
https://lore.kernel.org/qemu-devel/20210624102040.2015280-1-dovmu...@linux.ibm.com/

Code is at
https://github.com/confidential-containers-demo/edk2/tree/sev-hashes-v4

v4 changes:
 - BlobVerifierSevHashes (patch 10): more comprehensive overflow tests
   when parsing the SEV hashes table structure

v3: https://edk2.groups.io/g/devel/message/77955
v3 changes:
 - Rename to BlobVerifierLibNull, use decimal INF_VERSION, remove unused
   DebugLib reference, fix doxygen comments, add missing IN attribute
 - Rename to BlobVerifierLibSevHashes, use decimal INF_VERSION, fix
   doxygen comments, add missing IN attribute,
   calculate buffer hash only when the guid is found in hashes table
 - SecretPei: use ALIGN_VALUE to round the hob size
 - Coding style fixes
 - Add missing 'Ref:' in patch 1 commit message
 - Fix phrasing and typos in commit messages
 - Remove Cc: Laszlo from series

v2: https://edk2.groups.io/g/devel/message/77505
v2 changes:
 - Use the last 1KB of the existing SEV launch secret page for hashes table
   (instead of reserving a whole new MEMFD page).
 - Build on top of commit cf203024745f ("OvmfPkg/GenericQemuLoadImageLib: Read
   cmdline from QemuKernelLoaderFs", 2021-06-28) to have a single location in
   which all of kernel/initrd/cmdline are fetched from QEMU.
 - Use static linking of the two BlobVerifierLib implemenatations.
 - Reorganize series.

v1: https://edk2.groups.io/g/devel/message/75567

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Leif Lindholm 
Cc: Sami Mujawar 

---

Ard: please review patch 6 (ArmVirtPkg). Thanks.

Tom, Brijesh: I'll also send the diff for patch 10. Thanks.

---

Dov Murik (8):
  OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev builds
  OvmfPkg: add library class BlobVerifierLib 

[edk2-devel] [PATCH v4 01/11] OvmfPkg/AmdSev/SecretDxe: fix header comment to generic naming

[Dov Murik]

From: James Bottomley 

Commit 96201ae7bf97 ("OvmfPkg/AmdSev/SecretDxe: make secret location
naming generic", 2020-12-15) replaced references to SEV with the generic
term Confidential Computing, but missed the file header comment.  Fix
the naming in that header.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Ashish Kalra 
Cc: Brijesh Singh 
Cc: Erdem Aktas 
Cc: James Bottomley 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
Signed-off-by: James Bottomley 
Reviewed-by: Brijesh Singh 
---
 OvmfPkg/AmdSev/SecretDxe/SecretDxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/AmdSev/SecretDxe/SecretDxe.c 
b/OvmfPkg/AmdSev/SecretDxe/SecretDxe.c
index 308022b5b25e..934ad207632b 100644
--- a/OvmfPkg/AmdSev/SecretDxe/SecretDxe.c
+++ b/OvmfPkg/AmdSev/SecretDxe/SecretDxe.c
@@ -1,5 +1,5 @@
 /** @file
-  SEV Secret configuration table constructor
+  Confidential Computing Secret configuration table constructor
 
   Copyright (C) 2020 James Bottomley, IBM Corporation.
   SPDX-License-Identifier: BSD-2-Clause-Patent
-- 
2.25.1



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

[edk2-devel] [edk2-platforms PATCH v4 2/2] Revert "Platform/RaspberryPi: Setup option for disabling Fast Boot"

[Grzegorz Bernacki]

This reverts commit efdc159ef7c9f15581a0f63d755a1530ff475156.

This commit is not longer required as Boot Discovery Policy has
been implemented for RPi.

Signed-off-by: Grzegorz Bernacki 
Reviewed-by: Sunny Wang 
---
 Platform/RaspberryPi/RaspberryPi.dec   
|  2 --
 Platform/RaspberryPi/RPi3/RPi3.dsc 
|  9 +
 Platform/RaspberryPi/RPi4/RPi4.dsc 
|  9 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   
|  3 +--
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
|  1 -
 Platform/RaspberryPi/Include/ConfigVars.h  
| 12 +---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
| 16 +---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
| 11 +--
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c   
| 15 ++-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
| 10 +-
 10 files changed, 9 insertions(+), 79 deletions(-)

diff --git a/Platform/RaspberryPi/RaspberryPi.dec 
b/Platform/RaspberryPi/RaspberryPi.dec
index f1dd8ac0ed..2ca25ff9e6 100644
--- a/Platform/RaspberryPi/RaspberryPi.dec
+++ b/Platform/RaspberryPi/RaspberryPi.dec
@@ -2,7 +2,6 @@
 #
 #  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
 #  Copyright (c) 2017-2018, Andrei Warkentin 
-#  Copyright (c) 2021, ARM Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -71,5 +70,4 @@
   gRaspberryPiTokenSpaceGuid.PcdFanTemp|0|UINT32|0x001D
   gRaspberryPiTokenSpaceGuid.PcdPlatformResetDelay|0|UINT32|0x001E
   gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|0|UINT32|0x001F
-  gRaspberryPiTokenSpaceGuid.PcdBootPolicy|0|UINT32|0x0020
   gRaspberryPiTokenSpaceGuid.PcdUartInUse|1|UINT32|0x0021
diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 53825bcf62..b6e3372c61 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -1,6 +1,6 @@
 # @file
 #
-#  Copyright (c) 2011 - 2021, ARM Limited. All rights reserved.
+#  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
 #  Copyright (c) 2014, Linaro Limited. All rights reserved.
 #  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 #  Copyright (c) 2017 - 2018, Andrei Warkentin 
@@ -512,13 +512,6 @@
   
gRaspberryPiTokenSpaceGuid.PcdFanOnGpio|L"FanOnGpio"|gConfigDxeFormSetGuid|0x0|0
   gRaspberryPiTokenSpaceGuid.PcdFanTemp|L"FanTemp"|gConfigDxeFormSetGuid|0x0|0
 
-  #
-  # Boot Policy
-  # 0  - Fast Boot
-  # 1  - Full Discovery (Connect All)
-  #
-  
gRaspberryPiTokenSpaceGuid.PcdBootPolicy|L"BootPolicy"|gConfigDxeFormSetGuid|0x0|1
-
   #
   # Reset-related.
   #
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 8b9beac64a..07f36e7f1b 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -1,6 +1,6 @@
 # @file
 #
-#  Copyright (c) 2011 - 2021, ARM Limited. All rights reserved.
+#  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
 #  Copyright (c) 2017 - 2018, Andrei Warkentin 
 #  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 #  Copyright (c) 2014, Linaro Limited. All rights reserved.
@@ -528,13 +528,6 @@
   
gRaspberryPiTokenSpaceGuid.PcdFanOnGpio|L"FanOnGpio"|gConfigDxeFormSetGuid|0x0|0
   gRaspberryPiTokenSpaceGuid.PcdFanTemp|L"FanTemp"|gConfigDxeFormSetGuid|0x0|60
 
-  #
-  # Boot Policy
-  # 0  - Fast Boot
-  # 1  - Full Discovery (Connect All)
-  #
-  
gRaspberryPiTokenSpaceGuid.PcdBootPolicy|L"BootPolicy"|gConfigDxeFormSetGuid|0x0|1
-
   #
   # Reset-related.
   #
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 597e1b4205..4bb2d08550 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -2,7 +2,7 @@
 #
 #  Component description file for the RasbperryPi DXE platform config driver.
 #
-#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
+#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
 #  Copyright (c) 2018 - 2020, Andrei Warkentin 
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -93,7 +93,6 @@
   gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
   gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
-  gRaspberryPiTokenSpaceGuid.PcdBootPolicy
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
 
 [Depex]
diff --git 
a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 
b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 4ef2f791ae..c047364b28 100644
--- 

[edk2-devel] [edk2-platforms PATCH v4 1/2] Platform/RaspberryPi: Enable Boot Discovery Policy.

[Grzegorz Bernacki]

This commit modify platform boot to check the value of
BootDiscoveryPolicy variable and use BootPolicyManager
Protocol to connect devices specified by the variable.

Signed-off-by: Grzegorz Bernacki 
Reviewed-by: Sunny Wang 
---
 Platform/RaspberryPi/RPi4/RPi4.dsc 
|  3 +
 Platform/RaspberryPi/RPi4/RPi4.fdf 
|  1 +
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
|  5 ++
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c   
| 91 
 4 files changed, 100 insertions(+)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index fd73c4d14b..8b9beac64a 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -555,6 +555,7 @@
   
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|L"Columns"|gRaspberryPiTokenSpaceGuid|0x0|80
   
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow|L"Rows"|gRaspberryPiTokenSpaceGuid|0x0|25
   
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|L"Rows"|gRaspberryPiTokenSpaceGuid|0x0|25
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy|L"BootDiscoveryPolicy"|gBootDiscoveryPolicyMgrFormsetGuid|0
 
 [PcdsDynamicDefault.common]
   #
@@ -682,6 +683,7 @@
   #
   # Bds
   #
+  MdeModulePkg/Universal/BootManagerPolicyDxe/BootManagerPolicyDxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
@@ -690,6 +692,7 @@
   Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.inf
   MdeModulePkg/Application/UiApp/UiApp.inf {
 
+  
NULL|MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
   NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
   NULL|Platform/RaspberryPi/Library/PlatformUiAppLib/PlatformUiAppLib.inf
diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf 
b/Platform/RaspberryPi/RPi4/RPi4.fdf
index 1e13909a57..371197a93e 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.fdf
+++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
@@ -253,6 +253,7 @@ READ_LOCK_STATUS   = TRUE
   #
   # Bds
   #
+  INF MdeModulePkg/Universal/BootManagerPolicyDxe/BootManagerPolicyDxe.inf
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
diff --git 
a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 
b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index fbf510ab96..4ef2f791ae 100644
--- 
a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ 
b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -61,11 +61,13 @@
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType
 
 [Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy 
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
   gRaspberryPiTokenSpaceGuid.PcdSdIsArasan
   gRaspberryPiTokenSpaceGuid.PcdBootPolicy
 
 [Guids]
+  gBootDiscoveryPolicyMgrFormsetGuid
   gEfiFileInfoGuid
   gEfiFileSystemInfoGuid
   gEfiFileSystemVolumeLabelInfoIdGuid
@@ -73,8 +75,11 @@
   gEfiTtyTermGuid
   gUefiShellFileGuid
   gEfiEventExitBootServicesGuid
+  gEfiBootManagerPolicyNetworkGuid
+  gEfiBootManagerPolicyConnectAllGuid
 
 [Protocols]
+  gEfiBootManagerPolicyProtocolGuid
   gEfiDevicePathProtocolGuid
   gEfiGraphicsOutputProtocolGuid
   gEfiLoadedImageProtocolGuid
diff --git a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c 
b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
index d081fdae63..d944d1a38d 100644
--- a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
@@ -6,6 +6,7 @@
  *  Copyright (c) 2015-2016, Red Hat, Inc.
  *  Copyright (c) 2014-2021, ARM Ltd. All rights reserved.
  *  Copyright (c) 2004-2016, Intel Corporation. All rights reserved.
+ *  Copyright (c) 2021, Semihalf All rights reserved.
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
  *
@@ -19,10 +20,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -598,6 +601,89 @@ PlatformBootManagerBeforeConsole (
   FilterAndProcess (, NULL, Connect);
 }
 
+/**
+  Connect device specified by BootDiscoverPolicy variable and refresh
+  Boot order for newly discovered boot device.
+
+  @retval  EFI_SUCCESS  Devices connected succesfully or connection
+not required.
+  @retval  others   Return values from GetVariable(), LocateProtocol()
+and ConnectDeviceClass().
+--*/
+STATIC
+EFI_STATUS
+BootDiscoveryPolicyHandler (
+  VOID
+  )
+{
+  

[edk2-devel] [PATCH v4 1/1] MdeModulePkg: Add BootDiscoveryPolicyUiLib.

[Grzegorz Bernacki]

This library extends Boot Maintenance Menu and allows to select
Boot Discovery Policy. When choice is made BootDiscoveryPolicy
variable is set. Platform code can use this variable to decide
which class of device shall be connected.

Signed-off-by: Grzegorz Bernacki 
Reviewed-by: Zhichao Gao 
---
 MdeModulePkg/MdeModulePkg.dec  
   |   9 ++
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf 
   |  52 +++
 MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
   |  22 +++
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c   
   | 160 
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni 
   |  18 +++
 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibStrings.uni
 |  29 
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibVfr.Vfr  
   |  44 ++
 7 files changed, 334 insertions(+)
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
 create mode 100644 MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibStrings.uni
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibVfr.Vfr

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index ad84421cf3..133e04ee86 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -425,6 +425,9 @@
   ## Include/UniversalPayload/SerialPortInfo.h
   gUniversalPayloadSerialPortInfoGuid = { 0xaa7e190d, 0xbe21, 0x4409, { 0x8e, 
0x67, 0xa2, 0xcd, 0xf, 0x61, 0xe1, 0x70 } }
 
+  ## GUID used for Boot Discovery Policy FormSet guid and related variables.
+  gBootDiscoveryPolicyMgrFormsetGuid = { 0x5b6f7107, 0xbb3c, 0x4660, { 0x92, 
0xcd, 0x54, 0x26, 0x90, 0x28, 0x0b, 0xbd } }
+
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
@@ -1600,6 +1603,12 @@
   # @Prompt Console Output Row of Text Setup
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow|25|UINT32|0x400e
 
+  ## Specify the Boot Discovery Policy settings
+  # To support configuring from setup page, this PCD should be overridden in 
DynamicHii type in its platform .dsc:
+  # 
gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy|L"BootDiscoveryPolicy"|gBootDiscoveryPolicyMgrFormsetGuid|0
+  # @Prompt Boot Discovery Policy
+  gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy|2|UINT32|0x400f
+
 [PcdsFixedAtBuild.AARCH64, PcdsPatchableInModule.AARCH64]
   
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20|UINT32|0x0001004c
 
diff --git 
a/MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf 
b/MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
new file mode 100644
index 00..1fb4d43caa
--- /dev/null
+++ b/MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
@@ -0,0 +1,52 @@
+## @file
+#  Library for BDS phase to use Boot Discovery Policy
+#
+#  Copyright (c) 2021, ARM Ltd. All rights reserved.
+#  Copyright (c) 2021, Semihalf All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = BootDiscoveryPolicyUiLib
+  MODULE_UNI_FILE= BootDiscoveryPolicyUiLib.uni
+  FILE_GUID  = BE73105A-B13D-4B57-A41A-463DBD15FE10
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = NULL|DXE_DRIVER UEFI_APPLICATION
+  CONSTRUCTOR= BootDiscoveryPolicyUiLibConstructor
+  DESTRUCTOR = BootDiscoveryPolicyUiLibDestructor
+#
+# The following information is for reference only and not required by the 
build tools.
+#
+#  VALID_ARCHITECTURES   = IA32 X64 AARCH64
+#
+
+[Sources]
+  BootDiscoveryPolicyUiLib.c
+  BootDiscoveryPolicyUiLibStrings.uni
+  BootDiscoveryPolicyUiLibVfr.Vfr
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+
+[LibraryClasses]
+  DevicePathLib
+  BaseLib
+  UefiRuntimeServicesTableLib
+  UefiBootServicesTableLib
+  DebugLib
+  HiiLib
+  UefiLib
+  BaseMemoryLib
+
+[Guids]
+  gBootDiscoveryPolicyMgrFormsetGuid
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy  ## PRODUCES
+
+[Depex]
+  gEfiHiiDatabaseProtocolGuid AND gPcdProtocolGuid
diff --git a/MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h 
b/MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
new file mode 100644
index 00..8eb0968a16
--- /dev/null
+++ 

[edk2-devel] [edk2-platforms PATCH v4 0/2]Add BootDiscoveryPolicyUiLib

[Grzegorz Bernacki]

This patchset extends Boot Maintenance Menu and allows to select
Boot Discovery Policy. Raspberry Pi platforms uses the variable to
connect specified class of devices on boot. This patchset also
removes efdc159e which has similar functionality.

Discussion on design can be found at:
https://edk2.groups.io/g/rfc/topic/rfc_boot_discovery_policy/82450628

Changes since v1:
- make 'Connect All' (0x2) default value for PcdBootDiscoveryPolicy
- initialize BootDiscoveryPolicy variable in platform code, if not found

Changes since v2:
- add missing local variable initialization

Changes since v3:
- add description to PcdBootDiscoveryPolicy
 
Grzegorz Bernacki (3):
edk2:
  MdeModulePkg: Add BootDiscoveryPolicyUiLib.
edk2-platform:
  Platform/RaspberryPi: Enable Boot Discovery Policy.
  Revert "Platform/RaspberryPi: Setup option for disabling Fast Boot"

 Platform/RaspberryPi/RaspberryPi.dec   
|   2 -
 Platform/RaspberryPi/RPi3/RPi3.dsc 
|   9 +-
 Platform/RaspberryPi/RPi4/RPi4.dsc 
|  12 +--
 Platform/RaspberryPi/RPi4/RPi4.fdf 
|   1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   
|   3 +-
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
|   6 +-
 Platform/RaspberryPi/Include/ConfigVars.h  
|  12 +--
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
|  16 +--
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
|  11 +--
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c   
| 102 +---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
|  10 +-
 MdeModulePkg/MdeModulePkg.dec  
   |   9 ++
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf 
   |  52 +++
 MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
   |  22 +++
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c   
   | 160 
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni 
   |  18 +++
 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibStrings.uni
 |  29 
 MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibVfr.Vfr  
   |  44 ++
 18 files changed, 443 insertions(+), 77 deletions(-)
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
 create mode 100644 MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibStrings.uni
 create mode 100644 
MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibVfr.Vfr


-- 
2.25.1



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

[edk2-devel] [Patch V2] NetworkPkg: Add HTTP Additional Event Notifications

[Heng Luo]

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

Add new EDKII_HTTP_CALLBACK_PROTOCOL in NetworkPkg,
Send HTTP Events via EDKII_HTTP_CALLBACK_PROTOCOL
when Dns/ConnectTcp/TlsConnectSession/InitSession
occurs.

Signed-off-by: Heng Luo 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
---
 NetworkPkg/HttpDxe/HttpDriver.h|  3 ++-
 NetworkPkg/HttpDxe/HttpDxe.inf |  3 ++-
 NetworkPkg/HttpDxe/HttpImpl.c  |  4 +++-
 NetworkPkg/HttpDxe/HttpProto.c | 58 
+-
 NetworkPkg/HttpDxe/HttpProto.h | 15 ++-
 NetworkPkg/Include/Protocol/HttpCallback.h | 85 
+
 NetworkPkg/NetworkPkg.dec  |  3 +++
 7 files changed, 166 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpDriver.h b/NetworkPkg/HttpDxe/HttpDriver.h
index 5fe8c5b5e9..b701b80858 100644
--- a/NetworkPkg/HttpDxe/HttpDriver.h
+++ b/NetworkPkg/HttpDxe/HttpDriver.h
@@ -1,7 +1,7 @@
 /** @file
   The header files of the driver binding and service binding protocol for 
HttpDxe driver.
 
-  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 //
diff --git a/NetworkPkg/HttpDxe/HttpDxe.inf b/NetworkPkg/HttpDxe/HttpDxe.inf
index 35fe31af18..23fb9ec394 100644
--- a/NetworkPkg/HttpDxe/HttpDxe.inf
+++ b/NetworkPkg/HttpDxe/HttpDxe.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Implementation of EFI HTTP protocol interfaces.
 #
-#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -65,6 +65,7 @@
   gEfiTlsServiceBindingProtocolGuid## SOMETIMES_CONSUMES
   gEfiTlsProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiTlsConfigurationProtocolGuid ## SOMETIMES_CONSUMES
+  gEdkiiHttpCallbackProtocolGuid   ## SOMETIMES_CONSUMES
 
 [Guids]
   gEfiTlsCaCertificateGuid ## SOMETIMES_CONSUMES  ## 
Variable:L"TlsCaCertificate"
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 5a6ecbc9d9..97f15d229f 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation of EFI_HTTP_PROTOCOL protocol interfaces.
 
-  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
   (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -527,6 +527,7 @@ EfiHttpRequest (
   } else {
 Status = HttpDns6 (HttpInstance, HostNameStr, 
>RemoteIpv6Addr);
   }
+  HttpNotify (HttpEventDns, Status);
 
   FreePool (HostNameStr);
   if (EFI_ERROR (Status)) {
@@ -588,6 +589,7 @@ EfiHttpRequest (
  Configure || ReConfigure,
  TlsConfigure
  );
+  HttpNotify (HttpEventInitSession, Status);
   if (EFI_ERROR (Status)) {
 goto Error2;
   }
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index afc7db5a72..affa916bd6 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1,7 +1,7 @@
 /** @file
   Miscellaneous routines for HttpDxe driver.
 
-Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
 (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -966,6 +966,7 @@ HttpCreateConnection (
 HttpInstance->IsTcp4ConnDone = FALSE;
 HttpInstance->Tcp4ConnToken.CompletionToken.Status = EFI_NOT_READY;
 Status = HttpInstance->Tcp4->Connect (HttpInstance->Tcp4, 
>Tcp4ConnToken);
+HttpNotify (HttpEventConnectTcp, Status);
 if (EFI_ERROR (Status)) {
   DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp4->Connect() = %r\n", 
Status));
   return Status;
@@ -981,6 +982,7 @@ HttpCreateConnection (
 HttpInstance->IsTcp6ConnDone = FALSE;
 HttpInstance->Tcp6ConnToken.CompletionToken.Status = EFI_NOT_READY;
 Status = HttpInstance->Tcp6->Connect (HttpInstance->Tcp6, 
>Tcp6ConnToken);
+HttpNotify (HttpEventConnectTcp, Status);
 if (EFI_ERROR (Status)) {
   DEBUG ((EFI_D_ERROR, "HttpCreateConnection: Tcp6->Connect() = %r\n", 
Status));
   return Status;
@@ -1277,6 +1279,7 @@ HttpConnectTcp4 (
 }
 
 Status = TlsConnectSession (HttpInstance, HttpInstance->TimeoutEvent);
+HttpNotify (HttpEventTlsConnectSession, Status);
 
 gBS->SetTimer 

[edk2-devel] [staging/edk2-redfish-client Tools PATCH 5/6] RedfishClientPkg/Redfish-Profile-Simulator: Add ETAG on memory resource

[Abner Chang]

Add ETAG support on Memory resource.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../Redfish-Profile-Simulator/v1sim/systems.py  | 13 +
 1 file changed, 13 insertions(+)

diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
index 690101fb10..de4b839aeb 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
@@ -18,6 +18,7 @@ from .resource import RfResource, RfCollection
 from .storage import RfSimpleStorageCollection, RfSmartStorage
 import flask
 import json
+import hashlib
 from collections import OrderedDict
 
 class RfSystemsCollection(RfCollection):
@@ -142,13 +143,25 @@ class RfMemoryCollection(RfCollection):
 self.res_data["Members"].append({"@odata.id":newMemoryUrl})
 
 post_data["@odata.id"] = newMemoryUrl
+
+md5 = hashlib.md5()
+md5.update(json.dumps(post_data).encode("utf-8"))
+etag_str = 'W/"' + md5.hexdigest() + '"'
+post_data["@odata.etag"] = etag_str
 self.elements[str(newMemoryIdx)] = post_data
 
 resp = flask.Response(json.dumps(post_data,indent=4))
 resp.headers["Location"] = newMemoryUrl
+resp.headers["ETag"] = etag_str
+
 return 0, 200, None, resp
 
 def patch_memory(self, Idx, patch_data):
+md5 = hashlib.md5()
+md5.update(json.dumps(patch_data).encode("utf-8"))
+etag_str = 'W/"' + md5.hexdigest() + '"'
+patch_data["@odata.etag"] = etag_str
+
 self.elements[str(Idx)] = {**self.elements[str(Idx)], **patch_data}
 resp = flask.Response(json.dumps(self.elements[str(Idx)],indent=4))
 return 0, 200, None, resp
-- 
2.17.1



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

[edk2-devel] [staging/edk2-redfish-client Tools PATCH 6/6] RedfishClientPkg/Redfish-Profile-Simulator: Add requirements

[Abner Chang]

add requirements.txt for the required python module

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../Tools/Redfish-Profile-Simulator/requirements.txt| 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt

diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt
new file mode 100644
index 00..88807d87c2
--- /dev/null
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/requirements.txt
@@ -0,0 +1,2 @@
+flask==1.1.1
+pyOpenSSL
-- 
2.17.1



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

[edk2-devel] [staging/edk2-redfish-client Tools PATCH 0/6] Initial commit of Redfish Profile Simulator

[Abner Chang]

This is an open source project on DMTF GitHub.
(https://github.com/DMTF/Redfish-Profile-Simulator)

We clone this project under RedfishClientPkg and maintain it by edk2
because this project has currently been using and updating rarely.
That is easier for edk2 to add features to the simulator or modify the
simulator to align with edk2 requirement on Redfish service.

The license of this tool is on the term of BSD 3-Clause License.
Refer to LICENSE.md.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 

Abner Chang (6):
  RedfishClientPkg/Tools: Initial commit of Redfish Profile Simulator
  RedfishClientPkg/Tools: Add more Redfish resource
  RedfishClientPkg/Redfish-Profile-Simulator: Add more features
  RedfishClientPkg/Redfish-Profile-Simulator: HTTP methods on Memory
Collection
  RedfishClientPkg/Redfish-Profile-Simulator: Add ETAG on memory
resource
  RedfishClientPkg/Redfish-Profile-Simulator: Add requirements

 .../Redfish-Profile-Simulator/AUTHORS.md  |   2 +
 .../Redfish-Profile-Simulator/CHANGELOG.md|  15 +
 .../Redfish-Profile-Simulator/LICENSE.md  |  57 +++
 .../Tools/Redfish-Profile-Simulator/README.md |  96 +
 .../SimpleOcpServerV1/redfish/index.json  |   3 +
 .../redfish/v1/$metadata/index.xml| 151 +++
 .../v1/AccountService/Accounts/index.json |  19 +
 .../AccountService/Accounts/jane/index.json   |  19 +
 .../AccountService/Accounts/john/index.json   |  19 +
 .../AccountService/Accounts/root/index.json   |  19 +
 .../v1/AccountService/Roles/Admin/index.json  |  17 +
 .../AccountService/Roles/Operator/index.json  |  15 +
 .../Roles/ReadOnlyUser/index.json |  13 +
 .../v1/AccountService/Roles/index.json|  19 +
 .../redfish/v1/AccountService/index.json  |  25 ++
 .../redfish/v1/Chassis/A33/Power/index.json   |  28 ++
 .../redfish/v1/Chassis/A33/Thermal/index.json | 150 +++
 .../redfish/v1/Chassis/A33/index.json |  46 ++
 .../redfish/v1/Chassis/index.json |  13 +
 .../bmc/EthernetInterfaces/eth0/index.json|  60 +++
 .../bmc/EthernetInterfaces/index.json |  15 +
 .../Managers/bmc/NetworkProtocol/index.json   |  47 +++
 .../redfish/v1/Managers/bmc/index.json|  53 +++
 .../redfish/v1/Managers/index.json|  13 +
 .../index.json|  16 +
 .../redfish/v1/Registries/index.json  |  14 +
 .../Sessions/SESSION123456/index.json |  10 +
 .../v1/SessionService/Sessions/index.json |  12 +
 .../redfish/v1/SessionService/index.json  |  17 +
 .../2M220100SL/Bios/Settings/index.json   |  31 ++
 .../v1/Systems/2M220100SL/Bios/index.json | 202 +
 .../LogServices/SEL/Entries/1/index.json  |  27 ++
 .../LogServices/SEL/Entries/2/index.json  |  27 ++
 .../LogServices/SEL/Entries/index.json|  62 +++
 .../2M220100SL/LogServices/SEL/index.json |  27 ++
 .../Systems/2M220100SL/LogServices/index.json |  15 +
 .../v1/Systems/2M220100SL/Memory/1/index.json |  56 +++
 .../v1/Systems/2M220100SL/Memory/2/index.json |  46 ++
 .../v1/Systems/2M220100SL/Memory/3/index.json |  46 ++
 .../v1/Systems/2M220100SL/Memory/4/index.json |  46 ++
 .../v1/Systems/2M220100SL/Memory/index.json   |  22 +
 .../redfish/v1/Systems/2M220100SL/index.json  |  76 
 .../2M220101SL/Bios/Settings/index.json   |  13 +
 .../v1/Systems/2M220101SL/Bios/index.json |  17 +
 .../Systems/2M220101SL/BootOptions/index.json |  10 +
 .../LogServices/SEL/Entries/1/index.json  |  28 ++
 .../LogServices/SEL/Entries/2/index.json  |  28 ++
 .../LogServices/SEL/Entries/index.json|  64 +++
 .../2M220101SL/LogServices/SEL/index.json |  27 ++
 .../Systems/2M220101SL/LogServices/index.json |  15 +
 .../2M220101SL/Memory/_backup/1/index.json|  56 +++
 .../2M220101SL/Memory/_backup/2/index.json|  46 ++
 .../2M220101SL/Memory/_backup/3/index.json|  46 ++
 .../2M220101SL/Memory/_backup/4/index.json|  46 ++
 .../2M220101SL/Memory/_backup/index.json  |  22 +
 .../v1/Systems/2M220101SL/Memory/index.json   |  10 +
 .../redfish/v1/Systems/2M220101SL/index.json  |  82 
 .../2M220102SL/Bios/Settings/index.json   |  31 ++
 .../v1/Systems/2M220102SL/Bios/index.json | 202 +
 .../LogServices/SEL/Entries/1/index.json  |  28 ++
 .../LogServices/SEL/Entries/2/index.json  |  28 ++
 .../LogServices/SEL/Entries/index.json|  64 +++
 .../2M220102SL/LogServices/SEL/index.json |  27 ++
 .../Systems/2M220102SL/LogServices/index.json |  15 +
 .../v1/Systems/2M220102SL/Memory/1/index.json |  56 +++
 .../v1/Systems/2M220102SL/Memory/2/index.json |  46 ++
 .../v1/Systems/2M220102SL/Memory/3/index.json |  46 ++
 .../v1/Systems/2M220102SL/Memory/4/index.json |  46 ++
 .../v1/Systems/2M220102SL/Memory/index.json   |  22 +
 .../redfish/v1/Systems/2M220102SL/index.json  |  76 
 .../redfish/v1/Systems/index.json |  19 +
 .../SimpleOcpServerV1/redfish/v1/index.json   |  34 ++
 

[edk2-devel] [staging/edk2-redfish-client Tools PATCH 3/6] RedfishClientPkg/Redfish-Profile-Simulator: Add more features

[Abner Chang]

- Add HTTPs support
- Add ETAG support
- Change default credential to admin/pwd123456
- Add HTTP methods on BIOS managed resource.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../redfishProfileSimulator.py|  92 --
 .../v1sim/redfishURIs.py  | 161 --
 .../v1sim/registry.py |  14 ++
 .../v1sim/resource.py |  27 ++-
 .../v1sim/systems.py  |  85 -
 5 files changed, 311 insertions(+), 68 deletions(-)
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/registry.py

diff --git 
a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/redfishProfileSimulator.py 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/redfishProfileSimulator.py
index 24be52bafc..91c792a2b7 100644
--- 
a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/redfishProfileSimulator.py
+++ 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/redfishProfileSimulator.py
@@ -1,4 +1,9 @@
 # Copyright Notice:
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+# Copyright Notice:
 # Copyright 2016 Distributed Management Task Force, Inc. All rights reserved.
 # License: BSD 3-Clause License. For full text see link: 
https://github.com/DMTF/Redfish-Profile-Simulator/blob/master/LICENSE.md
 
@@ -9,13 +14,16 @@
 import sys
 import getopt
 import os
+import functools
+import flask
+import werkzeug
 
 rfVersion = "0.9.6"
 rfProgram1 = "redfishProfileSimulator"
 rfProgram2 = ""
 rfUsage1 = "[-Vh]  [--Version][--help]"
-rfUsage2 = "[-H] [-P] [-p]"
-rfUsage3 = "[--Host=] [--Port=] [--profile_path=]"
+rfUsage2 = "[-H] [-P] [-C] [-K] [-p]"
+rfUsage3 = "[--Host=] [--Port=] [--Cert=] [--Key=] 
[--profile_path=]"
 
 
 def rf_usage():
@@ -27,18 +35,19 @@ def rf_usage():
 
 def rf_help():
 print(rfProgram1,"implements a simulation of a redfish service for the 
\"Simple OCP Server V1\" Mockup.")
-print(" The simulation includes an http server, RestEngine, and 
dynamic Redfish datamodel.")
+print(" The simulation includes an http/https server, RestEngine, and 
dynamic Redfish datamodel.")
 print(" You can GET, PATHCH,... to the service just like a real 
Redfish service.")
 print(" Both Basic and Redfish Session/Token authentication is 
supported (for a single user/passwd and token")
 print("the user/passwd is:   root/password123456.The authToken 
is: 123456SESSIONauthcode")
 print("these can be changed by editing the redfishURIs.py file.  
will make dynamic later.")
-print(" The http service and Rest engine is built on Flask, and all 
code is Python 3.4+")
+print(" The http/https service and Rest engine is built on Flask, and 
all code is Python 3.4+")
 print(" The data model resources are \"initialized\" from the SPMF 
\"SimpleOcpServerV1\" Mockup.")
 print(" and stored as python dictionaries--then the dictionaries 
are updated with patches, posts, deletes.")
 print(" The program can be extended to support other mockup 
\"profiles\".")
 print("")
-print(" By default, the simulation runs on localhost (127.0.0.1), on 
port 5000.")
-print(" These can be changed with CLI options: -P -H   | 
--port= --host=")
+print(" By default, the simulation runs over http, on localhost 
(127.0.0.1), on port 5000.")
+print(" These can be changed with CLI options: -P -C 
-K -H  | --port= --Cert= --Key= --host=")
+print(" -C -K | --Cert= --Key= options must be 
used together with port 443 to enable https session.")
 print("")
 print("Version: ", rfVersion)
 rf_usage()
@@ -47,19 +56,69 @@ def rf_help():
 print("   -h,  --help,  --- help")
 print("   -H,  --Host=  --- host 
IP address. dflt=127.0.0.1")
 print("   -P,--Port=--- the 
port to use. dflt=5000")
+print("   -C,--Cert=--- Server 
certificate.")
+print("   -K, --Key=  --- Server 
key.")
 print("   -p, --profile=--- the 
path to the Redfish profile to use. "
   "dflt=\"./MockupData/SimpleOcpServerV1\" ")
 
+# Conditional Requests with ETags
+# http://flask.pocoo.org/snippets/95/
+def conditional(func):
+'''Start conditional method execution for this resource'''
+@functools.wraps(func)
+def wrapper(*args, **kwargs):
+flask.g.condtnl_etags_start = True
+return func(*args, **kwargs)
+return wrapper
+
+class NotModified(werkzeug.exceptions.HTTPException):
+code = 304
+def get_response(self, environment):
+return flask.Response(status=304)
+
+class PreconditionRequired(werkzeug.exceptions.HTTPException):
+code = 428
+description = ('This 

[edk2-devel] [staging/edk2-redfish-client Tools PATCH 4/6] RedfishClientPkg/Redfish-Profile-Simulator: HTTP methods on Memory Collection

[Abner Chang]

Add POST and PATCH methods on Memory collection and resource.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../v1sim/redfishURIs.py  | 25 +++
 .../v1sim/systems.py  | 43 +++
 2 files changed, 68 insertions(+)

diff --git 
a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
index 3c912f7ce1..35d3794cc6 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/redfishURIs.py
@@ -1,6 +1,7 @@
 #
 # Copyright Notice:
 # Copyright (c) 2019, Intel Corporation. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 # Copyright Notice:
@@ -308,6 +309,30 @@ def rfApi_SimpleServer(root, versions, host="127.0.0.1", 
port=5000, cert="", key
 else:
 return err_string, status_code
 
+@app.route("/redfish/v1/Systems//Memory", 
methods=['POST'])
+@auth.rfAuthRequired
+def rf_computer_memory_post(system_id):
+print ("in POST memory collection")
+rdata = json.loads(request.data,object_pairs_hook=OrderedDict)
+print("rdata:{}".format(rdata))
+rc, status_code, err_string, resp = 
root.components['Systems'].get_element(system_id).components['Memory'].post_resource(rdata)
+if rc == 0:
+return resp, status_code
+else:
+return err_string, status_code
+
+
@app.route("/redfish/v1/Systems//Memory/", 
methods=['PATCH'])
+@auth.rfAuthRequired
+def rf_computer_memory_patch(system_id, MemoryIdx):
+print ("in PATCH memory[%s] resource" % MemoryIdx)
+rdata = json.loads(request.data,object_pairs_hook=OrderedDict)
+print("rdata:{}".format(rdata))
+rc, status_code, err_string, resp = 
root.components['Systems'].get_element(system_id).components['Memory'].patch_memory(MemoryIdx,
 rdata)
+if rc == 0:
+return resp, status_code
+else:
+return err_string, status_code
+
 def resolve_path(service, path):
 parts = path.split('/')
 result = service
diff --git a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py 
b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
index b8b3788054..690101fb10 100644
--- a/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
+++ b/RedfishClientPkg/Tools/Redfish-Profile-Simulator/v1sim/systems.py
@@ -2,6 +2,7 @@
 # Copyright Notice:
 #
 # Copyright (c) 2019, Intel Corporation. All rights reserved.
+# (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 # Copyright Notice:
@@ -123,9 +124,50 @@ class RfSystemObj(RfResource):
 
 # subclass Logs Collection
 class RfMemoryCollection(RfCollection):
+def final_init_processing(self, base_path, rel_path):
+self.maxIdx = self.res_data["Members@odata.count"]
+
 def element_type(self):
 return RfMemory
 
+def post_resource(self, post_data):
+
print("Members@odata.count:{}".format(self.res_data["Members@odata.count"]))
+print("Members:{}".format(self.res_data["Members"]))
+print("post_data:{}".format(post_data))
+
+self.res_data["Members@odata.count"] = 
self.res_data["Members@odata.count"] + 1
+self.maxIdx = self.maxIdx + 1
+newMemoryIdx = self.maxIdx
+newMemoryUrl = self.res_data["@odata.id"] + "/" + str(newMemoryIdx)
+self.res_data["Members"].append({"@odata.id":newMemoryUrl})
+
+post_data["@odata.id"] = newMemoryUrl
+self.elements[str(newMemoryIdx)] = post_data
+
+resp = flask.Response(json.dumps(post_data,indent=4))
+resp.headers["Location"] = newMemoryUrl
+return 0, 200, None, resp
+
+def patch_memory(self, Idx, patch_data):
+self.elements[str(Idx)] = {**self.elements[str(Idx)], **patch_data}
+resp = flask.Response(json.dumps(self.elements[str(Idx)],indent=4))
+return 0, 200, None, resp
+
+def get_memory(self, Idx):
+return json.dumps(self.elements[Idx],indent=4)
+
+def delete_memory(self, Idx):
+print("in delete_memory")
+
+resp = flask.Response(json.dumps(self.elements[Idx],indent=4))
+
+self.elements.pop(Idx)
+self.res_data["Members@odata.count"] = 
self.res_data["Members@odata.count"] - 1
+
+newMemoryUrl = self.res_data["@odata.id"] + "/" + str(Idx)
+self.res_data["Members"].remove({"@odata.id":newMemoryUrl})
+return 0, 200, None, resp
+
 
 class RfMemory(RfResource):
 pass
@@ -267,3 +309,4 @@ class RfBootOptionCollection(RfCollection):
 return 0, 200, None, resp
 
 class RfBootOption(RfResource):
+pass
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all 

[edk2-devel] [staging/edk2-redfish-client Tools PATCH 2/6] RedfishClientPkg/Tools: Add more Redfish resource

[Abner Chang]

Add more Redfish resource for EDK2 Redfish development.
- Add two more systems to profile.
- Add BIOS, Memory and Log service to profile.

Signed-off-by: Abner Chang 
Cc: Nickle Wang 
Cc: Liming Gao 
---
 .../redfish/v1/$metadata/index.xml|   6 +-
 .../index.json|  16 ++
 .../redfish/v1/Registries/index.json  |  14 ++
 .../2M220100SL/Bios/Settings/index.json   |  31 +++
 .../v1/Systems/2M220100SL/Bios/index.json | 202 ++
 .../v1/Systems/2M220100SL/Memory/1/index.json |  56 +
 .../v1/Systems/2M220100SL/Memory/2/index.json |  46 
 .../v1/Systems/2M220100SL/Memory/3/index.json |  46 
 .../v1/Systems/2M220100SL/Memory/4/index.json |  46 
 .../v1/Systems/2M220100SL/Memory/index.json   |  22 ++
 .../redfish/v1/Systems/2M220100SL/index.json  |  10 +-
 .../2M220101SL/Bios/Settings/index.json   |  13 ++
 .../v1/Systems/2M220101SL/Bios/index.json |  17 ++
 .../Systems/2M220101SL/BootOptions/index.json |  10 +
 .../LogServices/SEL/Entries/1/index.json  |  28 +++
 .../LogServices/SEL/Entries/2/index.json  |  28 +++
 .../LogServices/SEL/Entries/index.json|  64 ++
 .../2M220101SL/LogServices/SEL/index.json |  27 +++
 .../Systems/2M220101SL/LogServices/index.json |  15 ++
 .../2M220101SL/Memory/_backup/1/index.json|  56 +
 .../2M220101SL/Memory/_backup/2/index.json|  46 
 .../2M220101SL/Memory/_backup/3/index.json|  46 
 .../2M220101SL/Memory/_backup/4/index.json|  46 
 .../2M220101SL/Memory/_backup/index.json  |  22 ++
 .../v1/Systems/2M220101SL/Memory/index.json   |  10 +
 .../redfish/v1/Systems/2M220101SL/index.json  |  82 +++
 .../2M220102SL/Bios/Settings/index.json   |  31 +++
 .../v1/Systems/2M220102SL/Bios/index.json | 202 ++
 .../LogServices/SEL/Entries/1/index.json  |  28 +++
 .../LogServices/SEL/Entries/2/index.json  |  28 +++
 .../LogServices/SEL/Entries/index.json|  64 ++
 .../2M220102SL/LogServices/SEL/index.json |  27 +++
 .../Systems/2M220102SL/LogServices/index.json |  15 ++
 .../v1/Systems/2M220102SL/Memory/1/index.json |  56 +
 .../v1/Systems/2M220102SL/Memory/2/index.json |  46 
 .../v1/Systems/2M220102SL/Memory/3/index.json |  46 
 .../v1/Systems/2M220102SL/Memory/4/index.json |  46 
 .../v1/Systems/2M220102SL/Memory/index.json   |  22 ++
 .../redfish/v1/Systems/2M220102SL/index.json  |  76 +++
 .../redfish/v1/Systems/index.json |  10 +-
 .../SimpleOcpServerV1/redfish/v1/index.json   |   7 +-
 41 files changed, 1702 insertions(+), 7 deletions(-)
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Registries/BiosAttributeRegistryUefiKeyword.v1_0_0/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Registries/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220100SL/Bios/Settings/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220100SL/Bios/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220100SL/Memory/1/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220100SL/Memory/2/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220100SL/Memory/3/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220100SL/Memory/4/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220100SL/Memory/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220101SL/Bios/Settings/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220101SL/Bios/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220101SL/BootOptions/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220101SL/LogServices/SEL/Entries/1/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220101SL/LogServices/SEL/Entries/2/index.json
 create mode 100644 
RedfishClientPkg/Tools/Redfish-Profile-Simulator/MockupData/SimpleOcpServerV1/redfish/v1/Systems/2M220101SL/LogServices/SEL/Entries/index.json
 create mode 100644 

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Add Jiewen Yao as OvmfPkg Maintainer

[Ard Biesheuvel]

On Wed, 21 Jul 2021 at 04:22, Yao, Jiewen  wrote:
>
> Reviewed-by: Jiewen Yao 
>

Reviewed-by: Ard Biesheuvel 

Thanks Jiewen!

> > -Original Message-
> > From: Kinney, Michael D 
> > Sent: Wednesday, July 21, 2021 8:44 AM
> > To: devel@edk2.groups.io
> > Cc: Yao, Jiewen ; Ard Biesheuvel
> > ; Justen, Jordan L ;
> > Andrew Fish ; Leif Lindholm 
> > Subject: [Patch 1/1] Maintainers.txt: Add Jiewen Yao as OvmfPkg Maintainer
> >
> > Cc: Jiewen Yao 
> > Cc: Ard Biesheuvel 
> > Cc: Jordan Justen 
> > Cc: Andrew Fish 
> > Cc: Leif Lindholm 
> > Signed-off-by: Michael D Kinney 
> > ---
> >  Maintainers.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index e9dda5c5ca0c..dd9647327774 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -420,6 +420,7 @@ OvmfPkg
> >  F: OvmfPkg/
> >  W: http://www.tianocore.org/ovmf/
> >  M: Ard Biesheuvel 
> > +M: Jiewen Yao 
> >  R: Jordan Justen 
> >  S: Maintained
> >
> > --
> > 2.32.0.windows.1
>


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