[PATCH v2] efi: Fix .data section size calculations when .sbat is present

Vitaly Kuznetsov posted 1 patch 3 months, 2 weeks ago
drivers/firmware/efi/libstub/zboot.lds | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH v2] efi: Fix .data section size calculations when .sbat is present
Posted by Vitaly Kuznetsov 3 months, 2 weeks ago
Commit 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT
section") neglected to adjust the sizes of the .data section when
CONFIG_EFI_SBAT_FILE is set. As the result, the produced PE binary is
incorrect and some tools complain about it. E.g. 'sbsign' reports:

 # sbsign --key my.key --cert my.crt arch/arm64/boot/vmlinuz.efi
 warning: file-aligned section .data extends beyond end of file
 warning: checksum areas are greater than image size. Invalid section table?

Note, '__data_size' is also used in the PE optional header and it is not
entirely clear whether .sbat needs to be accounted as part of
SizeOfInitializedData or not. As the header seems to be unused by the real
world firmware, keeping the field equal to __data_size.

Fixes: 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section")
Reported-by: Heinrich Schuchardt <heinrich.schuchardt@gmx.de>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
Changes in v2: drop PE optional header adjustment [Ard]
---
 drivers/firmware/efi/libstub/zboot.lds | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/zboot.lds b/drivers/firmware/efi/libstub/zboot.lds
index 4b8d5cd3dfa2..367907eb7d86 100644
--- a/drivers/firmware/efi/libstub/zboot.lds
+++ b/drivers/firmware/efi/libstub/zboot.lds
@@ -58,6 +58,6 @@ SECTIONS
 PROVIDE(__efistub__gzdata_size =
 		ABSOLUTE(__efistub__gzdata_end - __efistub__gzdata_start));
 
-PROVIDE(__data_rawsize = ABSOLUTE(_edata - _etext));
-PROVIDE(__data_size = ABSOLUTE(_end - _etext));
+PROVIDE(__data_rawsize = ABSOLUTE(_edata - _data));
+PROVIDE(__data_size = ABSOLUTE(_end - _data));
 PROVIDE(__sbat_size = ABSOLUTE(_esbat - _sbat));
-- 
2.49.0
Re: [PATCH v2] efi: Fix .data section size calculations when .sbat is present
Posted by Ard Biesheuvel 3 months, 2 weeks ago
On Fri, 20 Jun 2025 at 13:16, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
>
> Commit 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT
> section") neglected to adjust the sizes of the .data section when
> CONFIG_EFI_SBAT_FILE is set. As the result, the produced PE binary is
> incorrect and some tools complain about it. E.g. 'sbsign' reports:
>
>  # sbsign --key my.key --cert my.crt arch/arm64/boot/vmlinuz.efi
>  warning: file-aligned section .data extends beyond end of file
>  warning: checksum areas are greater than image size. Invalid section table?
>
> Note, '__data_size' is also used in the PE optional header and it is not
> entirely clear whether .sbat needs to be accounted as part of
> SizeOfInitializedData or not. As the header seems to be unused by the real
> world firmware, keeping the field equal to __data_size.
>
> Fixes: 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section")
> Reported-by: Heinrich Schuchardt <heinrich.schuchardt@gmx.de>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> Changes in v2: drop PE optional header adjustment [Ard]
> ---
>  drivers/firmware/efi/libstub/zboot.lds | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/zboot.lds b/drivers/firmware/efi/libstub/zboot.lds
> index 4b8d5cd3dfa2..367907eb7d86 100644
> --- a/drivers/firmware/efi/libstub/zboot.lds
> +++ b/drivers/firmware/efi/libstub/zboot.lds
> @@ -58,6 +58,6 @@ SECTIONS
>  PROVIDE(__efistub__gzdata_size =
>                 ABSOLUTE(__efistub__gzdata_end - __efistub__gzdata_start));
>
> -PROVIDE(__data_rawsize = ABSOLUTE(_edata - _etext));
> -PROVIDE(__data_size = ABSOLUTE(_end - _etext));
> +PROVIDE(__data_rawsize = ABSOLUTE(_edata - _data));
> +PROVIDE(__data_size = ABSOLUTE(_end - _data));
>  PROVIDE(__sbat_size = ABSOLUTE(_esbat - _sbat));
> --
> 2.49.0
>
>

Thanks, I've queued this up now.