[PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Fiona Klute]

CONFIG_ENV_WRITEABLE_LIST only restricts loading stored environment,
not runtime modification e.g. using "env set", while the Kconfig
description implied otherwise. Describe the actual behavior, and add a
note in the documentation.

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 doc/develop/environment.rst | 7 +++++++
 env/Kconfig                 | 5 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst
index a7ed4aab0a5..e7cf6de3586 100644
--- a/doc/develop/environment.rst
+++ b/doc/develop/environment.rst
@@ -89,3 +89,10 @@ an association in the static list.
 If CONFIG_REGEX is defined, the variable name is evaluated as a regular
 expression. This allows multiple variables to define the same flags without
 explicitly listing them all.
+
+If CONFIG_ENV_WRITEABLE_LIST is defined, only environment variables
+which explicitly set the 'w' writeable flag can be written from stored
+environment. It restricts only environment loading, not runtime
+modification using "env set", etc. Non-writable variables can still be
+written to stored environment by external tools (e.g. ``fw_setenv``
+from a running OS), but will be ignored when loading the environment.
diff --git a/env/Kconfig b/env/Kconfig
index c6df09a3349..70f6cca701c 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -897,8 +897,9 @@ config ENV_WRITEABLE_LIST
 	select ENV_APPEND
 	help
 	  If defined, only environment variables which explicitly set the 'w'
-	  writeable flag can be written and modified at runtime. No variables
-	  can be otherwise created, written or imported into the environment.
+	  writeable flag can be written from stored environment. This
+	  restricts only environment loading, not runtime modification using
+	  "env set", etc.
 
 config ENV_ACCESS_IGNORE_FORCE
 	bool "Block forced environment operations"
-- 
2.55.0

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Richard Weinberger]

On Dienstag, 20. Oktober 2026 11:21 Fiona Klute wrote:
> CONFIG_ENV_WRITEABLE_LIST only restricts loading stored environment,
> not runtime modification e.g. using "env set", while the Kconfig
> description implied otherwise. Describe the actual behavior, and add a
> note in the documentation.
> 
> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
> ---
>  doc/develop/environment.rst | 7 +++++++
>  env/Kconfig                 | 5 +++--
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst
> index a7ed4aab0a5..e7cf6de3586 100644
> --- a/doc/develop/environment.rst
> +++ b/doc/develop/environment.rst
> @@ -89,3 +89,10 @@ an association in the static list.
>  If CONFIG_REGEX is defined, the variable name is evaluated as a regular
>  expression. This allows multiple variables to define the same flags without
>  explicitly listing them all.
> +
> +If CONFIG_ENV_WRITEABLE_LIST is defined, only environment variables
> +which explicitly set the 'w' writeable flag can be written from stored
> +environment. It restricts only environment loading, not runtime
> +modification using "env set", etc. Non-writable variables can still be
> +written to stored environment by external tools (e.g. ``fw_setenv``
> +from a running OS), but will be ignored when loading the environment.
> diff --git a/env/Kconfig b/env/Kconfig
> index c6df09a3349..70f6cca701c 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -897,8 +897,9 @@ config ENV_WRITEABLE_LIST
>  	select ENV_APPEND
>  	help
>  	  If defined, only environment variables which explicitly set the 'w'
> -	  writeable flag can be written and modified at runtime. No variables
> -	  can be otherwise created, written or imported into the environment.
> +	  writeable flag can be written from stored environment. This
> +	  restricts only environment loading, not runtime modification using
> +	  "env set", etc.

Wow, just wow.
I always assumed that the protection applies also to "env import ..." too
since the documentation explicitly said "written or imported into the environment".

Instead of fixing the documentation, are we sure that this isn't a serve (security)
bug which needs addressing?

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Marek Vasut]

On 10/20/26 11:51 AM, Richard Weinberger wrote:
> On Dienstag, 20. Oktober 2026 11:21 Fiona Klute wrote:
>> CONFIG_ENV_WRITEABLE_LIST only restricts loading stored environment,
>> not runtime modification e.g. using "env set", while the Kconfig
>> description implied otherwise. Describe the actual behavior, and add a
>> note in the documentation.
>>
>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>> ---
>>   doc/develop/environment.rst | 7 +++++++
>>   env/Kconfig                 | 5 +++--
>>   2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst
>> index a7ed4aab0a5..e7cf6de3586 100644
>> --- a/doc/develop/environment.rst
>> +++ b/doc/develop/environment.rst
>> @@ -89,3 +89,10 @@ an association in the static list.
>>   If CONFIG_REGEX is defined, the variable name is evaluated as a regular
>>   expression. This allows multiple variables to define the same flags without
>>   explicitly listing them all.
>> +
>> +If CONFIG_ENV_WRITEABLE_LIST is defined, only environment variables
>> +which explicitly set the 'w' writeable flag can be written from stored
>> +environment. It restricts only environment loading, not runtime
>> +modification using "env set", etc. Non-writable variables can still be
>> +written to stored environment by external tools (e.g. ``fw_setenv``
>> +from a running OS), but will be ignored when loading the environment.
>> diff --git a/env/Kconfig b/env/Kconfig
>> index c6df09a3349..70f6cca701c 100644
>> --- a/env/Kconfig
>> +++ b/env/Kconfig
>> @@ -897,8 +897,9 @@ config ENV_WRITEABLE_LIST
>>   	select ENV_APPEND
>>   	help
>>   	  If defined, only environment variables which explicitly set the 'w'
>> -	  writeable flag can be written and modified at runtime. No variables
>> -	  can be otherwise created, written or imported into the environment.
>> +	  writeable flag can be written from stored environment. This
>> +	  restricts only environment loading, not runtime modification using
>> +	  "env set", etc.
> 
> Wow, just wow.
> I always assumed that the protection applies also to "env import ..." too
> since the documentation explicitly said "written or imported into the environment".
> 
> Instead of fixing the documentation, are we sure that this isn't a serve (security)
> bug which needs addressing?
If the attacker has access to U-Boot shell, then they have unrestricted 
access to the system and it is over (the attacker can e.g. modify memory 
which can be used to circumvent other protections). For the writeable 
list to have any meaningful effect, U-Boot shell access must be disabled 
(e.g. bootdelay set to -2 or similar). The writeable list protects 
U-Boot from importing undesired data from the external environment.

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Marek Vasut]

On 10/20/26 11:21 AM, Fiona Klute wrote:
> CONFIG_ENV_WRITEABLE_LIST only restricts loading stored environment,
> not runtime modification e.g. using "env set", while the Kconfig
> description implied otherwise. Describe the actual behavior, and add a
> note in the documentation.
> 
> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
> ---
>   doc/develop/environment.rst | 7 +++++++
>   env/Kconfig                 | 5 +++--
>   2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst
> index a7ed4aab0a5..e7cf6de3586 100644
> --- a/doc/develop/environment.rst
> +++ b/doc/develop/environment.rst
> @@ -89,3 +89,10 @@ an association in the static list.
>   If CONFIG_REGEX is defined, the variable name is evaluated as a regular
>   expression. This allows multiple variables to define the same flags without
>   explicitly listing them all.
> +
> +If CONFIG_ENV_WRITEABLE_LIST is defined, only environment variables
> +which explicitly set the 'w' writeable flag can be written

... can be loaded from  ... (not ... written from ...)

> from stored
> +environment. It restricts only environment loading, not runtime
> +modification using "env set", etc. Non-writable variables can still be
> +written to stored environment by external tools (e.g. ``fw_setenv``
> +from a running OS), but will be ignored when loading the environment.

Even the U-Boot 'env save' stores the entire environment into external 
storage. The loading of environment then filters out the relevant 
entries (the writeable ones) and imports only those, while the rest of 
the entries are default from the built-in environment.

It might be good to also include a note, that it is strongly suggested 
to have U-Boot prompt access restricted, because if attacker can access 
the prompt, it is game over for any security.

> diff --git a/env/Kconfig b/env/Kconfig
> index c6df09a3349..70f6cca701c 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -897,8 +897,9 @@ config ENV_WRITEABLE_LIST
>   	select ENV_APPEND
>   	help
>   	  If defined, only environment variables which explicitly set the 'w'
> -	  writeable flag can be written and modified at runtime. No variables
> -	  can be otherwise created, written or imported into the environment.
> +	  writeable flag can be written from stored environment. This

s@written from@loaded from@

> +	  restricts only environment loading, not runtime modification using
> +	  "env set", etc.
>   
>   config ENV_ACCESS_IGNORE_FORCE
>   	bool "Block forced environment operations"

Thank you !

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Richard Weinberger]

On Dienstag, 20. Oktober 2026 12:22 Marek Vasut wrote:
> >> -	  writeable flag can be written and modified at runtime. No variables
> >> -	  can be otherwise created, written or imported into the environment.
> >> +	  writeable flag can be written from stored environment. This
> >> +	  restricts only environment loading, not runtime modification using
> >> +	  "env set", etc.
> > 
> > Wow, just wow.
> > I always assumed that the protection applies also to "env import ..." too
> > since the documentation explicitly said "written or imported into the environment".
> > 
> > Instead of fixing the documentation, are we sure that this isn't a serve (security)
> > bug which needs addressing?
> If the attacker has access to U-Boot shell, then they have unrestricted 
> access to the system and it is over (the attacker can e.g. modify memory 
> which can be used to circumvent other protections). For the writeable 
> list to have any meaningful effect, U-Boot shell access must be disabled 
> (e.g. bootdelay set to -2 or similar). The writeable list protects 
> U-Boot from importing undesired data from the external environment.

Well, I have a different use case in mind.

What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
to import variables form a file like /boot/extraEnv.txt?
I like this a lot because it allows applications to set various u-boot variables.
And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
is configured to that set.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Marek Vasut]

On 10/20/26 2:29 PM, Richard Weinberger wrote:
> On Dienstag, 20. Oktober 2026 12:22 Marek Vasut wrote:
>>>> -	  writeable flag can be written and modified at runtime. No variables
>>>> -	  can be otherwise created, written or imported into the environment.
>>>> +	  writeable flag can be written from stored environment. This
>>>> +	  restricts only environment loading, not runtime modification using
>>>> +	  "env set", etc.
>>>
>>> Wow, just wow.
>>> I always assumed that the protection applies also to "env import ..." too
>>> since the documentation explicitly said "written or imported into the environment".
>>>
>>> Instead of fixing the documentation, are we sure that this isn't a serve (security)
>>> bug which needs addressing?
>> If the attacker has access to U-Boot shell, then they have unrestricted
>> access to the system and it is over (the attacker can e.g. modify memory
>> which can be used to circumvent other protections). For the writeable
>> list to have any meaningful effect, U-Boot shell access must be disabled
>> (e.g. bootdelay set to -2 or similar). The writeable list protects
>> U-Boot from importing undesired data from the external environment.
> 
> Well, I have a different use case in mind.
> 
> What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
> to import variables form a file like /boot/extraEnv.txt?

How do you authenticate extraEnv.txt in this case ?

If you do not authenticate the file, then it is game over.

> I like this a lot because it allows applications to set various u-boot variables.
> And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
> is configured to that set.
[...]

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Richard Weinberger]

On Dienstag, 20. Oktober 2026 14:53 Marek Vasut wrote:
> > What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
> > to import variables form a file like /boot/extraEnv.txt?
> 
> How do you authenticate extraEnv.txt in this case ?
> 
> If you do not authenticate the file, then it is game over.

Well, since I allow only very few variables who's content can't harm,
it's okay.
Of course you need to be very careful, but that's a different story.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Massimo Pegorer]

Hi Richard,

Il giorno mar 20 ott 2026 alle ore 14:30 Richard Weinberger ha scritto:
>
> Well, I have a different use case in mind.
>
> What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
> to import variables form a file like /boot/extraEnv.txt?
> I like this a lot because it allows applications to set various u-boot variables.
> And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
> is configured to that set.

How would the detail clarified by the documentation fix break your use case?

Thanks. Regards,
Massimo

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Richard Weinberger]

On Dienstag, 20. Oktober 2026 19:04 Massimo Pegorer wrote:
> Hi Richard,
> 
> Il giorno mar 20 ott 2026 alle ore 14:30 Richard Weinberger ha scritto:
> >
> > Well, I have a different use case in mind.
> >
> > What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
> > to import variables form a file like /boot/extraEnv.txt?
> > I like this a lot because it allows applications to set various u-boot variables.
> > And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
> > is configured to that set.
> 
> How would the detail clarified by the documentation fix break your use case?

Yes. I always (wrongly) assumed that importing an env is protected by CONFIG_ENV_WRITEABLE_LIST.
And I'm very sure I'm not the only one...

Thanks,
//richard   

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT UID/VAT Nr:
ATU 66964118 | FN: 374287y

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Marek Vasut]

On 10/20/26 2:55 PM, Richard Weinberger wrote:
> On Dienstag, 20. Oktober 2026 14:53 Marek Vasut wrote:
>>> What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
>>> to import variables form a file like /boot/extraEnv.txt?
>>
>> How do you authenticate extraEnv.txt in this case ?
>>
>> If you do not authenticate the file, then it is game over.
> 
> Well, since I allow only very few variables who's content can't harm,
> it's okay.

I think there is a bit more to this -- what about "env set" usage in 
U-Boot scripts, should that "env set" invocation be able to set 
non-writeable variables or not ?

If I recall the discussion around the addition of the writeable list 
right, it did originally filter even import of variables into live env 
(what env set / env import does), but that was removed in one of the 
follow up versions, because if attacker has ability to modify the env at 
runtime, it is all lost.

But please don't get me wrong, I see the issue and the wording of the 
ENV_WRITEABLE_LIST symbol is not good. But I am not yet convinced that 
it is not up to the user to secure the U-Boot shell. What would you 
suggest we do to improve the situation here ?

> Of course you need to be very careful, but that's a different story.
Right.

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Massimo Pegorer]

Il giorno mar 20 ott 2026 alle ore 19:21 Richard Weinberger ha scritto:
>
> On Dienstag, 20. Oktober 2026 19:04 Massimo Pegorer wrote:
> > Hi Richard,
> >
> > Il giorno mar 20 ott 2026 alle ore 14:30 Richard Weinberger ha scritto:
> > >
> > > Well, I have a different use case in mind.
> > >
> > > What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
> > > to import variables form a file like /boot/extraEnv.txt?
> > > I like this a lot because it allows applications to set various u-boot variables.
> > > And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
> > > is configured to that set.
> >
> > How would the detail clarified by the documentation fix break your use case?
>
> Yes. I always (wrongly) assumed that importing an env is protected by CONFIG_ENV_WRITEABLE_LIST.
> And I'm very sure I'm not the only one...

Probably I am missing something, but in my understanding importing == loading,
therefore I do not see any breakage in your use case: importing variables from
file will load in the U-Boot environment just CONFIG_ENV_WRITEABLE_LIST ones.

Regards,
Massimo

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Fiona Klute]

Am 20.10.26 um 20:38 schrieb Massimo Pegorer:
> Il giorno mar 20 ott 2026 alle ore 19:21 Richard Weinberger ha scritto:
>>
>> On Dienstag, 20. Oktober 2026 19:04 Massimo Pegorer wrote:
>>> Hi Richard,
>>>
>>> Il giorno mar 20 ott 2026 alle ore 14:30 Richard Weinberger ha scritto:
>>>>
>>>> Well, I have a different use case in mind.
>>>>
>>>> What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
>>>> to import variables form a file like /boot/extraEnv.txt?
>>>> I like this a lot because it allows applications to set various u-boot variables.
>>>> And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
>>>> is configured to that set.
>>>
>>> How would the detail clarified by the documentation fix break your use case?
>>
>> Yes. I always (wrongly) assumed that importing an env is protected by CONFIG_ENV_WRITEABLE_LIST.
>> And I'm very sure I'm not the only one...
> 
> Probably I am missing something, but in my understanding importing == loading,
> therefore I do not see any breakage in your use case: importing variables from
> file will load in the U-Boot environment just CONFIG_ENV_WRITEABLE_LIST ones.
No, I tested that. "env import" overwrites variables without writable 
flag, too. "env load" is a separate command, and also what U-Boot does 
by default (if configured to use a stored env).

Best regards,
Fiona

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Rasmus Villemoes]

On Tue, Oct 20 2026, Richard Weinberger <richard@sigma-star.at> wrote:

> On Dienstag, 20. Oktober 2026 12:22 Marek Vasut wrote:
>> >> -	  writeable flag can be written and modified at runtime. No variables
>> >> -	  can be otherwise created, written or imported into the environment.
>> >> +	  writeable flag can be written from stored environment. This
>> >> +	  restricts only environment loading, not runtime modification using
>> >> +	  "env set", etc.
>> > 
>> > Wow, just wow.
>> > I always assumed that the protection applies also to "env import ..." too
>> > since the documentation explicitly said "written or imported into the environment".
>> > 
>> > Instead of fixing the documentation, are we sure that this isn't a serve (security)
>> > bug which needs addressing?
>> If the attacker has access to U-Boot shell, then they have unrestricted 
>> access to the system and it is over (the attacker can e.g. modify memory 
>> which can be used to circumvent other protections). For the writeable 
>> list to have any meaningful effect, U-Boot shell access must be disabled 
>> (e.g. bootdelay set to -2 or similar). The writeable list protects 
>> U-Boot from importing undesired data from the external environment.
>
> Well, I have a different use case in mind.
>
> What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
> to import variables form a file like /boot/extraEnv.txt?
> I like this a lot because it allows applications to set various u-boot variables.
> And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
> is configured to that set.

You can do this today, but not through ENV_WRITEABLE_LIST. If you give
'env import' extra arguments, those are treated as names of the (only)
variable settings in the imported env block to honour. So you can do

  env import -t ${loadaddr} ${filesize} ${safe_vars}

That can for example be used to have a completely static environment
(i.e. never store/load it to/from permanent storage), yet import the
metadata necessary for doing A/B slot selection from somewhere that
userspace can update when installing new firmware. Obviously, one should
also sanity check those imported variables, but the point is that one
doesn't risk the above command overwriting/setting $bootcmd or $verify
or similar. And if an attacker has had sufficient access to manipulate
whatever mechanism is used for communicating A/B metadata between
userspace and the bootloader, he could just as well have bricked the
device there and then.

Rasmus

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Jan Kiszka]

On 20.10.26 20:16, Marek Vasut wrote:
> On 10/20/26 2:55 PM, Richard Weinberger wrote:
>> On Dienstag, 20. Oktober 2026 14:53 Marek Vasut wrote:
>>>> What if you have something like this in your bootcmd: "env import -t
>>>> ${loadaddr} ${filesize}"
>>>> to import variables form a file like /boot/extraEnv.txt?
>>>
>>> How do you authenticate extraEnv.txt in this case ?
>>>
>>> If you do not authenticate the file, then it is game over.
>>
>> Well, since I allow only very few variables who's content can't harm,
>> it's okay.
> 
> I think there is a bit more to this -- what about "env set" usage in U-
> Boot scripts, should that "env set" invocation be able to set non-
> writeable variables or not ?
> 
> If I recall the discussion around the addition of the writeable list
> right, it did originally filter even import of variables into live env
> (what env set / env import does), but that was removed in one of the
> follow up versions, because if attacker has ability to modify the env at
> runtime, it is all lost.
> 

The primary purpose of that list is to allow importing env setting from
unauthenticated sources but then only permitting a certain list of
variables to adjust their states accordingly. Variables no in the list
will stay with their hard-coded, typically image-authenticated values.
Env storages may then still carry value for those protected vars, but
those will be ignored.

> But please don't get me wrong, I see the issue and the wording of the
> ENV_WRITEABLE_LIST symbol is not good. But I am not yet convinced that
> it is not up to the user to secure the U-Boot shell. What would you
> suggest we do to improve the situation here ?
> 
>> Of course you need to be very careful, but that's a different story.
> Right.

Configuring U-Boot into some secure lock-down remains a challenge, that
is true. Long ago, I was dreaming of some "lock me down" meta switch
that generic features could consult to flip their default behavior if
set and that board support could also take into account when there are
specialties. Would still start with a convention, would still need
engineering and may still not prevent all bugs, but at least in bug-free
setups, users would have to invest much more to get things wrong by chance.

For UEFI secure boot, we use in isar-cip-core now such a config snippet [1]:

### Secure boot config
# CONFIG_BOOTSTD_DEFAULTS is not set
# CONFIG_BOOTMETH_CROS is not set
# CONFIG_BOOTMETH_EXTLINUX is not set
# CONFIG_BOOTMETH_EXTLINUX_PXE is not set
# CONFIG_BOOTMETH_VBE is not set
# CONFIG_BOOTMETH_SCRIPT is not set
CONFIG_BOOTDELAY=-2
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="bootflow scan -lb; echo 'EFI Boot failed!'; sleep
1000; reset"
CONFIG_HUSH_PARSER=y
CONFIG_EFI_PARTITION=y
CONFIG_FS_FAT=y
CONFIG_EFI_SECURE_BOOT=y
# overruled by CONFIG_EFI_MM_COMM_TEE where available
CONFIG_EFI_VARIABLES_PRESEED=y

Not fully generic, just considering the few boards we have in scope
there so far and their defconfigs.

Jan

[1]
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg?ref_type=heads

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Massimo Pegorer]

Il giorno mer 21 ott 2026 alle ore 09:28 Rasmus Villemoes ha scritto:
>
> On Tue, Oct 20 2026, Richard Weinberger <richard@sigma-star.at> wrote:
>
> > On Dienstag, 20. Oktober 2026 12:22 Marek Vasut wrote:
> >> >> -   writeable flag can be written and modified at runtime. No variables
> >> >> -   can be otherwise created, written or imported into the environment.
> >> >> +   writeable flag can be written from stored environment. This
> >> >> +   restricts only environment loading, not runtime modification using
> >> >> +   "env set", etc.
> >> >
> >> > Wow, just wow.
> >> > I always assumed that the protection applies also to "env import ..." too
> >> > since the documentation explicitly said "written or imported into the environment".
> >> >
> >> > Instead of fixing the documentation, are we sure that this isn't a serve (security)
> >> > bug which needs addressing?
> >> If the attacker has access to U-Boot shell, then they have unrestricted
> >> access to the system and it is over (the attacker can e.g. modify memory
> >> which can be used to circumvent other protections). For the writeable
> >> list to have any meaningful effect, U-Boot shell access must be disabled
> >> (e.g. bootdelay set to -2 or similar). The writeable list protects
> >> U-Boot from importing undesired data from the external environment.
> >
> > Well, I have a different use case in mind.
> >
> > What if you have something like this in your bootcmd: "env import -t ${loadaddr} ${filesize}"
> > to import variables form a file like /boot/extraEnv.txt?
> > I like this a lot because it allows applications to set various u-boot variables.
> > And to make sure to allow only a trusted set of variables, CONFIG_ENV_WRITEABLE_LIST
> > is configured to that set.
>
> You can do this today, but not through ENV_WRITEABLE_LIST. If you give
> 'env import' extra arguments, those are treated as names of the (only)
> variable settings in the imported env block to honour. So you can do
>
>   env import -t ${loadaddr} ${filesize} ${safe_vars}
>
> That can for example be used to have a completely static environment
> (i.e. never store/load it to/from permanent storage), yet import the
> metadata necessary for doing A/B slot selection from somewhere that
> userspace can update when installing new firmware. Obviously, one should
> also sanity check those imported variables, but the point is that one
> doesn't risk the above command overwriting/setting $bootcmd or $verify
> or similar. And if an attacker has had sufficient access to manipulate
> whatever mechanism is used for communicating A/B metadata between
> userspace and the bootloader, he could just as well have bricked the
> device there and then.

Thanks to Fiona for the clarification (I wasn't aware of the "env load" command)
and thanks to Rasmus for reminding me of the details I'd forgotten on how to
make "env import" safer. Indeed, I agree with his approach. Having the "env
import" command built-in with just the variables that need to be imported
specified should be like having built-in these variables flagged as writable
and everything else not.

Regards,
Massimo