Re: [PATCH v3 3/5] security: policy: set active policy on boot

[Fabian Pflug <f.pflug@pengutronix.de>]

On Wed, 2026-03-18 at 12:54 +0100, Ahmad Fatoum wrote:
> On 3/18/26 12:38, Fabian Pflug wrote:
> > On Wed, 2026-03-18 at 12:28 +0100, Ahmad Fatoum wrote:
> > > On 3/18/26 10:22, Fabian Pflug wrote:
> > > > If init name has been set at compiletime and the policy is available,
> > > > because it is part of the path, then set the active policy to the policy
> > > > selected by compiletime.
> > > > Since this is so early in the bootchain, there is no need to call
> > > > security_policy_activate, because there should not be any registered
> > > > callbacks at this moment in time.
> > > > If no policy could be found, then it will be filled as before by the
> > > > first call to is_allowed.
> > > 
> > > The code in is_allowed is:
> > > 
> > > if (!policy && *CONFIG_SECURITY_POLICY_INIT) {
> > >         security_policy_select(CONFIG_SECURITY_POLICY_INIT);
> > >         policy = active_policy;
> > > }
> > > 
> > > It becomes dead code with your change here as CONFIG_SECURITY_POLICY_INIT
> > > is a compile-time constant, there is no filling on the first call anymore.
> > 
> > I also thought about it, but if the initial policy is not part of the compiletime policies, but instead gets added
> > during board setup code, then the change in init will not find the specified policy, resulting in policy being NULL
> > and
> > this code still working.
> 
> I can't follow. policy is an argument and CONFIG_SECURITY_POLICY_INIT
> is not settable from any board, so that's dead code now AFAICS.

policy is the argument, but the argument could be NULL, for example if `IS_ALLOWED` is used in the code.
Then policy is replaced by active_policy, which could also be NULL, if `security_policy_get(CONFIG_SECURITY_POLICY_INIT)
` during init returns NULL, which is the case, if the policy is not registered at the time of call.
During security_init only CONFIG_SECURITY_POLICY_PATH are registered. So for example, you could add multiple policys
with `security_policy_add` inside your boardcode and have one of them declared as init policy with
CONFIG_SECURITY_POLICY_INIT. Then this path is taken during the first call to `IS_ALLOWED` (after board init)

Kind regards
Fabian
> 
> Cheers,
> Ahmad 
> 
> > 
> > > 
> > > > 
> > > > Signed-off-by: Fabian Pflug <f.pflug@pengutronix.de>
> > > > ---
> > > >  security/policy.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/security/policy.c b/security/policy.c
> > > > index 85333d9e6f..e2d1b10a78 100644
> > > > --- a/security/policy.c
> > > > +++ b/security/policy.c
> > > > @@ -235,6 +235,9 @@ static int security_init(void)
> > > >  	if (*CONFIG_SECURITY_POLICY_PATH)
> > > >  		security_policy_add(default);
> > > >  
> > > > +	if (*CONFIG_SECURITY_POLICY_INIT)
> > > > +		active_policy = security_policy_get(CONFIG_SECURITY_POLICY_INIT);
> > > > +
> > > 
> > > I think I decided initially against this, because there was initially
> > > a Sconfig option against changing the active security policy.
> > > 
> > > I believe now a single option is too limiting, it should instead be
> > > a directed graph that explains which policies are reachable from a given
> > > policy.
> > > 
> > > Anyways, the change here invalidates the Kconfig help text for
> > > SECURITY_POLICY_INIT.
> > > 
> > > I am not fully sure if this change is a good idea, but it needs to
> > > be fixed to be considered. I assume you do this, because checking
> > > the name of the policy doesn't trigger a selection like IS_ALLOWED does?
> > 
> > exactly.
> > during device_probe, there is a need to know the current policy name, if there is a policy active.
> > 
> > I will have a look into it.
> > 
> > Fabian
> > 
> > > 
> > > Thanks,
> > > Ahmad
> > > 
> > > 
> > > >  	return 0;
> > > >  }
> > > >  pure_initcall(security_init);
> > > > 
> > > 
> > 
>