linux-kernel - X86-64 uses generic string functions (strlen, strchr, memcmp, ...)

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

Message-ID: <CAG48ez30qnKuWHkzkkxxEhBPjVVnsgA1wSarfvx=U=Jb0maO0Q@mail.gmail.com>
Date:   Wed, 3 Oct 2018 17:10:26 +0200
From:   Jann Horn <jannh@...gle.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     kernel list <linux-kernel@...r.kernel.org>
Subject: X86-64 uses generic string functions (strlen, strchr, memcmp, ...)

Hi!

I noticed that X86-64 is using the generic string functions from
lib/string.c for things like strlen(), strchr(), memcmp() and so on.
Is that an intentional omission, because they're not considered worth
optimizing, or is this an oversight? The kernel doesn't use string
functions much, but if you e.g. run readlinkat() in a loop on a
symlink with a 1000-byte target, something around 25%-50% of time are
spent on strlen(). But that's a microbenchmark that people probably
don't care about a lot?

One notable in-kernel user of memcmp() is BPF, which uses it for its
hash table implementations when walking the linked list of a hash
bucket. But I don't know whether anyone uses BPF hash tables with keys
that are sufficiently large to make this noticeable?