From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 7A37F2E72C for ; Mon, 2 Sep 2024 14:08:00 +0200 (CEST) Received: (qmail 17836 invoked by uid 550); 2 Sep 2024 12:07:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17814 invoked from network); 2 Sep 2024 12:07:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725278867; 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=pjOW0E49Yqw0mfiCURQMWGxKRTpi1ev/eO7YHhvgkrY=; b=Yfn1ma/8pg1EuA5LQh/NH1vnz3PILTzhhpKTz9kPgPrDqNEuQEwDWuTHZD0FLeP6Zx/zD2 IA6g6ECfJTNtDAQgiiF+/0RIicdKvVlJUip/cB2KiMrQ8xE8hFo/Md7hTLB+T5k7SUlrsh h32y+cK2/RGjAYZtPgl1Q/Ezw5rJqC0= X-MC-Unique: CfVNYkG0OgOLqsUrGaZQyA-1 From: Florian Weimer To: Rich Felker Cc: "H.J. Lu" , Linux Kernel Mailing List , linux-api@vger.kernel.org, libc-alpha@sourceware.org, musl@lists.openwall.com In-Reply-To: <20240831154101.GN32249@brightrain.aerifal.cx> (Rich Felker's message of "Sat, 31 Aug 2024 11:41:02 -0400") References: <20240829205436.GA14562@brightrain.aerifal.cx> <20240831092902.GA2724612@port70.net> <20240831150241.GP10433@brightrain.aerifal.cx> <20240831154101.GN32249@brightrain.aerifal.cx> Date: Mon, 02 Sep 2024 14:07:36 +0200 Message-ID: <87v7zetg1j.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 Subject: Re: [musl] AT_MINSIGSTKSZ mismatched interpretation kernel vs libc * Rich Felker: > This is ambiguously worded (does "operating system" mean kernel?) and > does not agree with POSIX, which defines it as: > > Minimum stack size for a signal handler. > > And otherwise just specifies that sigaltstack shall fail if given a > smaller size. > > The POSIX definition is also underspecified but it's clear that it > should be possible to execute at least a do-nothing signal handler > (like one which immediately returns and whose sole purpose is to > induce EINTR when intalled without SA_RESTART), or even a minimal one > that does something like storing to a global variable, with such a > small stack. Allowing a size where even a do-nothing signal handler > results in a memory-clobbering overflow or access fault seems > non-conforming to me. POSIX does not specify what happens on a stack overflow (or more generally, if most resource limits are exceeded), so I think the behavior is conforming on a technicality. Thanks, Florian