[PATCH] Support --with-env-file-name

13 views
Skip to first unread message

Earl Chew

unread,
Apr 5, 2024, 7:01:46 PM4/5/24
to efibootg...@googlegroups.com, earl...@yahoo.com
Allow configuration to override the default ENV_FILE_NAME
to support scenarios with multiple distributions or architectures.

Signed-off-by: Earl Chew <earl...@yahoo.com>
---
configure.ac | 12 ++++++++++++
include/envdata.h | 1 -
2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 20fcf32..9fc7157 100644
--- a/configure.ac
+++ b/configure.ac
@@ -156,6 +156,17 @@ AC_ARG_WITH([env-backend],

AC_SUBST([env_api_file], [${ENV_API_FILE}])

+AC_ARG_WITH([env-file-name],
+ AS_HELP_STRING([--with-env-file-name=STRING],
+ [override the boot environment file name]),
+ [
+ ENV_FILE_NAME="$withval"
+ ],
+ [ ENV_FILE_NAME="BGENV.DAT" ])
+
+AC_DEFINE_UNQUOTED(
+ [ENV_FILE_NAME], [L"${ENV_FILE_NAME}"], [Boot environment file name])
+
AC_ARG_WITH([boot-delay],
AS_HELP_STRING([--with-boot-delay=INT],
[specify the additional boot delay in seconds, defaults to 3]),
@@ -268,6 +279,7 @@ AC_MSG_RESULT([
efi libs: ${GNUEFI_LIB_DIR}

environment backend: ${ENV_API_FILE}.c
+ environment file name: ${ENV_FILE_NAME}
number of config parts: ${ENV_NUM_CONFIG_PARTS}
reserved for uservars: ${ENV_MEM_USERVARS} bytes
boot delay: ${ENV_BOOT_DELAY} seconds
diff --git a/include/envdata.h b/include/envdata.h
index 9c4ad44..fddfa7f 100644
--- a/include/envdata.h
+++ b/include/envdata.h
@@ -16,7 +16,6 @@

#include <stdint.h>

-#define ENV_FILE_NAME L"BGENV.DAT"
#define FAT_ENV_FILENAME "BGENV.DAT"
#define ENV_STRING_LENGTH 255

--
2.39.1

Jan Kiszka

unread,
Apr 8, 2024, 3:43:09 AM4/8/24
to Earl Chew, efibootg...@googlegroups.com
On 06.04.24 01:01, 'Earl Chew' via EFI Boot Guard wrote:
> Allow configuration to override the default ENV_FILE_NAME
> to support scenarios with multiple distributions or architectures.

Can you be a bit more specific why you need to have this configurable?
That causes an inconsistency between those semantically connected
variables. Is there a reason for this?

Jan

> #define ENV_STRING_LENGTH 255
>

--
Siemens AG, Technology
Linux Expert Center

Earl Chew

unread,
Apr 13, 2024, 8:47:41 PM4/13/24
to Jan Kiszka, efibootg...@googlegroups.com
Jan,

> Can you be a bit more specific why you need to have this configurable?

I'm looking to support multiple distributions.

https://wiki.debian.org/UEFI

> Debian installs grub-efi for its EFI bootloader, as:
>
> Architecture Path
> amd64 \EFI\debian\grubx64.efi
> i386 \EFI\debian\grubia32.efi
> arm64 \EFI\debian\grubaa64.efi
> armhf \EFI\debian\grubarm.efi

Other distributions use their own directories (eg \EFI\fedora, etc).

EFI Boot Guard (EBG) looks for a specific data file (normally BGENV.DAT)
which contains a single kernel configuration entry, and there is no
obvious way to configure EBG to select a corresponding distribution.

This patch proposes a change where each distribution builds and
configures its own instance of EBG, which can find its corresponding
data file (eg BGENV-DEBIAN.DAT, or EFI\debian\BGENV.DAT, etc). This
also has the benefit of decoupling the distributions at boot so that
a breaking EBG change to one distribution will not affect another.

>> #define FAT_ENV_FILENAME "BGENV.DAT"
>
> That causes an inconsistency between those semantically connected
> variables. Is there a reason for this?

That's an oversight on my part.

Earl

Jan Kiszka

unread,
Apr 15, 2024, 10:06:54 AM4/15/24
to Earl Chew, efibootg...@googlegroups.com
On 13.04.24 02:47, 'Earl Chew' via EFI Boot Guard wrote:
> Jan,
>
>> Can you be a bit more specific why you need to have this configurable?
>
> I'm looking to support multiple distributions.
>
> https://wiki.debian.org/UEFI
>
>> Debian installs grub-efi for its EFI bootloader, as:
>>
>> Architecture Path
>> amd64        \EFI\debian\grubx64.efi
>> i386         \EFI\debian\grubia32.efi
>> arm64        \EFI\debian\grubaa64.efi
>> armhf        \EFI\debian\grubarm.efi
>
> Other distributions use their own directories (eg \EFI\fedora, etc).
>
> EFI Boot Guard (EBG) looks for a specific data file (normally BGENV.DAT)
> which contains a single kernel configuration entry, and there is no
> obvious way to configure EBG to select a corresponding distribution.
>
> This patch proposes a change where each distribution builds and
> configures its own instance of EBG, which can find its corresponding
> data file (eg BGENV-DEBIAN.DAT, or EFI\debian\BGENV.DAT, etc). This
> also has the benefit of decoupling the distributions at boot so that
> a breaking EBG change to one distribution will not affect another.
>

Thanks, that makes things much clearer. Please add some words about that
also to the v2 commit message of this patch.

Jan
Reply all
Reply to author
Forward
0 new messages