From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id 5C9AD3858413 for ; Mon, 20 Mar 2023 15:41:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5C9AD3858413 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 compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6F0E95C006A; Mon, 20 Mar 2023 11:40:59 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Mon, 20 Mar 2023 11:40:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-type: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=1679326859; x=1679413259; bh=45 Ry39U7B6EettRcOLlP3z06gsv4AkQkwNGpsIOmaTs=; b=tQc/IwPQq4WtLoHo44 Bm92Bv/y6qd0fc81mcYdW8WWymq0W4hR1CEM2l0t34uVYHzOayseb51HOLGoVBie 9hGaqETul/O89J67NWYHFdVbCFs0UAQFNH+TUzu7+ypEntYweoqqG5cRJIsrJiBk +5WijF/fopmZiy4V6RAQ4gPyTZq/OA4zCX9GIqdGiqYzP2n6vDFPLTwxOUAQu5TH 3RvJUFfY8CCDtb4Oqw1IO3GU32/TQa80wFEiIaTwnduAFv9a+LgFNqIKLJL9EO73 SqLM5KyDAsrrroUHCAQE8rsDHMUF9Ep4FPU79PefQ4FhcDuzBDm8V1ktnjbZlSZ8 W6bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type: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=1679326859; x=1679413259; bh=45Ry39U7B6Eet tRcOLlP3z06gsv4AkQkwNGpsIOmaTs=; b=MCfqcBe6CWzwa11n9bxw8OZKh5llX 7/TSAbC7ML+LubifDX/ufHDs9CQgyVnMzpKJ6Dqsgkon3WLkeRBT5cfa2bmyocBg yUWCFjMFqD5dNBt3zTFw9pmJxN8O78AA7agw+tOgBbOi1sURyc3bPUvpAb7rQhP9 sbMchnNna3W7mU2qqlkxi5pv5U6QC137whI55yNV+GGau9q+Jln2Agdr99ShbOja TG6avL/YKrf+fRaocNCTl3mU/TtlepXg/u1LmGCtkogk700U9VqSimcdwLCZ2DqJ 2ZvJajhQ8EmFAi8A36Rwri3ASjO1LT5OjHjGhQKqqdQE8vWnxXMJNm3qg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdefkedgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhephfelfeehudfhleegheegjeevheeuieehvdfgueeuteetleeiieet heefhfeludeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 992E4272007A; Mon, 20 Mar 2023 11:40:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-221-gec32977366-fm-20230306.001-gec329773 Mime-Version: 1.0 Message-Id: <6d87500b-d0ed-46f4-a6b8-5f3cc1d0a64d@app.fastmail.com> In-Reply-To: <4b1f7f41-535-8947-80c1-662768db9235@codesourcery.com> References: <2a6f6912-592a-b82b-0efb-ea985dea2548@gmail.com> <4b1f7f41-535-8947-80c1-662768db9235@codesourcery.com> Date: Mon, 20 Mar 2023 11:40:36 -0400 From: "Zack Weinberg" To: "Joseph Myers" , "'Alejandro Colomar (man-pages)'" Cc: "Wilco Dijkstra" , "Carlos O'Donell" , "GNU libc development" Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change Content-Type: text/plain X-Spam-Status: No, score=-3.0 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_H3,RCVD_IN_MSPIKE_WL,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 Fri, Dec 30, 2022, at 1:02 PM, Joseph Myers wrote: > I also think it should be OK for strcmp to SEGV if a NUL terminator > byte in either string at the time strlen is called, or at any time > during its execution, ceases at any point during the execution of > strlen to be a NUL byte (even if there is an earlier or later NUL > already present at the time the terminator byte is changed). (There > is a reasonable case for avoiding a SEGV when the contents of the > strings change during execution, as long as any byte that is the NUL > terminator byte at any point during execution of the call never ceases > to be a NUL byte during execution of that call - an earlier NUL might > be added, however.) Coming back to this ages later, I'm not sure how this differs from what I said about the oracle for strlen... Imagine we have a hardware debugger that can freeze execution of the entire computer at the moment the call instruction for strcmp is invoked, perform strlen() on both strings passed to strcmp, and then resume execution. Call the string lengths measured by this hypothetical debugger the "original" string lengths. What I was trying to communicate is that any concurrent modification to the strings that *changes either string's length from its original* should still permit constrained-unpredictable behavior by the implementation of strcmp. It seems to me that this is the same as talking about insertion or deletion of NULs within the bounds of the original string lengths. zw