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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 0C36F2D2B2 for ; Sat, 31 Aug 2024 17:10:38 +0200 (CEST) Received: (qmail 5365 invoked by uid 550); 31 Aug 2024 15:10:34 -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 5324 invoked from network); 31 Aug 2024 15:10:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725117025; x=1725721825; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V2d3mA2+uVAqPemFiOJXwGzLufJDht758g4ucyWTe6M=; b=Q0Zi1fpvDWWQ2ljIQ0I6HSQFdqf0d1Ql1GAoW7OArJQgLaOD+5ysPeQ7MiUQQilEA6 8UqNsPsfZNdo31eydcrp19/wJUuxKfLbaCfIuocS4bwi0bq7k6MdyA0hcjFvHvUYyLiO vHKHuw26j8hgxcrOGoWHuJOo5dcMWsd7IEt9cABxiAEkc2e0A7r+46CJb0ruUh74GoHH yHmPaO86RDYZ3qZAjruD8YALSvIBBPBIEv+5cTk999iLWnFdrNRL/73tshD4Ig2jHzgq 5rFQIObLCXIlFlig5ljCB0iZnKxVNmq8EsVWpcCiw0cM2Ln13TXnJOZ+W5pY2MWrGCJz 74sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725117025; x=1725721825; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V2d3mA2+uVAqPemFiOJXwGzLufJDht758g4ucyWTe6M=; b=RpTuXKyDvvk6hEYZaZZuCO3qz+NJljzr+CbuSK9L+NKotz7YEcjCDaHt+ujtR2dRuT CMqpY+KgtGa6OnOoC4r4bDARiuRIfZCoe0HCgk4GdbAKTwsgtLngBhYLjvSbOb+id8Xz ZjXg/iUj3kIuW1+MyOUARODwbNzjRZy3UEHgUBqBEDA2CsL1liDkMoKOX2yyCKR7hFuj Tu1ITJutIRcN69AerbUnjL+/IDtlIWOaliWMzzrTXLpkYRz9O0l95n7Lo8TYZlKugGBD 5FX9X4+AVCeiCrTNtTTp0bSKXJuD/3ysGX4CnVXNDTMO4d/e1qKljX0O9s6+zSubdJ8o NioA== X-Forwarded-Encrypted: i=1; AJvYcCWPnkUHzY60yBndeB7WXPeBmj6I+fSedzXcWIKtyjuzvd+U3WauXNxHkzuk45PvktmUxLAs@lists.openwall.com X-Gm-Message-State: AOJu0Yy1fVKlIHooIvS4CqpFnU3X3IAsK+Wqn5irarZOiWrMZQWgf2cU Jv5DJfVc412txV8OzxvTkcLg0TviZ7ecD+HPv6hUaWj+LNGidKluXJb3wfE+FnbQ6kr3TUmEo79 DUo/ln+BJEX8bKEXlQcadk6aGQ0I= X-Google-Smtp-Source: AGHT+IGQlv+0vjwX+PYoG1jtD9Jt03NaGommlMhRMYySvt0ALK33izI0Urab5jUPxMcGsBt4+YKYtgebhxqm/ibIJxY= X-Received: by 2002:a05:690c:ec1:b0:697:7cc0:ce1 with SMTP id 00721157ae682-6d40d78d826mr70278427b3.7.1725117025416; Sat, 31 Aug 2024 08:10:25 -0700 (PDT) MIME-Version: 1.0 References: <20240829205436.GA14562@brightrain.aerifal.cx> <20240831092902.GA2724612@port70.net> <20240831150241.GP10433@brightrain.aerifal.cx> In-Reply-To: <20240831150241.GP10433@brightrain.aerifal.cx> From: "H.J. Lu" Date: Sat, 31 Aug 2024 08:09:49 -0700 Message-ID: To: Rich Felker Cc: Linux Kernel Mailing List , linux-api@vger.kernel.org, libc-alpha@sourceware.org, musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] AT_MINSIGSTKSZ mismatched interpretation kernel vs libc On Sat, Aug 31, 2024 at 8:03=E2=80=AFAM Rich Felker wrote= : > > On Sat, Aug 31, 2024 at 11:29:02AM +0200, Szabolcs Nagy wrote: > > * Rich Felker [2024-08-29 16:54:38 -0400]: > > > As I understand it, the AT_MINSIGSTKSZ auxv value is supposed to be a > > > suitable runtime value for MINSIGSTKSZ (sysconf(_SC_MINSIGSTKSZ)), > > > such that it's safe to pass as a size to sigaltstack. However, this i= s > > > not how the kernel actually implements it. At least on x86 and > > > powerpc, the kernel fills it via get_sigframe_size, which computes th= e > > > size of the sigcontext/siginfo/etc to be pushed and uses that > > > directly, without allowing any space for actual execution, and withou= t > > > ensuring the value is at least as large as the legacy constant > > > MINSIGSTKSZ. This leads to two problems: > > > > > > 1. If userspace uses the value without clamping it not-below > > > MINSIGSTKSZ, sigaltstack will fail with ENOMEM. > > > > > > 2. If the kernel needs more space than MINSIGSTKSZ just for the signa= l > > > frame structures, userspace that trusts AT_MINSIGSTKSZ will only > > > allocate enough for the frame, and the program will immediately > > > crash/stack-overflow once execution passes to userspace. > > > > > > Since existing kernels in the wild can't be fixed, and since it looks > > > like the problem is just that the kernel chose a poor definition of > > > AT_MINSIGSTKSZ, I think userspace (glibc, musl, etc.) need to work > > > around the problem, adding a per-arch correction term to > > > AT_MINSIGSTKSZ that's basically equal to: > > > > > > legacy_MINSIGSTKSZ - AT_MINSIGSTKSZ as returned on legacy hw > > > > > > such that adding the correction term would reproduce the expected > > > value MINSIGSTKSZ. > > > > > > The only question is whether the kernel will commit to keeping this > > > behavior, or whether it would be "fixed" to include all the needed > > > working space when they eventually decide they want bigger stacks for > > > some new register file bloat. I think keeping the current behavior, s= o > > > we can just add a fixed offset, is probably the best thing to do. > > > > i think it makes sense that the kernel sets AT_MINSIGSTKSZ > > according to what the kernel needs (signal frame size) > > anything beyond that is up to userspace requirements (e.g. > > the kernel cannot know if the libc wraps signal handlers) > > > > it's up to the libc to adjust sysconf(_SC_MINSIGSTKSZ) > > according to posix or backward compat requirements. > > I think this is a reasonable viea and means the aux key was just very > poorly named. It should have been called something like > AT_SIGFRAMESIZE to indicate to the userspace-side consumer that it's > not a suitable value for MINSIGSTKSZ, only a contributing term for it. > > Rich glibc manual has =E2=80=98_SC_MINSIGSTKSZ=E2=80=99 Inquire about the minimum number of bytes of free stack space required in order to guarantee successful, non-nested handling of a single signal whose handler is an empty function. =E2=80=98MINSIGSTKSZ=E2=80=99 This is the amount of signal stack space the operating system needs just to implement signal delivery. The size of a signal stack *must* be greater than this. For most cases, just using =E2=80=98SIGSTKSZ=E2=80=99 for = =E2=80=98ss_size=E2=80=99 is sufficient. But if you know how much stack space your program's signal handlers will need, you may want to use a different size. In this case, you should allocate =E2=80=98MINSIGSTKSZ=E2=80=99 additional bytes for the signa= l stack and increase =E2=80=98ss_size=E2=80=99 accordingly. --=20 H.J.