linux-kernel - RE: x86: should clear_user() have alternatives?

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:   Tue, 8 Feb 2022 23:36:25 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Borislav Petkov' <bp@...en8.de>, Hugh Dickins <hughd@...gle.com>
CC:     Peter Zijlstra <peterz@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: RE: x86: should clear_user() have alternatives?

From: Borislav Petkov
> Sent: 08 February 2022 12:53
> 
> On Mon, Feb 07, 2022 at 09:45:36PM -0800, Hugh Dickins wrote:
> > I realize that dd'ing from /dev/zero to /dev/null, and sparse files on
> > tmpfs, are not prime candidates for optimization; and I've no idea how
> > much clear_user() normally gets used for long clears.
> 
> Right, we usually don't take such "optimizations" because the folks who
> send them always come up with either microbenchmarks or only test on a
> single machine.

I think it is reasonable to use microbenchmarks to see how fast
a particular loop runs on a specific cpu - since you can work out
the number of clocks per iteration and directly compare different
versions.

The problem with microbenchmarks is when they get used on unrolled loops.
Run something 10000 times with hot-cache data and unrolled loops
almost always seem best.
Cold cache or the effects of displacing other code from the I-cache
can make loop unrolling a big loss.
Especially on current cpu that execute multiple instructions/clock
and out-of-order execution.

Loops only need unrolling just enough to hit some architectural limit.
For memset() (using normal instructions) that is 1 write per clock.

A classic example has to be the sparc divide remainder function
in the original CY7C600 book (which I happen to still have).
I'm not sure how many instructions it is - but it is printed
on 4 pages. It just has to blow anything else out of the
small I-cache those cpu had.
It might be faster - but only if you are doing a lot of divides.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)