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

[Paul Moore]

On Wed, Jul 31, 2024 at 6:33 PM KP Singh <kpsingh at kernel.org> wrote:
> On Wed, Jul 31, 2024 at 11:33 PM Paul Moore <paul at paul-moore.com> wrote:
> > 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
>
> I sent this a couple of minutes after you sent the email. I was trying
> to reproduce / confirm the original issue before posting the patch.

Yes, I think our emails must have crossed paths.  Regardless, let's
see if we can get some ACKs/Reviews from the static call folks just to
make sure we are doing something silly by moving the init point.

-- 
paul-moore.com