Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7562940imu; Tue, 22 Jan 2019 07:59:03 -0800 (PST) X-Google-Smtp-Source: ALg8bN63h53IXBNTATJtUHjqVipwGva2epm+wqsuOmy/QeZH1UxWcXd1pPEKKZzydWkdsDHVZmzw X-Received: by 2002:a62:104a:: with SMTP id y71mr14894293pfi.34.1548172743469; Tue, 22 Jan 2019 07:59:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548172743; cv=none; d=google.com; s=arc-20160816; b=i+lYjZQslhLGrbu6sJNmeOt7G36GASHepd1alHFHfz72pAHrHkcqVGczR3sFDym0LL 9xLR76ZU1g/TafSCUjcZbbnzJ4Nnz+Gh6sb4cnTFe7l7Nbs6lBJVK+L9hOA2VrYvCP2g oOnIPgwOiF5i9uSF+A+uLyWAMDM5CJxs9n4XoEgrZBDFOAzX40ydAOBts/y6NwTRpgPM CokDbFRpI3eeOZDhE0nvw7OgAYlnUfag/8tdRfEGKEPFkfBG949IfFoSC2Vp+EQcEyNu vyhs8iGwyRVZKOn2ZVRpA+RijunSh9Xg9WBZylPJPqYagVUqSeMRWOH8DF9ESUn8Du8Z 6iYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=tkkonW4S5G+/KsQciaSt8YUQZr0VtJMgYaVM9gl1xzk=; b=Y65I0E98MyyhaALA0Ja/KoE2kbIR5XkkOiHAY5bHLMtkmcuoBNVBSSNcrCO6OX2+iu jnu3PxoCnhOd3Yn2OnG+NCPaobwYR79zwHpA+pYHUxlN4CYQatmdC5IDWsvhL8Ii3Jos Tge1JK3R7A5nRrxUkftS1JYctWOvMyTM5zryC4meDeB4DNipcVeUXl2TAhZASma7e5E0 btdMFXK9eivZv+O1OorfKT8HxSjTOM7uIKULKmM3yDLJqEO/5be8TKXDQKl1cOC4mdsO ByZ1p3a2W5hUjCkJ1tB900ht0BfmBdy+5vmitr0F60DHuAmK6BEwnYO5qrA+Nxcm/bis ySfQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c8si16200979pfe.243.2019.01.22.07.58.47; Tue, 22 Jan 2019 07:59:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729218AbfAVP5h (ORCPT + 99 others); Tue, 22 Jan 2019 10:57:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34338 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728756AbfAVP5e (ORCPT ); Tue, 22 Jan 2019 10:57:34 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DC6B73DE0D; Tue, 22 Jan 2019 15:57:33 +0000 (UTC) Received: from jlaw-desktop.bos.redhat.com (dhcp-17-208.bos.redhat.com [10.18.17.208]) by smtp.corp.redhat.com (Postfix) with ESMTP id D7FE81048107; Tue, 22 Jan 2019 15:57:32 +0000 (UTC) From: Joe Lawrence To: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, live-patching@vger.kernel.org Cc: Balbir Singh , Jiri Kosina , Josh Poimboeuf , Michael Ellerman , Nicolai Stange , Torsten Duwe Subject: [PATCH 1/4] powerpc/64s: Clear on-stack exception marker upon exception return Date: Tue, 22 Jan 2019 10:57:21 -0500 Message-Id: <20190122155724.27557-2-joe.lawrence@redhat.com> In-Reply-To: <20190122155724.27557-1-joe.lawrence@redhat.com> References: <20190122155724.27557-1-joe.lawrence@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 22 Jan 2019 15:57:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Nicolai Stange The ppc64 specific implementation of the reliable stacktracer, save_stack_trace_tsk_reliable(), bails out and reports an "unreliable trace" whenever it finds an exception frame on the stack. Stack frames are classified as exception frames if the STACK_FRAME_REGS_MARKER magic, as written by exception prologues, is found at a particular location. However, as observed by Joe Lawrence, it is possible in practice that non-exception stack frames can alias with prior exception frames and thus, that the reliable stacktracer can find a stale STACK_FRAME_REGS_MARKER on the stack. It in turn falsely reports an unreliable stacktrace and blocks any live patching transition to finish. Said condition lasts until the stack frame is overwritten/initialized by function call or other means. In principle, we could mitigate this by making the exception frame classification condition in save_stack_trace_tsk_reliable() stronger: in addition to testing for STACK_FRAME_REGS_MARKER, we could also take into account that for all exceptions executing on the kernel stack - their stack frames's backlink pointers always match what is saved in their pt_regs instance's ->gpr[1] slot and that - their exception frame size equals STACK_INT_FRAME_SIZE, a value uncommonly large for non-exception frames. However, while these are currently true, relying on them would make the reliable stacktrace implementation more sensitive towards future changes in the exception entry code. Note that false negatives, i.e. not detecting exception frames, would silently break the live patching consistency model. Furthermore, certain other places (diagnostic stacktraces, perf, xmon) rely on STACK_FRAME_REGS_MARKER as well. Make the exception exit code clear the on-stack STACK_FRAME_REGS_MARKER for those exceptions running on the "normal" kernel stack and returning to kernelspace: because the topmost frame is ignored by the reliable stack tracer anyway, returns to userspace don't need to take care of clearing the marker. Furthermore, as I don't have the ability to test this on Book 3E or 32 bits, limit the change to Book 3S and 64 bits. Finally, make the HAVE_RELIABLE_STACKTRACE Kconfig option depend on PPC_BOOK3S_64 for documentation purposes. Before this patch, it depended on PPC64 && CPU_LITTLE_ENDIAN and because CPU_LITTLE_ENDIAN implies PPC_BOOK3S_64, there's no functional change here. Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for the consistency model") Reported-by: Joe Lawrence Signed-off-by: Nicolai Stange Signed-off-by: Joe Lawrence --- arch/powerpc/Kconfig | 2 +- arch/powerpc/kernel/entry_64.S | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 2890d36eb531..73bf87b1d274 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -220,7 +220,7 @@ config PPC select HAVE_PERF_USER_STACK_DUMP select HAVE_RCU_TABLE_FREE if SMP select HAVE_REGS_AND_STACK_ACCESS_API - select HAVE_RELIABLE_STACKTRACE if PPC64 && CPU_LITTLE_ENDIAN + select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN select HAVE_SYSCALL_TRACEPOINTS select HAVE_VIRT_CPU_ACCOUNTING select HAVE_IRQ_TIME_ACCOUNTING diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index 435927f549c4..a2c168b395d2 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -1002,6 +1002,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR) ld r2,_NIP(r1) mtspr SPRN_SRR0,r2 + /* + * Leaving a stale exception_marker on the stack can confuse + * the reliable stack unwinder later on. Clear it. + */ + li r2,0 + std r2,STACK_FRAME_OVERHEAD-16(r1) + ld r0,GPR0(r1) ld r2,GPR2(r1) ld r3,GPR3(r1) -- 2.20.1