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

[Sascha Hauer <s.hauer@pengutronix.de>]

On Mon, May 04, 2026 at 03:52:42PM +0200, Ahmad Fatoum wrote:
> 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(); ?

As said, that's not enough. We would have to call nvvar_load() before
default_environment_path_get() as well.

> 
> > 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...

That could leak in unintended into a bsp during development while
thinking about development convenience and not about security. I thought
that was the point of having HAS_INSECURE_DEFAULTS: To have a marker
that says: Look at every option selecting this option and think about
its security implications.

> 
> 
> > 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

It isn't, as it's guarded by SCONFIG_ENVIRONMENT_LOAD in my case.

> 
> - 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...

Ok.

As CONFIG_INSECURE_DEFAULTS and CONFIG_INSECURE predates security
policies we might want to rethink these options anyway. Should they be
there at all? It seems there are many ways to configure an insecure
system with CONFIG_INSECURE_DEFAULTS disabled and at the same time what
it covers is in parts redundant to what we have in security policies.

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 |