Re: [PATCH] init/main.c: Initialize early LSMs after arch code
From: Guenter Roeck
Date: Thu Aug 08 2024 - 12:43:18 EST
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.
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?
This version is much better, except for alpha which still crashes hard
with no log output. It bisects to one of your patches (results below).
Also, there is a backtrace on ppc (also see below), but that is unrelated
to your patches and only seen now because I enabled the security modules
on that architecture. I'll bring that up with ppc maintainers.
Thanks,
Guenter
---
bisect:
# bad: [b92c86ad4f4311706fe436a1545d9a97e6aebcf8] lsm: replace indirect LSM hook calls with static calls
# good: [de9c2c66ad8e787abec7c9d7eff4f8c3cdd28aed] Linux 6.11-rc2
git bisect start 'HEAD' 'v6.11-rc2'
# good: [bd2c890317b2d60b4afd89a374a56a7c9a0275bd] kernel: Add helper macros for loop unrolling
git bisect good bd2c890317b2d60b4afd89a374a56a7c9a0275bd
# good: [6a1e94163fc53a4f1b47a8689f416a1a3d0a154a] lsm: count the LSMs enabled at compile time
git bisect good 6a1e94163fc53a4f1b47a8689f416a1a3d0a154a
# first bad commit: [b92c86ad4f4311706fe436a1545d9a97e6aebcf8] lsm: replace indirect LSM hook calls with static calls
---
ppc backtrace:
LSM: initializing lsm=lockdown,capability,landlock,yama,loadpin,safesetid
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/smp.c:779 smp_call_function_many_cond+0x518/0x9d4
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc2-00127-g2e3e7093e9c8 #1
Hardware name: MPC8544DS e500v2 0x80210030 MPC8544 DS
NIP: c0172ca8 LR: c01731b0 CTR: 00000000
REGS: c2669d60 TRAP: 0700 Not tainted (6.11.0-rc2-00127-g2e3e7093e9c8)
MSR: 00021000 <CE,ME> CR: 24004288 XER: 20000000
GPR00: c002255c c2669e50 c253b5c0 c267b484 00000000 00000000 00000001 c2680000
GPR08: 00000000 00000003 c2680000 00000000 44004288 020a1e18 00000000 00000000
GPR16: 00000000 00000000 00000001 00000000 c0000000 c01731b0 00000000 c267b484
GPR24: c00224fc c0773760 c0770b50 00000000 00000000 00029000 00000000 00000000
NIP [c0172ca8] smp_call_function_many_cond+0x518/0x9d4
LR [c01731b0] smp_call_function+0x3c/0x58
Call Trace:
[c2669eb0] [84000282] 0x84000282
[c2669ec0] [c002255c] flush_tlb_kernel_range+0x2c/0x50
[c2669ed0] [c0023b8c] patch_instruction+0x108/0x1b0
[c2669ef0] [c00188a4] arch_static_call_transform+0x104/0x148
[c2669f10] [c2033ebc] security_add_hooks+0x138/0x24c
[c2669f40] [c2032e24] capability_init+0x24/0x38
[c2669f50] [c203322c] initialize_lsm+0x48/0x90
[c2669f70] [c2033b68] security_init+0x31c/0x538
[c2669fa0] [c2001154] start_kernel+0x5d4/0x81c
[c2669ff0] [c0000478] set_ivor+0x150/0x18c
Code: 91220000 81620004 3d20c209 3929e478 556b103a 7c84582e 7c89202e 81220000 2c040000 3929ffff 91220000 40a2fbb8 <0fe00000> 4bfffbb0 80e20000 2c070000
irq event stamp: 1204
hardirqs last enabled at (1203): [<c11d85f8>] _raw_spin_unlock_irqrestore+0x70/0xa8
hardirqs last disabled at (1204): [<c0023bcc>] patch_instruction+0x148/0x1b0
softirqs last enabled at (50): [<c0064b4c>] handle_softirqs+0x348/0x508
softirqs last disabled at (43): [<c0006fd0>] do_softirq_own_stack+0x34/0x4c
---[ end trace 0000000000000000 ]---
landlock: Up and running.
Yama: becoming mindful.
LoadPin: ready to pin (currently not enforcing)