Re: [PATCH] doc: fix description of CONFIG_ENV_WRITEABLE_LIST

[Rasmus Villemoes <ravi@prevas.dk>]

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