static_key_enable_cpuslocked(): static key 'security_hook_active_locked_down_0+0x0/0x10' used before call to jump_label_init()

[Paul Moore]

On Tue, Jul 30, 2024 at 4:36 PM Paul Moore <paul at paul-moore.com> wrote:
> On Tue, Jul 30, 2024 at 1:40 PM KP Singh <kpsingh at kernel.org> wrote:
> > On Tue, Jul 30, 2024 at 5:03 PM Paul Moore <paul at paul-moore.com> wrote:
> > > On Tue, Jul 30, 2024 at 7:34 AM Borislav Petkov <bp at alien8.de> wrote:
> > > >
> > > > Hi,
> > > >
> > > > this is with today's linux-next:
> > > >
> > > > ...
> > > >
> > > > 09:44:13  [console-expect]#kexec -e
> > > > 09:44:13  kexec -e
> > > > 09:44:16  ^[[?2004l^M[    0.000000] Linux version 6.11.0-rc1-next-20240730-1722324631886 (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP PREEMPT_DYNAMIC Tue Jul 30 07:40:55 UTC 2024
> > > > 09:44:16  [    0.000000] ------------[ cut here ]------------
> > > > 09:44:16  [    0.000000] WARNING: CPU: 0 PID: 0 at kernel/static_call_inline.c:153 __static_call_update+0x1c6/0x220
>
> ...
>
> > > KP, please take a look at this as soon as you can (lore link below for
> > > those who aren't on the list).  One obvious first thing to look at is
> > > simply moving the call to early_security_init(), but that requires
> > > some code audit to make sure it is safe and doesn't break something
> > > else.  Of course, if we can do something with how we setup/use static
> > > calls that is even better.  I'll take a look at it myself later today,
> > > but I'm busy with meetings for the next several hours.
> > >
> > > If we can't resolve this in the next day or two I'm going to
> >
> > Thanks for the ping.
> >
> > Taking a look, yeah it's possible that we need to move jump_label_init
> > before early_security_init / inside it.
> >
> > I will do a repro and test my change and reply back.
>
> I'm pretty sure we don't want to move jump_label_init() inside
> early_security_init(), we likely want to keep those as distinct calls
> in start_kernel().  Shuffling the ordering around seems like a better
> solution if we can't solve this some other way.
>
> Regardless, thanks for looking into this, I'll hold off on digging
> into this and wait for your patch.

Since I don't want to leave linux-next broken any longer, I'm going to
yank the static-call patches from the lsm/next branch but I'll leave
them in lsm/dev so you can continue to use that as a basis for your
fix.  If we don't have a fix in hand by the first half of next week,
I'll drop the patches from lsm/dev too and we can revisit the patchset
when you have a fix ready.

For casual observers, the lsm/next is normally an automatically
composed branch made up of the latest lsm/stable-X.Y and lsm/dev
branches however in this particular case I'm going to manually update
the lsm/next branch.  The normal process is described here:

* https://github.com/LinuxSecurityModule/kernel/blob/main/README.md

-- 
paul-moore.com