Date   

[PATCH] UefiPayloadPkg/PayloadLoader: Add more checks to verify ELF images

Ni, Ray
 

More checks are added to verify ELF image.
ParseElfImage() is changed to InitializeElfContext()

Signed-off-by: Ray Ni <ray.ni@...>
Cc: Marvin Häuser <mhaeuser@...>
Cc: Guo Dong <guo.dong@...>
Cc: Benjamin You <benjamin.you@...>
---
UefiPayloadPkg/PayloadLoaderPeim/ElfLib.h | 11 +-
.../PayloadLoaderPeim/ElfLib/Elf32Lib.c | 38 ++--
.../PayloadLoaderPeim/ElfLib/Elf64Lib.c | 39 ++--
.../PayloadLoaderPeim/ElfLib/ElfLib.c | 210 +++++++++++++-----
.../PayloadLoaderPeim/PayloadLoaderPeim.c | 6 +-
5 files changed, 188 insertions(+), 116 deletions(-)

diff --git a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib.h b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib.h
index 9cfc2912cf..0ed93140a9 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib.h
+++ b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib.h
@@ -17,7 +17,6 @@
#define ELF_PT_LOAD 1

typedef struct {
- RETURN_STATUS ParseStatus; ///< Return the status after ParseElfImage().
UINT8 *FileBase; ///< The source location in memory.
UINTN FileSize; ///< The size including sections that don't require loading.
UINT8 *PreferredImageAddress; ///< The preferred image to be loaded. No relocation is needed if loaded to this address.
@@ -45,7 +44,10 @@ typedef struct {
/**
Parse the ELF image info.

- @param[in] ImageBase Memory address of an image.
+ On return, all fields in ElfCt are updated except ImageAddress.
+
+ @param[in] FileBase Memory address of an image.
+ @param[in] MaxFileSize The maximum file size.
@param[out] ElfCt The EFL image context pointer.

@retval EFI_INVALID_PARAMETER Input parameters are not valid.
@@ -55,8 +57,9 @@ typedef struct {
**/
EFI_STATUS
EFIAPI
-ParseElfImage (
- IN VOID *ImageBase,
+InitializeElfContext (
+ IN VOID *FileBase,
+ IN UINTN MaxFileSize,
OUT ELF_IMAGE_CONTEXT *ElfCt
);

diff --git a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf32Lib.c b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf32Lib.c
index 3fa100ce4a..79f4ce623b 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf32Lib.c
+++ b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf32Lib.c
@@ -115,7 +115,7 @@ ProcessRelocation32 (
UINT32 Type;

for ( Index = 0
- ; RelaEntrySize * Index < RelaSize
+ ; Index < RelaSize / RelaEntrySize
; Index++, Rela = ELF_NEXT_ENTRY (Elf32_Rela, Rela, RelaEntrySize)
) {
//
@@ -137,7 +137,6 @@ ProcessRelocation32 (
// Dynamic section doesn't contain entries of this type.
//
DEBUG ((DEBUG_INFO, "Unsupported relocation type %02X\n", Type));
- ASSERT (FALSE);
} else {
*Ptr += (UINT32) Delta;
}
@@ -164,7 +163,6 @@ ProcessRelocation32 (
// Calculation: B + A
//
if (RelaType == SHT_RELA) {
- ASSERT (*Ptr == 0);
*Ptr = (UINT32) Delta + Rela->r_addend;
} else {
//
@@ -177,7 +175,6 @@ ProcessRelocation32 (
// non-Dynamic section doesn't contain entries of this type.
//
DEBUG ((DEBUG_INFO, "Unsupported relocation type %02X\n", Type));
- ASSERT (FALSE);
}
break;

@@ -236,12 +233,12 @@ RelocateElf32Dynamic (
//
// It's abnormal a DYN ELF doesn't contain a dynamic section.
//
- ASSERT (DynShdr != NULL);
if (DynShdr == NULL) {
return EFI_UNSUPPORTED;
}
- ASSERT (DynShdr->sh_type == SHT_DYNAMIC);
- ASSERT (DynShdr->sh_entsize >= sizeof (*Dyn));
+ if ((DynShdr->sh_type != SHT_DYNAMIC) || DynShdr->sh_entsize < sizeof (*Dyn)) {
+ return EFI_UNSUPPORTED;
+ }

//
// 2. Locate the relocation section from the dynamic section.
@@ -286,9 +283,6 @@ RelocateElf32Dynamic (
}

if (RelaOffset == MAX_UINT64) {
- ASSERT (RelaCount == 0);
- ASSERT (RelaEntrySize == 0);
- ASSERT (RelaSize == 0);
//
// It's fine that a DYN ELF doesn't contain relocation section.
//
@@ -299,23 +293,22 @@ RelocateElf32Dynamic (
// Verify the existence of the relocation section.
//
RelShdr = GetElf32SectionByRange (ElfCt->FileBase, RelaOffset, RelaSize);
- ASSERT (RelShdr != NULL);
if (RelShdr == NULL) {
return EFI_UNSUPPORTED;
}
- ASSERT (RelShdr->sh_type == RelaType);
- ASSERT (RelShdr->sh_entsize == RelaEntrySize);
+ if ((RelShdr->sh_type != RelaType) || (RelShdr->sh_entsize != RelaEntrySize)) {
+ return EFI_UNSUPPORTED;
+ }

//
// 3. Process the relocation section.
//
- ProcessRelocation32 (
- (Elf32_Rela *) (ElfCt->FileBase + RelShdr->sh_offset),
- RelShdr->sh_size, RelShdr->sh_entsize, RelShdr->sh_type,
- (UINTN) ElfCt->ImageAddress - (UINTN) ElfCt->PreferredImageAddress,
- TRUE
- );
- return EFI_SUCCESS;
+ return ProcessRelocation32 (
+ (Elf32_Rela *) (ElfCt->FileBase + RelShdr->sh_offset),
+ RelShdr->sh_size, RelShdr->sh_entsize, RelShdr->sh_type,
+ (UINTN) ElfCt->ImageAddress - (UINTN) ElfCt->PreferredImageAddress,
+ TRUE
+ );
}

/**
@@ -331,7 +324,6 @@ RelocateElf32Sections (
IN ELF_IMAGE_CONTEXT *ElfCt
)
{
- EFI_STATUS Status;
Elf32_Ehdr *Ehdr;
Elf32_Shdr *RelShdr;
Elf32_Shdr *Shdr;
@@ -351,9 +343,7 @@ RelocateElf32Sections (
//
if (Ehdr->e_type == ET_DYN) {
DEBUG ((DEBUG_INFO, "DYN ELF: Relocate using dynamic sections...\n"));
- Status = RelocateElf32Dynamic (ElfCt);
- ASSERT_EFI_ERROR (Status);
- return Status;
+ return RelocateElf32Dynamic (ElfCt);
}

//
diff --git a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c
index e364807007..cfe70639ca 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c
+++ b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/Elf64Lib.c
@@ -115,7 +115,7 @@ ProcessRelocation64 (
UINT32 Type;

for ( Index = 0
- ; MultU64x64 (RelaEntrySize, Index) < RelaSize
+ ; Index < DivU64x64Remainder (RelaSize, RelaEntrySize, NULL)
; Index++, Rela = ELF_NEXT_ENTRY (Elf64_Rela, Rela, RelaEntrySize)
) {
//
@@ -138,7 +138,6 @@ ProcessRelocation64 (
// Dynamic section doesn't contain entries of this type.
//
DEBUG ((DEBUG_INFO, "Unsupported relocation type %02X\n", Type));
- ASSERT (FALSE);
} else {
*Ptr += Delta;
}
@@ -149,7 +148,6 @@ ProcessRelocation64 (
// Dynamic section doesn't contain entries of this type.
//
DEBUG ((DEBUG_INFO, "Unsupported relocation type %02X\n", Type));
- ASSERT (FALSE);
break;

case R_X86_64_RELATIVE:
@@ -173,7 +171,6 @@ ProcessRelocation64 (
// Calculation: B + A
//
if (RelaType == SHT_RELA) {
- ASSERT (*Ptr == 0);
*Ptr = Delta + Rela->r_addend;
} else {
//
@@ -186,7 +183,6 @@ ProcessRelocation64 (
// non-Dynamic section doesn't contain entries of this type.
//
DEBUG ((DEBUG_INFO, "Unsupported relocation type %02X\n", Type));
- ASSERT (FALSE);
}
break;

@@ -245,12 +241,12 @@ RelocateElf64Dynamic (
//
// It's abnormal a DYN ELF doesn't contain a dynamic section.
//
- ASSERT (DynShdr != NULL);
if (DynShdr == NULL) {
return EFI_UNSUPPORTED;
}
- ASSERT (DynShdr->sh_type == SHT_DYNAMIC);
- ASSERT (DynShdr->sh_entsize >= sizeof (*Dyn));
+ if ((DynShdr->sh_type != SHT_DYNAMIC) || DynShdr->sh_entsize < sizeof (*Dyn)) {
+ return EFI_UNSUPPORTED;
+ }

//
// 2. Locate the relocation section from the dynamic section.
@@ -295,9 +291,6 @@ RelocateElf64Dynamic (
}

if (RelaOffset == MAX_UINT64) {
- ASSERT (RelaCount == 0);
- ASSERT (RelaEntrySize == 0);
- ASSERT (RelaSize == 0);
//
// It's fine that a DYN ELF doesn't contain relocation section.
//
@@ -308,23 +301,22 @@ RelocateElf64Dynamic (
// Verify the existence of the relocation section.
//
RelShdr = GetElf64SectionByRange (ElfCt->FileBase, RelaOffset, RelaSize);
- ASSERT (RelShdr != NULL);
if (RelShdr == NULL) {
return EFI_UNSUPPORTED;
}
- ASSERT (RelShdr->sh_type == RelaType);
- ASSERT (RelShdr->sh_entsize == RelaEntrySize);
+ if ((RelShdr->sh_type != RelaType) || (RelShdr->sh_entsize != RelaEntrySize)) {
+ return EFI_UNSUPPORTED;
+ }

//
// 3. Process the relocation section.
//
- ProcessRelocation64 (
- (Elf64_Rela *) (ElfCt->FileBase + RelShdr->sh_offset),
- RelShdr->sh_size, RelShdr->sh_entsize, RelShdr->sh_type,
- (UINTN) ElfCt->ImageAddress - (UINTN) ElfCt->PreferredImageAddress,
- TRUE
- );
- return EFI_SUCCESS;
+ return ProcessRelocation64 (
+ (Elf64_Rela *) (ElfCt->FileBase + RelShdr->sh_offset),
+ RelShdr->sh_size, RelShdr->sh_entsize, RelShdr->sh_type,
+ (UINTN) ElfCt->ImageAddress - (UINTN) ElfCt->PreferredImageAddress,
+ TRUE
+ );
}

/**
@@ -340,7 +332,6 @@ RelocateElf64Sections (
IN ELF_IMAGE_CONTEXT *ElfCt
)
{
- EFI_STATUS Status;
Elf64_Ehdr *Ehdr;
Elf64_Shdr *RelShdr;
Elf64_Shdr *Shdr;
@@ -360,9 +351,7 @@ RelocateElf64Sections (
//
if (Ehdr->e_type == ET_DYN) {
DEBUG ((DEBUG_INFO, "DYN ELF: Relocate using dynamic sections...\n"));
- Status = RelocateElf64Dynamic (ElfCt);
- ASSERT_EFI_ERROR (Status);
- return Status;
+ return RelocateElf64Dynamic (ElfCt);
}

//
diff --git a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/ElfLib.c b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/ElfLib.c
index 531b3486d2..70de81c3ac 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/ElfLib.c
+++ b/UefiPayloadPkg/PayloadLoaderPeim/ElfLib/ElfLib.c
@@ -11,22 +11,32 @@
/**
Check if the ELF image is valid.

- @param[in] ImageBase Memory address of an image.
+ @param[in] FileBase Memory address of an image.
+ @param[in] MaxFileSize The maximum file size.

@retval TRUE if valid.

**/
BOOLEAN
IsElfFormat (
- IN CONST UINT8 *ImageBase
+ IN CONST UINT8 *FileBase,
+ IN UINTN MaxFileSize
)
{
Elf32_Ehdr *Elf32Hdr;
Elf64_Ehdr *Elf64Hdr;

- ASSERT (ImageBase != NULL);
+ ASSERT (FileBase != NULL);

- Elf32Hdr = (Elf32_Ehdr *)ImageBase;
+ Elf32Hdr = (Elf32_Ehdr *)FileBase;
+ Elf64Hdr = (Elf64_Ehdr *)FileBase;
+
+ //
+ // Make sure MaxFileSize covers e_ident[].
+ //
+ if (MaxFileSize < sizeof (Elf32Hdr->e_ident)) {
+ return FALSE;
+ }

//
// Start with correct signature "\7fELF"
@@ -50,15 +60,13 @@ IsElfFormat (
// Check 32/64-bit architecture
//
if (Elf32Hdr->e_ident[EI_CLASS] == ELFCLASS64) {
- Elf64Hdr = (Elf64_Ehdr *)Elf32Hdr;
- Elf32Hdr = NULL;
- } else if (Elf32Hdr->e_ident[EI_CLASS] == ELFCLASS32) {
- Elf64Hdr = NULL;
- } else {
- return FALSE;
- }
+ //
+ // Before accessing fields in Elf64_Ehdr, make sure the MaxFileSize covers the entire header.
+ //
+ if (MaxFileSize < sizeof (Elf64_Ehdr)) {
+ return FALSE;
+ }

- if (Elf64Hdr != NULL) {
//
// Support intel architecture only for now
//
@@ -79,7 +87,7 @@ IsElfFormat (
if (Elf64Hdr->e_version != EV_CURRENT) {
return FALSE;
}
- } else {
+ } else if (Elf32Hdr->e_ident[EI_CLASS] == ELFCLASS32) {
//
// Support intel architecture only for now
//
@@ -100,7 +108,10 @@ IsElfFormat (
if (Elf32Hdr->e_version != EV_CURRENT) {
return FALSE;
}
+ } else {
+ return FALSE;
}
+
return TRUE;
}

@@ -108,6 +119,7 @@ IsElfFormat (
Calculate a ELF file size.

@param[in] ElfCt ELF image context pointer.
+ @param[in] MaxFileSize The maximum file size.
@param[out] FileSize Return the file size.

@retval EFI_INVALID_PARAMETER ElfCt or SecPos is NULL.
@@ -117,12 +129,12 @@ IsElfFormat (
EFI_STATUS
CalculateElfFileSize (
IN ELF_IMAGE_CONTEXT *ElfCt,
+ IN UINTN MaxFileSize,
OUT UINTN *FileSize
)
{
EFI_STATUS Status;
- UINTN FileSize1;
- UINTN FileSize2;
+ UINT32 Index;
Elf32_Ehdr *Elf32Hdr;
Elf64_Ehdr *Elf64Hdr;
UINTN Offset;
@@ -132,24 +144,34 @@ CalculateElfFileSize (
return EFI_INVALID_PARAMETER;
}

- // Use last section as end of file
- Status = GetElfSectionPos (ElfCt, ElfCt->ShNum - 1, &Offset, &Size);
- if (EFI_ERROR(Status)) {
- return EFI_UNSUPPORTED;
- }
- FileSize1 = Offset + Size;
-
- // Use end of section header as end of file
- FileSize2 = 0;
+ //
+ // Optional section headers might exist in the end of file.
+ //
+ *FileSize = 0;
if (ElfCt->EiClass == ELFCLASS32) {
Elf32Hdr = (Elf32_Ehdr *)ElfCt->FileBase;
- FileSize2 = Elf32Hdr->e_shoff + Elf32Hdr->e_shentsize * Elf32Hdr->e_shnum;
+ *FileSize = Elf32Hdr->e_shoff + Elf32Hdr->e_shentsize * Elf32Hdr->e_shnum;
} else if (ElfCt->EiClass == ELFCLASS64) {
Elf64Hdr = (Elf64_Ehdr *)ElfCt->FileBase;
- FileSize2 = (UINTN)(Elf64Hdr->e_shoff + Elf64Hdr->e_shentsize * Elf64Hdr->e_shnum);
+ *FileSize = (UINTN)(Elf64Hdr->e_shoff + Elf64Hdr->e_shentsize * Elf64Hdr->e_shnum);
}

- *FileSize = MAX(FileSize1, FileSize2);
+ //
+ // Get the end of section body.
+ //
+ for (Index = 0; Index < ElfCt->ShNum; Index++) {
+ Status = GetElfSectionPos (ElfCt, Index, &Offset, &Size);
+ if (EFI_ERROR (Status)) {
+ return Status;
+ }
+ if ((Offset >= MaxFileSize) || (Size > MaxFileSize - Offset)) {
+ //
+ // Section body is outside of file range.
+ //
+ return EFI_UNSUPPORTED;
+ }
+ *FileSize = MAX (*FileSize, Offset + Size);
+ }

return EFI_SUCCESS;
}
@@ -213,7 +235,8 @@ GetElfSegmentInfo (

On return, all fields in ElfCt are updated except ImageAddress.

- @param[in] ImageBase Memory address of an image.
+ @param[in] FileBase Memory address of an image.
+ @param[in] MaxFileSize The maximum file size.
@param[out] ElfCt The EFL image context pointer.

@retval EFI_INVALID_PARAMETER Input parameters are not valid.
@@ -223,8 +246,9 @@ GetElfSegmentInfo (
**/
EFI_STATUS
EFIAPI
-ParseElfImage (
- IN VOID *ImageBase,
+InitializeElfContext (
+ IN VOID *FileBase,
+ IN UINTN MaxFileSize,
OUT ELF_IMAGE_CONTEXT *ElfCt
)
{
@@ -238,30 +262,58 @@ ParseElfImage (
UINTN End;
UINTN Base;

- if (ElfCt == NULL) {
- return EFI_INVALID_PARAMETER;
- }
+ ASSERT (ElfCt != NULL);
+
ZeroMem (ElfCt, sizeof(ELF_IMAGE_CONTEXT));

- if (ImageBase == NULL) {
- return (ElfCt->ParseStatus = EFI_INVALID_PARAMETER);
+ if (FileBase == NULL) {
+ return EFI_INVALID_PARAMETER;
}

- ElfCt->FileBase = (UINT8 *)ImageBase;
- if (!IsElfFormat (ElfCt->FileBase)) {
- return (ElfCt->ParseStatus = EFI_UNSUPPORTED);
+ ElfCt->FileBase = (UINT8 *)FileBase;
+ if (!IsElfFormat (ElfCt->FileBase, MaxFileSize)) {
+ return EFI_UNSUPPORTED;
}

Elf32Hdr = (Elf32_Ehdr *)ElfCt->FileBase;
ElfCt->EiClass = Elf32Hdr->e_ident[EI_CLASS];
if (ElfCt->EiClass == ELFCLASS32) {
if ((Elf32Hdr->e_type != ET_EXEC) && (Elf32Hdr->e_type != ET_DYN)) {
- return (ElfCt->ParseStatus = EFI_UNSUPPORTED);
+ return EFI_UNSUPPORTED;
}
- Elf32Shdr = (Elf32_Shdr *)GetElf32SectionByIndex (ElfCt->FileBase, Elf32Hdr->e_shstrndx);
+
+ if ((Elf32Hdr->e_phoff >= MaxFileSize) || ((UINT32) (Elf32Hdr->e_phentsize * Elf32Hdr->e_phnum) > MaxFileSize - Elf32Hdr->e_phoff)) {
+ //
+ // Program headers are outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
+ }
+
+ if ((Elf32Hdr->e_shoff >= MaxFileSize) || ((UINT32) (Elf32Hdr->e_shentsize * Elf32Hdr->e_shnum) > MaxFileSize - Elf32Hdr->e_shoff)) {
+ //
+ // Section headers are outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
+ }
+
+ if (Elf32Hdr->e_entry >= MaxFileSize) {
+ //
+ // Entrypoint is outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
+ }
+
+ Elf32Shdr = GetElf32SectionByIndex (ElfCt->FileBase, Elf32Hdr->e_shstrndx);
if (Elf32Shdr == NULL) {
- return (ElfCt->ParseStatus = EFI_UNSUPPORTED);
+ return EFI_UNSUPPORTED;
}
+ if ((Elf32Shdr->sh_offset >= MaxFileSize) || (Elf32Shdr->sh_size > MaxFileSize - Elf32Shdr->sh_offset)) {
+ //
+ // String section is outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
+ }
+
ElfCt->EntryPoint = (UINTN)Elf32Hdr->e_entry;
ElfCt->ShNum = Elf32Hdr->e_shnum;
ElfCt->PhNum = Elf32Hdr->e_phnum;
@@ -270,12 +322,41 @@ ParseElfImage (
} else {
Elf64Hdr = (Elf64_Ehdr *)Elf32Hdr;
if ((Elf64Hdr->e_type != ET_EXEC) && (Elf64Hdr->e_type != ET_DYN)) {
- return (ElfCt->ParseStatus = EFI_UNSUPPORTED);
+ return EFI_UNSUPPORTED;
+ }
+
+ if ((Elf64Hdr->e_phoff >= MaxFileSize) || ((UINT32) Elf64Hdr->e_phentsize * Elf64Hdr->e_phnum > MaxFileSize - (UINTN) Elf64Hdr->e_phoff)) {
+ //
+ // Program headers are outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
+ }
+
+ if ((Elf64Hdr->e_shoff >= MaxFileSize) || ((UINT32) Elf64Hdr->e_shentsize * Elf64Hdr->e_shnum > MaxFileSize - (UINTN) Elf64Hdr->e_shoff)) {
+ //
+ // Section headers are outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
+ }
+
+ if (Elf64Hdr->e_entry >= MaxFileSize) {
+ //
+ // Entrypoint is outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
}
- Elf64Shdr = (Elf64_Shdr *)GetElf64SectionByIndex (ElfCt->FileBase, Elf64Hdr->e_shstrndx);
+
+ Elf64Shdr = GetElf64SectionByIndex (ElfCt->FileBase, Elf64Hdr->e_shstrndx);
if (Elf64Shdr == NULL) {
- return (ElfCt->ParseStatus = EFI_UNSUPPORTED);
+ return EFI_UNSUPPORTED;
+ }
+ if ((Elf64Shdr->sh_offset >= MaxFileSize) || (Elf64Shdr->sh_size > MaxFileSize - Elf64Shdr->sh_offset)) {
+ //
+ // String section is outside of the file range.
+ //
+ return EFI_UNSUPPORTED;
}
+
ElfCt->EntryPoint = (UINTN)Elf64Hdr->e_entry;
ElfCt->ShNum = Elf64Hdr->e_shnum;
ElfCt->PhNum = Elf64Hdr->e_phnum;
@@ -297,6 +378,13 @@ ParseElfImage (
continue;
}

+ //
+ // Loadable process segments must have congruent values for p_vaddr and p_offset, modulo the page size.
+ //
+ if ((SegInfo.MemAddr % EFI_PAGE_SIZE) != (SegInfo.Offset % EFI_PAGE_SIZE)) {
+ return EFI_UNSUPPORTED;
+ }
+
if (SegInfo.MemLen != SegInfo.Length) {
//
// Not enough space to execute at current location.
@@ -317,8 +405,7 @@ ParseElfImage (
ElfCt->ImageSize = End - Base + 1;
ElfCt->PreferredImageAddress = (VOID *) Base;

- CalculateElfFileSize (ElfCt, &ElfCt->FileSize);
- return (ElfCt->ParseStatus = EFI_SUCCESS);;
+ return CalculateElfFileSize (ElfCt, MaxFileSize, &ElfCt->FileSize);
}

/**
@@ -348,10 +435,6 @@ LoadElfImage (
return EFI_INVALID_PARAMETER;
}

- if (EFI_ERROR (ElfCt->ParseStatus)) {
- return ElfCt->ParseStatus;
- }
-
if (ElfCt->ImageAddress == NULL) {
return EFI_INVALID_PARAMETER;
}
@@ -370,6 +453,8 @@ LoadElfImage (
/**
Get a ELF section name from its index.

+ ElfCt is returned from InitializeElfContext().
+
@param[in] ElfCt ELF image context pointer.
@param[in] SectionIndex ELF section index.
@param[out] SectionName The pointer to the section name.
@@ -389,25 +474,25 @@ GetElfSectionName (
Elf32_Shdr *Elf32Shdr;
Elf64_Shdr *Elf64Shdr;
CHAR8 *Name;
+ UINTN MaxSize;

if ((ElfCt == NULL) || (SectionName == NULL)) {
return EFI_INVALID_PARAMETER;
}

- if (EFI_ERROR (ElfCt->ParseStatus)) {
- return ElfCt->ParseStatus;
- }
-
- Name = NULL;
+ Name = NULL;
+ MaxSize = 0;
if (ElfCt->EiClass == ELFCLASS32) {
Elf32Shdr = GetElf32SectionByIndex (ElfCt->FileBase, SectionIndex);
if ((Elf32Shdr != NULL) && (Elf32Shdr->sh_name < ElfCt->ShStrLen)) {
- Name = (CHAR8 *)(ElfCt->FileBase + ElfCt->ShStrOff + Elf32Shdr->sh_name);
+ Name = (CHAR8 *)(ElfCt->FileBase + ElfCt->ShStrOff + Elf32Shdr->sh_name);
+ MaxSize = ElfCt->ShStrLen - Elf32Shdr->sh_name;
}
} else if (ElfCt->EiClass == ELFCLASS64) {
Elf64Shdr = GetElf64SectionByIndex (ElfCt->FileBase, SectionIndex);
if ((Elf64Shdr != NULL) && (Elf64Shdr->sh_name < ElfCt->ShStrLen)) {
- Name = (CHAR8 *)(ElfCt->FileBase + ElfCt->ShStrOff + Elf64Shdr->sh_name);
+ Name = (CHAR8 *)(ElfCt->FileBase + ElfCt->ShStrOff + Elf64Shdr->sh_name);
+ MaxSize = ElfCt->ShStrLen - Elf64Shdr->sh_name;
}
}

@@ -415,6 +500,13 @@ GetElfSectionName (
return EFI_NOT_FOUND;
}

+ if (AsciiStrnLenS (Name, MaxSize) == MaxSize) {
+ //
+ // No null terminator is found for the section name.
+ //
+ return EFI_NOT_FOUND;
+ }
+
*SectionName = Name;
return EFI_SUCCESS;
}
@@ -449,10 +541,6 @@ GetElfSectionPos (
return EFI_INVALID_PARAMETER;
}

- if (EFI_ERROR (ElfCt->ParseStatus)) {
- return ElfCt->ParseStatus;
- }
-
if (ElfCt->EiClass == ELFCLASS32) {
Elf32Shdr = GetElf32SectionByIndex (ElfCt->FileBase, Index);
if (Elf32Shdr != NULL) {
diff --git a/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.c b/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.c
index 44639f9fd2..efedaef1b3 100644
--- a/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.c
+++ b/UefiPayloadPkg/PayloadLoaderPeim/PayloadLoaderPeim.c
@@ -69,8 +69,10 @@ PeiLoadFileLoadPayload (
return Status;
}

- ZeroMem (&Context, sizeof (Context));
- Status = ParseElfImage (Elf, &Context);
+ //
+ // Trust the ELF image loaded from FV.
+ //
+ Status = InitializeElfContext (Elf, MAX_UINTN - (UINTN) Elf, &Context);
} while (EFI_ERROR (Status));

DEBUG ((
--
2.31.1.windows.1


[PATCH v1 1/1] Pytool: SpellCheck: Defer path expansion in cspell parameters

Kun Qin
 

From: Sean Brogan <sean.brogan@...>

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

On Linux the shell expands the wildcard paths and causes multiple files
to be missed. This change adds additional quotes to defer expansion in
order to bring parity in cspell result.

Cc: Sean Brogan <sean.brogan@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>

Signed-off-by: Sean Brogan <sean.brogan@...>
---
.pytool/Plugin/SpellCheck/SpellCheck.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.pytool/Plugin/SpellCheck/SpellCheck.py b/.pytool/Plugin/SpellCheck/SpellCheck.py
index 43365441b91c..97b240ef747c 100644
--- a/.pytool/Plugin/SpellCheck/SpellCheck.py
+++ b/.pytool/Plugin/SpellCheck/SpellCheck.py
@@ -133,7 +133,8 @@ class SpellCheck(ICiBuildPlugin):
#
relpath = os.path.relpath(abs_pkg_path)
cpsell_paths = " ".join(
- [f"{relpath}/**/{x}" for x in package_relative_paths_to_spell_check])
+ # Double quote each path to defer expansion to cspell parameters
+ [f'"{relpath}/**/{x}"' for x in package_relative_paths_to_spell_check])

# Make the config file
config_file_path = os.path.join(
--
2.31.1.windows.1


[PATCH v1 0/1] SpellCheck plugin inspects fewer files when run on Linux

Kun Qin
 

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

When spellcheck plugin invokes cspell to check files, it uses wildcard
path patterns, i.e. <package>/**/*.h.

On Linux system, this will be expanded by the shell therefore fewer files
will be picked up than speficied through original command line.

To resolve this issue, the path needs double quoting. So that the shell
does not expand and the input parameter is passed to cspell to expand.

Patch v1 branch: https://github.com/kuqin12/edk2/tree/exp_shell_v1

Cc: Sean Brogan <sean.brogan@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>

Sean Brogan (1):
Pytool: SpellCheck: Defer path expansion in cspell parameters

.pytool/Plugin/SpellCheck/SpellCheck.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--
2.31.1.windows.1


Re: Help with debugging

Ethin Probst
 

Yeah, maybe. Now I just have to figure out where to even begin with
USB audio. The specs aren't useful in determining where to begin -- or
at least they aren't from my POV (though that might just be my
inexperience with USB/XHCI showing).

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 4:29 PM, Ethin Probst <harlydavidsen@...>
wrote:

Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!
OK that makes sense. The address in the add-symbol-file command is not the
load address of the image, but the start address of the text section. So
that is why you had to add 0x240.

Sorry I had to work backwards from how it works, but maybe that info will be
helpful for others?

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...>
wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file
"Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0 0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1 ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2 _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3 0x000000007fead316 in ?? ()
#4 0x000000007e4f7518 in ?? ()
#5 0x000000007feab5c7 in ?? ()
#6 0x000000007fea3520 in ?? ()
#7 0x0000000101000000 in ?? ()
#8 0x0000000000000030 in ?? ()
#9 0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2 GCC inline implementation of BaseLib processor specific functions.
3
4 Copyright (c) 2006 - 2020, Intel Corporation. All rights
reserved.<BR>
5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6 SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
OK that is interesting…. +576 -> 0x240 witch is about the size of the
PE/COFF header.

For mach-O (macOS executables) we have to link at 0x240 to make space
for
the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section
starts at 0x7e4b8240? So try adding 0x240 to the load address on the
add-symbol-file command. If that does not work trip subtracting 0x240
from
the load address.

We would need to dump out the UsbAudio.efi file to figure out exactly
what
is going on. What distro are you on? Do you have the readpe utility? I’m
not
sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick
look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's
what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB
myself.
:)
What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>>>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs
or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac.
There
is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote
9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst
<harlydavidsen@... <mailto:harlydavidsen@...>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>
<mailto:harlydavidsen@...
<mailto:harlydavidsen@...>>>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd
reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I
do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>>) like this (from the
main
EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev
alsa,id=audio
-s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev
alsa,id=audio
-s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait
until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code
but
the
image isn't loaded anymore), and resetting the system and placing
a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers
and
the image base and entry point addresses, and then appears to
just
sit
there waiting for something. Once I load the symbols using the
image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump
into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I
might
be
a
little off on gdb specifics…. Also my terminology may be lldb
centric.

Easy one 1st. When you run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you
don’t
have
a
debugger hooked in underneath the exception 3 is going to get
handled
in
the unexpected exception handler, and that is probably in the CPUD
DXE
driver or DXE Core or some such. So you are going to end up with
the
PC/IP/RIP in the wrong driver. A lot of times for hardware
debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU
acts
a
lot
more like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the
CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target
for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there
is
a
handshake that describes the target and what registers are
available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So
this
changing the target definition might confuse the debugger. To be
safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why
you
need
to
specify the load address to get the symbols to resolve. One trick
I
use
is
to load the ELF (or PE/COFF) build output directly into the
debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read
any
variables. This can be useful if you get the unhandled exception
and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded
at
the
correct address, as you can see what bytes/instructions should be
at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst

--
Signed,
Ethin D. Probst


--
Signed,
Ethin D. Probst


Re: 回复: [edk2-devel] [PATCH v1 1/1] Pytool: SpellCheck: Fix incorrect file mask across package matrices

Kun Qin
 

Thanks for the review, Liming. Could you please help merging this patch to the master when you have a chance?

Thanks in advance!
Kun

On 06/10/2021 20:23, gaoliming wrote:
Reviewed-by: Liming Gao <gaoliming@...>

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Kun Qin
发送时间: 2021年6月10日 9:48
收件人: devel@edk2.groups.io
抄送: Sean Brogan <sean.brogan@...>; Bret Barkelew
<Bret.Barkelew@...>; Michael D Kinney
<michael.d.kinney@...>; Liming Gao <gaoliming@...>
主题: [edk2-devel] [PATCH v1 1/1] Pytool: SpellCheck: Fix incorrect file
mask
across package matrices

From: Sean Brogan <spbrogan@...>

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

Existing implementation could modify class global data that causes
potential incorrect file mask to be used for execution of plugin.

This change switches class variable to be tuple so that it cannot be
accidently modified. Local usage of STANDARD_PLUGIN_DEFINED_PATHS is
also
changed to copy to new list before modification.

Cc: Sean Brogan <sean.brogan@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>

Signed-off-by: Sean Brogan <sean.brogan@...>
---
.pytool/Plugin/SpellCheck/SpellCheck.py | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/.pytool/Plugin/SpellCheck/SpellCheck.py
b/.pytool/Plugin/SpellCheck/SpellCheck.py
index 43365441b91c..9ad57632a6e8 100644
--- a/.pytool/Plugin/SpellCheck/SpellCheck.py
+++ b/.pytool/Plugin/SpellCheck/SpellCheck.py
@@ -37,12 +37,12 @@ class SpellCheck(ICiBuildPlugin):
#
# A package can remove any of these using IgnoreStandardPaths
#
- STANDARD_PLUGIN_DEFINED_PATHS = ["*.c", "*.h",
+ STANDARD_PLUGIN_DEFINED_PATHS = ("*.c", "*.h",
"*.nasm", "*.asm", "*.masm",
"*.s",
"*.asl",
"*.dsc", "*.dec", "*.fdf",
"*.inf",
"*.md", "*.txt"
- ]
+ )

def GetTestName(self, packagename: str, environment: VarDict) ->
tuple:
""" Provide the testcase name and classname for use in reporting
@@ -107,7 +107,8 @@ class SpellCheck(ICiBuildPlugin):
version_aggregator.GetVersionAggregator().ReportVersion(
"CSpell", cspell_version,
version_aggregator.VersionTypes.INFO)

- package_relative_paths_to_spell_check =
SpellCheck.STANDARD_PLUGIN_DEFINED_PATHS
+ # copy the default as a list
+ package_relative_paths_to_spell_check =
list(SpellCheck.STANDARD_PLUGIN_DEFINED_PATHS)

#
# Allow the ci.yaml to remove any of the above standard paths
--
2.31.1.windows.1




Re: CI is failing - June 2021

Kun Qin
 

Thanks for the heads up, Sean.

The patch series was just sent for review: https://edk2.groups.io/g/devel/message/76419.

The PR that passes all checks against this branch is here: https://github.com/tianocore/edk2/pull/1705

Any feedback is appreciated.

Regards,
Kun

On 06/11/2021 20:41, Sean wrote:
The CI system is failing around the spellcheck plugin.
https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=23772&view=results The patch never got merged (15 months ago and again 8 months ago) to update nodejs to a newer version.  See bug https://bugzilla.tianocore.org/show_bug.cgi?id=2618
This has now caused the spell checker to stop working and is then causing an error which is breaking the CI builds.
Updating Node resolves this error.
But after updating a few packages fail because of spelling errors. ArmPkg, ArmPlatformPkg, and StandaloneMMPkg.
More info being tracked in this
https://bugzilla.tianocore.org/show_bug.cgi?id=3445
Please prioritize reviewing the patch series that will be sent out soon
FYI - There is also another bug that is hiding a few of the spelling failures on linux machines.
https://bugzilla.tianocore.org/show_bug.cgi?id=3454
Thanks
Sean


[PATCH v1 4/4] Azurepipeline: SpellCheck: Enforce Node dependency to use version 14.x

Kun Qin
 

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

Per update from Cspell tool, the minimal requirement of Cspell 5.x
regarding Node is 12 and above. This has caused multple Cspell failures
during CI build validation:
"Failed to process "**.c" TypeError: text.matchAll(...) is not a function
or its return value is not iterable"

This change updates the lowest required node version to 14.x to support
Cspell functionalities.

Cc: Sean Brogan <sean.brogan@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>

Signed-off-by: Kun Qin <kuqin12@...>
---
.azurepipelines/templates/spell-check-prereq-steps.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/spell-check-prereq-steps.yml b/.azurepipelines/templates/spell-check-prereq-steps.yml
index e1570d4f2aac..98ee3cfa6bc6 100644
--- a/.azurepipelines/templates/spell-check-prereq-steps.yml
+++ b/.azurepipelines/templates/spell-check-prereq-steps.yml
@@ -13,7 +13,7 @@ parameters:
steps:
- task: NodeTool@0
inputs:
- versionSpec: '10.x'
+ versionSpec: '14.x'
#checkLatest: false # Optional
condition: and(gt(variables.pkg_count, 0), succeeded())

--
2.31.1.windows.1


[PATCH v1 3/4] ArmPkg: SpellCheck: Update valid acronyms in ExtendedWords

Kun Qin
 

From: Sean Brogan <sean.brogan@...>

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

Spellcheck was not covering all specified files due to CSpell v5 and
Node v10 incompatibility of current CI pipeline configuration.

This change updates ExtendedWords for ArmPkg with valid acronyms to avoid
potential spell errors.

Cc: Laszlo Ersek <lersek@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>

Signed-off-by: Kun Qin <kuqin12@...>
Signed-off-by: Sean Brogan <sean.brogan@...>
---
ArmPkg/ArmPkg.ci.yaml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/ArmPkg/ArmPkg.ci.yaml b/ArmPkg/ArmPkg.ci.yaml
index d91c03f2acb8..a0d6a75fe881 100644
--- a/ArmPkg/ArmPkg.ci.yaml
+++ b/ArmPkg/ArmPkg.ci.yaml
@@ -94,13 +94,18 @@
"ackintid",
"actlr",
"aeabi",
+ "asedis",
"ashldi",
"ashrdi",
+ "baddr",
"ccidx",
"ccsidr",
"clidr",
"clrex",
"clzsi",
+ "cnthctl",
+ "cortexa",
+ "cpacr",
"cpuactlr",
"csselr",
"ctzsi",
@@ -116,6 +121,7 @@
"divdi",
"divsi",
"dmdepkg",
+ "dpref",
"drsub",
"fcmpeq",
"fcmpge",
@@ -125,17 +131,25 @@
"ffreestanding",
"frsub",
"hisilicon",
+ "iccabpr",
"iccbpr",
"icciar",
"iccicr",
"icciidr",
+ "iccpir",
"iccpmr",
+ "iccrpr",
+ "icdabr",
"icdicer",
"icdicfr",
+ "icdicpr",
"icdictr",
+ "icdiidr",
"icdiser",
"icdisr",
+ "icdppisr",
"icdsgir",
+ "icdspr",
"icenabler",
"intid",
"ipriority",
@@ -160,6 +174,7 @@
"lshrdi",
"moddi",
"modsi",
+ "mpcore",
"mpidr",
"muldi",
"mullu",
@@ -168,6 +183,9 @@
"nsasedis",
"nuvia",
"oldit",
+ "pcten",
+ "plpis",
+ "procno",
"readc",
"revsh",
"rfedb",
@@ -189,6 +207,7 @@
"smmlsr",
"sourcery",
"srsdb",
+ "ssacr",
"stmdb",
"stmia",
"strbt",
--
2.31.1.windows.1


[PATCH v1 2/4] ArmPlatformPkg: SpellCheck: Switch spellcheck CI to AuditOnly

Kun Qin
 

From: Sean Brogan <sean.brogan@...>

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

Spellcheck was not covering all specified files due to CSpell v5 and
Node v10 incompatibility of current CI pipeline configuration.

This change switches the spellcheck for ArmPlatformPkg to AuditOnly to
avoid potentially numerous spell errors. The correction action is to be
revisited by package maintainers once the tool incompatibility is
resolved.

Cc: Leif Lindholm <leif@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>

Signed-off-by: Kun Qin <kuqin12@...>
Signed-off-by: Sean Brogan <sean.brogan@...>
---
ArmPlatformPkg/ArmPlatformPkg.ci.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.ci.yaml b/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
index 1abaa2f6870c..3dbbcc673bf0 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
+++ b/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
@@ -83,7 +83,7 @@

## options defined .pytool/Plugin/SpellCheck
"SpellCheck": {
- "AuditOnly": False,
+ "AuditOnly": True,
"IgnoreFiles": [], # use gitignore syntax to ignore errors
# in matching files
"ExtendWords": [
--
2.31.1.windows.1


[PATCH v1 1/4] StandaloneMmPkg: Core: Spelling error in comment

Kun Qin
 

From: Sean Brogan <sean.brogan@...>

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

This change fixed a misspelling that was not caught by spell check.

Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Supreeth Venkatesh <supreeth.venkatesh@...>
Cc: Sean Brogan <sean.brogan@...>

Signed-off-by: Sean Brogan <sean.brogan@...>
---
StandaloneMmPkg/Core/Dispatcher.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/StandaloneMmPkg/Core/Dispatcher.c b/StandaloneMmPkg/Core/Dispatcher.c
index dbd5332fa9d3..7e4bf5e94025 100644
--- a/StandaloneMmPkg/Core/Dispatcher.c
+++ b/StandaloneMmPkg/Core/Dispatcher.c
@@ -4,7 +4,7 @@
Step #1 - When a FV protocol is added to the system every driver in the FV
is added to the mDiscoveredList. The Before, and After Depex are
pre-processed as drivers are added to the mDiscoveredList. If an Apriori
- file exists in the FV those drivers are addeded to the
+ file exists in the FV those drivers are added to the
mScheduledQueue. The mFwVolList is used to make sure a
FV is only processed once.

--
2.31.1.windows.1


[PATCH v1 0/4] Update Node to 14.x to resolve cspell failure

Kun Qin
 

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

According to requirements set by cspell, the minimal node version to
support cspell v5+ should be 12 or above (ref:
https://github.com/streetsidesoftware/cspell/tree/main/packages/cspell).

This mismatched dependency caused "Failed to process "**" TypeError:
text.matchAll(...) is not a function or its return value is not iterable"
errors on multiple files during spell check, and they have been ignored
silently.

This change will update the node dependency to be at least v14 to fix
incompatibility issue. With this resolved, the newly discovered
misspellings are handled accordingly:
* Spelling error in StandaloneMM get fixed.
* Spelling errors in ArmPkg are added to package config for their validity.
* Spelling errors in ArmPlatformPkg is set to audit mode and request the
maintainers resolve the errors.

Patch v1 branch: https://github.com/kuqin12/edk2/tree/node_14_v1

Cc: Sean Brogan <sean.brogan@...>
Cc: Bret Barkelew <Bret.Barkelew@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Supreeth Venkatesh <supreeth.venkatesh@...>

Kun Qin (1):
Azurepipeline: SpellCheck: Enforce Node dependency to use version 14.x

Sean Brogan (3):
StandaloneMmPkg: Core: Spelling error in comment
ArmPlatformPkg: SpellCheck: Switch spellcheck CI to AuditOnly
ArmPkg: SpellCheck: Update valid acronyms in ExtendedWords

StandaloneMmPkg/Core/Dispatcher.c | 2 +-
.azurepipelines/templates/spell-check-prereq-steps.yml | 2 +-
ArmPkg/ArmPkg.ci.yaml | 19 +++++++++++++++++++
ArmPlatformPkg/ArmPlatformPkg.ci.yaml | 2 +-
4 files changed, 22 insertions(+), 3 deletions(-)

--
2.31.1.windows.1


CI is failing - June 2021

Sean
 

The CI system is failing around the spellcheck plugin.
https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=23772&view=results


The patch never got merged (15 months ago and again 8 months ago) to update nodejs to a newer version. See bug https://bugzilla.tianocore.org/show_bug.cgi?id=2618

This has now caused the spell checker to stop working and is then causing an error which is breaking the CI builds.
Updating Node resolves this error.

But after updating a few packages fail because of spelling errors. ArmPkg, ArmPlatformPkg, and StandaloneMMPkg.

More info being tracked in this
https://bugzilla.tianocore.org/show_bug.cgi?id=3445

Please prioritize reviewing the patch series that will be sent out soon

FYI - There is also another bug that is hiding a few of the spelling failures on linux machines.
https://bugzilla.tianocore.org/show_bug.cgi?id=3454



Thanks
Sean


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 4:29 PM, Ethin Probst <harlydavidsen@...> wrote:

Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!


OK that makes sense. The address in the add-symbol-file command is not the load address of the image, but the start address of the text section. So that is why you had to add 0x240. 

Sorry I had to work backwards from how it works, but maybe that info will be helpful for others?

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...>
wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0  0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()
#5  0x000000007feab5c7 in ?? ()
#6  0x000000007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2   GCC inline implementation of BaseLib processor specific functions.
3
4   Copyright (c) 2006 - 2020, Intel Corporation. All rights
reserved.<BR>
5   Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6   SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug

OK that is interesting…. +576 -> 0x240 witch is about the size of the
PE/COFF header.

For mach-O (macOS executables) we have to link at 0x240 to make space for
the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section
starts at 0x7e4b8240? So try adding 0x240 to the load address on the
add-symbol-file command. If that does not work trip subtracting 0x240 from
the load address.

We would need to dump out the UsbAudio.efi file to figure out exactly what
is going on. What distro are you on? Do you have the readpe utility? I’m not
sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB
myself.
:)

What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There
is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote
9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>) like this (from the main
EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers
and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the
image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump
into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might
be
a
little off on gdb specifics…. Also my terminology may be lldb
centric.

Easy one 1st. When you run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath  the exception 3 is going to get
handled
in
the unexpected exception handler, and that is probably in the CPUD
DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU
acts
a
lot
more like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the
CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target
for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is
a
handshake that describes the target and what registers are
available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So
this
changing the target definition might confuse the debugger. To be
safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the
debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst




-- 
Signed,
Ethin D. Probst




Re: Help with debugging

Ethin Probst
 

Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...>
wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0 0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1 ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2 _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3 0x000000007fead316 in ?? ()
#4 0x000000007e4f7518 in ?? ()
#5 0x000000007feab5c7 in ?? ()
#6 0x000000007fea3520 in ?? ()
#7 0x0000000101000000 in ?? ()
#8 0x0000000000000030 in ?? ()
#9 0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2 GCC inline implementation of BaseLib processor specific functions.
3
4 Copyright (c) 2006 - 2020, Intel Corporation. All rights
reserved.<BR>
5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6 SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
OK that is interesting…. +576 -> 0x240 witch is about the size of the
PE/COFF header.

For mach-O (macOS executables) we have to link at 0x240 to make space for
the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section
starts at 0x7e4b8240? So try adding 0x240 to the load address on the
add-symbol-file command. If that does not work trip subtracting 0x240 from
the load address.

We would need to dump out the UsbAudio.efi file to figure out exactly what
is going on. What distro are you on? Do you have the readpe utility? I’m not
sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB
myself.
:)
What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There
is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote
9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>) like this (from the main
EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers
and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the
image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump
into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might
be
a
little off on gdb specifics…. Also my terminology may be lldb
centric.

Easy one 1st. When you run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath the exception 3 is going to get
handled
in
the unexpected exception handler, and that is probably in the CPUD
DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU
acts
a
lot
more like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the
CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target
for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is
a
handshake that describes the target and what registers are
available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So
this
changing the target definition might confuse the debugger. To be
safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the
debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst
--
Signed,
Ethin D. Probst


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...> wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug" at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0  0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()
#5  0x000000007feab5c7 in ?? ()
#6  0x000000007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2   GCC inline implementation of BaseLib processor specific functions.
3
4   Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR>
5   Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
6   SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
 Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug

OK that is interesting…. +576 -> 0x240 witch is about the size of the PE/COFF header. 

For mach-O (macOS executables) we have to link at 0x240 to make space for the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section starts at 0x7e4b8240? So try adding 0x240 to the load address on the add-symbol-file command. If that does not work trip subtracting 0x240 from the load address. 

We would need to dump out the UsbAudio.efi file to figure out exactly what is going on. What distro are you on? Do you have the readpe utility? I’m not sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look. 

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself.
:)

What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be
a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath  the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts
a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst







-- 
Signed,
Ethin D. Probst


Re: [edk2-platforms][PATCH] IpmiFeaturePkg : Rename IPMI Macro and Structure Defintions

Isaac Oram
 

Reviewed-by: Isaac Oram <isaac.w.oram@...>

-----Original Message-----
From: manickavasakam karpagavinayagam <manickavasakamk@...>
Sent: Friday, June 11, 2021 2:52 PM
To: devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Felixp@...; DOPPALAPUDI, HARIKRISHNA <harikrishnad@...>; Jha, Manish <manishj@...>; Bobroff, Zachary <zacharyb@...>; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@...>; gaoliming@...
Subject: [edk2-platforms][PATCH] IpmiFeaturePkg : Rename IPMI Macro and Structure Defintions

Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE
---
.../IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
index 1e0c132508..d788b48867 100644
--- a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/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;

--
2.25.0.windows.1


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


Re: [edk2][PATCH V1] MdePkg : Add IPMI Macro and Structure Defintions to resolve the IPMI build error

Isaac Oram
 

Reviewed-by: Isaac Oram <isaac.w.oram@...>

-----Original Message-----
From: manickavasakam karpagavinayagam <manickavasakamk@...>
Sent: Friday, June 11, 2021 2:50 PM
To: devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@...>; Desimone, Nathaniel L <nathaniel.l.desimone@...>; Felixp@...; DOPPALAPUDI, HARIKRISHNA <harikrishnad@...>; Jha, Manish <manishj@...>; Bobroff, Zachary <zacharyb@...>; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@...>; gaoliming@...
Subject: [edk2][PATCH V1] MdePkg : Add IPMI Macro and Structure Defintions to resolve the IPMI build error

Build error reported for missing structures IPMI_SET_BOOT_OPTIONS_RESPONSE, EFI_IPMI_MSG_GET_BMC_EXEC_RSP and macros EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FULL_RUNTIME/EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE
when using edk2-platforms\Features\Intel\OutOfBandManagement\IpmiFeaturePkg

MdePkg : Rename IPMI Macro and Structure Defintions

Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE
---

Notes:
V1 :
- Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
- EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
- IPMI_BMC_IN_FORCED_UPDATE_MODE

0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch | 61 ++++++++++++++++++++
MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h | 4 ++
MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h | 18 ++++++
3 files changed, 83 insertions(+)

diff --git a/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch b/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch
new file mode 100644
index 0000000000..16d149e2d8
--- /dev/null
+++ b/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch
@@ -0,0 +1,61 @@
+From c5e221cfe5d815883f39b71667b6e8f644a27390 Mon Sep 17 00:00:00 2001
+From: manickavasakam karpagavinayagam <manickavasakamk@...>
+Date: Thu, 10 Jun 2021 14:59:22 -0400
+Subject: [edk2][PATCH] MdePkg : Add IPMI Macro and Structure Defintions
+to resolve the IPMI build error
+
+Build error reported for missing structures
+IPMI_SET_BOOT_OPTIONS_RESPONSE, EFI_IPMI_MSG_GET_BMC_EXEC_RSP and
+macros EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
+EFI_FIRMWARE_BMC_IN_FULL_RUNTIME/EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE
+when using
+edk2-platforms\Features\Intel\OutOfBandManagement\IpmiFeaturePkg
+---
+ MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h | 4 ++++
+MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h | 19
++++++++++++++++++++
+ 2 files changed, 23 insertions(+)
+
+diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+index 79db55523d..d7cdd3a865 100644
+--- a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
++++ b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+@@ -186,6 +186,10 @@ typedef struct {
+ UINT8 ParameterData[0];
+ } IPMI_SET_BOOT_OPTIONS_REQUEST;
+
++typedef struct {
++ UINT8 CompletionCode:8;
++} IPMI_SET_BOOT_OPTIONS_RESPONSE;
++
+ //
+ // Definitions for Get System Boot options command // diff --git
+a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+index 2d892dbd5a..1c692cc792 100644
+--- a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
++++ b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+@@ -17,4 +17,23 @@
+ // All Firmware commands and their structure definitions to follow
+here //
+
++/*----------------------------------------------------------------------------------------
++ Definitions for Get BMC Execution Context
++----------------------------------------------------------------------
++------------------*/ #define EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
++0x23
++
++//
++// 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;
++
++//
++// Current Execution Context responses //
++#define EFI_FIRMWARE_BMC_IN_FULL_RUNTIME 0x10
++#define EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE 0x11
++
+ #endif
+--
+2.25.0.windows.1
+
diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
index 79db55523d..d7cdd3a865 100644
--- a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
@@ -186,6 +186,10 @@ typedef struct {
UINT8 ParameterData[0]; } IPMI_SET_BOOT_OPTIONS_REQUEST; +typedef struct {+ UINT8 CompletionCode:8;+} IPMI_SET_BOOT_OPTIONS_RESPONSE;+ // // Definitions for Get System Boot options command //diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
index 2d892dbd5a..c4cbe2349b 100644
--- a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
@@ -17,4 +17,22 @@
// All Firmware commands and their structure definitions to follow here // +// ----------------------------------------------------------------------------------------+// Definitions for Get BMC Execution Context+// ----------------------------------------------------------------------------------------+#define IPMI_GET_BMC_EXECUTION_CONTEXT 0x23++//+// Constants and Structure definitions for "Get Device ID" command to follow here+//+typedef struct {+ UINT8 CurrentExecutionContext;+ UINT8 PartitionPointer;+} IPMI_MSG_GET_BMC_EXEC_RSP;++//+// Current Execution Context responses+//+#define IPMI_BMC_IN_FORCED_UPDATE_MODE 0x11+ #endif--
2.25.0.windows.1


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


Re: [PATCH v1 3/5] MdeModulePkg: MemoryProfileInfo: Updated MessageLength calculation

Kun Qin
 

Hi Hao,

Thanks for pointing out the missing place. Will update this accordingly.

This patch series needs a PI spec update, I thought I should mark all changes with BZ#### before the spec update is taken. But I can drop them for the next patch version.

Regards,
Kun

On 06/11/2021 00:46, Wu, Hao A wrote:
-----Original Message-----
From: Kun Qin <kuqin12@...>
Sent: Thursday, June 10, 2021 9:43 AM
To: devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>
Subject: [PATCH v1 3/5] MdeModulePkg: MemoryProfileInfo: Updated
MessageLength calculation

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

This change replaced the calculation of communication buffer size from
explicitly adding the size of each member with the OFFSET macro function.
This will make the structure field defition change transparent to consumers.
I think there is one missing place in function GetSmramProfileData():
MinimalSizeNeeded = sizeof (EFI_GUID) +
sizeof (UINTN) +
MAX (sizeof (SMRAM_PROFILE_PARAMETER_GET_PROFILE_INFO),
MAX (sizeof (SMRAM_PROFILE_PARAMETER_GET_PROFILE_DATA_BY_OFFSET),
sizeof (SMRAM_PROFILE_PARAMETER_RECORDING_STATE)));
More inline comments below:


Cc: Jian J Wang <jian.j.wang@...>
Cc: Hao A Wu <hao.a.wu@...>

Signed-off-by: Kun Qin <kuqin12@...>
---
MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 20
+++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)

diff --git
a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
index 191c31068545..39ed8b2e0484 100644
--- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
+++
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
@@ -1190,7 +1190,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_DISABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
Please help to drop the explicit mention of BZ3398 in the comment.
How about using:
//
// The CommHeader->MessageLength contains a definitive value, thus UINTN cast is safe here.
//
There are 4 more similar cases below.
Best Regards,
Hao Wu

+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Status = SmmCommunication->Communicate (SmmCommunication,
CommBuffer, &CommSize);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "SmramProfile: SmmCommunication - %r\n",
Status)); @@ -1213,7 +1215,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_DISABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
SmmCommunication->Communicate (SmmCommunication, CommBuffer,
&CommSize);
}

@@ -1230,7 +1234,9 @@ GetSmramProfileData (
CommGetProfileInfo->Header.ReturnStatus = (UINT64)-1;
CommGetProfileInfo->ProfileSize = 0;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Status = SmmCommunication->Communicate (SmmCommunication,
CommBuffer, &CommSize);
ASSERT_EFI_ERROR (Status);

@@ -1261,7 +1267,9 @@ GetSmramProfileData (
CommGetProfileData->Header.DataLength = sizeof
(*CommGetProfileData);
CommGetProfileData->Header.ReturnStatus = (UINT64)-1;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Buffer = (UINT8 *) CommHeader + CommSize;
Size -= CommSize;

@@ -1320,7 +1328,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_ENABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
SmmCommunication->Communicate (SmmCommunication, CommBuffer,
&CommSize);
}

--
2.31.1.windows.1


Re: Help with debugging

Ethin Probst
 

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug" at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0 0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1 ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2 _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3 0x000000007fead316 in ?? ()
#4 0x000000007e4f7518 in ?? ()
#5 0x000000007feab5c7 in ?? ()
#6 0x000000007fea3520 in ?? ()
#7 0x0000000101000000 in ?? ()
#8 0x0000000000000030 in ?? ()
#9 0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2 GCC inline implementation of BaseLib processor specific functions.
3
4 Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR>
5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
6 SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself.
:)
What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be
a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts
a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst


--
Signed,
Ethin D. Probst


Re: GSOC 2021 EXT4 driver Project

Michael D Kinney
 

Hi Michael,

Thanks for the feedback.

#4 should be clarified as adding a new feature package called Ext4Pkg. Not adding EXT4 to the existing AdvancedFeaturePkg.

Mike

-----Original Message-----
From: Michael Kubacki <mikuback@...>
Sent: Friday, June 11, 2021 11:23 AM
To: devel@edk2.groups.io; leif@...; Kinney, Michael D <michael.d.kinney@...>
Cc: pedro.falcato@...
Subject: Re: [edk2-devel] GSOC 2021 EXT4 driver Project

I had done some of the early work in moving content to
edk2-platforms/Features. Just wanted to add my support for maintaining
this as a vendor neutral feature there.

#4 in the options list is not really what AdvancedFeaturePkg intended
for, there's more details here -
https://github.com/tianocore/edk2-platforms/tree/master/Features/Intel#AdvancedFeaturePkg.

- Michael

On 6/10/2021 1:54 PM, Leif Lindholm wrote:
edk2-platforms/Features/Ext4Pkg sounds good to me too.

/
Leif

On Thu, Jun 10, 2021 at 17:38:17 +0000, Michael D Kinney wrote:
Hi Pedro,

After thinking about this, I think I would prefer Option (4).

The proposed landing zone would be a new Ext4Pkg in the edk2-platforms repository in the Features directory.

edk2-platforms/Features/Intel/Ext4Pkg

All the features in that directory and not specific to Intel. There are other email discussions about moving some of
that content up a level, so an alternative path would be:

edk2-platforms/Features/Ext4Pkg

Best regards,

Mike


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Monday, May 24, 2021 12:27 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] GSOC 2021 EXT4 driver Project

Hi everyone,

Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity
to collaborate with you and improve Tianocore!
If anyone has any questions, please fire away :)
How do I get started? I'd like to find some easier tasks as to start trying out patch submission and generally
programming in a firmware environment.
Also, I've been talking with my mentors and a relevant question to ask the mailing list is: Where should we put the
EXT4 driver?
Michael said there are other filesystems in MdeModulePkg, but it might be getting too big and proposed the following
options:

1) EXT4 in new package in edk2 repo as a peer to FatPkg.
2) EXT4 in edk2 repo in MdeModulePkg
3) EXT4 in edk2-platforms advanced feature package.
4) EXT4 in edk2 advanced feature package

As someone that's still learning how to navigate the project's tree(s), this is a bit over my head and so I'd like your
opinion on the matter.
Also, I would love if someone could point me to some good reading material and/or examples of the package/build system,
as I couldn't find documentation on those
and my previous experiment with Tianocore involved looking at FatPkg and mindlessly copying what it was doing.

Thanks,

Pedro







18221 - 18240 of 94575