linux-kernel - Re: memchr() vs. memscan()

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

Message-ID: <f484c11b-a221-b096-7ae6-91de7490b8a0@rasmusvillemoes.dk>
Date:   Fri, 3 Feb 2023 08:18:24 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Andy Shevchenko <andriy.shevchenko@...el.com>,
        linux-kernel@...r.kernel.org
Cc:     Kees Cook <keescook@...omium.org>
Subject: Re: memchr() vs. memscan()

On 02/02/2023 16.34, Andy Shevchenko wrote:
> Why do we have memchr() and memscan() implementations in lib/string.c?
> As far as I can see the one may be derived from the other easily.

Well, memchr() is the C standard thing, and the one arches are more
likely to (and do) provide custom implementations of. memscan() seems to
be to memchr() as strchrnul() is to strchr(), and judging by the number
of callers, I don't think any optimizations or a separate C
implementation is really worth it. So yes, by all means we can replace
its entire body by

  return memchr(addr, c, size) ?: addr + size;

That's possibly even a win for the arches that do provide their own
memchr(), but again, performance of this one doesn't matter at all. But
the tiny kernel folks might appreciate this.

Rasmus