From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 17BD5384DDA4 for ; Tue, 13 Dec 2022 22:59:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 17BD5384DDA4 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x534.google.com with SMTP id c66so20060341edf.5 for ; Tue, 13 Dec 2022 14:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oGFz8Kzhplfv7NR9NVVKEN05nkjGelXuAdmJatByH8I=; b=GFxAPxoUq0aWv62n00Y5sfx29ppb79C4udHbMt/731RYUyUNfnLBMwBqtJJxymdPF3 BZwlJShAOwQtOVybuDbi6+hkm+pb08Cv1g6WzEHt2zD1JxVCr3ZPSfiQyuXQyKTvniAN ppiG6/T4TkV30Thrx9ZQy0tu6Mrt9HSxk/z/wdLNhSiXkdN6O8caKbI4rnJiAB0q9J6G BrvoSiypGlZC+Hovp1n+nSepRbnLdQGdH6q32P75tHfvg+bkoEoKkVm3qMQTIl2LTZDb 6e8xqrdHQ3jYCsrJl0ydcXjTKQACmd669ex0R76gBzGQkTdFYML1MIQqO4s8k9Adc/dS nsXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oGFz8Kzhplfv7NR9NVVKEN05nkjGelXuAdmJatByH8I=; b=nJlKbar0l/6IGYqEcG8T7NHXPUor17yL69RY/6HiyMF8LTOryR/+TtJmfu/Vt+FFlY rkqIZwgorZssQqaq6Vyu8zDn5pgNFTQclbDN2OpmNKEueONnO2loOkf5X2eOkvE8n9IK Ls52knk3wQ2RcFWzjNym0H+B/NmtsHiJ6abamfGd4Ec4Uk8KwcaCBo6bj7b0bh+AMSp+ 7ehCOjXhKUJ6Oc+4KA1sTXsUOCj+EpV+bjT79p3Vn1leevWpfThsiODaSycHO1fugVcm zlWlocwGwOSPq453oi9ZwMjui+JRcQVC6JYY1Ak0G+YujE+IquaRkdl398WGQhgHG5Kw 4MpQ== X-Gm-Message-State: ANoB5pkXzLSEU2jxZl049EaN2Oixsby075wFiRuUmB0PzToSOWxJ7yow dXXGfiF3gOFZYQlcKJJB0oVnEajrnaNxqMJgoFLyTVgOm8c= X-Google-Smtp-Source: AA0mqf6QBXZSBn7nCtYqhbR2ab4pRbMwcw8mBC+JOReJtkZAJTznGZuYZ0bi4nf4/Iz2skih7tUcKB4xhduewM6vXew= X-Received: by 2002:a05:6402:3711:b0:461:b6a9:c5cb with SMTP id ek17-20020a056402371100b00461b6a9c5cbmr72956431edb.148.1670972392769; Tue, 13 Dec 2022 14:59:52 -0800 (PST) MIME-Version: 1.0 References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> <871qp380hp.fsf@oldenburg.str.redhat.com> In-Reply-To: <871qp380hp.fsf@oldenburg.str.redhat.com> From: Noah Goldstein Date: Tue, 13 Dec 2022 14:59:32 -0800 Message-ID: Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change To: Florian Weimer Cc: Noah Goldstein via Libc-alpha , Narayanan Iyer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Dec 13, 2022 at 1:20 PM Florian Weimer wrote: > > * Noah Goldstein via Libc-alpha: > > > Is this something we have to support? I believe other functions / > > implementations of memcmp will suffer from a similar bug. > > Of course the crash is by no means deterministic, so I'm not sure how > useful it is to detect application bugs. Maybe papering over the > application bug is the right approach here. > > On the other hand, I really don't see how such a racing memcmp call > could deliver any useful information whatsoever. The result will always > be arbitrary in practice. So I hope such application bugs are really > rare. The usecase in the bugzilla is optimistic reads in concurrent databases. > > > 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 > > ``` > > How costly is this change? I would have thought about ANDing the offset > so that it is always in range (but maybe it will stil result in a page > crossing, I don't really know how this works). Its a bit expensive b.c it misaligned a lot of hot paths. A better fix (untested) is probably: ``` @@ -308,7 +308,7 @@ L(ret_nonzero_vec_end_0): setg %dl leal -1(%rdx, %rdx), %eax # else - addl %edx, %eax + addq %rdx, %rax movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rsi, %rax), %ecx movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rdi, %rax), %eax subl %ecx, %eax ``` The issue is the 32-bit negative number becomes a very large unsigned 64-bit number. If we just use 64-bit addition the issue goes away (I think at least). I'm okay with this change going in (assuming it works). This fix can be a "happy accident" that this unsupported usage no longer causes a sig-11, but I think it's a mistake to explicitly support this use case as anything other than UB. > > Thanks, > Florian >