From patchwork Tue Jan 26 13:05:15 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Raoni Fassina Firmino X-Patchwork-Id: 41818 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 06493384A026; Tue, 26 Jan 2021 13:05:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06493384A026 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611666326; bh=LEpzbJVV6A9RPvOxWB+7BwHjw7+GsB9vFDdV1fCMzTI=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=UkCwdo1IQcr81LCsFdYNH+sH177BmYqrLG9zvhBw9XNXO5LTiskLIL/+6fq8fUpF0 yzrQApxmJKyl9OiqaRtr3Lp3Z8aXIj00qrNypND2iETbnvAJt3Bez6PuwYgTO1x0ck JngHuAu4VmyJk+aRNTLTyg2BlncFLoLo+qoI8riI= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 3F7683850403 for ; Tue, 26 Jan 2021 13:05:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3F7683850403 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 10QD1jRR084098 for ; Tue, 26 Jan 2021 08:05:21 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 36ak4j0xuj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 26 Jan 2021 08:05:21 -0500 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 10QD4GNT098598 for ; Tue, 26 Jan 2021 08:05:20 -0500 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 36ak4j0xsx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jan 2021 08:05:20 -0500 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 10QD5DRd015327; Tue, 26 Jan 2021 13:05:19 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma02wdc.us.ibm.com with ESMTP id 36acj92867-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jan 2021 13:05:19 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 10QD5IPa27001296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Jan 2021 13:05:19 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D7027AE05F; Tue, 26 Jan 2021 13:05:18 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1C3E2AE060; Tue, 26 Jan 2021 13:05:18 +0000 (GMT) Received: from work-tp (unknown [9.65.209.189]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTPS; Tue, 26 Jan 2021 13:05:17 +0000 (GMT) Date: Tue, 26 Jan 2021 10:05:15 -0300 To: libc-alpha@sourceware.org Subject: [PATCH] powerpc64: Workaround sigtramp vdso return call. Message-ID: <20210126130515.jivsqeoyj5nu5znk@work-tp> Mail-Followup-To: libc-alpha@sourceware.org, fweimer@redhat.com MIME-Version: 1.0 Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-26_07:2021-01-26, 2021-01-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=999 spamscore=0 phishscore=0 impostorscore=0 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101260068 X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-Patchwork-Original-From: Raoni Fassina Firmino via Libc-alpha From: Raoni Fassina Firmino Reply-To: Raoni Fassina Firmino Cc: fweimer@redhat.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Hi all, There was some initial discussions on the mailing list about the failing misc/tst-sigcontext-get_pc[1], and I made some suggestions of possible solutions. As the window for the release is closing I want to sent the more simple one of them ASAP for consideration (others would not make it in time) o/ Raoni [1] https://sourceware.org/pipermail/libc-alpha/2021-January/121933.html ---- 8< ---- A not so recent kernel change[1] changed how the trampoline `__kernel_sigtramp_rt64` is used to call signal handlers. This was exposed on the test misc/tst-sigcontext-get_pc Before kernel 5.9, the kernel set LR to the trampoline address and jumped directly to the signal handler, and at the end the signal handler, as any other function, would `blr` to the address set. In other words, the trampoline was executed just at the end of the signal handler and the only thing it did was call sigreturn. But since kernel 5.9 the kernel set CTRL to the signal handler and calls to the trampoline code, the trampoline then `bctrl` to the address in CTRL, setting the LR to the next instruction in the middle of the trampoline, when the signal handler returns, the rest of the trampoline code executes the same code as before. Here is the full trampoline code as of kernel 5.11.0-rc5 for reference: V_FUNCTION_BEGIN(__kernel_sigtramp_rt64) .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) This new behavior breaks how `backtrace()` uses to detect the trampoline frame to correctly reconstruct the stack frame when it is called from inside a signal handling. This workaround rely on the fact that the trampoline code is at very least two (maybe 3?) instructions in size (as it is in the 32 bits version, only on `li` and `sc`), so it is safe to check the return address be in the range __kernel_sigtramp_rt64 .. + 4. [1] subject: powerpc/64/signal: Balance return predictor stack in signal trampoline commit: 0138ba5783ae0dcc799ad401a1e8ac8333790df9 url: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0138ba5783ae0dcc799ad401a1e8ac8333790df9 --- sysdeps/powerpc/powerpc64/backtrace.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/sysdeps/powerpc/powerpc64/backtrace.c b/sysdeps/powerpc/powerpc64/backtrace.c index ae64c5d7a5..5540085436 100644 --- a/sysdeps/powerpc/powerpc64/backtrace.c +++ b/sysdeps/powerpc/powerpc64/backtrace.c @@ -54,11 +54,20 @@ struct signal_frame_64 { /* We don't care about the rest, since the IP value is at 'uc' field. */ }; +/* Test if the address match to the inside the trampoline code. We cannot + * count on the return address be the beginning of sigtramp, the kernel may jump + * to the trampoline and the trampoline jump to the signal handler and in this + * case the address will be somewhere in the middle of the trampoline. This is + * a workaround while we cannot know the sigtramp size. It will be at least two + * instructions long since it needs at least to load the syscall number for + * sigreturn and call it. + */ static inline bool is_sigtramp_address (void *nip) { #ifdef HAVE_SIGTRAMP_RT64 - if (nip == GLRO (dl_vdso_sigtramp_rt64)) + void *sigtramp_addr = GLRO (dl_vdso_sigtramp_rt64); + if (nip >= sigtramp_addr && nip <= sigtramp_addr + 4) return true; #endif return false;