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

[KP Singh]

On Wed, Jul 31, 2024 at 11:33 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Tue, Jul 30, 2024 at 4:36 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On Tue, Jul 30, 2024 at 1:40 PM KP Singh <kpsingh@xxxxxxxxxx> wrote:
> > > On Tue, Jul 30, 2024 at 5:03 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > > > On Tue, Jul 30, 2024 at 7:34 AM Borislav Petkov <bp@xxxxxxxxx> 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.

https://lore.kernel.org/linux-security-module/20240731213429.2244234-1-kpsingh@xxxxxxxxxx/T/#u

> --
> paul-moore.com