[PATCH 3/3] environment: add explicit option to allow searching for environment devices

[Ahmad Fatoum]

Hello Sascha,

On 5/4/26 3:39 PM, Sascha Hauer wrote:
> On Mon, May 04, 2026 at 02:02:16PM +0200, Ahmad Fatoum wrote:
>> Hello,
>>
>> On 5/4/26 1:35 PM, Marco Felsch wrote:
>>> Hi Sascha,
>>>
>>> On 26-04-28, Sascha Hauer wrote:
>>>> Add an explicit Kconfig option to allow searching the environment storage path
>>>> based on the barebox environment partition GUID.
>>>>
>>>> So far this depended on CONFIG_INSECURE being set. First of all loading the
>>>> barebox environment from storage is always insecure as the barebox environment
>>>> doesn't have any security measures.
>>
>> It's possible to only allow environment loading after having verified
>> that the system is in development mode for example.
>>
>> Autoloading the environment can't be secured as you note.
>>
>>
>>>> The difference that comes with loading
>>>> the environment from an explicitly specified storage device and autoprobing
>>>> it from the available block devices is that with the former an attacker would
>>>> need access to the internal storage whereas with the latter barebox could
>>>> be tricked into loading an environment from an external SD card.
>>>>
>>>> Whether or not this is acceptable depends on the case, so ask the user for it.
>>>>
>>>> Real security can only be provided by not loading an environment from storage
>>>> at all, but that can be controlled at compile time by disabling CONFIG_ENV_HANDLING
>>>> or at runtime by security policies.
>>>
>>> TBH I actually don't see why this option can't follow the
>>> CONFIG_INSECURE.
>>>
>>> Since ENV handling is enabled you do pull the HAS_INSECURE_DEFAULTS=y.
>>> As you written above env handling is always insecure as of now.
>>>
>>> So it seems that you want to get rid of the CONFIG_INSECURE=y in your
>>> setup. The only users of this CONFIG switch are global_env_autoprobe and
>>> lib/random.c. Therefore my question, that I don't see why we can't stick
>>> with the CONFIG_INSECURE switch.
>>
>> I also don't understand Sascha's motivation here.
>>
>> You can add global.env.autoprobe=1 to your environment to opt-in despite
>> CONFIG_INSECURE being disabled. What's the new Kconfig option needed for?
> 
> Maybe I was confused by that because it's evaluated in the wrong order.
> global.env.autoprobe is evaluated in default_environment_path_get() which
> is executed before the default environment is loaded. We could fix that
> with the cost of calling nvvar_load() twice, once with the default
> environment loaded and once again with the persistent environment
> loaded.

Ah.. Should load_environment() be changed, so defaultenv_load() happens
before default_environment_path = default_environment_path_get(); ?

> That said, I think whether or not we load the environment by part UUID
> deserves its own decision, it shouldn't be hidden behind a generic
> option.

It has its own decision though, it's called global.env.autoprobe if it
were made to work...


> Also it's not consistent to claim that loading environment by
> part UUID is insecure, but allowing it to be bypassed by setting
> global.env.autoprobe=1, as if that would make it secure.

I disagree. There is a difference:

- Enabling the config option on boot up is always insecure

- Setting global.env.autoprobe=1 after verifying a runtime condition can
be secure if e.g. an unlock token has been verified

> ENV_HANDLING_AUTOPROBE depends on ENV_HANDLING which itself selects
> HAS_INSECURE_DEFAULTS which indicates that an option is selected that
> has "potentially insecure defaults". Sounds consistent to me.

Just pointing out we already have a magicvar for that.

I am not against adding ENV_HANDLING_AUTOPROBE in principle, but I think
the commit needs a better rationale why we need it when CONFIG_INSECURE
and global.env.autoprobe are already there...

Cheers,
Ahmad

> 
> Sascha
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |