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  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:   Mon, 10 Aug 2020 09:31:48 -0700
From:   Linus Torvalds <>
To:     Willy Tarreau <>
Cc:     George Spelvin <>, Netdev <>,
        Amit Klein <>,
        Eric Dumazet <>,
        "Jason A. Donenfeld" <>,
        Andrew Lutomirski <>,
        Kees Cook <>,
        Thomas Gleixner <>,
        Peter Zijlstra <>,
        "Theodore Ts'o" <>,
        Marc Plumb <>,
        Stephen Hemminger <>,
        Florian Westphal <>
Subject: Re: [DRAFT PATCH] random32: make prandom_u32() output unpredictable

On Mon, Aug 10, 2020 at 4:47 AM Willy Tarreau <> wrote:
> Doing testing on real hardware showed that retrieving the TSC on every
> call had a non negligible cost, causing a loss of 2.5% on the accept()
> rate and 4% on packet rate when using iptables -m statistics.

And by "real hardware" I assume you mean x86, with a fairly fast and
high-performance TSC for get_random_entropy().

Reading the TSC takes on the order of 20-50 cycles, iirc.

But it can actually be *much* more expensive. On non-x86, it can be an
IO cycle to external chips.

And on older hardware VM's in x86, it can be a vm exit etc, so
thousands of cycles. I hope nobody uses those VM's any more, but it
would be a reasonable test-case for some non-x86 implementations, so..

IOW, no. You guys are - once again - ignoring reality.


Powered by blists - more mailing lists