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]

Message-ID: <CAPcyv4hyOtJsnM6qqey7ADY=7brzVQ5TH3URrofmsQ57t1=WbQ@mail.gmail.com>
Date:   Tue, 16 Apr 2019 13:37:45 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Guenter Roeck <groeck@...gle.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 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?

> 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.

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();
-
        /*
         * These use large bootmem allocations and must precede
         * kmem_cache_init()