Re: [PATCH] init/main.c: Do jump_label_init before early_security_init

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Aug 01, 2024 at 10:34:41AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 31, 2024 at 09:15:04PM -0400, Paul Moore wrote:
> > On Wed, Jul 31, 2024 at 5:34 PM KP Singh <kpsingh@kernel.org> wrote:
> > >
> > > LSM indirect calls being are now replaced by static calls, this requires
> > > a jumpt_table_init before early_security_init where LSM hooks and their
> > > static calls and keys are initialized.
> > >
> > > Fixes: 2732ad5ecd5b ("lsm: replace indirect LSM hook calls with static calls")
> > > Signed-off-by: KP Singh <kpsingh@kernel.org>
> > > ---
> > >  init/main.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Does this look okay, static call folks?
> 
> Are we confused between jump_label/static_branch and static_call ?
> 
> > > diff --git a/init/main.c b/init/main.c
> > > index 206acdde51f5..5bd45af7a49e 100644
> > > --- a/init/main.c
> > > +++ b/init/main.c
> > > @@ -922,6 +922,8 @@ void start_kernel(void)
> > >         boot_cpu_init();
> > >         page_address_init();
> > >         pr_notice("%s", linux_banner);
> > > +       /* LSM and command line parameters use static keys */
> > > +       jump_label_init();
> > >         early_security_init();
> > >         setup_arch(&command_line);
> > >         setup_boot_config();
> > > @@ -933,8 +935,6 @@ void start_kernel(void)
> > >         boot_cpu_hotplug_init();
> > >
> > >         pr_notice("Kernel command line: %s\n", saved_command_line);
> > > -       /* parameters may set static keys */
> > > -       jump_label_init();
> > >         parse_early_param();
> > >         after_dashes = parse_args("Booting kernel",
> > >                                   static_command_line, __start___param,

Anyway, the scariest thing jump_label_init() does is
arch_jump_label_transform_static(). Which, IIRC, was used to optimize
NOPs on x86, which we've since removed.

Only csky and mips seem to still implement this hook, and they do
flush_icache() -- as one would expect.

If any of that is affected by the placement you propose, is something
you'd have to ask those architecture maintainers I'm afraid.

Aside from that I don't see a problem :-)