linux-kernel - Re: [GIT PULL] probes: Updates for v6.11

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: <CAHk-=wi6RzMFr3zWfkwHh1JwLxQzN0BtH3H7M6JJogVxOat8CA@mail.gmail.com>
Date: Thu, 18 Jul 2024 17:49:50 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>, Arnd Bergmann <arnd@...db.de>
Cc: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, 
	Jeff Johnson <quic_jjohnson@...cinc.com>, Jiri Olsa <jolsa@...nel.org>, 
	Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] probes: Updates for v6.11

On Thu, 18 Jul 2024 at 17:28, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> But another fix that I have been carrying was missed:

Hmm. I'm starting to absolutely hate that "generic" syscall.tbl file,
and it was literally merged just two days ago.

That may not be a new record - I'm sure there have been other things
that I started hating even more quickly - but it's certainly up there
with the best (worst?) of them.

It's now come up twice in just this merge window for different
reasons, and I think both cases showed that it's just fundamentally
bogus.

There are system calls that are architecture-specific (the whole vdso
thing), and nothing is ever going to change that.

Others may not be as fundamentally tied to certain architectures -
like this uprobes thing - but will simply be introduced at different
times because they still need possibly a lot of architecture support.

So considering that it was added this merge window, and already is
showing all these issues before the merge window is even over, I'm not
at all convinced "scripts/syscall.tbl" has a future.

Now, I do think we should strive to unify the system call table
generation under one syntax. I don't think *that* is a bad idea.

But I'm not AT ALL convinced we should strive to unify the numbering,
and do it in one file.

In fact, I think that the numbering should not exist at all in that
"unified table syntax", because the number itself is causing problems.

That whole "the numbers themselves are a problem" is not a new issue,
we've seen all these silly renumbering issues forever, just look at
something like this:

  git log --oneline --merges --cc arch/x86/entry/syscalls/syscall_64.tbl

and that's with people often _trying_ to work together.  So I think
'scripts/syscall.tbl' is actively detrimental, because it introduces
*new* problems, and it doesn't actually solve that *old* problem.

So I think this needs to be re-visited.

One possible model might be:

 - remove the numbering from the syscall.tbl (because the numbers
_are_ going to be different)

 - make it really easy to add actual generic new system calls in one
place, for when the system call is NOT something that needs
architecture-specific trampolines and stuff

 - make the common infrastructure generate the numbers

because I think the current model of "let's share a table with
numbers" is already dead in the water before we have even completed a
single merge window with it.

Other ideas? Arnd?

             Linus