From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by sourceware.org (Postfix) with ESMTPS id 06E9F3858D20 for ; Thu, 29 Dec 2022 07:23:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 06E9F3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CDED95C02C2; Thu, 29 Dec 2022 02:23:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 29 Dec 2022 02:23:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1672298626; x=1672385026; bh=PTfZvb+fzT pdsx8mhZ7uGTQY84+JUn3jTBrh/ZQujmo=; b=4WJkh5csB/NJnlhHPDsREhBiCt vhSzI7Wmtan1GW6FNBnpM0OotHp6RwINgbR+to43j0nSfanHXMjxyuVEUmgtCFMg rm87qZitu5UlZamUYrJr1PnIM4U59t0F6YQUw8mpzgoGKIjNmrcLh+qgB7tIZhCq 2nDPzWoc8U0QIAxWZFkKW6tnx1U4xoIGxim2SHgy2ET1/0cGK4i+2WzDdPe7JDv2 miDrN2wfOqMBpzwioGaAVSekAibU85fSmajvTOrhEU8VVr1sKHdT88u9CtJTIiHj FCjuWga/vyXD+hXOFRWsfvO4g5wwAPpRYPmkZWYHvnAVSu+a+e9GGW21P9AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672298626; x=1672385026; bh=PTfZvb+fzTpdsx8mhZ7uGTQY84+J Un3jTBrh/ZQujmo=; b=mjhNCk+jCwMBCY+zWO1KbYZskLB8Tz2grfHd9rq38F58 8geEeOIM1BGfo0loy7CPWx6pjQAEPkAj+i1D0Yz2okb9uL5CPP+ZKcLI/OQqZ6d7 Xm6hQwqT9ZBXwUYREz0MhGVKXrHIl/WUsdYVgMHABdtFaDpO3oqkKISFtbkKV820 1l3a03yobuhvt0Sw7FS9ByqWwyLtrOpTnLiNwKYFCpmheHnILprLsMcHs5IJRjCW Ozj03UiwMEkOkVOhR/5tC2DEPf97sfLcG8PKab6sJzcprfHx6kIRIjIuObJ4JDPX sxba4cwXTUiyUoTiv5BF9bEZXStHYtpYXvaf16jNTA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrieefgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffkhffvvefujghffgggtgesthdtredttdergfenucfhrhhomhepkggrtghk ucghvghinhgsvghrghcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtffrrg htthgvrhhnpedufeelfefgkeejudegudegkedvgfdtledtteeltdfgffehvddufeetjeej uefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe iirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Dec 2022 02:23:45 -0500 (EST) Date: Thu, 29 Dec 2022 02:21:45 -0500 Message-ID: From: Zack Weinberg To: Wilco Dijkstra Cc: Carlos O'Donell , 'GNU C Library' Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 Wed, 14 Dec 2022 16:56:28 -0500, Wilco Dijkstra wrote: > I'd expect that mem* functions will never read outside their bounds > since the bounds are explicitly defined by the arguments, not by the > data. So that should be easy to guarantee. I concur. > For the str* functions it may be harder since the data itself > defines when to stop reading. So if an implementation uses multiple > accesses to the same address, you could potentially mistake the end > of a string (eg. first one detects a special case, while the 2nd > then verifies it). I also concur here. > Still, I wouldn't expect totally random memory accesses even in this > case - you would read beyond the end of a string if the string end > is changed concurrently. We may run into a problem where it’s difficult to _state_ the limits of the misbehavior, just because the C standard doesn’t itself try to put limits on misbehavior in the face of an incorrect program, so we don’t have any language for it (which I would argue is a bug in the standard, see the detailed reply to Carlos that I’ll be writing, er, tomorrow). Still, taking strcmp(a, b) for example, and assuming WLOG a flat address space in which a < b, it should be possible to guarantee - no accesses to any byte in the range [0, a) ever - if an oracle for strlen(), capable of executing in zero cycles, would return the same value for strlen(a) throughout the execution of strcmp(), then no accesses to any byte in the range [a+strlen(a), b) - if an oracle for strlen(), capable of executing in zero cycles, would return the same value for strlen(b) throughout the execution of strcmp(), then no accesses to any byte in the range [b+strlen(b), ADDR_MAX) - however, if the oracle strlen() values _do_ change during the execution of strcmp(), then accesses to bytes in the latter two ranges are possible - a SIGSEGV is permissible if and only if there was at least one point during execution at which a call to the oracle strlen() would have triggered a SIGSEGV Ne? > Finally it's worth mentioning that nscd does the exact same thing: > it uses memcmp and non-atomic accesses on shared data that is being > modified by other threads. It looks totally broken, especially with > weaker memory ordering, however this kind of insanity may actually > be a common design pattern... I don’t want to hold up nscd as an example of quality design or implementation, but yeah, I share your concern re “may actually be a common design pattern”… zw