netdev - Re: pull-request: bpf-next 2022-03-21

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: <CAADnVQKreLtGkfAVXxwLGUVKobqYhBS5r+GtNa6Oc8BUzYa92Q@mail.gmail.com>
Date:   Mon, 21 Mar 2022 17:31:28 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Miller <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Netdev <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: pull-request: bpf-next 2022-03-21

On Mon, Mar 21, 2022 at 4:59 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, Mar 21, 2022 at 4:11 PM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > Did you look at the code?
> > In particular:
> > https://lore.kernel.org/bpf/164735286243.1084943.7477055110527046644.stgit@devnote2/
> >
> > it's a copy paste of arch/x86/kernel/kprobes/core.c
> >
> > How is it "bad architecture code" ?
>
> It's "bad architecture code" because the architecture maintainers have
> made changes to check ENDBR in the meantime.
>
> So it used to be perfectly fine. It's not any longer - and the
> architecture maintainers were clearly never actually cc'd on the
> changes, so they didn't find out until much too late.

Not denying that missing cc was an issue.

We can drop just arch patches:
      rethook: x86: Add rethook x86 implementation
      arm64: rethook: Add arm64 rethook implementation
      powerpc: Add rethook support
      ARM: rethook: Add rethook arm implementation

or everything including Jiri's work on top of it.
Which would be a massive 27 patches.

We'd prefer the former, of course.
Later during the merge window we can add a single
'rethook: x86' patch that takes endbr into account,
so that multi-kprobe feature will work on x86.
For the next merge window we can add other archs.
Would that work?