From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id BCC9D3838CE5 for ; Tue, 13 Dec 2022 21:20:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BCC9D3838CE5 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670966409; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EB6mrfR88Ujhex0EgRssX8fMdF8lajyR92wNP5Bq10I=; b=Pg6PZx0fg4ksLV5hVWSWOH1bFU2sCKiSI975XUOsCeUxqy2TY/qG11L0Pz9elbZnGLXNhs PFwIs9YDkPYDrqyiA9/ZE+DY//qE7QIDpjv8wuTz5D5379uEsbhhqijSXeH3GP1fHqPMlZ 20ouPBX5LqksbTFnUaNhnfBk1x95Qzk= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-424-WgdM-25XMUW0AbWDrwR_Uw-1; Tue, 13 Dec 2022 16:20:07 -0500 X-MC-Unique: WgdM-25XMUW0AbWDrwR_Uw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 559112A2AD44; Tue, 13 Dec 2022 21:20:07 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.63]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4DF9A492C14; Tue, 13 Dec 2022 21:20:06 +0000 (UTC) From: Florian Weimer To: Noah Goldstein via Libc-alpha Cc: Narayanan Iyer , Noah Goldstein Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change References: <0a1f01d90f1f$96c7ce60$c4576b20$@yottadb.com> Date: Tue, 13 Dec 2022 22:20:02 +0100 In-Reply-To: (Noah Goldstein via Libc-alpha's message of "Tue, 13 Dec 2022 11:08:09 -0800") Message-ID: <871qp380hp.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: * 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 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). Thanks, Florian