linux-kernel - Re: next/master boot bisection: next-20190215 on beaglebone-black

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 16 Apr 2019 14:04:10 -0700
From:   Guenter Roeck <groeck@...gle.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     Kees Cook <keescook@...omium.org>, kernelci@...ups.io,
        Guillaume Tucker <guillaume.tucker@...labora.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>,
        Mark Brown <broonie@...nel.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Matt Hart <matthew.hart@...aro.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Kevin Hilman <khilman@...libre.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Adrian Reber <adrian@...as.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Linux MM <linux-mm@...ck.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Richard Guy Briggs <rgb@...hat.com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>, info@...nelci.org
Subject: Re: next/master boot bisection: next-20190215 on beaglebone-black

On Tue, Apr 16, 2019 at 1:37 PM Dan Williams <dan.j.williams@...el.com> wrote:
>
> On Tue, Apr 16, 2019 at 12:34 PM Guenter Roeck <groeck@...gle.com> wrote:
> >
> > On Tue, Apr 16, 2019 at 11:54 AM Dan Williams <dan.j.williams@...el.com> wrote:
> > >
> > > On Thu, Apr 11, 2019 at 1:54 PM Guenter Roeck <groeck@...gle.com> wrote:
> > > [..]
> > > > > > Boot tests report
> > > > > >
> > > > > > Qemu test results:
> > > > > >     total: 345 pass: 345 fail: 0
> > > > > >
> > > > > > This is on top of next-20190410 with CONFIG_SHUFFLE_PAGE_ALLOCATOR=y
> > > > > > and the known crashes fixed.
> > > > >
> > > > > In addition to CONFIG_SHUFFLE_PAGE_ALLOCATOR=y you also need the
> > > > > kernel command line option "page_alloc.shuffle=1"
> > > > >
> > > > > ...so I doubt you are running with shuffling enabled. Another way to
> > > > > double check is:
> > > > >
> > > > >    cat /sys/module/page_alloc/parameters/shuffle
> > > >
> > > > Yes, you are right. Because, with it enabled, I see:
> > > >
> > > > Kernel command line: rdinit=/sbin/init page_alloc.shuffle=1 panic=-1
> > > > console=ttyAMA0,115200 page_alloc.shuffle=1
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 0 PID: 0 at ./include/linux/jump_label.h:303
> > > > page_alloc_shuffle+0x12c/0x1ac
> > > > static_key_enable(): static key 'page_alloc_shuffle_key+0x0/0x4' used
> > > > before call to jump_label_init()
> > >
> > > This looks to be specific to ARM never having had to deal with
> > > DEFINE_STATIC_KEY_TRUE in the past.
> > >
> >
> > This affects almost all architectures, not just arm, presumably
> > because parse_args() is called before jump_label_init() in
> > start_kernel().
>
> Hmm, you're right, but this should effect *every* architecture not
> just ARM. Why is it not screaming at me on x86?
>
Guess you figured that out yourself...

> > I did not bother to report back with further details
> > after someone stated that qemu doesn't support omap2, and the context
> > seemed to suggest that running any other tests would not add any
> > value.
> >
> > > I am able to avoid this warning by simply not enabling JUMP_LABEL
> > > support in my build.
> > >
> >
> > Fine with me, as long as CONFIG_SHUFFLE_PAGE_ALLOCATOR=y is not
> > enabled by default, or if it is made dependent on !JUMP_LABEL.
>
> Ah, no, the problem is that jump_label_init() is called by
> setup_arch() on x86, and smp_prepare_boot_cpu() on powerpc, but not
> until after parse_args() on ARM.
>
Anywhere but arm64, x86, and ppc, really.

$ git grep jump_label_init arch
arch/arm64/kernel/smp.c:        jump_label_init();
arch/powerpc/lib/feature-fixups.c:      jump_label_init();
arch/x86/kernel/setup.c:        jump_label_init();

> Given it appears to be safe to call jump_label_init() early how about
> something like the following?
>
> diff --git a/init/main.c b/init/main.c
> index 598e278b46f7..7d4025d665eb 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -582,6 +582,8 @@ asmlinkage __visible void __init start_kernel(void)
>         page_alloc_init();
>
>         pr_notice("Kernel command line: %s\n", boot_command_line);
> +       /* parameters may set static keys */
> +       jump_label_init();
>         parse_early_param();
>         after_dashes = parse_args("Booting kernel",
>                                   static_command_line, __start___param,
> @@ -591,8 +593,6 @@ asmlinkage __visible void __init start_kernel(void)
>                 parse_args("Setting init args", after_dashes, NULL, 0, -1, -1,
>                            NULL, set_init_arg);
>
> -       jump_label_init();
> -

That should work, unless there was a reason to have it that late. It
doesn't look like that was the case, but I may be missing something.

Guenter