[PATCH v8 1/5] efi: add EFI_SYSTEM_TABLE_POINTER for debug

[Heinrich Schuchardt]

On 7/11/25 22:55, Heinrich Schuchardt wrote:
> Am 4. Juli 2025 13:59:53 MESZ schrieb Paul Liu<paul.liu at linaro.org>:
>> Hi Heinrich, Ilias,
>>
>> Sorry for the late reply. I'm a bit worried about this change. This
>> structure (efi_system_table_pointer), is not packed.
>> So its actual size is a bit larger. The crc32 field is not at the end of
>> the structure. Actually there are 4 bytes padding after it. But the CRC32
>> function is calculating the crc sum on the whole structure. So it might
>> produce random value if we don't zero those padding bytes.
> Thanks for highlighting this.
> 
> Structures in UEFI are typically packed.
> 
> Should padding bytes really be included in the crc32?
> 
> We should add a test of the crc32 tohttps://github.com/trini/u-boot/blob/master/lib/efi_loader/dbginfodump.c so that we can compare U-Boot to EDK2.
> 
> Best regards
> 
> Heinrich


EDK II only zeros out the crc32 field.

BaseTools/Scripts/efi_debugging.py has this logic:

if system_table_pointer.Signature == efi_system_table_signature:
     buf1 = bytearray(system_table_pointer)[:16]
     crc32_value = zlib.crc32(buf1)
     crc32_value = zlib.crc32(b'\0' * (sizeof(EFI_SYSTEM_TABLE_POINTER) 
- len(buf1)), crc32_value)
     if crc32_value == system_table_pointer.Crc32:
         break

sizeof(EFI_SYSTEM_TABLE_POINTER) evaluates to 24. So it includes padding 
bytes. The logic calculates the crc32 as if the padding bytes were zero.

In contrast to your contribution EDK II uses BootServicesData for 
storing the system table pointer.

Here is a dump of what I saw on EDK II:

System Table Pointer @ 0x000000017fc00000
49 42 49 20 53 59 53 54 18 e0 ff 7f 01 00 00 00 56 d8 89 d0 00 00 00 00

The crc32 contains the trailing NULs.

So you are right we should zero out the padding bytes.

Best regards

Heinrich