netdev - Re: Flaw in "random32: update the net random state on interrupt and activity"

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: <CAHk-=whL2Uz7V8OGvZBN0aW0cgn3xTQhPu-jb-Aikn65nkt4Dw@mail.gmail.com>
Date:   Fri, 7 Aug 2020 13:24:20 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Willy Tarreau <w@....eu>, Marc Plumb <lkml.mplumb@...il.com>,
        "Theodore Ts'o" <tytso@....edu>, Netdev <netdev@...r.kernel.org>,
        Amit Klein <aksecurity@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Andrew Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        stable <stable@...r.kernel.org>
Subject: Re: Flaw in "random32: update the net random state on interrupt and activity"

On Fri, Aug 7, 2020 at 1:16 PM Andy Lutomirski <luto@...capital.net> wrote:
>
> I think this will come down to actual measurements :).

Numbers talk, bullshit walks.

But:

> If the cost of one block of cache-cold ChaCha20 is 100 cycles of actual computation and 200 cycles of various cache misses, then let’s do more than one block.

That's *completely* nonsensical thinking and crazy talk.

If the issue is latency (and for a lot of networking, that literally
*is* the issue), your mental model is completely insane.

"Oh, it's so expensive that we should queue *more*" is classic
throughput thinking, and it's wrong.

If you have performance problems, you should look really really hard
at fixing latency.

Because fixing latency helps throughput. But fixing throughput _hurts_ latency.

It really is that simple. Latency is the much more important thing to optimize.

Nobody cares about "bulk TCP sequence numbers". Sure, you'll find
benchmarks for it, because it's a lot easier to benchmark throughput.
But what people _care_ about is generally latency.

              Linus