linux-kernel - Re: [PATCH] ARM: initialize jump labels before setup_machine

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] [day] [month] [year] [list]

Message-ID: <CAMj1kXGAf2twVczdxOCnYVPefnekT9U4J08+-5=GygAd7htDXg@mail.gmail.com>
Date:   Fri, 3 Jun 2022 10:17:35 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Russell King <linux@...linux.org.uk>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Stephen Boyd <swboyd@...omium.org>,
        "# 3.4.x" <stable@...r.kernel.org>
Subject: Re: [PATCH] ARM: initialize jump labels before setup_machine_fdt()

On Fri, 3 Jun 2022 at 10:12, Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> Hi Ard,
>
> On 6/3/22, Ard Biesheuvel <ardb@...nel.org> wrote:
> > The problem is that your original patch
>
> You remain extremely unpleasant to communicate with.

Noted.

> Can we keep
> things on topic please?
>

Sure. Are you saying the original patch is off-topic? Isn't that the
patch that caused the regression to begin with?

> > As far as I can tell, the early patching code on ARM does not rely on
> > the early fixmap code. Did you try just moving jump_label_init()
> > earlier in the function?
> >
> > Also, how did you test this change?
>
> Just booting a few configs in QEMU. I don't have access to real
> hardware right now unfortunately.
>
> Let me give a try to just moving the jump_label_init() function alone.
> That'd certainly make this patch a lot more basic, which would be a
> good thing, and might assuage your well justified concerns that too
> much boot order churn will break something subtle. I was just afraid
> of complicated intermingling with the other stuff after I saw that
> arm64 did things in the other order. But maybe that's silly.
>
> I'll send a v2 if that works, and send an update here if it doesn't.
> Thanks for the suggestion.
>
> Jason