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.8 required=5.0 tests=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 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 B8FFF201A4 for ; Thu, 30 May 2024 13:51:59 +0200 (CEST) Received: (qmail 26355 invoked by uid 550); 30 May 2024 11:51:51 -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 26318 invoked from network); 30 May 2024 11:51:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1717069902; x=1717674702; i=nullplan@gmx.net; bh=Zo7w0cVhvRpNirXB9mStk0eqp9zFAUdcpMGay7E13DM=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=YF2ZTFNB3PwbpW+bb0nQOHpvQhKCWLfechPsNC9CpqZ1+OMNZ9Wu7mVxICuMJT+Q Pa8xM32eRFwx+EQEEZkCo8CJNjJI8ZX+/IRVozqZb+01AOuMVyeKpVIK5gJ6ut9e3 Dr1zUNWKQVBzJpn+pBkXZW4r42Ig67BZnPnxQnGFnU2KR1fvvf2+Mm3wI34H6lgCU EgizTDWiPmWNB4OQP2ZgqLmtXy6h+g7X8gS4DG5rY4488AMc1eE2I5V6H2dlnLQjV EvvlnNwwdsFY69sVdLpCtSOETEQDgW8SU3OBodC7UXkEGmKIb/curwjCGbR/A5AkE REQCXMmsh7UF8zKZHA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 30 May 2024 13:51:40 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Pablo Correa Gomez Message-ID: References: <20240529131533.GH10433@brightrain.aerifal.cx> <3201c36ee287e6d38e0f3805440a507de8fb52bf.camel@postmarketos.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3201c36ee287e6d38e0f3805440a507de8fb52bf.camel@postmarketos.org> X-Provags-ID: V03:K1:aUaqcH7pXyakINSgOeePLs3jXRDdi7ZBhajRyghgqdt2nwkVRcg /tVq/mktMe7A2XFztWUyYs0WiE0QX4rLBSN7ZrJBA4JpshipqoEnUaaeKiRng0eBZ0ONz/K 4TIJcnSaDYzOX2P4VBD88bmx8xet2DcUqykVPzWbYtReE7fiVTJpTwsPPBmU8G8EfKHi37h 1CHJeisAeLTlS37Jz23oA== UI-OutboundReport: notjunk:1;M01:P0:jkdaCugNY8g=;RhRjQ/b2kmBhp+MHS5RsTKfdr4h zmkHHLCnD6K4nu6Scu9//HAWCIi2kAs0aoBiyG7XAMT9XScddT0yA04bIPk7whGsn2bh2+iDI z44lmuB7dcb4gQ66cCjK3jORUXObbyreb/efqZhB+1F4+uL8MiKHdOzecSoOIfMAJ+VWYkMFq JT3noYdk3/YTSGHAL09H9WKDJBmKr7qSOFXthTkPCJZ1m9ZpeTfwzpYQyQv2/EXa1Ykj/ckbL ACvc3Xhl+5h/ijWWv28ze3RQ1IEVJe5/35ZOeOrRoLUevbF6YvIc7O9pvyxCCN2Os+KCvA3v1 4zfUbAEnCOMRsLrQa5FZ07VLzoBymVyTKO68Iptm6Z/Y1AX0vpreOCActGJqI1ovDfVO2IQc5 U0BjIqFUEMEULGkKet+Qv/uuvJHp1yOpu+R07EC7oyWlrT92O4UZaWjEXvsmjp5sS74TphIje M5/DYyKSo1RWp13b+5lsDDOn6zyl5F2utyAdyECWUJgW+h3+x6zo/reRjGinb3WOApXm/U5J6 XjfqOB7m0SMO0reJuVIft1hghRhVhhyExNEQruRv0DjThPdJYxYiJG+Vvt4IBNXaJJii5a/ra LY2E/rv1OGoKLY8HEio62xpkhASjQTLtB1XlPQHcyouFEdt4SjfzFM5DaehVC1ypwVIqzhad8 dWHlvGlUnYiAT3op1m8sPek1PlF2YI9XEOHzD4ZUNaoeVuLRUQZ5xXIOmr1bll0ZhKdlSbLpg aPlFujCCQSvYBco16YfncZxDxf+ciuIHiiZM3ou1yXwrIjsTNiVKA6YwI+zu4XOL7lUKGdinR CY/uNxXXQOspbIV5SABu3b4s9FdzGe6LBKQp52n5nZzgY= Subject: Re: [musl] Crash in kill(..., SIGHUP) when using SA_ONSTACK Am Thu, May 30, 2024 at 12:17:59PM +0200 schrieb Pablo Correa Gomez: > El mie, 29-05-2024 a las 09:15 -0400, Rich Felker escribi=F3: > > On Wed, May 29, 2024 at 02:04:25PM +0200, Pablo Correa Gomez wrote: > > > Thread 1 "unix" received signal SIGSEGV, Segmentation fault. > > > 0x00007ffff7fa96e8 in __syscall2 (a2=3D1, a1=3D17483, n=3D62) at > > > ../arch/x86_64/syscall_arch.h:21 > (gdb) layout asm > > 0x7ffff7fa96f9 movslq %esi,%rsi > 0x7ffff7fa96fc mov $0x3e,%eax > 0x7ffff7fa9701 syscall > >0x7ffff7fa9703 mov %rax,%rdi > [...] > Does this tell you anything? > It tells me that Rich's reasoning was correct. I'll explain further down. > > I'm not sure if the crashing code is running on the signal stack or > > main stack, but here's a thought: is it possible the CI machines are > > running on a cpu/kernel with some monster AVX512 or whatever > > extension > > enabled with register file that doesn't fit in MINSIGSTKSZ? > > That might be the case. Would explain why I could not reproduce in my > 9-year old laptop I was running last month, but I can reproduce it now > in a new machine with a 13th Gen Intel(R) Core(TM) i7-1360P > That is exactly what the program is doing, according to the link you provided in the OP. > > It's also possible that the kernel may have some weird behavior > > deciding if the task is already "running on the alt stack" when the > > alt stack is embedded in the normal stack like this. Just getting rid > > of that might be worth trying. If so, whether the problem manifests > > could be subject to timing of signal delivery (although I would not > > expect that for synchronously generated signals like here). > > Thankfully, we needn't speculate, as Linux is open source. The function get_sigframe() will determine if the thread is currently executing on the signal stack. It does that by determining that the sp is between stack base and stack top. If that isn't the case, it will allocate a red zone, else it will start at the top of the altstack. It will then try to allocate a full frame. If that doesn't work (because it already was on an altstack that got overflowed, or it tried to enter too small of an altstack), then it will generate a message "overflowed sigaltstack", that you might find in dmesg, before returning a bogus address. Due to the bogus address, all calls to unsafe_put_user() in x64_setup_rt_frame() will fail, and it will return EFAULT. This error will be reported to signal_setup_done() and it will call force_sigsegv(), which then reports a SIGSEGV at the "current" IP. Since this all happens during a syscall, the current IP is the one directly following the syscall instruction. > > Rich > Ciao, Markus