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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 8 Aug 2020 13:47:49 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     George Spelvin <lkml@....org>
Cc:     Willy Tarreau <w@....eu>, 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>,
        "Theodore Ts'o" <tytso@....edu>,
        Marc Plumb <lkml.mplumb@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: Flaw in "random32: update the net random state on interrupt and activity"

On Sat, Aug 8, 2020 at 1:08 PM George Spelvin <lkml@....org> wrote:
>
> So assuming that once per interrupt equals "often" is completely false.

That's not what people are assuming.

They are assuming it's "unpredictable".

Guys, look up the real and true meaning of "random" some day.

Guess what? It at no point says "secure hash".

> Not to mention that the generators are per-CPU, and the CPU gnerating the
> random numbers might not be the one getting what few interrupts there are.
> (It's quite common in networking applications to bind network interrupts
> and application logic to separate CPUs.)

.. which is exactly why the commit that introduced this _also_ does
things from timer interrupts.

And yes. We know.Timer interrupts are turned off when there's nothing going on.

But the sending side - if it's not responding to an interrupt -
explicitly does have something going on, so you actually end up having
timer interrupts.

And yes, both IP and the TSC are "predictable". In theory. Not in
reality, and particularly not remotely.

And again, we knew - and discussed - interrupts coalescing and not
happening under load.

And again - that's a completely specious and pointless argument.

If you can put a machine under such load that it goes into polling
mode _and_ you also control _all_ the network traffic to such an
extent that other actors don't matter, and you get all the data out
and can analyze it to the point of trying to figure out what the prng
internal buffers are, you are basically already on the same network
and are controlling the machine.

It's not an interesting attack, in other words.

I repeat: reality matters. Your theoretical arguments are irrelevant,
because they simply don't even apply.

Btw, don't get me wrong - I think we can improve on the actual hashing
on the prng too. But I'm not backing down on the whole "we need noise
too, and the noise is actually more important".

> This whole bit of logic just seems ridiculously fragile to me.

No, what is fragile is assuming that you can have a random number
generator that is an analyzable secure hash, and then expecting that
to be high-performance and unpredictable.

We can do both. I'm _hoping_ people can come up with a
high-performance hash that is better than what we have. But there was
absolutely nothing going on for months after the last report, and even
with a better high-performance hash, I will absolutely refuse to get
rid of the noise factor.

           Linus