From: Noah Goldstein <goldstein.w.n@gmail.com>
To: libc-coord@lists.openwall.com
Cc: GNU C Library <libc-alpha@sourceware.org>,
Richard Biener via Gcc <gcc@gcc.gnu.org>
Subject: Re: Add new ABI '__memcmpeq()' to libc
Date: Tue, 26 Oct 2021 17:47:16 -0500 [thread overview]
Message-ID: <CAFUsyfL1AG==bQ0JPkVFygu0Uw6yg23x_PW3aHUirA_=ADLVGw@mail.gmail.com> (raw)
In-Reply-To: <CAFUsyfJLcDuUhF+97u9DNMR8+u0WEHdVEtaDLLmG_6dLU-6DuA@mail.gmail.com>
On Thu, Sep 16, 2021 at 12:02 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>
> Hi All,
>
> This is a proposal for a new interface to be supported by libc.
>
> The new interface is the same as the old 'bcmp()' routine. Essentially
> the goal of this proposal is to add a reserved namespace for a new
> function, '__memcmpeq()', which shares the same behavior as the old
> 'bcmp()'.
>
> #### Interface ####
>
> int __memcmpeq(void const * s1, const void * s2, size_t n)
>
>
> #### Description ####
>
> The '__memcmpeq()' function would compare the two byte sequences 's1'
> and 's2', each of length 'n'. If the two byte sequences are equal, the
> return would be zero. Otherwise it would return some non-zero
> value. 'memcmp()' is a valid implementation of '__memcmpeq()'.
>
>
> #### Use Case ####
>
> 1. The goal is that '__memcmpeq()' will be usable as an optimization
> by compilers if a program uses the return value of 'memcmp()' as a
> boolean. For example:
>
>
> void foo(const void* s1, const void* s2, size_t n)
> {
> if (!memcmp(s1, s2, n)) {
> printf("memcmp can be optimized to __memcmpeq in this use case\n");
> }
> }
>
>
> - In the above case '__memcmpeq()' could be used instead. Due to the
> simpler constraints on the return value of '__memcmpeq()', it will
> be able to be implemented more optimally for this case than
> 'memcmp()'. If there is no separately optimized version of
> '__memcmpeq()' can alias 'memcmp()' and thus be at least equally as
> fast.
>
> 2. Possibly use cases in security as the runtime of the function will
> be *more* oblivious to the byte sequences being compared.
>
>
> #### Argument Specifications ####
>
> 1. 's1'
> - All 'n' bytes in the byte sequence starting at 's1' and ending
> at, but not including, 's1 + n' must be accessible memory. There
> are no guarantees about the order the sequence will be
> traversed.
> 2. 's2'
> - All 'n' bytes in the byte sequence starting at 's2' and ending
> at, but not including, 's2 + n' must be accessible memory. There
> are no guarantees about the order the sequence will be
> traversed.
> 3. 'n'
> - 'n' may be any value that does not violate the specifications on
> 's1' and 's2'.
>
> If any of the argument specifications are violated there are no
> guarantees about the behavior of the interface.
>
>
> #### Return Value Specification ####
>
> If the byte sequences starting at 's1' and 's2' are equals the
> function will return zero. Otherwise the function will return a
> non-zero value.
>
> Equality between the byte sequences starting at 's1' and 's2' is
> defined as follows:
>
> 1. If 'n' is zero the two sequences are zero.
> 2. If 'n' is non-zero then for all 'i' in range [0, n) the byte at
> offset 'i' of 's1' equals the byte at offset 'i' in 's2'.
>
> For a simple C implementation of '__memcmpeq()' could be as follows:
>
>
> int __memcmpeq(const void* s1, const void* s2, size_t n)
> {
> int ret;
> size_t i;
> const char *s1c, *s2c;
> s1c = (const char*)s1;
> s2c = (const char*)s2;
> for (i = 0, ret = 0; ret == 0 && i < n; ++i) {
> ret = s1c[i] - s2c[i]
> }
> return ret;
> }
>
>
> #### Notes ####
>
> This interface is essentially old 'bcmp()' and 'memcmp()' will always
> be a valid implementation of '__memcmpeq()'.
>
>
> #### ABI vs API ####
>
> This proposal is for '__memcmpeq()' as a new ABI. As an ABI
> '__memcmpeq()' will have value, as using the return value of
> 'memcmp()' is quite idiomatic in C code.
>
> It is, however, possible that this would also be useful as a new API
> as well. Especially if there are likely use cases where the compiler
> would be unable to prove that '__memcmpeq()' would be a valid
> replacement for 'memcmp()'.
>
>
> #### Further Options ####
>
> If this proposal is received positively, libc could also add
> interfaces for '__streq()', '__strneq()', '__wcseq()' and '__wcsneq()'
> which similarly would loosen return value restrictions on 'strcmp()',
> 'strncmp()', 'wcscmp()' and 'wcsncmp()' respectively.
>
> Best,
> Noah
ABI support for '__memcmpeq' have been pushed for GLIBC with:
commit 44829b3ddb64e99e37343a0f25b2c082387d31a5
prev parent reply other threads:[~2021-10-26 22:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-16 17:02 Noah Goldstein
2021-09-16 17:55 ` [libc-coord] " Chris Kennelly
2021-09-16 18:31 ` Noah Goldstein
2021-09-16 20:32 ` Chris Kennelly
2021-09-16 20:35 ` Joseph Myers
2021-09-16 20:55 ` enh
2021-09-17 7:43 ` Richard Biener
2021-09-17 8:08 ` Florian Weimer
2021-09-17 8:31 ` Richard Biener
2021-09-17 8:37 ` Florian Weimer
2021-09-17 9:30 ` Richard Biener
2021-09-17 17:40 ` Noah Goldstein
2021-09-17 9:12 ` Jakub Jelinek
2021-09-17 16:55 ` Martin Sebor
2021-09-17 14:19 ` Joseph Myers
2021-09-17 14:26 ` Florian Weimer
2021-09-21 19:53 ` Noah Goldstein
2021-09-22 17:46 ` Christoph Müllner
2021-09-22 18:15 ` Noah Goldstein
2021-09-16 21:27 ` James Y Knight
2021-09-16 21:42 ` Joseph Myers
2021-09-16 21:50 ` enh
2021-09-16 21:59 ` Noah Goldstein
2021-09-16 22:17 ` Chris Kennelly
2021-09-16 22:36 ` Joseph Myers
2021-09-16 23:24 ` Noah Goldstein
2021-09-18 1:36 ` James Y Knight
2021-10-26 22:47 ` Noah Goldstein [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFUsyfL1AG==bQ0JPkVFygu0Uw6yg23x_PW3aHUirA_=ADLVGw@mail.gmail.com' \
--to=goldstein.w.n@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-coord@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).