[PATCH 0/3] environment: Allow autoprobing env devices without CONFIG_INSECURE

[PATCH 0/3] environment: Allow autoprobing env devices without CONFIG_INSECURE

[Sascha Hauer]

Autoprobing environment devices vie barebox environment GUID currently
only works with CONFIG_INSECURE enabled. Add an explicit Kconfig option
for it.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Sascha Hauer (3):
      environment: Drop /dev/env0 default
      environment: add global.env.path
      environment: add explicit option to allow searching for environment devices

 common/Kconfig       | 14 ++++++++++++++
 common/environment.c | 10 ++++++----
 2 files changed, 20 insertions(+), 4 deletions(-)
---
base-commit: 019d102038a64e6b6e8f445cbfd2d15e68d0ec3f
change-id: 20260428-env-autoprobe-621b9d14ab98

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>

[PATCH 1/3] environment: Drop /dev/env0 default

[Sascha Hauer]

Since [1] all boards that want to use /dev/env0 as environment path do so
explicitly, so we can drop the default fallback to /dev/env0.

[1] c31204804b ("environment: explicitly set env path to /dev/env0 where used")

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 common/environment.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/common/environment.c b/common/environment.c
index ec14d0629a..207b58e743 100644
--- a/common/environment.c
+++ b/common/environment.c
@@ -132,8 +132,6 @@ const char *default_environment_path_get(void)
 	cdev = default_environment_path_search();
 	if (cdev)
 		default_environment_path = basprintf("/dev/%s", cdev->name);
-	else
-		default_environment_path = xstrdup("/dev/env0");
 
 	return default_environment_path;
 }

-- 
2.47.3

[PATCH 2/3] environment: add global.env.path

[Sascha Hauer]

barebox doesn't give an indication where the environment is stored without
actually doing a loadenv/saveenv. Add global.env.path which can be used to
show the path or even to set it.

A variable added with globalvar_add_simple_string() will be set to an empty
string whereas default_environment_path_get() used to return NULL when unset,
so we have to catch this explicitly.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 common/environment.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/common/environment.c b/common/environment.c
index 207b58e743..f883a520c6 100644
--- a/common/environment.c
+++ b/common/environment.c
@@ -126,7 +126,7 @@ const char *default_environment_path_get(void)
 {
 	struct cdev *cdev;
 
-	if (default_environment_path)
+	if (default_environment_path && *default_environment_path)
 		return default_environment_path;
 
 	cdev = default_environment_path_search();
@@ -547,9 +547,13 @@ int envfs_load(const char *filename, const char *dir, unsigned flags)
 static int register_env_vars(void)
 {
 	globalvar_add_simple_bool("env.autoprobe", &global_env_autoprobe);
+	globalvar_add_simple_string("env.path", &default_environment_path);
+
 	return 0;
 }
 postcore_initcall(register_env_vars);
 BAREBOX_MAGICVAR(global.env.autoprobe,
                  "Automatically probe known block devices for environment");
+BAREBOX_MAGICVAR(global.env.path,
+                 "The path the environment is stored");
 #endif

-- 
2.47.3

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

[Sascha Hauer]

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

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 common/Kconfig       | 14 ++++++++++++++
 common/environment.c |  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/common/Kconfig b/common/Kconfig
index fd422714d5..f74f06b4ad 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -987,6 +987,20 @@ config ENV_HANDLING
 	  A safe use of the mutable environment may be possible if board code only
 	  mounts it after verifying a JSON Web Token that enables a debug mode.
 
+config ENV_HANDLING_AUTOPROBE
+	depends on ENV_HANDLING
+	bool "Autoprobe for environment devices"
+	default y
+	help
+	  There are two ways for specifying where the barebox environment is. The first one
+	  specifies the path explicitly in the device tree or board code. The other one is
+	  to automatically search it on block devices which is enabled with this option.
+	  Here a partition with the barebox environment GUID is searched. If this option
+	  is enabled and no environment is chosen by device tree or board code then a block
+	  device containing a partition with the barebox environment GUID is used for the
+	  environment. A block device barebox has booted from is preferred over other block
+	  devices.
+
 config DEFAULT_ENVIRONMENT
 	select CRC32
 	bool
diff --git a/common/environment.c b/common/environment.c
index f883a520c6..a3281feca2 100644
--- a/common/environment.c
+++ b/common/environment.c
@@ -53,7 +53,7 @@ struct action_data {
 
 #define TMPDIR "/.defaultenv"
 
-static int global_env_autoprobe = IS_ENABLED(CONFIG_INSECURE);
+static int global_env_autoprobe = IS_ENABLED(CONFIG_ENV_HANDLING_AUTOPROBE);
 static char *default_environment_path;
 
 void default_environment_path_set(const char *path)

-- 
2.47.3

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

[Marco Felsch]

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

Regards,
  Marco


> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  common/Kconfig       | 14 ++++++++++++++
>  common/environment.c |  2 +-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/common/Kconfig b/common/Kconfig
> index fd422714d5..f74f06b4ad 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -987,6 +987,20 @@ config ENV_HANDLING
>  	  A safe use of the mutable environment may be possible if board code only
>  	  mounts it after verifying a JSON Web Token that enables a debug mode.
>  
> +config ENV_HANDLING_AUTOPROBE
> +	depends on ENV_HANDLING
> +	bool "Autoprobe for environment devices"
> +	default y
> +	help
> +	  There are two ways for specifying where the barebox environment is. The first one
> +	  specifies the path explicitly in the device tree or board code. The other one is
> +	  to automatically search it on block devices which is enabled with this option.
> +	  Here a partition with the barebox environment GUID is searched. If this option
> +	  is enabled and no environment is chosen by device tree or board code then a block
> +	  device containing a partition with the barebox environment GUID is used for the
> +	  environment. A block device barebox has booted from is preferred over other block
> +	  devices.
> +
>  config DEFAULT_ENVIRONMENT
>  	select CRC32
>  	bool
> diff --git a/common/environment.c b/common/environment.c
> index f883a520c6..a3281feca2 100644
> --- a/common/environment.c
> +++ b/common/environment.c
> @@ -53,7 +53,7 @@ struct action_data {
>  
>  #define TMPDIR "/.defaultenv"
>  
> -static int global_env_autoprobe = IS_ENABLED(CONFIG_INSECURE);
> +static int global_env_autoprobe = IS_ENABLED(CONFIG_ENV_HANDLING_AUTOPROBE);
>  static char *default_environment_path;
>  
>  void default_environment_path_set(const char *path)
> 
> -- 
> 2.47.3
> 
> 
> 

-- 
#gernperDu 
#CallMeByMyFirstName

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

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

[Ahmad Fatoum]

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?

Cheers,
Ahmad

> 
> Regards,
>   Marco
> 
> 
>>
>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>> ---
>>  common/Kconfig       | 14 ++++++++++++++
>>  common/environment.c |  2 +-
>>  2 files changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index fd422714d5..f74f06b4ad 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -987,6 +987,20 @@ config ENV_HANDLING
>>  	  A safe use of the mutable environment may be possible if board code only
>>  	  mounts it after verifying a JSON Web Token that enables a debug mode.
>>  
>> +config ENV_HANDLING_AUTOPROBE
>> +	depends on ENV_HANDLING
>> +	bool "Autoprobe for environment devices"
>> +	default y
>> +	help
>> +	  There are two ways for specifying where the barebox environment is. The first one
>> +	  specifies the path explicitly in the device tree or board code. The other one is
>> +	  to automatically search it on block devices which is enabled with this option.
>> +	  Here a partition with the barebox environment GUID is searched. If this option
>> +	  is enabled and no environment is chosen by device tree or board code then a block
>> +	  device containing a partition with the barebox environment GUID is used for the
>> +	  environment. A block device barebox has booted from is preferred over other block
>> +	  devices.
>> +
>>  config DEFAULT_ENVIRONMENT
>>  	select CRC32
>>  	bool
>> diff --git a/common/environment.c b/common/environment.c
>> index f883a520c6..a3281feca2 100644
>> --- a/common/environment.c
>> +++ b/common/environment.c
>> @@ -53,7 +53,7 @@ struct action_data {
>>  
>>  #define TMPDIR "/.defaultenv"
>>  
>> -static int global_env_autoprobe = IS_ENABLED(CONFIG_INSECURE);
>> +static int global_env_autoprobe = IS_ENABLED(CONFIG_ENV_HANDLING_AUTOPROBE);
>>  static char *default_environment_path;
>>  
>>  void default_environment_path_set(const char *path)
>>
>> -- 
>> 2.47.3
>>
>>
>>
> 

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

Re: [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 |

Re: [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 |

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

[Sascha Hauer]

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 |

Re: (subset) [PATCH 0/3] environment: Allow autoprobing env devices without CONFIG_INSECURE

[Sascha Hauer]

On Tue, 28 Apr 2026 11:24:09 +0200, Sascha Hauer wrote:
> Autoprobing environment devices vie barebox environment GUID currently
> only works with CONFIG_INSECURE enabled. Add an explicit Kconfig option
> for it.
> 
> 

Applied, thanks!

[1/3] environment: Drop /dev/env0 default
      https://git.pengutronix.de/cgit/barebox/commit/?id=88c56ccae7f2 (link may not be stable)
[2/3] environment: add global.env.path
      https://git.pengutronix.de/cgit/barebox/commit/?id=7675489c6ac4 (link may not be stable)

Best regards,
-- 
Sascha Hauer <s.hauer@pengutronix.de>