linux-kernel - Re: deconflicting new syscall numbers for 6.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-=wgqD9h0Eb-n94ZEuK9SugnkczXvX497X=OdACVEhsw5xQ@mail.gmail.com>
Date: Thu, 4 Jul 2024 11:35:12 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: jolsa@...nel.org, mhiramat@...nel.org, cgzones@...glemail.com, 
	brauner@...nel.org, linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: deconflicting new syscall numbers for 6.11

On Thu, 4 Jul 2024 at 11:18, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> See what my argument is? I suspect _strongly_ that this is all
> completely over-engineered based on theoretical grounds that aren't
> actually practical grounds.

I also have a separate suggestion: I'm more than happy to do something
*MUCH SIMPLER*.

If people want just generation counts, we can give them generation
counts and maybe something extra in the vdso read-only page.  No new
VM stuff, no new "allocate a buffer that the kernel manages", just
something like one cacheline of helper data in the vdso page that is
shared with everybody and is already mapped.

THAT is what the vdso stuff is designed for. It's not supposed to be a
whole new library routine.

The state allocation should all be done in user space. The mixing
should all be done in user space. As far as I can tell, the *ONLY*
reason this is at all about the kernel is that "generation" counter.

Just expose the generation counter in the vdso data. It will even be
backwards compatible, in that old kernels will always have a value of
zero, and whatever user space library then uses the generation counter
to check that we haven't had some migration event or whetever won't
get the *migration* events, but the code will otherwise work.

And the regular user space library can decide to use whatever mixing
it wants, whatever state size it wants, and the kernel doesn't have to
worry about special memory allocations.

See why I think this is all so *HORRENDOUSLY* over-engineered? The
kernel has absolutely _zero_ special knowledge about random numbers
that user space doesn't have, except for that *one* number.

And you literally don't want to do kernel system calls anyway due to
performance, so your code is 99% user code anyway. KEEP IT THAT WAY.
Don't add it to the kernel.

                Linus