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:   Sat, 22 Aug 2020 12:20:17 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Nick Desaulniers' <>,
        Linus Torvalds <>,
        Arvind Sankar <>,
        Masahiro Yamada <>
CC:     Rasmus Villemoes <>,
        Dávid Bolvanský <>,
        "Eli Friedman" <>,
        "H. Peter Anvin" <>,
        "Andrew Morton" <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        Michal Marek <>,
        Linux Kbuild mailing list <>,
        LKML <>,
        "Kees Cook" <>,
        Tony Luck <>,
        Dmitry Vyukov <>,
        Michael Ellerman <>,
        Joe Perches <>,
        Joel Fernandes <>,
        Daniel Axtens <>,
        Andy Shevchenko <>,
        Alexandru Ardelean <>,
        Yury Norov <>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <>,
        Ard Biesheuvel <>,
        "Paul E . McKenney" <>,
        Daniel Kiper <>,
        Bruce Ashfield <>,
        Marco Elver <>,
        "Vamshi K Sthambamkadi" <>
Subject: RE: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

> For more context for folks at home eating popcorn and enjoying the
> show:
> And that was specifically with KASAN enabled and doesn't appear to be
> common behavior in clang otherwise (higher threshold). Why the
> heuristics change for when it seems to be more profitable to roll
> assignment of contiguous members of the same struct to the same value
> into a memset, and 2 longs seems to be the threshold for KASAN, I
> don't know.  But I agree that should be fixed on the compiler side,
> which is why I haven't been pushing the kernel workaround.

Given x86 has is a simple 3-instruction loop for memset
that will do 1 write/clock (the max on current cpu) I
doubt it is ever worth not inlining memset().
The only real special case is lengths < 8.

For KASAN I wonder if something is stopping it inlining memset()?
So what usually happens is the two stores get converted to memset()
and then the memset() gets inlined back to two stores?

OTOH all this faffing for memset and memcpy is probably a
waste of time.


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

Powered by blists - more mailing lists