Re: [PATCH] init/main.c: Initialize early LSMs after arch code

[Guenter Roeck]

On 8/8/24 02:57, KP Singh wrote:
> On Thu, Aug 8, 2024 at 6:07 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> > On 8/7/24 19:13, Guenter Roeck wrote:
> > ...
> > > I'll need to establish a baseline first to determine if the failures
> > > are caused by newly enabled configuration options or by this patch set.
> > > Below are just early test results.
> > >
> > > [ Though if those are all upstream there seems to be be something seriously
> > >     wrong with the lockdown lsm.
> > > ]
> >
> > Verdict is that all the messages below are from this patch set.
> >
> > On top of the reports below, alpha images fail completely, and the
> > backtraces are seen with several architectures. Please see the
> > "testing" column at https://kerneltests.org/builders for details.
> >
> > The only unrelated problems are the apparmor unit test failures;
> > those apparently fail on all big endian systems.
> >
> > Guenter
> >
> > > Guenter
> > >
> > > ----
> > > arm:
> > >
> > > [    0.000000] ------------[ cut here ]------------
> > > [    0.000000] WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:199 static_key_enable_cpuslocked+0xb0/0xfc
> > > [    0.000000] static_key_enable_cpuslocked(): static key 'security_hook_active_locked_down_0+0x0/0x8' used before call to jump_label_init()
> > > [    0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.11.0-rc2-00134-g679d51771510 #1
> > > [    0.000000] Hardware name: Generic DT based system
> > > [    0.000000] Call trace:
> > > [    0.000000]  unwind_backtrace from show_stack+0x18/0x1c
> > > [    0.000000]  show_stack from dump_stack_lvl+0x48/0x74
> > > [    0.000000]  dump_stack_lvl from __warn+0x7c/0x134
> > > [    0.000000]  __warn from warn_slowpath_fmt+0x9c/0xdc
> > > [    0.000000]  warn_slowpath_fmt from static_key_enable_cpuslocked+0xb0/0xfc
> > > [    0.000000]  static_key_enable_cpuslocked from security_add_hooks+0xa0/0x104
> > > [    0.000000]  security_add_hooks from lockdown_lsm_init+0x1c/0x2c
> > > [    0.000000]  lockdown_lsm_init from initialize_lsm+0x44/0x84
> > > [    0.000000]  initialize_lsm from early_security_init+0x3c/0x58
> > > [    0.000000]  early_security_init from start_kernel+0x78/0x748
> > > [    0.000000]  start_kernel from 0x0
> > > [    0.000000] irq event stamp: 0
> > > [    0.000000] hardirqs last  enabled at (0): [<00000000>] 0x0
> > > [    0.000000] hardirqs last disabled at (0): [<00000000>] 0x0
> > > [    0.000000] softirqs last  enabled at (0): [<00000000>] 0x0
> > > [    0.000000] softirqs last disabled at (0): [<00000000>] 0x0
> > > [    0.000000] ---[ end trace 0000000000000000 ]---
>
> This seems very odd for especially ARM as I don't see this error when
> I do it on the next branch. Possibly something in setup_arch is
> initializing jump_tables indirectly between v6.11-rc2 and linux-next
> and/or this is a warning that does not immediately splash up on the
> dmesg.

I suspect it is more likely because I have lots of debug options enabled in my tests.

> Both ARM64 and x86 (the architectures I really have access to)
> initializes jump_tables and x86 is the only architecture that does an
> explicit static_call_init is x86 and it's already in the setup_arch
> code.
>
> https://elixir.bootlin.com/linux/v6.11-rc2/source/arch/arm64/kernel/setup.c#L295
> https://elixir.bootlin.com/linux/v6.11-rc2/source/arch/x86/kernel/setup.c#L783
>
> Guenter, I have updated my tree, could you give it another run please?

Sure, underway.

Guenter