Date   

[PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx

Min Xu
 

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 <ardb+tianocore@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
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
+
+ smsw ax
+ test al, 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
+
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
+
+_jumpTo64Bit:
jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
+
BITS 64
jumpTo64BitAndLandHere:

+ ;
+ ; For Td guest we are done and jump to the end
+ ;
+ mov eax, TDX_WORK_AREA
+ cmp dword [eax], 0x47584454 ; 'TDXG'
+ jz GoodCompare
+
;
; Check if the second step of the SEV-ES mitigation is to be performed.
;
diff --git a/OvmfPkg/ResetVector/Ia32/Init32.asm b/OvmfPkg/ResetVector/Ia32/Init32.asm
new file mode 100644
index 000000000000..772adc51e531
--- /dev/null
+++ b/OvmfPkg/ResetVector/Ia32/Init32.asm
@@ -0,0 +1,34 @@
+;------------------------------------------------------------------------------
+; @file
+; 32-bit initialization for Tdx
+;
+; Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+BITS 32
+
+;
+; Modified: EBP
+;
+; @param[in] EBX [6:0] CPU supported GPA width
+; [7:7] 5 level page table support
+; @param[in] ECX [31:0] TDINITVP - Untrusted Configuration
+; @param[in] EDX [31:0] VCPUID
+; @param[in] ESI [31:0] VCPU_Index
+;
+Init32:
+ ;
+ ; Save EBX in EBP because EBX will be changed in ReloadFlat32
+ ;
+ mov ebp, ebx
+
+ OneTimeCall ReloadFlat32
+
+ ;
+ ; Init Tdx
+ ;
+ OneTimeCall InitTdx
+
+ OneTimeCallRet Init32
diff --git a/OvmfPkg/ResetVector/Ia32/InitTdx.asm b/OvmfPkg/ResetVector/Ia32/InitTdx.asm
new file mode 100644
index 000000000000..de8273da6a0c
--- /dev/null
+++ b/OvmfPkg/ResetVector/Ia32/InitTdx.asm
@@ -0,0 +1,57 @@
+;------------------------------------------------------------------------------
+; @file
+; Initialize TDX_WORK_AREA to record the Tdx flag ('TDXG') and other Tdx info
+; so that the following codes can use these information.
+;
+; Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+BITS 32
+
+;
+; Modified: EBP
+;
+InitTdx:
+ ;
+ ; In Td guest, BSP/AP shares the same entry point
+ ; BSP builds up the page table, while APs shouldn't do the same task.
+ ; Instead, APs just leverage the page table which is built by BSP.
+ ; APs will wait until the page table is ready.
+ ; In Td guest, vCPU 0 is treated as the BSP, the others are APs.
+ ; ESI indicates the vCPU ID.
+ ;
+ cmp esi, 0
+ je tdBspEntry
+
+apWait:
+ cmp byte[TDX_WORK_AREA_PGTBL_READY], 0
+ je apWait
+ jmp doneTdxInit
+
+tdBspEntry:
+ ;
+ ; It is of Tdx Guest
+ ; Save the Tdx info in TDX_WORK_AREA so that the following code can use
+ ; these information.
+ ;
+ mov dword [TDX_WORK_AREA], 0x47584454 ; 'TDXG'
+
+ ;
+ ; EBP[6:0] CPU supported GPA width
+ ;
+ and ebp, 0x3f
+ cmp ebp, 52
+ jl NotPageLevel5
+ mov byte[TDX_WORK_AREA_PAGELEVEL5], 1
+
+NotPageLevel5:
+ ;
+ ; ECX[31:0] TDINITVP - Untrusted Configuration
+ ;
+ mov DWORD[TDX_WORK_AREA_INITVP], ecx
+ mov DWORD[TDX_WORK_AREA_INFO], ebp
+
+doneTdxInit:
+ OneTimeCallRet InitTdx
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index 5fae8986d9da..508df6cf5967 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -218,6 +218,24 @@ SevEsDisabled:
;
SetCr3ForPageTables64:

+ ;
+ ; Check Td guest
+ ;
+ cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
+ jnz CheckSev
+
+ xor edx, edx
+
+ ;
+ ; In Td guest, BSP builds the page table and set the flag of
+ ; TDX_WORK_AREA_PGTBL_READY. APs check this flag and then set
+ ; cr3 directly.
+ ;
+ cmp byte[TDX_WORK_AREA_PGTBL_READY], 1
+ jz SetCr3
+ jmp SevNotActive
+
+CheckSev:
OneTimeCall CheckSevFeatures
xor edx, edx
test eax, eax
@@ -277,6 +295,29 @@ pageTableEntriesLoop:
mov [(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], edx
loop pageTableEntriesLoop

+ ;
+ ; If it is Td guest, TdxExtraPageTable should be initialized as well
+ ;
+ cmp dword[TDX_WORK_AREA], 0x47584454 ; 'TDXG'
+ jnz IsSevEs
+
+ xor eax, eax
+ mov ecx, 0x400
+tdClearTdxPageTablesMemoryLoop:
+ mov dword [ecx * 4 + TDX_PT_ADDR (0) - 4], eax
+ loop tdClearTdxPageTablesMemoryLoop
+
+ xor edx, edx
+ ;
+ ; Top level Page Directory Pointers (1 * 256TB entry)
+ ;
+ mov dword[TDX_PT_ADDR (0)], PT_ADDR (0) + PAGE_PDP_ATTR
+ mov dword[TDX_PT_ADDR (4)], edx
+
+ mov byte[TDX_WORK_AREA_PGTBL_READY], 1
+ jmp SetCr3
+
+IsSevEs:
OneTimeCall IsSevEsEnabled
test eax, eax
jz SetCr3
diff --git a/OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm b/OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm
new file mode 100644
index 000000000000..06d44142625a
--- /dev/null
+++ b/OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm
@@ -0,0 +1,44 @@
+;------------------------------------------------------------------------------
+; @file
+; Load the GDT and set the CR0/CR4, then jump to Flat 32 protected mode.
+;
+; Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+%define SEC_DEFAULT_CR0 0x00000023
+%define SEC_DEFAULT_CR4 0x640
+
+BITS 32
+
+;
+; Modified: EAX, EBX, CR0, CR4, DS, ES, FS, GS, SS
+;
+ReloadFlat32:
+
+ cli
+ mov ebx, ADDR_OF(gdtr)
+ lgdt [ebx]
+
+ mov eax, SEC_DEFAULT_CR0
+ mov cr0, eax
+
+ jmp LINEAR_CODE_SEL:dword ADDR_OF(jumpToFlat32BitAndLandHere)
+BITS 32
+jumpToFlat32BitAndLandHere:
+
+ mov eax, SEC_DEFAULT_CR4
+ mov cr4, eax
+
+ debugShowPostCode POSTCODE_32BIT_MODE
+
+ mov ax, LINEAR_SEL
+ mov ds, ax
+ mov es, ax
+ mov fs, ax
+ mov gs, ax
+ mov ss, ax
+
+ OneTimeCallRet ReloadFlat32
+
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb
index b653fe87abd6..3ec163613477 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -106,6 +106,21 @@
%define TDX_EXTRA_PAGE_TABLE_BASE FixedPcdGet32 (PcdOvmfSecGhcbPageTableBase)
%define TDX_EXTRA_PAGE_TABLE_SIZE FixedPcdGet32 (PcdOvmfSecGhcbPageTableSize)

+ ;
+ ; TdMailboxBase [0x10, 0x800] is reserved for OS.
+ ; Td guest initialize piece of this area (TdMailboxBase [0x10,0x20]) to
+ ; record the Td guest info so that this information can be used in the
+ ; following ResetVector flow.
+ ;
+ %define TD_MAILBOX_WORKAREA_OFFSET 0x10
+ %define TDX_WORK_AREA (TDX_MAILBOX_MEMORY_BASE + TD_MAILBOX_WORKAREA_OFFSET)
+ %define TDX_WORK_AREA_PAGELEVEL5 (TDX_WORK_AREA + 4)
+ %define TDX_WORK_AREA_PGTBL_READY (TDX_WORK_AREA + 5)
+ %define TDX_WORK_AREA_INITVP (TDX_WORK_AREA + 8)
+ %define TDX_WORK_AREA_INFO (TDX_WORK_AREA + 8 + 4)
+
+ %define TDX_PT_ADDR(Offset) (TDX_EXTRA_PAGE_TABLE_BASE + (Offset))
+
%define PT_ADDR(Offset) (FixedPcdGet32 (PcdOvmfSecPageTablesBase) + (Offset))

%define GHCB_PT_ADDR (FixedPcdGet32 (PcdOvmfSecGhcbPageTableBase))
@@ -117,6 +132,9 @@
%define SEV_ES_VC_TOP_OF_STACK (FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) + FixedPcdGet32 (PcdOvmfSecPeiTempRamSize))

%include "X64/TdxMetadata.asm"
+ %include "Ia32/Init32.asm"
+ %include "Ia32/InitTdx.asm"
+ %include "Ia32/ReloadFlat32.asm"

%include "Ia32/Flat32ToFlat64.asm"
%include "Ia32/PageTables64.asm"
--
2.29.2.windows.2


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

Min Xu
 

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 <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
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 000000000000..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.<BR>
+; 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:

BITS 32

+%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


[PATCH V2 2/4] OvmfPkg: Add Tdx metadata

Min Xu
 

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

Tdx Metadata describes the information about the image for VMM use.
For example, the base address and length of the TdHob, TdMailbox, etc.
Its offset is put in a GUID-ed structure which is appended in the GUID-ed
chain from a fixed GPA (0xffffffd0). Below are the items in TdxMetadata:
_Bfv:
Boot Firmware Volume
_Cfv:
Configuration Firmware Volume
_Stack:
Initial stack
_Heap:
Initial heap
_MailBox:
TDVF reserves the memory region so each AP can receive the message
sent by the guest OS.
_TdHob:
VMM pass the resource information in TdHob to TDVF.
_TdxPageTable:
If 5-level page table is supported (GPAW is 52), a top level page
directory pointers (1 * 256TB entry) is generated in this page.
_OvmfPageTable:
Initial page table for standard Ovmf.

TDVF indicate above chunk of temporary initialized memory region (_Stack/
_Heap/_MailBox/_TdHob/_TdxPageTables/OvmfPageTable) to support TDVF code
finishing the memory initialization. Because the other unaccepted memory
cannot be accessed until they're accepted.

Since AMD SEV has already defined some SEV specific memory region in
MEMFD. SEV and TDX will not run at the same time. So TDX re-use the
memory region defined by SEV.
- MailBox : PcdOvmfSecGhcbBackupBase|PcdOvmfSecGhcbBackupSize
- TdHob : PcdOvmfSecGhcbBase|PcdOvmfSecGhcbSize
- TdxPageTable : PcdOvmfSecGhcbPageTableBase|PcdOvmfSecGhcbPageTableSize

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 17 ++++
OvmfPkg/ResetVector/ResetVector.inf | 11 ++-
OvmfPkg/ResetVector/ResetVector.nasmb | 47 +++++++++-
OvmfPkg/ResetVector/X64/TdxMetadata.asm | 97 ++++++++++++++++++++
4 files changed, 169 insertions(+), 3 deletions(-)
create mode 100644 OvmfPkg/ResetVector/X64/TdxMetadata.asm

diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
index 9c0b5853a46f..ac86ce69ebe8 100644
--- a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
+++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
@@ -47,6 +47,23 @@ TIMES (15 - ((guidedStructureEnd - guidedStructureStart + 15) % 16)) DB 0
;
guidedStructureStart:

+%ifdef ARCH_X64
+;
+; TDX Metadata offset block
+;
+; If TdxMetadata.asm is included then we need below block which describes
+; the offset of TdxMetadata block in Ovmf image
+;
+; GUID : e47a6535-984a-4798-865e-4685a7bf8ec2
+;
+tdxMetadataOffsetStart:
+ DD (OVMF_IMAGE_SIZE_IN_KB * 1024 - (fourGigabytes - TdxMetadataGuid - 16))
+ DD tdxMetadataOffsetEnd - tdxMetadataOffsetStart
+ DB 0x35, 0x65, 0x7a, 0xe4, 0x4a, 0x98, 0x98, 0x47
+ DB 0x86, 0x5e, 0x46, 0x85, 0xa7, 0xbf, 0x8e, 0xc2
+tdxMetadataOffsetEnd:
+
+%endif
;
; SEV Secret block
;
diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/ResetVector.inf
index dc38f68919cd..fd65c0c9621d 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -1,7 +1,7 @@
## @file
# Reset Vector
#
-# Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -43,6 +43,15 @@
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBackupSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfImageSizeInKb
+ gUefiOvmfPkgTokenSpaceGuid.PcdCfvBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataOffset
+ gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataSize
+ gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase
+ gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataOffset
+ gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataSize

[FixedPcd]
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb
index 5fbacaed5f9d..b653fe87abd6 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -4,6 +4,7 @@
;
; Copyright (c) 2008 - 2013, Intel Corporation. All rights reserved.<BR>
; Copyright (c) 2020, Advanced Micro Devices, Inc. All rights reserved.<BR>
+; Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
; SPDX-License-Identifier: BSD-2-Clause-Patent
;
;------------------------------------------------------------------------------
@@ -67,6 +68,44 @@
%error "This implementation inherently depends on PcdOvmfSecGhcbBase not straddling a 2MB boundary"
%endif

+ ;
+ ; TDX meta data
+ ;
+ %define TDX_METADATA_SECTION_TYPE_BFV 0
+ %define TDX_METADATA_SECTION_TYPE_CFV 1
+ %define TDX_METADATA_SECTION_TYPE_TD_HOB 2
+ %define TDX_METADATA_SECTION_TYPE_TEMP_MEM 3
+ %define TDX_METADATA_VERSION 1
+ %define TDX_METADATA_ATTRIBUTES_EXTENDMR 0x00000001
+
+ %define TDX_BFV_RAW_DATA_OFFSET FixedPcdGet32 (PcdBfvRawDataOffset)
+ %define TDX_BFV_RAW_DATA_SIZE FixedPcdGet32 (PcdBfvRawDataSize)
+ %define TDX_BFV_MEMORY_BASE FixedPcdGet32 (PcdBfvBase)
+ %define TDX_BFV_MEMORY_SIZE FixedPcdGet32 (PcdBfvRawDataSize)
+
+ %define TDX_CFV_RAW_DATA_OFFSET FixedPcdGet32 (PcdCfvRawDataOffset)
+ %define TDX_CFV_RAW_DATA_SIZE FixedPcdGet32 (PcdCfvRawDataSize)
+ %define TDX_CFV_MEMORY_BASE FixedPcdGet32 (PcdCfvBase),
+ %define TDX_CFV_MEMORY_SIZE FixedPcdGet32 (PcdCfvRawDataSize),
+
+ %define TDX_HEAP_MEMORY_BASE FixedPcdGet32 (PcdOvmfSecPeiTempRamBase)
+ %define TDX_HEAP_MEMORY_SIZE FixedPcdGet32 (PcdOvmfSecPeiTempRamSize) / 2
+
+ %define TDX_STACK_MEMORY_BASE (TDX_HEAP_MEMORY_BASE + TDX_HEAP_MEMORY_SIZE)
+ %define TDX_STACK_MEMORY_SIZE FixedPcdGet32 (PcdOvmfSecPeiTempRamSize) / 2
+
+ %define TDX_HOB_MEMORY_BASE FixedPcdGet32 (PcdOvmfSecGhcbBase)
+ %define TDX_HOB_MEMORY_SIZE FixedPcdGet32 (PcdOvmfSecGhcbSize)
+
+ %define TDX_MAILBOX_MEMORY_BASE FixedPcdGet32 (PcdOvmfSecGhcbBackupBase)
+ %define TDX_MAILBOX_MEMORY_SIZE FixedPcdGet32 (PcdOvmfSecGhcbBackupSize)
+
+ %define OVMF_PAGE_TABLE_BASE FixedPcdGet32 (PcdOvmfSecPageTablesBase)
+ %define OVMF_PAGE_TABLE_SIZE FixedPcdGet32 (PcdOvmfSecPageTablesSize)
+
+ %define TDX_EXTRA_PAGE_TABLE_BASE FixedPcdGet32 (PcdOvmfSecGhcbPageTableBase)
+ %define TDX_EXTRA_PAGE_TABLE_SIZE FixedPcdGet32 (PcdOvmfSecGhcbPageTableSize)
+
%define PT_ADDR(Offset) (FixedPcdGet32 (PcdOvmfSecPageTablesBase) + (Offset))

%define GHCB_PT_ADDR (FixedPcdGet32 (PcdOvmfSecGhcbPageTableBase))
@@ -76,8 +115,11 @@
%define SEV_ES_WORK_AREA_RDRAND (FixedPcdGet32 (PcdSevEsWorkAreaBase) + 8)
%define SEV_ES_WORK_AREA_ENC_MASK (FixedPcdGet32 (PcdSevEsWorkAreaBase) + 16)
%define SEV_ES_VC_TOP_OF_STACK (FixedPcdGet32 (PcdOvmfSecPeiTempRamBase) + FixedPcdGet32 (PcdOvmfSecPeiTempRamSize))
-%include "Ia32/Flat32ToFlat64.asm"
-%include "Ia32/PageTables64.asm"
+
+ %include "X64/TdxMetadata.asm"
+
+ %include "Ia32/Flat32ToFlat64.asm"
+ %include "Ia32/PageTables64.asm"
%endif

%include "Ia16/Real16ToFlat32.asm"
@@ -88,5 +130,6 @@
%define SEV_ES_AP_RESET_IP FixedPcdGet32 (PcdSevEsWorkAreaBase)
%define SEV_LAUNCH_SECRET_BASE FixedPcdGet32 (PcdSevLaunchSecretBase)
%define SEV_LAUNCH_SECRET_SIZE FixedPcdGet32 (PcdSevLaunchSecretSize)
+ %define OVMF_IMAGE_SIZE_IN_KB FixedPcdGet32 (PcdOvmfImageSizeInKb)
%include "Ia16/ResetVectorVtf0.asm"

diff --git a/OvmfPkg/ResetVector/X64/TdxMetadata.asm b/OvmfPkg/ResetVector/X64/TdxMetadata.asm
new file mode 100644
index 000000000000..8dba8daa0165
--- /dev/null
+++ b/OvmfPkg/ResetVector/X64/TdxMetadata.asm
@@ -0,0 +1,97 @@
+;------------------------------------------------------------------------------
+; @file
+; Tdx Virtual Firmware metadata
+;
+; Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
+; SPDX-License-Identifier: BSD-2-Clause-Patent
+;
+;------------------------------------------------------------------------------
+
+BITS 64
+
+%define TDX_VIRTUAL_FIRMWARE
+
+ALIGN 16
+TIMES (15 - ((TdxGuidedStructureEnd - TdxGuidedStructureStart + 15) % 16)) DB 0
+
+TdxGuidedStructureStart:
+
+;
+; TDVF meta data
+;
+TdxMetadataGuid:
+ DB 0xf3, 0xf9, 0xea, 0xe9, 0x8e, 0x16, 0xd5, 0x44
+ DB 0xa8, 0xeb, 0x7f, 0x4d, 0x87, 0x38, 0xf6, 0xae
+
+_Descriptor:
+ DB 'T','D','V','F' ; Signature
+ DD TdxGuidedStructureEnd - _Descriptor ; Length
+ DD TDX_METADATA_VERSION ; Version
+ DD (TdxGuidedStructureEnd - _Descriptor - 16)/32 ; Number of sections
+
+_Bfv:
+ DD TDX_BFV_RAW_DATA_OFFSET
+ DD TDX_BFV_RAW_DATA_SIZE
+ DQ TDX_BFV_MEMORY_BASE
+ DQ TDX_BFV_MEMORY_SIZE
+ DD TDX_METADATA_SECTION_TYPE_BFV
+ DD TDX_METADATA_ATTRIBUTES_EXTENDMR
+
+_Cfv:
+ DD TDX_CFV_RAW_DATA_OFFSET
+ DD TDX_CFV_RAW_DATA_SIZE
+ DQ TDX_CFV_MEMORY_BASE
+ DQ TDX_CFV_MEMORY_SIZE
+ DD TDX_METADATA_SECTION_TYPE_CFV
+ DD 0
+
+_Stack:
+ DD 0
+ DD 0
+ DQ TDX_STACK_MEMORY_BASE
+ DQ TDX_STACK_MEMORY_SIZE
+ DD TDX_METADATA_SECTION_TYPE_TEMP_MEM
+ DD 0
+
+_Heap:
+ DD 0
+ DD 0
+ DQ TDX_HEAP_MEMORY_BASE
+ DQ TDX_HEAP_MEMORY_SIZE
+ DD TDX_METADATA_SECTION_TYPE_TEMP_MEM
+ DD 0
+
+_MailBox:
+ DD 0
+ DD 0
+ DQ TDX_MAILBOX_MEMORY_BASE
+ DQ TDX_MAILBOX_MEMORY_SIZE
+ DD TDX_METADATA_SECTION_TYPE_TEMP_MEM
+ DD 0
+
+_TdHob:
+ DD 0
+ DD 0
+ DQ TDX_HOB_MEMORY_BASE
+ DQ TDX_HOB_MEMORY_SIZE
+ DD TDX_METADATA_SECTION_TYPE_TD_HOB
+ DD 0
+
+_TdxPageTable:
+ DD 0
+ DD 0
+ DQ TDX_EXTRA_PAGE_TABLE_BASE
+ DQ TDX_EXTRA_PAGE_TABLE_SIZE
+ DD TDX_METADATA_SECTION_TYPE_TEMP_MEM
+ DD 0
+
+_OvmfPageTable:
+ DD 0
+ DD 0
+ DQ OVMF_PAGE_TABLE_BASE
+ DQ OVMF_PAGE_TABLE_SIZE
+ DD TDX_METADATA_SECTION_TYPE_TEMP_MEM
+ DD 0
+
+TdxGuidedStructureEnd:
+ALIGN 16
--
2.29.2.windows.2


[PATCH V2 0/4] Add Intel TDX support in OvmfPkg/ResetVector

Min Xu
 

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

Intel's Trust Domain Extensions (Intel TDX) refers to an Intel technology
that extends Virtual Machines Extensions (VMX) and Multi-Key Total Memory
Encryption (MKTME) with a new kind of virutal machines guest called a
Trust Domain (TD). A TD is desinged to run in a CPU mode that protects the
confidentiality of TD memory contents and the TD's CPU state from other
software, including the hosting Virtual-Machine Monitor (VMM), unless
explicitly shared by the TD itself.

The patch-sets to support Intel TDX in OvmfPkg is split into several
waves. This is wave1 which adds Intel TDX support in OvmfPkg/ResetVector.
Note: TDX only works in X64.

Patch 1 add the PCDs of BFV/CFV. BFV is the code part of the image. CFV is
the configuration part. BFV is measured by VMM and CFV is measured by TDVF
itself.

Patch 2 add TdxMetadata in OvmfPkg/ResetVector. It describes the
information about the image so that VMM can do the initialization and
measurement based on these information.

Patch 3 updates the UefiCpuPkg/Vtf0/Main.asm to add Main32 entrypoint. It
is because on reset all the CPUs are in 32-bit protected mode. In the
Main32 entry point, Init32 is called to do the 32-bit initializaiton. In
UefiCpuPkg/ResetVector/Vtf0/Ia32, Init32.asm is added. It is a null stub
of the 32-bit initialization. The actual work is implemented in OvmfPkg.

In Patch 4, InitTdx.asm does the tdx initialization, ReloadFlat32 loads
the GDT and sets the CR0, then jump to 32-bit protected mode. Init32.asm
put above 2 together to complete the 32-bit initializaiton. After that
page tables are built and set, then jump to SecEntry.

[TDX]: https://software.intel.com/content/dam/develop/external/us/en/
documents/tdx-whitepaper-final9-17.pdf

[TDVF]: https://software.intel.com/content/dam/develop/external/us/en/
documents/tdx-virtual-firmware-design-guide-rev-1.pdf

Code is at https://github.com/mxu9/edk2/tree/tdvf_wave1.v2

v2 changes:
- Move InitTdx.asm and ReloadFlat32.asm from UefiCpuPkg/ResetVector/Vtf0
to OvmfPkg/ResetVector. Init32.asm is created which is a null stub of
32-bit initialization. In Main32 just simply call Init32. It makes
the Main.asm in UefiCpuPkg/ResetVector clean and clear.
- Init32.asm/InitTdx.asm/ReloadFlat32.asm are created under
OvmfPkg/ResetVector/Ia32.
- Update some descriptions of the patch-sets.
- Update the REF link in cover letter.
- Add Ard Biesheuvel in Cc list.

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

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
CC: Debkumar De <debkumar.de@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>

Min Xu (4):
OvmfPkg: Add Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb
OvmfPkg: Add Tdx metadata
UefiCpuPkg/ResetVector: Add Main32 entry point in Main.asm
OvmfPkg/ResetVector: Update ResetVector to support Tdx

OvmfPkg/OvmfPkg.dec | 13 +++
OvmfPkg/OvmfPkgDefines.fdf.inc | 12 ++-
OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 38 ++++++++
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.inf | 11 ++-
OvmfPkg/ResetVector/ResetVector.nasmb | 65 ++++++++++++-
OvmfPkg/ResetVector/X64/TdxMetadata.asm | 97 ++++++++++++++++++++
UefiCpuPkg/ResetVector/Vtf0/Ia32/Init32.asm | 13 +++
UefiCpuPkg/ResetVector/Vtf0/Main.asm | 14 +++
UefiCpuPkg/ResetVector/Vtf0/Vtf0.nasmb | 2 +-
14 files changed, 483 insertions(+), 5 deletions(-)
create mode 100644 OvmfPkg/ResetVector/Ia32/Init32.asm
create mode 100644 OvmfPkg/ResetVector/Ia32/InitTdx.asm
create mode 100644 OvmfPkg/ResetVector/Ia32/ReloadFlat32.asm
create mode 100644 OvmfPkg/ResetVector/X64/TdxMetadata.asm
create mode 100644 UefiCpuPkg/ResetVector/Vtf0/Ia32/Init32.asm

--
2.29.2.windows.2


[PATCH V2 1/4] OvmfPkg: Add Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb

Min Xu
 

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

Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known
as the Boot Firmware Volume (BFV). The FV format is defined in the
UEFI Platform Initialization (PI) spec. BFV includes all TDVF components
required during boot.

TDVF also include a configuration firmware volume (CFV) that is separated
from the BFV. The reason is because the CFV is measured in RTMR, while
the BFV is measured in MRTD.

In practice BFV is the code part of Ovmf image. CFV is the vars part of
Ovmf image (exclude the SPARE part).

PcdOvmfImageSizeInKb is added which is used to calculate the offset
of TdxMetadata in ResetVectorVtf0.asm.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
OvmfPkg/OvmfPkg.dec | 13 +++++++++++++
OvmfPkg/OvmfPkgDefines.fdf.inc | 12 +++++++++++-
2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 6ae733f6e39f..6d9bb91e9274 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -321,6 +321,19 @@
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|0x0|UINT32|0x42
gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize|0x0|UINT32|0x43

+ ## The base address and size of the TDX Cfv base and size.
+ gUefiOvmfPkgTokenSpaceGuid.PcdCfvBase|0|UINT32|0x47
+ gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataOffset|0|UINT32|0x48
+ gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataSize|0|UINT32|0x49
+
+ ## The base address and size of the TDX Bfv base and size.
+ gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase|0|UINT32|0x4a
+ gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataOffset|0|UINT32|0x4b
+ gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataSize|0|UINT32|0x4c
+
+ ## Size of the Ovmf image in KB
+ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfImageSizeInKb|0|UINT32|0x4d
+
[PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/OvmfPkgDefines.fdf.inc b/OvmfPkg/OvmfPkgDefines.fdf.inc
index 35fd454b97ab..401e491e4cbe 100644
--- a/OvmfPkg/OvmfPkgDefines.fdf.inc
+++ b/OvmfPkg/OvmfPkgDefines.fdf.inc
@@ -2,13 +2,14 @@
# FDF include file that defines the main macros and sets the dependent PCDs.
#
# Copyright (C) 2014, Red Hat, Inc.
-# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##

DEFINE BLOCK_SIZE = 0x1000
+DEFINE VARS_OFFSET = 0

#
# A firmware binary built with FD_SIZE_IN_KB=1024, and a firmware binary built
@@ -66,6 +67,7 @@ DEFINE SECFV_OFFSET = 0x003CC000
DEFINE SECFV_SIZE = 0x34000
!endif

+SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfImageSizeInKb = $(FD_SIZE_IN_KB)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize = $(FW_SIZE)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE)
@@ -82,6 +84,14 @@ SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize = $(BLOCK_SIZ
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize = $(VARS_SPARE_SIZE)

+SET gUefiOvmfPkgTokenSpaceGuid.PcdCfvBase = $(FW_BASE_ADDRESS)
+SET gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataOffset = $(VARS_OFFSET)
+SET gUefiOvmfPkgTokenSpaceGuid.PcdCfvRawDataSize = $(VARS_LIVE_SIZE)
+
+SET gUefiOvmfPkgTokenSpaceGuid.PcdBfvBase = $(CODE_BASE_ADDRESS)
+SET gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataOffset = $(VARS_SIZE)
+SET gUefiOvmfPkgTokenSpaceGuid.PcdBfvRawDataSize = $(CODE_SIZE)
+
!if $(SMM_REQUIRE) == TRUE
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64 = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase
--
2.29.2.windows.2


Re: [Patch V2 3/3] Maintainers.txt: Add GitHub IDs

Andrew Fish
 

Reviewed-by: Andrew Fish <afish@apple.com>

On Jul 8, 2021, at 12:50 PM, Michael D Kinney <michael.d.kinney@intel.com> wrote:

Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
---
Maintainers.txt | 282 ++++++++++++++++++++++++------------------------
1 file changed, 139 insertions(+), 143 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index f4e4c72d0628..575a80be5e89 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -68,10 +68,9 @@ F: */
Tianocore Stewards
------------------
F: *
-M: Andrew Fish <afish@apple.com>
-M: Laszlo Ersek <lersek@redhat.com>
-M: Leif Lindholm <leif@nuviainc.com>
-M: Michael D Kinney <michael.d.kinney@intel.com>
+M: Andrew Fish <afish@apple.com> [ajfish]
+M: Leif Lindholm <leif@nuviainc.com> [leiflindholm]
+M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]

Responsible Disclosure, Reporting Security Issues
-------------------------------------------------
@@ -80,73 +79,72 @@ W: https://github.com/tianocore/tianocore.github.io/wiki/Security
EDK II Releases:
----------------
W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
-M: Liming Gao <gaoliming@byosoft.com.cn>
+M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]

UEFI Shell Binaries (ShellBinPkg.zip) from EDK II Releases:
-----------------------------------------------------------
W: https://github.com/tianocore/edk2/releases/
-M: Ray Ni <ray.ni@intel.com> (Ia32/X64)
-M: Zhichao Gao <zhichao.gao@intel.com> (Ia32/X64)
-M: Leif Lindholm <leif@nuviainc.com> (ARM/AArch64)
-M: Ard Biesheuvel <ardb+tianocore@kernel.org> (ARM/AArch64)
+M: Ray Ni <ray.ni@intel.com> [niruiyu] (Ia32/X64)
+M: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao] (Ia32/X64)
+M: Leif Lindholm <leif@nuviainc.com> [leiflindholm] (ARM/AArch64)
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel] (ARM/AArch64)

EDK II Architectures:
---------------------
ARM, AARCH64
F: */AArch64/
F: */Arm/
-M: Leif Lindholm <leif@nuviainc.com>
-M: Ard Biesheuvel <ardb+tianocore@kernel.org>
+M: Leif Lindholm <leif@nuviainc.com> [leiflindholm]
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]

RISCV64
F: */RiscV64/
-M: Abner Chang <abner.chang@hpe.com>
+M: Abner Chang <abner.chang@hpe.com> [changab]
R: Daniel Schaefer <daniel.schaefer@hpe.com>

EDK II Continuous Integration:
------------------------------
.azurepipelines/
F: .azurepipelines/
-M: Sean Brogan <sean.brogan@microsoft.com>
-M: Bret Barkelew <Bret.Barkelew@microsoft.com>
-R: Michael D Kinney <michael.d.kinney@intel.com>
-R: Liming Gao <gaoliming@byosoft.com.cn>
+M: Sean Brogan <sean.brogan@microsoft.com> [spbrogan]
+M: Bret Barkelew <Bret.Barkelew@microsoft.com> [corthon]
+R: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
+R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]

.mergify/
F: .mergify/
-M: Michael D Kinney <michael.d.kinney@intel.com>
-M: Liming Gao <gaoliming@byosoft.com.cn>
-R: Sean Brogan <sean.brogan@microsoft.com>
-R: Bret Barkelew <Bret.Barkelew@microsoft.com>
+M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
+M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
+R: Sean Brogan <sean.brogan@microsoft.com> [spbrogan]
+R: Bret Barkelew <Bret.Barkelew@microsoft.com> [corthon]

.pytool/
F: .pytool/
-M: Sean Brogan <sean.brogan@microsoft.com>
-M: Bret Barkelew <Bret.Barkelew@microsoft.com>
-R: Michael D Kinney <michael.d.kinney@intel.com>
-R: Liming Gao <gaoliming@byosoft.com.cn>
+M: Sean Brogan <sean.brogan@microsoft.com> [spbrogan]
+M: Bret Barkelew <Bret.Barkelew@microsoft.com> [corthon]
+R: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
+R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]

EDK II Packages:
----------------
ArmPkg
F: ArmPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg
-M: Leif Lindholm <leif@nuviainc.com>
-M: Ard Biesheuvel <ardb+tianocore@kernel.org>
+M: Leif Lindholm <leif@nuviainc.com> [leiflindholm]
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]

ArmPlatformPkg
F: ArmPlatformPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/ArmPlatformPkg
-M: Leif Lindholm <leif@nuviainc.com>
-M: Ard Biesheuvel <ardb+tianocore@kernel.org>
+M: Leif Lindholm <leif@nuviainc.com> [leiflindholm]
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]

ArmVirtPkg
F: ArmVirtPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/ArmVirtPkg
-M: Laszlo Ersek <lersek@redhat.com>
-M: Ard Biesheuvel <ardb+tianocore@kernel.org>
-R: Leif Lindholm <leif@nuviainc.com>
-R: Sami Mujawar <sami.mujawar@arm.com>
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
+R: Leif Lindholm <leif@nuviainc.com> [leiflindholm]
+R: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]

ArmVirtPkg: modules used on Xen
F: ArmVirtPkg/ArmVirtXen.*
@@ -161,78 +159,78 @@ R: Julien Grall <julien@xen.org>
BaseTools
F: BaseTools/
W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
-M: Bob Feng <bob.c.feng@intel.com>
-M: Liming Gao <gaoliming@byosoft.com.cn>
-R: Yuwei Chen <yuwei.chen@intel.com>
+M: Bob Feng <bob.c.feng@intel.com> [BobCF]
+M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
+R: Yuwei Chen <yuwei.chen@intel.com> [YuweiChen1110]

CryptoPkg
F: CryptoPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
-M: Jiewen Yao <jiewen.yao@intel.com>
-M: Jian J Wang <jian.j.wang@intel.com>
-R: Xiaoyu Lu <xiaoyux.lu@intel.com>
-R: Guomin Jiang <guomin.jiang@intel.com>
+M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
+M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
+R: Xiaoyu Lu <xiaoyux.lu@intel.com> [xiaoyuxlu]
+R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]

DynamicTablesPkg
F: DynamicTablesPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/DynamicTablesPkg
-M: Sami Mujawar <Sami.Mujawar@arm.com>
-M: Alexei Fedorov <Alexei.Fedorov@arm.com>
+M: Sami Mujawar <Sami.Mujawar@arm.com> [samimujawar]
+M: Alexei Fedorov <Alexei.Fedorov@arm.com> [AlexeiFedorov]

EmbeddedPkg
F: EmbeddedPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
-M: Leif Lindholm <leif@nuviainc.com>
-M: Ard Biesheuvel <ardb+tianocore@kernel.org>
+M: Leif Lindholm <leif@nuviainc.com> [leiflindholm]
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]

EmulatorPkg
F: EmulatorPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/EmulatorPkg
-M: Andrew Fish <afish@apple.com>
-M: Ray Ni <ray.ni@intel.com>
+M: Andrew Fish <afish@apple.com> [ajfish]
+M: Ray Ni <ray.ni@intel.com> [niruiyu]
S: Maintained

FatPkg
F: FatPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/Edk2-fat-driver
-M: Ray Ni <ray.ni@intel.com>
+M: Ray Ni <ray.ni@intel.com> [niruiyu]
T: svn - https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/EnhancedFat
T: git - https://github.com/tianocore/edk2-FatPkg.git

FmpDevicePkg
F: FmpDevicePkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
-M: Liming Gao <gaoliming@byosoft.com.cn>
-M: Michael D Kinney <michael.d.kinney@intel.com>
-R: Guomin Jiang <guomin.jiang@intel.com>
-R: Wei6 Xu <wei6.xu@intel.com>
+M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
+M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
+R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]
+R: Wei6 Xu <wei6.xu@intel.com> [xuweiintel]

IntelFsp2Pkg
F: IntelFsp2Pkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
-M: Chasel Chiu <chasel.chiu@intel.com>
-R: Nate DeSimone <nathaniel.l.desimone@intel.com>
-R: Star Zeng <star.zeng@intel.com>
+M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
+R: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
+R: Star Zeng <star.zeng@intel.com> [lzeng14]

IntelFsp2WrapperPkg
F: IntelFsp2WrapperPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2WrapperPkg
-M: Chasel Chiu <chasel.chiu@intel.com>
-R: Nate DeSimone <nathaniel.l.desimone@intel.com>
-R: Star Zeng <star.zeng@intel.com>
+M: Chasel Chiu <chasel.chiu@intel.com> [ChaselChiu]
+R: Nate DeSimone <nathaniel.l.desimone@intel.com> [nate-desimone]
+R: Star Zeng <star.zeng@intel.com> [lzeng14]

MdeModulePkg
F: MdeModulePkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
-M: Jian J Wang <jian.j.wang@intel.com>
-M: Hao A Wu <hao.a.wu@intel.com>
+M: Jian J Wang <jian.j.wang@intel.com> [jwang36]
+M: Hao A Wu <hao.a.wu@intel.com> [hwu25]

MdeModulePkg: ACPI modules
F: MdeModulePkg/Include/*Acpi*.h
F: MdeModulePkg/Universal/Acpi/
-R: Zhiguang Liu <zhiguang.liu@intel.com>
-R: Dandan Bi <dandan.bi@intel.com>
-R: Liming Gao <gaoliming@byosoft.com.cn>
+R: Zhiguang Liu <zhiguang.liu@intel.com> [LiuZhiguang001]
+R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
+R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]

MdeModulePkg: ACPI modules related to S3
F: MdeModulePkg/*LockBox*/
@@ -240,8 +238,8 @@ F: MdeModulePkg/Include/*BootScript*.h
F: MdeModulePkg/Include/*LockBox*.h
F: MdeModulePkg/Include/*S3*.h
F: MdeModulePkg/Library/*S3*/
-R: Hao A Wu <hao.a.wu@intel.com>
-R: Eric Dong <eric.dong@intel.com>
+R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
+R: Eric Dong <eric.dong@intel.com> [ydong10]

MdeModulePkg: BDS modules
F: MdeModulePkg/*BootManager*/
@@ -251,8 +249,8 @@ F: MdeModulePkg/Universal/DevicePathDxe/
F: MdeModulePkg/Universal/DriverHealthManagerDxe/
F: MdeModulePkg/Universal/LoadFileOnFv2/
F: MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.*
-R: Zhichao Gao <zhichao.gao@intel.com>
-R: Ray Ni <ray.ni@intel.com>
+R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]

MdeModulePkg: Console and Graphics modules
F: MdeModulePkg/*Logo*/
@@ -266,8 +264,8 @@ F: MdeModulePkg/Include/Library/FrameBufferBltLib.h
F: MdeModulePkg/Library/BaseBmpSupportLib/
F: MdeModulePkg/Library/FrameBufferBltLib/
F: MdeModulePkg/Universal/Console/
-R: Zhichao Gao <zhichao.gao@intel.com>
-R: Ray Ni <ray.ni@intel.com>
+R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]

MdeModulePkg: Core services (PEI, DXE and Runtime) modules
F: MdeModulePkg/*Mem*/
@@ -293,8 +291,8 @@ F: MdeModulePkg/Library/DxeSecurityManagementLib/
F: MdeModulePkg/Universal/PCD/
F: MdeModulePkg/Universal/PlatformDriOverrideDxe/
F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c
-R: Dandan Bi <dandan.bi@intel.com>
-R: Liming Gao <gaoliming@byosoft.com.cn>
+R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
+R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]

MdeModulePkg: Device and Peripheral modules
F: MdeModulePkg/*PciHostBridge*/
@@ -313,14 +311,14 @@ F: MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
F: MdeModulePkg/Include/Protocol/Ps2Policy.h
F: MdeModulePkg/Library/NonDiscoverableDeviceRegistrationLib/
F: MdeModulePkg/Universal/PcatSingleSegmentPciCfg2Pei/
-R: Hao A Wu <hao.a.wu@intel.com>
-R: Ray Ni <ray.ni@intel.com>
+R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]

MdeModulePkg: Disk modules
F: MdeModulePkg/Universal/Disk/
-R: Hao A Wu <hao.a.wu@intel.com>
-R: Ray Ni <ray.ni@intel.com>
-R: Zhichao Gao <zhichao.gao@intel.com>
+R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]
+R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]

MdeModulePkg: Firmware Update modules
F: MdeModulePkg/*Capsule*/
@@ -332,9 +330,9 @@ F: MdeModulePkg/Include/Protocol/FirmwareManagementProgress.h
F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
F: MdeModulePkg/Library/FmpAuthenticationLibNull/
F: MdeModulePkg/Universal/Esrt*/
-R: Hao A Wu <hao.a.wu@intel.com>
-R: Liming Gao <gaoliming@byosoft.com.cn>
-R: Guomin Jiang <guomin.jiang@intel.com>
+R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
+R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
+R: Guomin Jiang <guomin.jiang@intel.com> [guominjia]

MdeModulePkg: HII and UI modules
F: MdeModulePkg/*FileExplorer*/
@@ -350,44 +348,44 @@ F: MdeModulePkg/Library/CustomizedDisplayLib/
F: MdeModulePkg/Universal/DisplayEngineDxe/
F: MdeModulePkg/Universal/DriverSampleDxe/
F: MdeModulePkg/Universal/SetupBrowserDxe/
-R: Dandan Bi <dandan.bi@intel.com>
-R: Eric Dong <eric.dong@intel.com>
+R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
+R: Eric Dong <eric.dong@intel.com> [ydong10]

MdeModulePkg: Management Mode (MM, SMM) modules
F: MdeModulePkg/*Smi*/
F: MdeModulePkg/*Smm*/
F: MdeModulePkg/Include/*Smi*.h
F: MdeModulePkg/Include/*Smm*.h
-R: Eric Dong <eric.dong@intel.com>
-R: Ray Ni <ray.ni@intel.com>
+R: Eric Dong <eric.dong@intel.com> [ydong10]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]

MdeModulePkg: Pei Core
F: MdeModulePkg/Core/Pei/
-R: Dandan Bi <dandan.bi@intel.com>
-R: Liming Gao <gaoliming@byosoft.com.cn>
+R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
+R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
R: Debkumar De <debkumar.de@intel.com>
R: Harry Han <harry.han@intel.com>
-R: Catharine West <catharine.west@intel.com>
+R: Catharine West <catharine.west@intel.com> [catharine-intl]

MdeModulePkg: Reset modules
F: MdeModulePkg/*Reset*/
F: MdeModulePkg/Include/*Reset*.h
-R: Zhichao Gao <zhichao.gao@intel.com>
-R: Ray Ni <ray.ni@intel.com>
+R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]

MdeModulePkg: Serial modules
F: MdeModulePkg/*Serial*/
F: MdeModulePkg/Include/*SerialPort*.h
-R: Hao A Wu <hao.a.wu@intel.com>
-R: Ray Ni <ray.ni@intel.com>
-R: Zhichao Gao <zhichao.gao@intel.com>
+R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]
+R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]

MdeModulePkg: SMBIOS modules
F: MdeModulePkg/Universal/Smbios*/
-R: Zhiguang Liu <zhiguang.liu@intel.com>
-R: Dandan Bi <dandan.bi@intel.com>
-R: Star Zeng <star.zeng@intel.com>
-R: Zhichao Gao <zhichao.gao@intel.com>
+R: Zhiguang Liu <zhiguang.liu@intel.com> [LiuZhiguang001]
+R: Dandan Bi <dandan.bi@intel.com> [dandanbi]
+R: Star Zeng <star.zeng@intel.com> [lzeng14]
+R: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]

MdeModulePkg: UEFI Variable modules
F: MdeModulePkg/*Var*/
@@ -396,34 +394,33 @@ F: MdeModulePkg/Include/*/*Var*.h
F: MdeModulePkg/Include/Guid/SystemNvDataGuid.h
F: MdeModulePkg/Include/Protocol/SwapAddressRange.h
F: MdeModulePkg/Universal/FaultTolerantWrite*/
-R: Hao A Wu <hao.a.wu@intel.com>
-R: Liming Gao <gaoliming@byosoft.com.cn>
+R: Hao A Wu <hao.a.wu@intel.com> [hwu25]
+R: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]

MdeModulePkg: Universal Payload definitions
F: MdeModulePkg/Include/UniversalPayload/
-R: Zhiguang Liu <zhiguang.liu@intel.com>
-R: Ray Ni <ray.ni@intel.com>
+R: Zhiguang Liu <zhiguang.liu@intel.com> [LiuZhiguang001]
+R: Ray Ni <ray.ni@intel.com> [niruiyu]

MdePkg
F: MdePkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
-M: Michael D Kinney <michael.d.kinney@intel.com>
-M: Liming Gao <gaoliming@byosoft.com.cn>
-R: Zhiguang Liu <zhiguang.liu@intel.com>
+M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
+M: Liming Gao <gaoliming@byosoft.com.cn> [lgao4]
+R: Zhiguang Liu <zhiguang.liu@intel.com> [LiuZhiguang001]

NetworkPkg
F: NetworkPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg
-M: Maciej Rabeda <maciej.rabeda@linux.intel.com>
-R: Jiaxin Wu <jiaxin.wu@intel.com>
-R: Siyuan Fu <siyuan.fu@intel.com>
+M: Maciej Rabeda <maciej.rabeda@linux.intel.com> [mrabeda]
+R: Jiaxin Wu <jiaxin.wu@intel.com> [jiaxinwu]
+R: Siyuan Fu <siyuan.fu@intel.com> [sfu5]

OvmfPkg
F: OvmfPkg/
W: http://www.tianocore.org/ovmf/
-M: Laszlo Ersek <lersek@redhat.com>
-M: Ard Biesheuvel <ardb+tianocore@kernel.org>
-R: Jordan Justen <jordan.l.justen@intel.com>
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
+R: Jordan Justen <jordan.l.justen@intel.com> [jljusten]
S: Maintained

OvmfPkg: bhyve-related modules
@@ -437,12 +434,12 @@ F: OvmfPkg/Library/PciHostBridgeLibScan/
F: OvmfPkg/Library/PlatformBootManagerLibBhyve/
F: OvmfPkg/Library/ResetSystemLib/BaseResetShutdownBhyve.c
F: OvmfPkg/Library/ResetSystemLib/BaseResetSystemLibBhyve.inf
-R: Rebecca Cran <rebecca@bsdio.com>
-R: Peter Grehan <grehan@freebsd.org>
+R: Rebecca Cran <rebecca@bsdio.com> [bcran]
+R: Peter Grehan <grehan@freebsd.org> [grehan-freebsd]

OvmfPkg: CSM modules
F: OvmfPkg/Csm/
-R: David Woodhouse <dwmw2@infradead.org>
+R: David Woodhouse <dwmw2@infradead.org> [dwmw2]

OvmfPkg: Confidential Computing
F: OvmfPkg/AmdSev/
@@ -456,12 +453,12 @@ F: OvmfPkg/Library/VmgExitLib/
F: OvmfPkg/PlatformPei/AmdSev.c
F: OvmfPkg/ResetVector/
F: OvmfPkg/Sec/
-R: Brijesh Singh <brijesh.singh@amd.com>
+R: Brijesh Singh <brijesh.singh@amd.com> [codomania]
R: Erdem Aktas <erdemaktas@google.com>
-R: James Bottomley <jejb@linux.ibm.com>
-R: Jiewen Yao <jiewen.yao@intel.com>
-R: Min Xu <min.m.xu@intel.com>
-R: Tom Lendacky <thomas.lendacky@amd.com>
+R: James Bottomley <jejb@linux.ibm.com> [jejb]
+R: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
+R: Min Xu <min.m.xu@intel.com> [mxu9]
+R: Tom Lendacky <thomas.lendacky@amd.com> [tlendacky]

OvmfPkg: LsiScsi driver
F: OvmfPkg/LsiScsiDxe/
@@ -509,86 +506,85 @@ F: OvmfPkg/XenPlatformPei/
F: OvmfPkg/XenPvBlkDxe/
F: OvmfPkg/XenResetVector/
F: OvmfPkg/XenTimerDxe/
-R: Anthony Perard <anthony.perard@citrix.com>
+R: Anthony Perard <anthony.perard@citrix.com> [sheep]
R: Julien Grall <julien@xen.org>

PcAtChipsetPkg
F: PcAtChipsetPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg
-M: Ray Ni <ray.ni@intel.com>
+M: Ray Ni <ray.ni@intel.com> [niruiyu]

RedfishPkg: Redfish related modules
F: RedfishPkg/
-M: Abner Chang <abner.chang@hpe.com>
-R: Nickle Wang <nickle.wang@hpe.com>
+M: Abner Chang <abner.chang@hpe.com> [changab]
+R: Nickle Wang <nickle.wang@hpe.com> [nicklela]

SecurityPkg
F: SecurityPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/SecurityPkg
-M: Jiewen Yao <jiewen.yao@intel.com>
-M: Jian J Wang <jian.j.wang@intel.com>
+M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
+M: Jian J Wang <jian.j.wang@intel.com> [jwang36]

SecurityPkg: Secure boot related modules
F: SecurityPkg/Library/DxeImageVerificationLib/
F: SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/
F: SecurityPkg/Library/AuthVariableLib/
-R: Min Xu <min.m.xu@intel.com>
+R: Min Xu <min.m.xu@intel.com> [mxu9]

SecurityPkg: Tcg related modules
F: SecurityPkg/Tcg/
-R: Qi Zhang <qi1.zhang@intel.com>
-R: Rahul Kumar <rahul1.kumar@intel.com>
+R: Qi Zhang <qi1.zhang@intel.com> [qizhangz]
+R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]

ShellPkg
F: ShellPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg
-M: Ray Ni <ray.ni@intel.com>
-M: Zhichao Gao <zhichao.gao@intel.com>
+M: Ray Ni <ray.ni@intel.com> [niruiyu]
+M: Zhichao Gao <zhichao.gao@intel.com> [ZhichaoGao]

SignedCapsulePkg
F: SignedCapsulePkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/SignedCapsulePkg
-M: Jian J Wang <jian.j.wang@intel.com>
+M: Jian J Wang <jian.j.wang@intel.com> [jwang36]

SourceLevelDebugPkg
F: SourceLevelDebugPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/SourceLevelDebugPkg
-M: Hao A Wu <hao.a.wu@intel.com>
+M: Hao A Wu <hao.a.wu@intel.com> [hwu25]

StandaloneMmPkg
F: StandaloneMmPkg/
-M: Ard Biesheuvel <ardb+tianocore@kernel.org>
-M: Sami Mujawar <sami.mujawar@arm.com>
-M: Jiewen Yao <jiewen.yao@intel.com>
-R: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
+M: Ard Biesheuvel <ardb+tianocore@kernel.org> [ardbiesheuvel]
+M: Sami Mujawar <sami.mujawar@arm.com> [samimujawar]
+M: Jiewen Yao <jiewen.yao@intel.com> [jyao1]
+R: Supreeth Venkatesh <supreeth.venkatesh@arm.com> [supven01]

UefiCpuPkg
F: UefiCpuPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/UefiCpuPkg
-M: Eric Dong <eric.dong@intel.com>
-M: Ray Ni <ray.ni@intel.com>
-R: Laszlo Ersek <lersek@redhat.com>
-R: Rahul Kumar <rahul1.kumar@intel.com>
+M: Eric Dong <eric.dong@intel.com> [ydong10]
+M: Ray Ni <ray.ni@intel.com> [niruiyu]
+R: Rahul Kumar <rahul1.kumar@intel.com> [rahul1-kumar]

UefiCpuPkg: Sec related modules
F: UefiCpuPkg/SecCore/
F: UefiCpuPkg/ResetVector/
R: Debkumar De <debkumar.de@intel.com>
R: Harry Han <harry.han@intel.com>
-R: Catharine West <catharine.west@intel.com>
+R: Catharine West <catharine.west@intel.com> [catharine-intl]

UefiPayloadPkg
F: UefiPayloadPkg/
W: https://github.com/tianocore/tianocore.github.io/wiki/UefiPayloadPkg
-M: Guo Dong <guo.dong@intel.com>
-M: Ray Ni <ray.ni@intel.com>
-R: Maurice Ma <maurice.ma@intel.com>
-R: Benjamin You <benjamin.you@intel.com>
+M: Guo Dong <guo.dong@intel.com> [gdong1]
+M: Ray Ni <ray.ni@intel.com> [niruiyu]
+R: Maurice Ma <maurice.ma@intel.com> [mauricema]
+R: Benjamin You <benjamin.you@intel.com> [BenjaminYou]
S: Maintained

UnitTestFrameworkPkg
F: UnitTestFrameworkPkg/
-M: Michael D Kinney <michael.d.kinney@intel.com>
-R: Sean Brogan <sean.brogan@microsoft.com>
-R: Bret Barkelew <Bret.Barkelew@microsoft.com>
+M: Michael D Kinney <michael.d.kinney@intel.com> [mdkinney]
+R: Sean Brogan <sean.brogan@microsoft.com> [spbrogan]
+R: Bret Barkelew <Bret.Barkelew@microsoft.com> [corthon]
S: Maintained
--
2.32.0.windows.1


Re: [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload

Cheng-Chieh Huang <chengchieh@...>
 


On Thu, Jul 22, 2021 at 9:29 AM gaoliming <gaoliming@...> wrote:
This is new feature. Can you submit one BZ (https://bugzilla.tianocore.org/ ) for it?

Thanks
Liming
> -----邮件原件-----
> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Cheng-Chieh
> Huang via groups.io
> 发送时间: 2021年7月21日 21:23
> 收件人: devel@edk2.groups.io
> 抄送: Cheng-Chieh Huang <chengchieh@...>; Daniel Schaefer
> <daniel.schaefer@...>; Trammell Hudson <hudson@...>;
> Maurice Ma <maurice.ma@...>; Guo Dong <guo.dong@...>;
> Benjamin You <benjamin.you@...>
> 主题: [edk2-devel] [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in
> UefiPayload
>
> These are necessary patches to Support LinuxBoot in UefiPayload.
> With these paches, we can boot to ESXi and Windows from a linux in QEMU.
>
> LinuxBoot README:
> https://github.com/linuxboot/edk2/blob/uefipayload/UefiPayloadPkg/READM
> E.md
>
> PR to tianocore:
> https://github.com/tianocore/edk2/pull/1820
>
> Cheng-Chieh Huang (5):
>   Add LINUXBOOT payload target
>   Use legacy timer in Linuxboot payload
>   Update maximum logic processor to 256
>   Reserve Payload config in runtime services data
>   Add DISABLE_MMX_SSE to avoid generating floating points operation
>
> Trammell Hudson (1):
>   LinuxBoot: use a text format for the configuration block.
>
>  UefiPayloadPkg/UefiPayloadPkg.dsc             |  29 +-
>  UefiPayloadPkg/UefiPayloadPkg.fdf             |   5 +
>  .../Library/LbParseLib/LbParseLib.inf         |  39 ++
>  UefiPayloadPkg/Include/Linuxboot.h            |  58 +++
>  .../Library/LbParseLib/LbParseLib.c           | 348
> ++++++++++++++++++
>  .../PciHostBridgeLib/PciHostBridgeSupport.c   |   6 +-
>  .../UefiPayloadEntry/UefiPayloadEntry.c       |   2 +
>  CryptoPkg/Library/OpensslLib/openssl          |   2 +-
>  8 files changed, 480 insertions(+), 9 deletions(-)
>  create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
>  create mode 100644 UefiPayloadPkg/Include/Linuxboot.h
>  create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
>
> Cc: Cheng-Chieh Huang <chengchieh@...>
> Cc: Daniel Schaefer <daniel.schaefer@...>
> Cc: Trammell Hudson <hudson@...>
> Cc: Maurice Ma <maurice.ma@...>
> Cc: Guo Dong <guo.dong@...>
> Cc: Benjamin You <benjamin.you@...>
> --
> 2.32.0.402.g57bb445576-goog
>
>
>
>
>




Re: [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload

Cheng-Chieh Huang <chengchieh@...>
 

On Thu, Jul 22, 2021 at 9:59 AM Daniel Schaefer <daniel.schaefer@...> wrote:
On 7/22/21 9:44 AM, Ni, Ray wrote:
> Cheng-Chieh,
> Thanks for the detailed explanation in doc https://docs.google.com/document/d/1mU6ICHTh0ot8U45uuRENKOGI8cVzizdyWHGYHpEguVg/edit#heading=h.xzptrog8pyxf .
>
> My original thought was LinuxBoot is a payload that aims to boot OS.
> But the idea of chaining UefiPayload producing UEFI services is very brilliant.

It can be and it is. The main usage of LinuxBoot is to load/boot another
Linux using the kexec mechanism. But in order to be able to boot
Windows, ESXI, ... a UEFI interface is required.
There have been a few proposals and POCs (like implementing UEFI
services in Linux) but UefiPayload is the most practical and easy way to
do it, for now.

> Have you considered to produce the universal payload interfaces (https://universalpayload.github.io/documentation/ ) from LinuxBoot so no LbParseLib is required?

I don't think we've looked at it. But we liked it to be a string because
it allows easy forward compatibility and not having to recreate the
structs in higher-level languages like Go.

Agree to Daniel. In the future, we can look for supporting HOB structure in u-root, but for now, we prefer to stick with the current approach.

--
Cheng-Chieh
 
> Thanks,
> Ray
>
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Cheng-Chieh Huang via groups.io
>> Sent: Wednesday, July 21, 2021 9:23 PM
>> To: devel@edk2.groups.io
>> Cc: Cheng-Chieh Huang <chengchieh@...>; Schaefer, Daniel <daniel.schaefer@...>; Trammell Hudson
>> <hudson@...>; Ma, Maurice <maurice.ma@...>; Dong, Guo <guo.dong@...>; You, Benjamin
>> <benjamin.you@...>
>> Subject: [edk2-devel] [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload
>>
>> These are necessary patches to Support LinuxBoot in UefiPayload.
>> With these paches, we can boot to ESXi and Windows from a linux in QEMU.
>>
>> LinuxBoot README:
>> https://github.com/linuxboot/edk2/blob/uefipayload/UefiPayloadPkg/README.md
>>
>> PR to tianocore:
>> https://github.com/tianocore/edk2/pull/1820
>>
>> Cheng-Chieh Huang (5):
>>    Add LINUXBOOT payload target
>>    Use legacy timer in Linuxboot payload
>>    Update maximum logic processor to 256
>>    Reserve Payload config in runtime services data
>>    Add DISABLE_MMX_SSE to avoid generating floating points operation
>>
>> Trammell Hudson (1):
>>    LinuxBoot: use a text format for the configuration block.
>>
>>   UefiPayloadPkg/UefiPayloadPkg.dsc             |  29 +-
>>   UefiPayloadPkg/UefiPayloadPkg.fdf             |   5 +
>>   .../Library/LbParseLib/LbParseLib.inf         |  39 ++
>>   UefiPayloadPkg/Include/Linuxboot.h            |  58 +++
>>   .../Library/LbParseLib/LbParseLib.c           | 348 ++++++++++++++++++
>>   .../PciHostBridgeLib/PciHostBridgeSupport.c   |   6 +-
>>   .../UefiPayloadEntry/UefiPayloadEntry.c       |   2 +
>>   CryptoPkg/Library/OpensslLib/openssl          |   2 +-
>>   8 files changed, 480 insertions(+), 9 deletions(-)
>>   create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
>>   create mode 100644 UefiPayloadPkg/Include/Linuxboot.h
>>   create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.c
>>
>> Cc: Cheng-Chieh Huang <chengchieh@...>
>> Cc: Daniel Schaefer <daniel.schaefer@...>
>> Cc: Trammell Hudson <hudson@...>
>> Cc: Maurice Ma <maurice.ma@...>
>> Cc: Guo Dong <guo.dong@...>
>> Cc: Benjamin You <benjamin.you@...>
>> --
>> 2.32.0.402.g57bb445576-goog
>>
>>
>>
>>
>>
>


Re: [edk2-platforms: PATCH] Features/Intel/IpmiFeaturePkg: Use MdePkg macros instead of redefining.

Chiu, Chasel
 

Patch pushed: d549e39ca1a9da14d86ff841358f990a0ace71f5

Thanks,
Chasel

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Chiu,
Chasel
Sent: Thursday, July 15, 2021 10:38 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@intel.com>; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Chaganty, Rangasai V
<rangasai.v.chaganty@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>;
Oram, Isaac W <isaac.w.oram@intel.com>
Subject: [edk2-devel] [edk2-platforms: PATCH]
Features/Intel/IpmiFeaturePkg: Use MdePkg macros instead of redefining.

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

Renamed below macros and structure to use MdePkg ones.
IPMI_MSG_GET_BMC_EXEC_RSP
IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE

Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Sai Chaganty <rangasai.v.chaganty@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
---

Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/I
pmiInit.c | 8 ++++----
Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/ServerMa
nagement.h | 17 -----------------
2 files changed, 4 insertions(+), 21 deletions(-)

diff --git
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dx
e/IpmiInit.c
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dx
e/IpmiInit.c
index 1e0c132508..d788b48867 100644
---
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dx
e/IpmiInit.c
+++
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dx
e/
+++ IpmiInit.c
@@ -242,7 +242,7 @@ Returns:
EFI_STATUS Status; UINT32 DataSize;
SM_CTRL_INFO *pBmcInfo;- EFI_IPMI_MSG_GET_BMC_EXEC_RSP
*pBmcExecContext;+ IPMI_MSG_GET_BMC_EXEC_RSP
*pBmcExecContext; UINT32 Retries; #ifdef
FAST_VIDEO_SUPPORT EFI_VIDEOPRINT_PROTOCOL
*VideoPrintProtocol;@@ -301,14 +301,14 @@ Returns:
Status = IpmiSendCommand ( &IpmiInstance->IpmiTransport,
IPMI_NETFN_FIRMWARE, 0,-
EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT,+
IPMI_GET_BMC_EXECUTION_CONTEXT, NULL, 0,
IpmiInstance->TempData, &DataSize ); - pBmcExecContext =
(EFI_IPMI_MSG_GET_BMC_EXEC_RSP*)&IpmiInstance->TempData[0];+
pBmcExecContext = (IPMI_MSG_GET_BMC_EXEC_RSP*)&IpmiInstance-
TempData[0]; DEBUG ((DEBUG_INFO, "[IPMI] Operational status of BMC:
0x%x\n", pBmcExecContext->CurrentExecutionContext));- if
((pBmcExecContext->CurrentExecutionContext ==
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE) &&+ if
((pBmcExecContext->CurrentExecutionContext ==
IPMI_BMC_IN_FORCED_UPDATE_MODE) && !EFI_ERROR (Status))
{ DEBUG ((DEBUG_ERROR, "[IPMI] BMC in Forced Update mode, skip
waiting for BMC_READY.\n")); IpmiInstance->BmcStatus =
BMC_UPDATE_IN_PROGRESS;diff --git
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Server
Management.h
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Server
Management.h
index 7591f33aba..244b86e91a 100644
---
a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Server
Management.h
+++
b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/Include/Server
Ma
+++ nagement.h
@@ -149,15 +149,6 @@ typedef enum {
#define UPPER_NON_RECOVER_GOING_LOW 0x400 #define
UPPER_NON_RECOVER_GOING_HI 0x800 -//-// Definitions for Get BMC
Execution Context-//-#define
EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT 0x23-//-// Current
Execution Context responses-//-#define
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE 0x11- // // Server
Management COM Addressing types //@@ -327,14 +318,6 @@ typedef
struct {
UINT16 IoBasePort; } IPMI_HOB_DATA; -//-// Constants and Structure
definitions for "Get Device ID" command to follow here-//-typedef struct {-
UINT8 CurrentExecutionContext;- UINT8 PartitionPointer;-}
EFI_IPMI_MSG_GET_BMC_EXEC_RSP;- // // COM Layer Callback //--
2.28.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77811): https://edk2.groups.io/g/devel/message/77811
Mute This Topic: https://groups.io/mt/84226659/1777047
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [chasel.chiu@intel.com]
-=-=-=-=-=-=


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

Andrew Fish
 



On Jul 21, 2021, at 6:20 PM, gaoliming <gaoliming@...> wrote:



-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Pedro Falcato
发送时间: 2021年7月22日 7:12
收件人: devel@edk2.groups.io
抄送: rfc@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 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 package in
the future, if possible.

Current limitations:
1) The Ext4Dxe driver is, at the moment, read-only.
2) The Ext4Dxe driver at the moment cannot mount older (ext2/3)
filesystems. Ensuring compatibility with
those may not be a bad idea.

I intend to test the package using the UEFI SCTs present in edk2-test,
and implement any other needed unit tests myself using the already
available unit test framework. I also intend to (privately) fuzz the
UEFI driver with bad/unusual disk images, to improve the security and
reliability of the driver.

In the future, ext4 write support should be added so edk2 has a
fully-featured RW ext4 driver. There could also be a focus on
supporting the older ext4-like filesystems, as I mentioned in the
limitations, but that is open for discussion.

The driver's handling of unclean unmounting through forced shutdown is
unclear.
Is there a position in edk2 on how to handle such cases? I don't think
FAT32 has a "this filesystem is/was dirty" and even though it seems to
me that stopping a system from booting/opening the partition because
"we may find some tiny irregularities" is not the best course of
action, I can't find a clear answer.

The driver also had to add implementations of CRC32C and CRC16, and
after talking with my mentor we quickly reached the conclusion that
these may be good candidates for inclusion in MdePkg. We also
discussed moving the Ucs2 <-> Utf8 conversion library in RedfishPkg
(BaseUcs2Utf8Lib) into MdePkg as well. Any comments?

Current MdePkg BaseLib has CalculateCrc32(). So, CRC32C and CRC16 can be added into BaseLib. 

If more modules need to consume Ucs2 <-> Utf8 conversion library, BaseUcs2Utf8Lib is generic enough
to be placed in MdePkg. 


I think the Terminal driver may have some similar logic to convert UTF-8 terminals to/from the UEFI UCS-2?


Thanks,

Andrew Fish

Thanks
Liming

Feel free to ask any questions you may find relevant.

Best Regards,

Pedro Falcato











Re: [PATCH v1 5/6] UefiPayloadPkg: Add DISABLE_MMX_SSE to avoid generating floating points operation

Cheng-Chieh Huang <chengchieh@...>
 

I mean, I will submit a patch to support DISABLE_GCC_MMX_SSE in tools_def. What do you think?

--
Cheng-Chieh

On Thu, Jul 22, 2021 at 9:28 AM gaoliming <gaoliming@...> wrote:

Tools_def.txt doesn’t support build flag DISABLE_GCC_MMX_SSE. If this flag is moved into BaseTools\Conf\tools_def.template, -mno-mmx -mno-sse option will be the default GCC options. That means all platforms will apply them.

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Cheng-Chieh Huang via groups.io
发送时间: 2021722 1:43
收件人: Kinney, Michael D <michael.d.kinney@...>
抄送: devel@edk2.groups.io
主题: Re: [edk2-devel] [PATCH v1 5/6] UefiPayloadPkg: Add DISABLE_MMX_SSE to avoid generating floating points operation

 

Yes, we can. I will drop this patch for this  uefipayload batch and send another one for support DISABLE_GCC_MMX_SSE in tools_de.txt.

 

--

Cheng-Chieh 

On Thu, Jul 22, 2021, 12:35 AM Kinney, Michael D <michael.d.kinney@...> wrote:

Are those flags needed for all packages that build with GCC?

Should this be moved into tools_def.txt?

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Cheng-Chieh Huang via groups.io
> Sent: Wednesday, July 21, 2021 6:23 AM
> To: devel@edk2.groups.io
> Cc: Cheng-Chieh Huang <chengchieh@...>
> Subject: [edk2-devel] [PATCH v1 5/6] UefiPayloadPkg: Add DISABLE_MMX_SSE to avoid generating floating points operation
>
> This will allow we compile payload using gcc8
>
> Signed-off-by: Cheng-Chieh Huang <chengchieh@...>
> ---
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index 8aa5f18cd35c..fa41c5a24af5 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
> @@ -30,6 +30,8 @@ [Defines]
>    DEFINE PS2_KEYBOARD_ENABLE          = FALSE
>    DEFINE UNIVERSAL_PAYLOAD            = FALSE
>
> +  DEFINE DISABLE_MMX_SSE              = FALSE
> +
>    #
>    # SBL:      UEFI payload for Slim Bootloader
>    # COREBOOT: UEFI payload for coreboot
> @@ -96,6 +98,9 @@ [BuildOptions]
>    *_*_*_CC_FLAGS                 = -D DISABLE_NEW_DEPRECATED_INTERFACES
>  !if $(BOOTLOADER) == "LINUXBOOT"
>    *_*_*_CC_FLAGS                 = -D LINUXBOOT_PAYLOAD
> +!endif
> +!if $(DISABLE_MMX_SSE)
> +  *_*_*_CC_FLAGS                 = -mno-mmx -mno-sse
>  !endif
>    GCC:*_UNIXGCC_*_CC_FLAGS       = -DMDEPKG_NDEBUG
>    GCC:RELEASE_*_*_CC_FLAGS       = -DMDEPKG_NDEBUG
> --
> 2.32.0.402.g57bb445576-goog
>
>
>
>
>


Re: [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload

Daniel Schaefer
 

On 7/22/21 9:44 AM, Ni, Ray wrote:
Cheng-Chieh,
Thanks for the detailed explanation in doc https://docs.google.com/document/d/1mU6ICHTh0ot8U45uuRENKOGI8cVzizdyWHGYHpEguVg/edit#heading=h.xzptrog8pyxf .
My original thought was LinuxBoot is a payload that aims to boot OS.
But the idea of chaining UefiPayload producing UEFI services is very brilliant.
It can be and it is. The main usage of LinuxBoot is to load/boot another Linux using the kexec mechanism. But in order to be able to boot Windows, ESXI, ... a UEFI interface is required.
There have been a few proposals and POCs (like implementing UEFI services in Linux) but UefiPayload is the most practical and easy way to do it, for now.

Have you considered to produce the universal payload interfaces (https://universalpayload.github.io/documentation/ ) from LinuxBoot so no LbParseLib is required?
I don't think we've looked at it. But we liked it to be a string because it allows easy forward compatibility and not having to recreate the structs in higher-level languages like Go.

Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Cheng-Chieh Huang via groups.io
Sent: Wednesday, July 21, 2021 9:23 PM
To: devel@edk2.groups.io
Cc: Cheng-Chieh Huang <chengchieh@google.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; Trammell Hudson
<hudson@trmm.net>; Ma, Maurice <maurice.ma@intel.com>; Dong, Guo <guo.dong@intel.com>; You, Benjamin
<benjamin.you@intel.com>
Subject: [edk2-devel] [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload

These are necessary patches to Support LinuxBoot in UefiPayload.
With these paches, we can boot to ESXi and Windows from a linux in QEMU.

LinuxBoot README:
https://github.com/linuxboot/edk2/blob/uefipayload/UefiPayloadPkg/README.md

PR to tianocore:
https://github.com/tianocore/edk2/pull/1820

Cheng-Chieh Huang (5):
Add LINUXBOOT payload target
Use legacy timer in Linuxboot payload
Update maximum logic processor to 256
Reserve Payload config in runtime services data
Add DISABLE_MMX_SSE to avoid generating floating points operation

Trammell Hudson (1):
LinuxBoot: use a text format for the configuration block.

UefiPayloadPkg/UefiPayloadPkg.dsc | 29 +-
UefiPayloadPkg/UefiPayloadPkg.fdf | 5 +
.../Library/LbParseLib/LbParseLib.inf | 39 ++
UefiPayloadPkg/Include/Linuxboot.h | 58 +++
.../Library/LbParseLib/LbParseLib.c | 348 ++++++++++++++++++
.../PciHostBridgeLib/PciHostBridgeSupport.c | 6 +-
.../UefiPayloadEntry/UefiPayloadEntry.c | 2 +
CryptoPkg/Library/OpensslLib/openssl | 2 +-
8 files changed, 480 insertions(+), 9 deletions(-)
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
create mode 100644 UefiPayloadPkg/Include/Linuxboot.h
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.c

Cc: Cheng-Chieh Huang <chengchieh@google.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Trammell Hudson <hudson@trmm.net>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
--
2.32.0.402.g57bb445576-goog




Re: [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload

Ni, Ray
 

Cheng-Chieh,
Thanks for the detailed explanation in doc https://docs.google.com/document/d/1mU6ICHTh0ot8U45uuRENKOGI8cVzizdyWHGYHpEguVg/edit#heading=h.xzptrog8pyxf.

My original thought was LinuxBoot is a payload that aims to boot OS.
But the idea of chaining UefiPayload producing UEFI services is very brilliant.

Have you considered to produce the universal payload interfaces (https://universalpayload.github.io/documentation/) from LinuxBoot so no LbParseLib is required?

Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Cheng-Chieh Huang via groups.io
Sent: Wednesday, July 21, 2021 9:23 PM
To: devel@edk2.groups.io
Cc: Cheng-Chieh Huang <chengchieh@google.com>; Schaefer, Daniel <daniel.schaefer@hpe.com>; Trammell Hudson
<hudson@trmm.net>; Ma, Maurice <maurice.ma@intel.com>; Dong, Guo <guo.dong@intel.com>; You, Benjamin
<benjamin.you@intel.com>
Subject: [edk2-devel] [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload

These are necessary patches to Support LinuxBoot in UefiPayload.
With these paches, we can boot to ESXi and Windows from a linux in QEMU.

LinuxBoot README:
https://github.com/linuxboot/edk2/blob/uefipayload/UefiPayloadPkg/README.md

PR to tianocore:
https://github.com/tianocore/edk2/pull/1820

Cheng-Chieh Huang (5):
Add LINUXBOOT payload target
Use legacy timer in Linuxboot payload
Update maximum logic processor to 256
Reserve Payload config in runtime services data
Add DISABLE_MMX_SSE to avoid generating floating points operation

Trammell Hudson (1):
LinuxBoot: use a text format for the configuration block.

UefiPayloadPkg/UefiPayloadPkg.dsc | 29 +-
UefiPayloadPkg/UefiPayloadPkg.fdf | 5 +
.../Library/LbParseLib/LbParseLib.inf | 39 ++
UefiPayloadPkg/Include/Linuxboot.h | 58 +++
.../Library/LbParseLib/LbParseLib.c | 348 ++++++++++++++++++
.../PciHostBridgeLib/PciHostBridgeSupport.c | 6 +-
.../UefiPayloadEntry/UefiPayloadEntry.c | 2 +
CryptoPkg/Library/OpensslLib/openssl | 2 +-
8 files changed, 480 insertions(+), 9 deletions(-)
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
create mode 100644 UefiPayloadPkg/Include/Linuxboot.h
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.c

Cc: Cheng-Chieh Huang <chengchieh@google.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Trammell Hudson <hudson@trmm.net>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
--
2.32.0.402.g57bb445576-goog





回复: [edk2-devel] [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in UefiPayload

gaoliming
 

This is new feature. Can you submit one BZ (https://bugzilla.tianocore.org/ ) for it?

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Cheng-Chieh
Huang via groups.io
发送时间: 2021年7月21日 21:23
收件人: devel@edk2.groups.io
抄送: Cheng-Chieh Huang <chengchieh@google.com>; Daniel Schaefer
<daniel.schaefer@hpe.com>; Trammell Hudson <hudson@trmm.net>;
Maurice Ma <maurice.ma@intel.com>; Guo Dong <guo.dong@intel.com>;
Benjamin You <benjamin.you@intel.com>
主题: [edk2-devel] [PATCH 0/6] UefiPayloadPkg: LinuxBoot Support in
UefiPayload

These are necessary patches to Support LinuxBoot in UefiPayload.
With these paches, we can boot to ESXi and Windows from a linux in QEMU.

LinuxBoot README:
https://github.com/linuxboot/edk2/blob/uefipayload/UefiPayloadPkg/READM
E.md

PR to tianocore:
https://github.com/tianocore/edk2/pull/1820

Cheng-Chieh Huang (5):
Add LINUXBOOT payload target
Use legacy timer in Linuxboot payload
Update maximum logic processor to 256
Reserve Payload config in runtime services data
Add DISABLE_MMX_SSE to avoid generating floating points operation

Trammell Hudson (1):
LinuxBoot: use a text format for the configuration block.

UefiPayloadPkg/UefiPayloadPkg.dsc | 29 +-
UefiPayloadPkg/UefiPayloadPkg.fdf | 5 +
.../Library/LbParseLib/LbParseLib.inf | 39 ++
UefiPayloadPkg/Include/Linuxboot.h | 58 +++
.../Library/LbParseLib/LbParseLib.c | 348
++++++++++++++++++
.../PciHostBridgeLib/PciHostBridgeSupport.c | 6 +-
.../UefiPayloadEntry/UefiPayloadEntry.c | 2 +
CryptoPkg/Library/OpensslLib/openssl | 2 +-
8 files changed, 480 insertions(+), 9 deletions(-)
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.inf
create mode 100644 UefiPayloadPkg/Include/Linuxboot.h
create mode 100644 UefiPayloadPkg/Library/LbParseLib/LbParseLib.c

Cc: Cheng-Chieh Huang <chengchieh@google.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Trammell Hudson <hudson@trmm.net>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
--
2.32.0.402.g57bb445576-goog





回复: [edk2-devel] [PATCH v1 5/6] UefiPayloadPkg: Add DISABLE_MMX_SSE to avoid generating floating points operation

gaoliming
 

Tools_def.txt doesn’t support build flag DISABLE_GCC_MMX_SSE. If this flag is moved into BaseTools\Conf\tools_def.template, -mno-mmx -mno-sse option will be the default GCC options. That means all platforms will apply them.

 

Thanks

Liming

发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Cheng-Chieh Huang via groups.io
发送时间: 2021722 1:43
收件人: Kinney, Michael D <michael.d.kinney@...>
抄送: devel@edk2.groups.io
主题: Re: [edk2-devel] [PATCH v1 5/6] UefiPayloadPkg: Add DISABLE_MMX_SSE to avoid generating floating points operation

 

Yes, we can. I will drop this patch for this  uefipayload batch and send another one for support DISABLE_GCC_MMX_SSE in tools_de.txt.

 

--

Cheng-Chieh 

On Thu, Jul 22, 2021, 12:35 AM Kinney, Michael D <michael.d.kinney@...> wrote:

Are those flags needed for all packages that build with GCC?

Should this be moved into tools_def.txt?

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Cheng-Chieh Huang via groups.io
> Sent: Wednesday, July 21, 2021 6:23 AM
> To: devel@edk2.groups.io
> Cc: Cheng-Chieh Huang <chengchieh@...>
> Subject: [edk2-devel] [PATCH v1 5/6] UefiPayloadPkg: Add DISABLE_MMX_SSE to avoid generating floating points operation
>
> This will allow we compile payload using gcc8
>
> Signed-off-by: Cheng-Chieh Huang <chengchieh@...>
> ---
>  UefiPayloadPkg/UefiPayloadPkg.dsc | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc b/UefiPayloadPkg/UefiPayloadPkg.dsc
> index 8aa5f18cd35c..fa41c5a24af5 100644
> --- a/UefiPayloadPkg/UefiPayloadPkg.dsc
> +++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
> @@ -30,6 +30,8 @@ [Defines]
>    DEFINE PS2_KEYBOARD_ENABLE          = FALSE
>    DEFINE UNIVERSAL_PAYLOAD            = FALSE
>
> +  DEFINE DISABLE_MMX_SSE              = FALSE
> +
>    #
>    # SBL:      UEFI payload for Slim Bootloader
>    # COREBOOT: UEFI payload for coreboot
> @@ -96,6 +98,9 @@ [BuildOptions]
>    *_*_*_CC_FLAGS                 = -D DISABLE_NEW_DEPRECATED_INTERFACES
>  !if $(BOOTLOADER) == "LINUXBOOT"
>    *_*_*_CC_FLAGS                 = -D LINUXBOOT_PAYLOAD
> +!endif
> +!if $(DISABLE_MMX_SSE)
> +  *_*_*_CC_FLAGS                 = -mno-mmx -mno-sse
>  !endif
>    GCC:*_UNIXGCC_*_CC_FLAGS       = -DMDEPKG_NDEBUG
>    GCC:RELEASE_*_*_CC_FLAGS       = -DMDEPKG_NDEBUG
> --
> 2.32.0.402.g57bb445576-goog
>
>
>
>
>


回复: [edk2-rfc] RFC: EXT4 filesystem driver

gaoliming
 

-----邮件原件-----
发件人: rfc@edk2.groups.io <rfc@edk2.groups.io> 代表 Pedro Falcato
发送时间: 2021年7月22日 7:12
收件人: devel@edk2.groups.io
抄送: rfc@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 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 package in
the future, if possible.

Current limitations:
1) The Ext4Dxe driver is, at the moment, read-only.
2) The Ext4Dxe driver at the moment cannot mount older (ext2/3)
filesystems. Ensuring compatibility with
those may not be a bad idea.

I intend to test the package using the UEFI SCTs present in edk2-test,
and implement any other needed unit tests myself using the already
available unit test framework. I also intend to (privately) fuzz the
UEFI driver with bad/unusual disk images, to improve the security and
reliability of the driver.

In the future, ext4 write support should be added so edk2 has a
fully-featured RW ext4 driver. There could also be a focus on
supporting the older ext4-like filesystems, as I mentioned in the
limitations, but that is open for discussion.

The driver's handling of unclean unmounting through forced shutdown is
unclear.
Is there a position in edk2 on how to handle such cases? I don't think
FAT32 has a "this filesystem is/was dirty" and even though it seems to
me that stopping a system from booting/opening the partition because
"we may find some tiny irregularities" is not the best course of
action, I can't find a clear answer.

The driver also had to add implementations of CRC32C and CRC16, and
after talking with my mentor we quickly reached the conclusion that
these may be good candidates for inclusion in MdePkg. We also
discussed moving the Ucs2 <-> Utf8 conversion library in RedfishPkg
(BaseUcs2Utf8Lib) into MdePkg as well. Any comments?
Current MdePkg BaseLib has CalculateCrc32(). So, CRC32C and CRC16 can be added into BaseLib.

If more modules need to consume Ucs2 <-> Utf8 conversion library, BaseUcs2Utf8Lib is generic enough
to be placed in MdePkg.

Thanks
Liming

Feel free to ask any questions you may find relevant.

Best Regards,

Pedro Falcato




Re: [PATCH v2] Xcode.md: Update instructions to work on modern macOS and Xcode versions

Andrew Fish
 

Reviewed-by: Andrew Fish <afish@apple.com>

On Jul 21, 2021, at 4:56 PM, Rebecca Cran <rebecca@bsdio.com> wrote:

The existing instructions no longer work on macOS Big Sur and Xcode 12.5.
Update them to include for example using lldb instead of gdb, installing
XQuartz, and using modern names such as macOS instead of Mac OS X.

Also, since MacPorts is less popular these days, remove instructions for
installing tools with it, leaving steps for using Homebrew.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
---
Xcode.md | 172 +++++++++-----------
1 file changed, 78 insertions(+), 94 deletions(-)

diff --git a/Xcode.md b/Xcode.md
index 3d220a5..8af2653 100644
--- a/Xcode.md
+++ b/Xcode.md
@@ -1,43 +1,28 @@
-This page provides step-by-step instructions for setting up a [http://www.tianocore.org/edk2/ EDK II] build environment on Mac OS X systems using the Xcode development tools. These steps have been verified with macOS Sierra Version 10.12.4
+This page provides step-by-step instructions for setting up a [EDK II](https://github.com/tianocore/tianocore.github.io/wiki/EDK-II) build environment on macOS systems using the Xcode development tools. These steps have been verified with macOS Big Sur 11.3.1

-# Mac OS X Xcode
-Download the latest version of [Xcode](https://developer.apple.com/xcode) (9.4.1 as of this writing) from the Mac App Store. After installing Xcode, you will additionally need to install the extra command-line tools. To do this, at a Terminal prompt, enter:
+# macOS Xcode
+Download the latest version of [Xcode](https://developer.apple.com/xcode) (12.5 as of 2021-05-09) from the Mac App Store. After installing Xcode, you will additionally need to install the extra command-line tools. To do this, at a Terminal prompt, enter:
```
$ xcode-select --install
```
## Additional Development Tools
-While Xcode provides a full development environment as well as a suite of different utilities, it does not provide all tools required for Tianocore development. These tools can be provided in a number of ways, but the two most popular ways come from [Brew](https://brew.sh) and [MacPorts](https://www.macports.org/install.php). Installation information is provided at the previous links.
-
-### MacPorts Tips
-* If you work behind a firewall and need to pass your network traffic through a proxy, ensure you set the environment variable RSYNC_PROXY to your http proxy in the form of `proxy.dns.name:port_number`.
- * Remember that `sudo` by default drops most environment variables. Add the `-E` option to tell `sudo` to keep your environment variables.
-* When installing MacPorts packages, if you would like to build from source like traditional [FreeBSD Ports](https://en.wikipedia.org/wiki/FreeBSD_Ports) systems, add the `-s` option to the command line. Otherwise, default behavior is to pull precompiled packages.
+While Xcode provides a full development environment as well as a suite of different utilities, it does not provide all tools required for TianoCore development. These tools can be provided in a number of ways, but the most popular way comes from [Brew](https://brew.sh). Installation information is provided at the previous link.

## Install mtoc
The mtoc utility is required to convert from the macOS Mach-O image format to the PE/COFF format as required by the UEFI specification.

### Brew Instructions
```
-$ brew install mtoc
-```
-## MacPorts Instructions
-```
-$ sudo port install cctools
+$ brew install mtoc
```
-By default, this will install `mtoc` at `/opt/local/bin/mtoc`.
# Install NASM

-The assembler used for EDK II builds is Netwide Assembler (NASM). The latest version of NASM is available from http://www.nasm.us/.
+The assembler used for EDK II builds is Netwide Assembler (NASM). The latest version of NASM is available from https://nasm.us/.
## Brew Instructions
```
$ brew install nasm
$ brew upgrade nasm
```
-## MacPorts Instructions
-```
-$ sudo port install nasm
-```
-By default this installs `nasm` at `/opt/local/bin/nasm`.

# Install ACPI Compiler

@@ -47,26 +32,20 @@ In order to support EDK II firmware builds, the latest version of the ASL compil
$ brew install acpica
$ brew upgrade acpica
```
-## MacPorts Install
-```
-$ sudo port install acpica
-```
-By default this installs `iasl` at `/opt/local/bin/iasl`
+
+# Install XQuartz
+
+The EmulatorPkg requires headers from X11, which are provided by the XQuartz project. Install it from https://www.xquartz.org/.

# Install QEMU Emulator

-On order to support running the OVMF platforms from the OvmfPkg, the QEMU emulator from http://www.qemu.org/ must be installed.
+On order to support running the OVMF platforms from the OvmfPkg, the QEMU emulator from https://www.qemu.org/ must be installed.

## Brew Install
```
$ brew install qemu
$ brew upgrade qemu
```
-## MacPorts Install
-```
-$ sudo port install qemu
-```
-By default qemu is installed in `/opt/local/bin`.
## Update PATH environment variable

Tools installed using the `brew` command are placed in `/usr/local/bin`. The `PATH` environment variable must be updated so the newly installed tools are used instead of older pre-installed tools.
@@ -75,11 +54,6 @@ Tools installed using the `brew` command are placed in `/usr/local/bin`. The `P
export PATH=/usr/local/bin:$PATH
```

-Tools installed using the `port` should automatically be in your shell's PATH. If not, you can manually set it by:
-```
-export PATH=/opt/local/bin:$PATH
-```
-
# Verify tool versions

Run the following commands to verify the versions of the tools that have been installed.
@@ -97,84 +71,94 @@ Pick the location you want to down load the files to and `cd` to that directory:
```
cd ~/work
git clone https://github.com/tianocore/edk2.git
+cd edk2
+git submodule update --init
```

-# Build from Command Line/Debug with gdb
+# Build from Command Line/Debug with lldb

-Build the UnixPkg:
+Build the EmulatorPkg:

```
-cd ~/work/edk2/UnixPkg
+cd ~/work/edk2/EmulatorPkg
./build.sh
```

-Debug the UnixPkg
+Debug the EmulatorPkg

```
./build.sh run

-Building from: /Users/fish/work/edk2
+Initializing workspace
+/Users/bcran/src/edk2/BaseTools
+Loading previous configuration from /Users/bcran/src/edk2/Conf/BuildEnv.sh
+Using EDK2 in-source Basetools
+WORKSPACE: /Users/bcran/src/edk2
+EDK_TOOLS_PATH: /Users/bcran/src/edk2/BaseTools
+CONF_PATH: /Users/bcran/src/edk2/Conf
using prebuilt tools
-Reading symbols for shared libraries ...... done
-Breakpoint 1 at 0xce84: file /Users/fish/work/edk2/UnixPkg/Sec/SecMain.c, line 1070.
-(gdb)
-```
-
-Type `r` at the gdb prompt (don't forget to hit carriage return) to boot the emulator. Ctrl-c in the terminal window will break in to gdb. bt is the stack backtrace command:
-
-```
-^C
-Program received signal SIGINT, Interrupt.
-0x92423806 in __semwait_signal ()
-(gdb) bt
-#0 0x92423806 in __semwait_signal ()
-#1 0x9244f441 in nanosleep$UNIX2003 ()
-#2 0x0000b989 in msSleep (Milliseconds=0x14) at /Users/fish/work/Migration/edk2/UnixPkg/Sec/UnixThunk.c:102
-#3 0x0000acf5 in UgaCheckKey (UgaIo=0x2078d0) at /Users/fish/work/Migration/edk2/UnixPkg/Sec/UgaX11.c:380
-#4 0x0000d8b7 in _GasketUintn () at /Users/fish/work/Migration/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/OUTPUT/Ia32/Gasket.iii:63
-#5 0x0000d801 in GasketUgaCheckKey (UgaIo=0x2078d0) at /Users/fish/work/Migration/edk2/UnixPkg/Sec/Gasket.c:406
-#6 0x454a25fb in UnixUgaSimpleTextInWaitForKey (Event=0x45603610, Context=0x45382110) at /Users/fish/work/Migration/edk2/UnixPkg/UnixUgaDxe/UnixUgaInput.c:169
-#7 0x45faad3a in CoreDispatchEventNotifies (Priority=0x10) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:185
-#8 0x45faa639 in CoreRestoreTpl (NewTpl=0x4) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:114
-#9 0x45f9f197 in CoreReleaseLock (Lock=0x45fb1024) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Library/Library.c:102
-#10 0x45faabd6 in CoreReleaseEventLock () at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:113
-#11 0x45fab26c in CoreCheckEvent (UserEvent=0x45603210) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:562
-#12 0x45fab2db in CoreWaitForEvent (NumberOfEvents=0x1, UserEvents=0x45f94cc4, UserIndex=0x45f94cb8) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:621
-#13 0x49ce9557 in ?? ()
-#14 0x49cf0344 in ?? ()
-#15 0x49ce3bc2 in ?? ()
-#16 0x49ce3ae1 in ?? ()
-#17 0x45f9e4e3 in CoreStartImage (ImageHandle=0x49e31e10, ExitDataSize=0x45f94eec, ExitData=0x45f94ee8) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Image/Image.c:1260
-#18 0x4550cccc in BdsLibBootViaBootOption (Option=0x49ffa110, DevicePath=0x49ffa190, ExitDataSize=0x45f94eec, ExitData=0x45f94ee8) at /Users/fish/work/Migration/edk2/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c:382
-#19 0x455252a9 in BdsBootDeviceSelect () at /Users/fish/work/Migration/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:214
-#20 0x455255bc in BdsEntry (This=0x4552d01c) at /Users/fish/work/Migration/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:356
-#21 0x45fad7e8 in DxeMain (HobStart=0x45f70010) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:425
-#22 0x45fadd1d in ProcessModuleEntryPointList (HobStart=0x42020000) at /Users/fish/work/Migration/edk2/Build/Unix/DEBUG_XCODE32/IA32/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c:287
-#23 0x45f97773 in _ModuleEntryPoint (HobStart=0x42020000) at /Users/fish/work/Migration/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54
-(gdb)
+(lldb) target create "./Host"
+Current executable set to '/Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_XCODE5/X64/Host' (x86_64).
+(lldb) command script import /Users/bcran/src/edk2/EmulatorPkg/Unix/lldbefi.py
+Type r to run emulator. SecLldbScriptBreak armed. EFI modules should now get source level debugging in the emulator.
+(lldb) script lldb.debugger.SetAsync(True)
+(lldb) run
+Process 12155 launched: '/Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_XCODE5/X64/Host' (x86_64)
+
+EDK II UNIX Host Emulation Environment from http://www.tianocore.org/edk2/
+ BootMode 0x00
+ OS Emulator passing in 128 KB of temp RAM at 0x102000000 to SEC
+ FD loaded from ../FV/FV_RECOVERY.fd at 0x102020000 contains SEC Core
+...
+```
+
+Type `process interrupt` at the lldb prompt (don't forget to hit carriage return) to pause execution. Ctrl-c in the terminal window will quit lldb. `bt` is the stack backtrace command:
+
+```
+Process 12420 stopped
+* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
+ frame #0: 0x00007fff2033cc22 libsystem_kernel.dylib:__semwait_signal() + 10
+libsystem_kernel.dylib`__semwait_signal:
+-> 0x7fff2033cc22 <+10>: jae 0x7fff2033cc2c ; <+20>
+ 0x7fff2033cc24 <+12>: movq %rax, %rdi
+ 0x7fff2033cc27 <+15>: jmp 0x7fff2033b72d ; cerror
+ 0x7fff2033cc2c <+20>: retq
+Target 0: (Host) stopped.
+(lldb) bt
+* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
+ * frame #0: 0x00007fff2033cc22 libsystem_kernel.dylib:__semwait_signal() + 10
+ frame #1: 0x00007fff202bcc2a libsystem_c.dylib:nanosleep() + 196
+ frame #2: 0x0000000100005e55 Host:SecCpuSleep() + 37 at /Users/bcran/src/edk2/EmulatorPkg/Unix/Host/EmuThunk.c:334
+ frame #3: 0x000000010000e96e Host:GasketSecCpuSleep() + 11 at /Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_XCODE5/X64/EmulatorPkg/Unix/Host/Host/OUTPUT/X64/Gasket.iiii:283
+ frame #4: 0x0000000106f985e9 DxeCore.dll:CoreDispatchEventNotifies() + 264 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:194
+ frame #5: 0x0000000106f97fce DxeCore.dll:CoreRestoreTpl() + 227 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:131
+ frame #6: 0x0000000106f989db DxeCore.dll:CoreSignalEvent() + 111 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:566
+ frame #7: 0x0000000106f98b01 DxeCore.dll:CoreWaitForEvent() + 94 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:707
+ frame #8: 0x0000000113e8e54c BdsDxe.dll:BdsWaitForSingleEvent() + 127 at /Users/bcran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:250
+ frame #9: 0x0000000113e8e70b BdsDxe.dll:BdsWait() + 215 at /Users/bcran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:328
+ frame #10: 0x0000000113e8dffb BdsDxe.dll:BdsEntry() + 2612 at /Users/bcran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:1012
+ frame #11: 0x0000000106f9bbd6 DxeCore.dll:DxeMain() + 2791 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:551
+ frame #12: 0x0000000106f9ed8f DxeCore.dll:_ModuleEntryPoint() + 20 at /Users/bcran/src/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:48
+ frame #13: 0x0000000106fdd02f DxeIpl.dll:InternalSwitchStack() + 15
+ frame #14: 0x0000000106fdc0b6 DxeIpl.dll:HandOffToDxeCore() + 546 at /Users/bcran/src/edk2/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c:126
+ frame #15: 0x0000000106fda78a DxeIpl.dll:DxeLoadCore() + 1354 at /Users/bcran/src/edk2/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:449
+ frame #16: 0x0000000106ff1d7c
+ frame #17: 0x00000001020255c6 PeiCore.dll:PeiCore() + 1982 at /Users/bcran/src/edk2/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c:331
+ frame #18: 0x000000010202a82c PeiCore.dll:PeiCheckAndSwitchStack() + 1171 at /Users/bcran/src/edk2/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c:842
+ frame #19: 0x000000010202b853 PeiCore.dll:PeiDispatcher() + 1206 at /Users/bcran/src/edk2/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c:1609
+(lldb)
+
```

# Build and Debug from Xcode
-To build from the Xcode GUI open ~/work/edk2/UnixPkg/Xcode/xcode_project/xcode_project.xcodeproj. You can build, clean, and source level debug from the Xcode GUI. You can hit the Build and Debug button to start the build process. You need to need to hit command-shift-B to show the output of the build. Click Pause to break into the debugger.
-
-[[File:Xcode.jpg]]
+To build from the Xcode GUI open ~/work/edk2/EmulatorPkg/Unix/Xcode/xcode_project64/xcode_project.xcodeproj. You can build, clean, and source level debug from the Xcode GUI. You can hit the Build and Debug button to start the build process. You need to need to hit command-shift-B to show the output of the build. Click Pause to break into the debugger.

The stack trace contains items that show as ?? since the default shell is checked in as a binary. `nanosleep$UNIX2003` and `__semwait_signal` are POSIX library calls and you do not get C source debug with these symbols.

-# Source Level Debug Shell
-
-It is possible to get source level debug for the EFI Shell by pulling these projects from source control and building them.
-
-Instructions for building and hooking in the shell are located in the [https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Gcc-shell gcc-shell] project.
-
-Please note the gcc-shell and UnixPkg build separately, so if you update shell code you need to build the shell to see the changes. The following screen shot shows being able to source level debug the shell:
-
-[[File:Xcode_good.jpg]]
+*Note* The Xcode project is currently (as of 2021-05-09) broken.

# See Also

-* [[Step-by-step instructions]]
-
# Continue with common instructions

-The [remaining instructions](../Common-instructions) are common for most UNIX-like systems.
+The [remaining instructions](https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions-for-Unix) are common for most UNIX-like systems.
--
2.30.1 (Apple Git-130)







Re: [tianocore.github.io.wiki PATCH 1/1] Xcode.md: Update instructions to work on modern macOS and Xcode versions

Rebecca Cran
 

Thanks. I've just sent out a v2 with the MacPorts instructions removed.


--
Rebecca Cran


On 7/21/21 8:30 AM, Andrew Fish wrote:


On Jul 21, 2021, at 7:24 AM, Rebecca Cran <rebecca@...> wrote:

I think most people (including myself) use brew nowadays, which installs to /usr/local/bin so the instructions work.

I was wondering if we should remove the MacPorts instructions?


Rebecca,

Makes sense to move the instructions over to brew I guess. 

Thanks,

Andrew Fish

--

Rebecca Cran


On 7/20/21 11:37 PM, Andrew Fish wrote:
These Xcode instructions look good to me in general. Thanks for doing this I usually do things following a non public path. 

I think to make these instructions work you need to update *_XCODE5_*_MTOC_PATH

By default, this will install mtoc at /opt/local/bin/mtoc.

*_XCODE5_*_MTOC_PATH = /usr/local/bin/mtoc

We could change this to match the brew default location, I think this location is way out of date. I think the other things get fixed by the path variables. 

Thanks,

Andrew Fish



On May 25, 2021, at 5:36 AM, Rebecca Cran <rebecca@...> wrote:

On 5/25/21 6:21 AM, Laszlo Ersek wrote:

The idea is to use the wiki of any one of your projects on github.com --
most fittingly, your edk2 fork's wiki.

The URL to clone the "real" wiki repo from is:

  git://github.com/tianocore/tianocore.github.io.wiki

And the repo URL of the wiki of your edk2 fork *should be*:

  git@...:bcran/edk2.wiki.git

I'm not sure if you first need to enable the wiki function, for your
edk2 fork, on github.com. Maybe that's hidden somewhere between the
project (fork) settings. Either way, once your wiki repo exists, just
force-push to it whatever your local clone contains. And, only the
"master" branch matters for rendering, AFAICT.


Ah, got it - thanks.

The updated Xcode.md page is at https://github.com/bcran/edk2/wiki/Xcode


--
Rebecca Cran














[PATCH v2] Xcode.md: Update instructions to work on modern macOS and Xcode versions

Rebecca Cran
 

The existing instructions no longer work on macOS Big Sur and Xcode 12.5.
Update them to include for example using lldb instead of gdb, installing
XQuartz, and using modern names such as macOS instead of Mac OS X.

Also, since MacPorts is less popular these days, remove instructions for
installing tools with it, leaving steps for using Homebrew.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
---
Xcode.md | 172 +++++++++-----------
1 file changed, 78 insertions(+), 94 deletions(-)

diff --git a/Xcode.md b/Xcode.md
index 3d220a5..8af2653 100644
--- a/Xcode.md
+++ b/Xcode.md
@@ -1,43 +1,28 @@
-This page provides step-by-step instructions for setting up a [http://www.=
tianocore.org/edk2/ EDK II] build environment on Mac OS X systems using the=
Xcode development tools. These steps have been verified with macOS Sierra=
Version 10.12.4
+This page provides step-by-step instructions for setting up a [EDK II](htt=
ps://github.com/tianocore/tianocore.github.io/wiki/EDK-II) build environmen=
t on macOS systems using the Xcode development tools. These steps have bee=
n verified with macOS Big Sur 11.3.1
=20
-# Mac OS X Xcode
-Download the latest version of [Xcode](https://developer.apple.com/xcode) =
(9.4.1 as of this writing) from the Mac App Store. After installing Xcode,=
you will additionally need to install the extra command-line tools. To do=
this, at a Terminal prompt, enter:
+# macOS Xcode
+Download the latest version of [Xcode](https://developer.apple.com/xcode) =
(12.5 as of 2021-05-09) from the Mac App Store. After installing Xcode, yo=
u will additionally need to install the extra command-line tools. To do th=
is, at a Terminal prompt, enter:
```
$ xcode-select --install
```
## Additional Development Tools
-While Xcode provides a full development environment as well as a suite of =
different utilities, it does not provide all tools required for Tianocore d=
evelopment. These tools can be provided in a number of ways, but the two m=
ost popular ways come from [Brew](https://brew.sh) and [MacPorts](https://w=
ww.macports.org/install.php). Installation information is provided at the =
previous links.
-
-### MacPorts Tips
-* If you work behind a firewall and need to pass your network traffic thro=
ugh a proxy, ensure you set the environment variable RSYNC_PROXY to your ht=
tp proxy in the form of `proxy.dns.name:port_number`.
- * Remember that `sudo` by default drops most environment variables. Ad=
d the `-E` option to tell `sudo` to keep your environment variables.
-* When installing MacPorts packages, if you would like to build from sourc=
e like traditional [FreeBSD Ports](https://en.wikipedia.org/wiki/FreeBSD_Po=
rts) systems, add the `-s` option to the command line. Otherwise, default =
behavior is to pull precompiled packages.=20
+While Xcode provides a full development environment as well as a suite of =
different utilities, it does not provide all tools required for TianoCore d=
evelopment. These tools can be provided in a number of ways, but the most =
popular way comes from [Brew](https://brew.sh). Installation information i=
s provided at the previous link.
=20
## Install mtoc
The mtoc utility is required to convert from the macOS Mach-O image format=
to the PE/COFF format as required by the UEFI specification.
=20
### Brew Instructions
```
-$ brew install mtoc=0D
-```
-## MacPorts Instructions
-```
-$ sudo port install cctools
+$ brew install mtoc
```
-By default, this will install `mtoc` at `/opt/local/bin/mtoc`.
# Install NASM
=20
-The assembler used for EDK II builds is Netwide Assembler (NASM). The late=
st version of NASM is available from http://www.nasm.us/.
+The assembler used for EDK II builds is Netwide Assembler (NASM). The late=
st version of NASM is available from https://nasm.us/.
## Brew Instructions
```
$ brew install nasm
$ brew upgrade nasm
```
-## MacPorts Instructions
-```
-$ sudo port install nasm
-```
-By default this installs `nasm` at `/opt/local/bin/nasm`.
=20
# Install ACPI Compiler
=20
@@ -47,26 +32,20 @@ In order to support EDK II firmware builds, the latest =
version of the ASL compil
$ brew install acpica
$ brew upgrade acpica
```
-## MacPorts Install
-```
-$ sudo port install acpica
-```
-By default this installs `iasl` at `/opt/local/bin/iasl`
+
+# Install XQuartz
+
+The EmulatorPkg requires headers from X11, which are provided by the XQuar=
tz project. Install it from https://www.xquartz.org/.
=20
# Install QEMU Emulator
=20
-On order to support running the OVMF platforms from the OvmfPkg, the QEMU =
emulator from http://www.qemu.org/ must be installed.
+On order to support running the OVMF platforms from the OvmfPkg, the QEMU =
emulator from https://www.qemu.org/ must be installed.
=20
## Brew Install
```
$ brew install qemu
$ brew upgrade qemu
```
-## MacPorts Install
-```
-$ sudo port install qemu
-```
-By default qemu is installed in `/opt/local/bin`.
## Update PATH environment variable
=20
Tools installed using the `brew` command are placed in `/usr/local/bin`. =
The `PATH` environment variable must be updated so the newly installed tool=
s are used instead of older pre-installed tools.
@@ -75,11 +54,6 @@ Tools installed using the `brew` command are placed in `=
/usr/local/bin`. The `P
export PATH=3D/usr/local/bin:$PATH
```
=20
-Tools installed using the `port` should automatically be in your shell's P=
ATH. If not, you can manually set it by:
-```
-export PATH=3D/opt/local/bin:$PATH
-```
-
# Verify tool versions
=20
Run the following commands to verify the versions of the tools that have b=
een installed.
@@ -97,84 +71,94 @@ Pick the location you want to down load the files to an=
d `cd` to that directory:
```
cd ~/work
git clone https://github.com/tianocore/edk2.git
+cd edk2
+git submodule update --init
```
=20
-# Build from Command Line/Debug with gdb
+# Build from Command Line/Debug with lldb
=20
-Build the UnixPkg:
+Build the EmulatorPkg:
=20
```
-cd ~/work/edk2/UnixPkg
+cd ~/work/edk2/EmulatorPkg
./build.sh
```
=20
-Debug the UnixPkg
+Debug the EmulatorPkg
=20
```
./build.sh run
=20
-Building from: /Users/fish/work/edk2
+Initializing workspace
+/Users/bcran/src/edk2/BaseTools
+Loading previous configuration from /Users/bcran/src/edk2/Conf/BuildEnv.sh
+Using EDK2 in-source Basetools
+WORKSPACE: /Users/bcran/src/edk2
+EDK_TOOLS_PATH: /Users/bcran/src/edk2/BaseTools
+CONF_PATH: /Users/bcran/src/edk2/Conf
using prebuilt tools
-Reading symbols for shared libraries ...... done
-Breakpoint 1 at 0xce84: file /Users/fish/work/edk2/UnixPkg/Sec/SecMain.c, =
line 1070.
-(gdb)=20
-```
-
-Type `r` at the gdb prompt (don't forget to hit carriage return) to boot t=
he emulator. Ctrl-c in the terminal window will break in to gdb. bt is the =
stack backtrace command:
-
-```
-^C
-Program received signal SIGINT, Interrupt.
-0x92423806 in __semwait_signal ()
-(gdb) bt
-#0 0x92423806 in __semwait_signal ()
-#1 0x9244f441 in nanosleep$UNIX2003 ()
-#2 0x0000b989 in msSleep (Milliseconds=3D0x14) at /Users/fish/work/Migrat=
ion/edk2/UnixPkg/Sec/UnixThunk.c:102
-#3 0x0000acf5 in UgaCheckKey (UgaIo=3D0x2078d0) at /Users/fish/work/Migra=
tion/edk2/UnixPkg/Sec/UgaX11.c:380
-#4 0x0000d8b7 in _GasketUintn () at /Users/fish/work/Migration/edk2/Build=
/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/OUTPUT/Ia32/Gasket.iii:63
-#5 0x0000d801 in GasketUgaCheckKey (UgaIo=3D0x2078d0) at /Users/fish/work=
/Migration/edk2/UnixPkg/Sec/Gasket.c:406
-#6 0x454a25fb in UnixUgaSimpleTextInWaitForKey (Event=3D0x45603610, Conte=
xt=3D0x45382110) at /Users/fish/work/Migration/edk2/UnixPkg/UnixUgaDxe/Unix=
UgaInput.c:169
-#7 0x45faad3a in CoreDispatchEventNotifies (Priority=3D0x10) at /Users/fi=
sh/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:185
-#8 0x45faa639 in CoreRestoreTpl (NewTpl=3D0x4) at /Users/fish/work/Migrat=
ion/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:114
-#9 0x45f9f197 in CoreReleaseLock (Lock=3D0x45fb1024) at /Users/fish/work/=
Migration/edk2/MdeModulePkg/Core/Dxe/Library/Library.c:102
-#10 0x45faabd6 in CoreReleaseEventLock () at /Users/fish/work/Migration/ed=
k2/MdeModulePkg/Core/Dxe/Event/Event.c:113
-#11 0x45fab26c in CoreCheckEvent (UserEvent=3D0x45603210) at /Users/fish/w=
ork/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:562
-#12 0x45fab2db in CoreWaitForEvent (NumberOfEvents=3D0x1, UserEvents=3D0x4=
5f94cc4, UserIndex=3D0x45f94cb8) at /Users/fish/work/Migration/edk2/MdeModu=
lePkg/Core/Dxe/Event/Event.c:621
-#13 0x49ce9557 in ?? ()
-#14 0x49cf0344 in ?? ()
-#15 0x49ce3bc2 in ?? ()
-#16 0x49ce3ae1 in ?? ()
-#17 0x45f9e4e3 in CoreStartImage (ImageHandle=3D0x49e31e10, ExitDataSize=
=3D0x45f94eec, ExitData=3D0x45f94ee8) at /Users/fish/work/Migration/edk2/Md=
eModulePkg/Core/Dxe/Image/Image.c:1260
-#18 0x4550cccc in BdsLibBootViaBootOption (Option=3D0x49ffa110, DevicePath=
=3D0x49ffa190, ExitDataSize=3D0x45f94eec, ExitData=3D0x45f94ee8) at /Users/=
fish/work/Migration/edk2/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsB=
oot.c:382
-#19 0x455252a9 in BdsBootDeviceSelect () at /Users/fish/work/Migration/edk=
2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:214
-#20 0x455255bc in BdsEntry (This=3D0x4552d01c) at /Users/fish/work/Migrati=
on/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:356
-#21 0x45fad7e8 in DxeMain (HobStart=3D0x45f70010) at /Users/fish/work/Migr=
ation/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:425
-#22 0x45fadd1d in ProcessModuleEntryPointList (HobStart=3D0x42020000) at /=
Users/fish/work/Migration/edk2/Build/Unix/DEBUG_XCODE32/IA32/MdeModulePkg/C=
ore/Dxe/DxeMain/DEBUG/AutoGen.c:287
-#23 0x45f97773 in _ModuleEntryPoint (HobStart=3D0x42020000) at /Users/fish=
/work/Migration/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54
-(gdb)=20
+(lldb) target create "./Host"
+Current executable set to '/Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_X=
CODE5/X64/Host' (x86_64).
+(lldb) command script import /Users/bcran/src/edk2/EmulatorPkg/Unix/lldbef=
i.py
+Type r to run emulator. SecLldbScriptBreak armed. EFI modules should now g=
et source level debugging in the emulator.
+(lldb) script lldb.debugger.SetAsync(True)
+(lldb) run
+Process 12155 launched: '/Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_XCO=
DE5/X64/Host' (x86_64)
+
+EDK II UNIX Host Emulation Environment from http://www.tianocore.org/edk2/
+ BootMode 0x00
+ OS Emulator passing in 128 KB of temp RAM at 0x102000000 to SEC
+ FD loaded from ../FV/FV_RECOVERY.fd at 0x102020000 contains SEC Core
+...
+```
+
+Type `process interrupt` at the lldb prompt (don't forget to hit carriage =
return) to pause execution. Ctrl-c in the terminal window will quit lldb. `=
bt` is the stack backtrace command:
+
+```
+Process 12420 stopped
+* thread #1, queue =3D 'com.apple.main-thread', stop reason =3D signal SIG=
STOP
+ frame #0: 0x00007fff2033cc22 libsystem_kernel.dylib:__semwait_signal()=
+ 10
+libsystem_kernel.dylib`__semwait_signal:
+-> 0x7fff2033cc22 <+10>: jae 0x7fff2033cc2c ; <+20>
+ 0x7fff2033cc24 <+12>: movq %rax, %rdi
+ 0x7fff2033cc27 <+15>: jmp 0x7fff2033b72d ; cerror
+ 0x7fff2033cc2c <+20>: retq
+Target 0: (Host) stopped.
+(lldb) bt
+* thread #1, queue =3D 'com.apple.main-thread', stop reason =3D signal SIG=
STOP
+ * frame #0: 0x00007fff2033cc22 libsystem_kernel.dylib:__semwait_signal()=
+ 10
+ frame #1: 0x00007fff202bcc2a libsystem_c.dylib:nanosleep() + 196
+ frame #2: 0x0000000100005e55 Host:SecCpuSleep() + 37 at /Users/bcran/s=
rc/edk2/EmulatorPkg/Unix/Host/EmuThunk.c:334
+ frame #3: 0x000000010000e96e Host:GasketSecCpuSleep() + 11 at /Users/b=
cran/src/edk2/Build/EmulatorX64/DEBUG_XCODE5/X64/EmulatorPkg/Unix/Host/Host=
/OUTPUT/X64/Gasket.iiii:283
+ frame #4: 0x0000000106f985e9 DxeCore.dll:CoreDispatchEventNotifies() +=
264 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:194
+ frame #5: 0x0000000106f97fce DxeCore.dll:CoreRestoreTpl() + 227 at /Us=
ers/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:131
+ frame #6: 0x0000000106f989db DxeCore.dll:CoreSignalEvent() + 111 at /U=
sers/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:566
+ frame #7: 0x0000000106f98b01 DxeCore.dll:CoreWaitForEvent() + 94 at /U=
sers/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:707
+ frame #8: 0x0000000113e8e54c BdsDxe.dll:BdsWaitForSingleEvent() + 127 =
at /Users/bcran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:250
+ frame #9: 0x0000000113e8e70b BdsDxe.dll:BdsWait() + 215 at /Users/bcra=
n/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:328
+ frame #10: 0x0000000113e8dffb BdsDxe.dll:BdsEntry() + 2612 at /Users/b=
cran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:1012
+ frame #11: 0x0000000106f9bbd6 DxeCore.dll:DxeMain() + 2791 at /Users/b=
cran/src/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:551
+ frame #12: 0x0000000106f9ed8f DxeCore.dll:_ModuleEntryPoint() + 20 at =
/Users/bcran/src/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:=
48
+ frame #13: 0x0000000106fdd02f DxeIpl.dll:InternalSwitchStack() + 15
+ frame #14: 0x0000000106fdc0b6 DxeIpl.dll:HandOffToDxeCore() + 546 at /=
Users/bcran/src/edk2/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c:126
+ frame #15: 0x0000000106fda78a DxeIpl.dll:DxeLoadCore() + 1354 at /User=
s/bcran/src/edk2/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:449
+ frame #16: 0x0000000106ff1d7c
+ frame #17: 0x00000001020255c6 PeiCore.dll:PeiCore() + 1982 at /Users/b=
cran/src/edk2/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c:331
+ frame #18: 0x000000010202a82c PeiCore.dll:PeiCheckAndSwitchStack() + 1=
171 at /Users/bcran/src/edk2/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c:=
842
+ frame #19: 0x000000010202b853 PeiCore.dll:PeiDispatcher() + 1206 at /U=
sers/bcran/src/edk2/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c:1609
+(lldb)
+
```
=20
# Build and Debug from Xcode
-To build from the Xcode GUI open ~/work/edk2/UnixPkg/Xcode/xcode_project/x=
code_project.xcodeproj. You can build, clean, and source level debug from=
the Xcode GUI. You can hit the Build and Debug button to start the build p=
rocess. You need to need to hit command-shift-B to show the output of the b=
uild. Click Pause to break into the debugger.
-
-[[File:Xcode.jpg]]
+To build from the Xcode GUI open ~/work/edk2/EmulatorPkg/Unix/Xcode/xcode_=
project64/xcode_project.xcodeproj. You can build, clean, and source level d=
ebug from the Xcode GUI. You can hit the Build and Debug button to start th=
e build process. You need to need to hit command-shift-B to show the output=
of the build. Click Pause to break into the debugger.
=20
The stack trace contains items that show as ?? since the default shell is =
checked in as a binary. `nanosleep$UNIX2003` and `__semwait_signal` are POS=
IX library calls and you do not get C source debug with these symbols.
=20
-# Source Level Debug Shell=20
-
-It is possible to get source level debug for the EFI Shell by pulling thes=
e projects from source control and building them.
-
-Instructions for building and hooking in the shell are located in the [htt=
ps://sourceforge.net/apps/mediawiki/tianocore/index.php?title=3DGcc-shell g=
cc-shell] project.
-
-Please note the gcc-shell and UnixPkg build separately, so if you update s=
hell code you need to build the shell to see the changes. The following scr=
een shot shows being able to source level debug the shell:
-
-[[File:Xcode_good.jpg]]
+*Note* The Xcode project is currently (as of 2021-05-09) broken.
=20
# See Also
=20
-* [[Step-by-step instructions]]
-
# Continue with common instructions
=20
-The [remaining instructions](../Common-instructions) are common for most U=
NIX-like systems.
+The [remaining instructions](https://github.com/tianocore/tianocore.github=
.io/wiki/Common-instructions-for-Unix) are common for most UNIX-like system=
s.
--=20
2.30.1 (Apple Git-130)


RFC: EXT4 filesystem driver

Pedro Falcato
 

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 package in
the future, if possible.

Current limitations:
1) The Ext4Dxe driver is, at the moment, read-only.
2) The Ext4Dxe driver at the moment cannot mount older (ext2/3)
filesystems. Ensuring compatibility with
those may not be a bad idea.

I intend to test the package using the UEFI SCTs present in edk2-test,
and implement any other needed unit tests myself using the already
available unit test framework. I also intend to (privately) fuzz the
UEFI driver with bad/unusual disk images, to improve the security and
reliability of the driver.

In the future, ext4 write support should be added so edk2 has a
fully-featured RW ext4 driver. There could also be a focus on
supporting the older ext4-like filesystems, as I mentioned in the
limitations, but that is open for discussion.

The driver's handling of unclean unmounting through forced shutdown is unclear.
Is there a position in edk2 on how to handle such cases? I don't think
FAT32 has a "this filesystem is/was dirty" and even though it seems to
me that stopping a system from booting/opening the partition because
"we may find some tiny irregularities" is not the best course of
action, I can't find a clear answer.

The driver also had to add implementations of CRC32C and CRC16, and
after talking with my mentor we quickly reached the conclusion that
these may be good candidates for inclusion in MdePkg. We also
discussed moving the Ucs2 <-> Utf8 conversion library in RedfishPkg
(BaseUcs2Utf8Lib) into MdePkg as well. Any comments?

Feel free to ask any questions you may find relevant.

Best Regards,

Pedro Falcato

6281 - 6300 of 84265