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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Aug 2020 09:31:48 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Willy Tarreau <w@....eu> Cc: George Spelvin <lkml@....org>, 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>, Florian Westphal <fw@...len.de> Subject: Re: [DRAFT PATCH] random32: make prandom_u32() output unpredictable On Mon, Aug 10, 2020 at 4:47 AM Willy Tarreau <w@....eu> 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. Linus
Powered by blists - more mailing lists