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-=whf2Pb8fSmUsLRSn6CnYvQoyUkLikKpFDWN_xnTJqix=A@mail.gmail.com>
Date: Thu, 4 Jul 2024 10:55:46 -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 10:46, Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> As far as speed goes, there are many legitimate applications that cannot
> make a syscall every time.

This is not an argument.

Nobody suggested a system call each time.

What I talked about, and suggested, was rdrand and user-space mixing.
The system call would be a "initialize the pool" thing with possibly
some re-seeding occasionally.

> Anyway, those actual users exist, and the partial solutions and hacks
> required to workaround this shortcoming are kind of grotesque and in one
> way or another bad. This isn't theoretical. I'm not working on this for
> "fun".

Once again: I don't want to hear "users exist".

I want to hear *from* those users. Because I would have expected all
those users to already have perfectly working setups in place already.

A trivial google for "rdrand library" finds lots of hits for things
that then use the AES-NI instructions to whiten things etc.

And several of them mention OS X and Windows in addition to Linux. So
those things are at least partly portable.

And no, I'm *NOT* interested in catering to the crazies that say "we
can't mix in the TSC values and do rdrand, because we don't trust
those". That's literally the kind of people I want to avoid lik,e the
plague, and WHY I don't want more of this in the kernel.

Because sane users don't say that. Sane users say "every round, we mix
in the TSC, and every X rounds we do rdread, and every 100*X rounds we
do rdseed, and that means that the end result in not really
predictable even if you've started from the same virtual machine
image".

And sane users presumably ALREADY HAVE THIS.

                  Linus