From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A090F1F601 for ; Mon, 5 Dec 2022 18:54:12 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="vZFuUiNT"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A365D3947C2F for ; Mon, 5 Dec 2022 18:54:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A365D3947C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1670266450; bh=ZeJkHbi0l/FOgH0H8OF0gENi/Tczeqp9U11WBRNsbvU=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=vZFuUiNTjGrSqWT0mryt6/jlpoX+Wy5ffU9ulJbYNNcihxdRtlX+hRyydvn7xAxjP JMy7O0EaKrab3UG6t35nqC28kN0/y9RJR5YrtP9GiyUazrKLJaXpXunMEPiDPUl/+j KvUjr/vNz/9lD6ZrJjmE+0qtnqT96DSK0DeKj+gE= Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by sourceware.org (Postfix) with ESMTPS id EA0DD3947C29 for ; Mon, 5 Dec 2022 18:53:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA0DD3947C29 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 722293200913 for ; Mon, 5 Dec 2022 13:53:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 05 Dec 2022 13:53:49 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeggdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtje ertddtfeejnecuhfhrohhmpegkrggtkhcuhggvihhnsggvrhhguceoiigrtghksehofihl fhholhhiohdrohhrgheqnecuggftrfgrthhtvghrnhepgedvueegveefudfhvdffudejhf fgleektdduvdeffedvueeuhfduiefgtdevjeefnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 5 Dec 2022 13:53:48 -0500 (EST) Message-ID: Date: Mon, 5 Dec 2022 13:53:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: bind(2): Missing [[gnu::nonnull]] Content-Language: en-US To: libc-alpha@sourceware.org References: <8292ef824696e0fbac4f4ed036aad43c0458b8a2.camel@xry111.site> <87wn78cnpe.fsf@igel.home> <4e085ada-10eb-9de9-7681-1c96ec74da30@gmail.com> <87y1rnf1mw.fsf@oldenburg.str.redhat.com> In-Reply-To: <87y1rnf1mw.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Zack Weinberg via Libc-alpha Reply-To: Zack Weinberg Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 2022-12-04 1:46 PM, Florian Weimer via Libc-alpha wrote: > * Alejandro Colomar via Libc-alpha: >> On 12/4/22 06:59, Xi Ruoyao wrote: >>> On Sat, 2022-12-03 at 20:05 +0100, Andreas Schwab wrote: >>>>> Currently the man page says: >>>> >>>> You can never depend on EFAULT for invalid addresses. >>> Hmm, is this documented somewhere? >> >> I don't know, but let me have an educated guess: >> >> Holding a pointer to invalid memory is Undefined Behavior by the >> standard, except if that pointer is NULL, or is still indeterminate >> because the pointer has not yet been initialized with a valid address. >> Using an uninitialized pointer is UB as using any uninitialized >> variable. Using a NULL pointer is only okay for comparisons, or as a >> sentinel value, but never for accessing memory. So chances are high >> that the program will already have invoked UB at the time bind(2) is >> called with an invalid address. > > Currently, Linux does not report for vDSO-accelerated system calls, but > generates SIGSEGV. We received bug reports when we added vDSO support > for time/gettimeofday/clock_gettime because some tests were relying on > the EFAULT behavior. I don't have time to dig through POSIX and find it now, but I'm like 95% sure there's explicit wording to the effect that the OS is allowed to send SIGSEGV under any circumstance that's documented to result in an EFAULT error, and vice versa. That should be good enough for the _manpages_, but I think the _headers_ probably need to be more cautious about adding annotations that can cause compilers to draw new inferences about which control flow paths are unreachable. I imagine this would be a hard sell with the "never break userspace" crowd but I would _like_ Linux to at least have a mode in which it would always send SIGSEGV rather than producing EFAULT. It seems like it would be helpful for debugging. zw