Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

[Noah Goldstein <goldstein.w.n@gmail.com>]

On Tue, Dec 13, 2022 at 11:13 AM Narayanan Iyer <nars@yottadb.com> wrote:
>
> Noah,
>
> Thank you for acknowledging that it is a bug.
I'm not sure this is a bug, I'm just saying to avoid this behavior you can
make that change.

I think we all agree supporting a correct non-atomic memcmp when the values
in memory can change during execution is not reasonable.
I think SIG11 is not a great outcome (of the many possible behaviors when its
incorrect), but am not sure it's worth fixing.

>
> In case it helps, I found in our testing cluster, that a system which uses sysdeps/x86_64/multiarch/memcmp-sse2.S has the bug whereas a system that uses sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S does not have the bug.
I wouldn't count on any of the other implementations being hardened to this.


>
> So it is possible, the issue is only in the sse2 version.

I did a quick check of avx2/evex and don't see the same pattern but I think
it might be present in the tail of the loops (end of much larger copies so
probably comes up less).

>
> Thanks,
> Narayanan.
>
> -----Original Message-----
> From: Noah Goldstein [mailto:goldstein.w.n@gmail.com]
> Sent: Tuesday, December 13, 2022 2:08 PM
> To: Narayanan Iyer <nars@yottadb.com>
> Cc: libc-alpha@sourceware.org
> Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
>
> On Tue, Dec 13, 2022 at 10:20 AM Narayanan Iyer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > Hi,
> >
> > I had created a glibc bug report at https://sourceware.org/bugzilla/show_bug.cgi?id=29863
> >
> > And have included the title of that report in the email subject as well.
> >
> > It has been a week since I created the issue and I did not hear anything back. I believe this is a regression in glibc 2.36 and have provided enough information in the bug report (along with the commit that caused the regression).
> >
> > Given the upcoming glibc 2.37 release, I was asked (by Carlos O'Donell <carlos@redhat.com>) to raise it on this mailing list to get the attention of the glibc developers.
> >
> > I am hoping one of you could take a quick look at the bug report and see if it is worth fixing it in time for glibc 2.37.
> >
> > Thanks,
> > Narayanan.
> >
> >
>
> The fix:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memcmp-sse2.S;h=afd450d0206d6633da9fbc4607a7fa6aeb4e137c;hb=HEAD#l46
> ```
> -#   define SIZE_OFFSET (CHAR_PER_VEC * 2)
> +#   define SIZE_OFFSET 0
> ```
>
> Is this something we have to support? I believe other functions /
> implementations
> of memcmp will suffer from a similar bug.
>