From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FDCEC433E0 for ; Fri, 22 Jan 2021 14:47:03 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0D15523437 for ; Fri, 22 Jan 2021 14:47:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D15523437 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4DMhtD0CyBzDr5n for ; Sat, 23 Jan 2021 01:47:00 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=libc.org (client-ip=216.12.86.13; helo=brightrain.aerifal.cx; envelope-from=dalias@libc.org; receiver=) Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4DMhq32RL3zDr5R for ; Sat, 23 Jan 2021 01:44:13 +1100 (AEDT) Date: Fri, 22 Jan 2021 09:44:05 -0500 From: Rich Felker To: Florian Weimer Subject: Re: [musl] Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline Message-ID: <20210122144402.GP23432@brightrain.aerifal.cx> References: <20200511101952.1463138-1-npiggin@gmail.com> <87im7pp5yl.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87im7pp5yl.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: musl@lists.openwall.com, libc-alpha@sourceware.org, linuxppc-dev@lists.ozlabs.org, Nicholas Piggin , Alan Modra Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Jan 22, 2021 at 12:27:14PM +0100, Florian Weimer wrote: > * Nicholas Piggin: > > > diff --git a/arch/powerpc/kernel/vdso64/sigtramp.S b/arch/powerpc/kernel/vdso64/sigtramp.S > > index a8cc0409d7d2..bbf68cd01088 100644 > > --- a/arch/powerpc/kernel/vdso64/sigtramp.S > > +++ b/arch/powerpc/kernel/vdso64/sigtramp.S > > @@ -6,6 +6,7 @@ > > * Copyright (C) 2004 Benjamin Herrenschmuidt (benh@kernel.crashing.org), IBM Corp. > > * Copyright (C) 2004 Alan Modra (amodra@au.ibm.com)), IBM Corp. > > */ > > +#include /* IFETCH_ALIGN_BYTES */ > > #include > > #include > > #include > > @@ -14,21 +15,17 @@ > > > > .text > > > > -/* The nop here is a hack. The dwarf2 unwind routines subtract 1 from > > - the return address to get an address in the middle of the presumed > > - call instruction. Since we don't have a call here, we artificially > > - extend the range covered by the unwind info by padding before the > > - real start. */ > > - nop > > .balign 8 > > + .balign IFETCH_ALIGN_BYTES > > V_FUNCTION_BEGIN(__kernel_sigtramp_rt64) > > -.Lsigrt_start = . - 4 > > +.Lsigrt_start: > > + bctrl /* call the handler */ > > addi r1, r1, __SIGNAL_FRAMESIZE > > li r0,__NR_rt_sigreturn > > sc > > .Lsigrt_end: > > V_FUNCTION_END(__kernel_sigtramp_rt64) > > -/* The ".balign 8" above and the following zeros mimic the old stack > > +/* The .balign 8 above and the following zeros mimic the old stack > > trampoline layout. The last magic value is the ucontext pointer, > > chosen in such a way that older libgcc unwind code returns a zero > > for a sigcontext pointer. */ > > As far as I understand it, this breaks cancellation handling on musl and > future glibc because it is necessary to look at the signal delivery > location to see if a system call sequence has result in an action, and > that location is no longer in user code after this change. > > We have a glibc test in preparation of our change, and it started > failing: > > Linux 5.10 breaks sigcontext_get_pc on powerpc64 > > > Isn't it possible to avoid the return predictor desynchronization by > adding the appropriate hint? Maybe I'm missing something but I don't see how this would break musl; we just inspect the PC in the mcontext, which I don't see any changes to and which should still point to the next instruction of the interrupted context. I don't have a test environment though so I'll have to wait for feedback from ppc users to be sure. Are there any further details on how it's breaking glibc? Rich