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

[Sascha Hauer]

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.

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

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.

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 |