Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp999948yba; Thu, 4 Apr 2019 02:06:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxsARzpMFIft59EjvLBUAwrkvNGpYCGNkP5GavpAjwqCv5hLcx7EKTC4qlg+08ZEZDRuU5x X-Received: by 2002:a65:4302:: with SMTP id j2mr4431724pgq.291.1554368813871; Thu, 04 Apr 2019 02:06:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554368813; cv=none; d=google.com; s=arc-20160816; b=oS44rhax84z3Df5Tx6BgRha50Zj7AZWohDog8E1HdXSsOcUg1WyPp4Nb8C0ckkH0K7 phHpEWNeXBHEfG7Q4vpUiYXAISMU7bDBz82OWIIrQEoNpsqrh7exT9W284h73W7YYgH6 xPURvRcYiRLPxOA1XCJXFvli/JY2txI0+2BDElvjcjCc/QQQhK6bn5Qs3CFlSsfMoMOn eycb6z/G0InF+LVDEpdOucZuSnayJpJFdHWsw6D5bxQ9X7yKRcgCjV3XD7s4/TnMAbGA cqTG7u9uwFLPvAgWIN4ImKwV1g2ytRVaV1I8WlZHA8QgEZA/OGl2iDkyYeyZF9wAUzun GlVw== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=5lQ9XroH3299daH4TGkD9uDuB9VaCxFSsILEw+Cuy20=; b=oWESjLmny23WrNhlBZrh2ruSwiDJbJcEz9uGkTqydgwW2i/0hbvFnVOS78Z2OPLa9z u4XW1+NNfa8I7Vqa1xBprVHH87XcsuI/lBK8IfJbMSWfGXnj0xqAIDgbwG9xY94xU9Wk zLqgZcQgj14OzK9f6PdpSL1LULB5wYzI1Yd6AevgeBzcSAXaM0f0EXvMHg57JkFyoDnh yWbJWYiaG3h3fbdtOHt3jo3sAFqB5X+XXodLmXkFC17re5a/ITuqfl4hu5Fk7L8wrbdK VVIlOfHLGTWNONRphwqVO4UHn2Elfl/5TNeCCeaFZlZAwgj//RvuGfDumvP3yAXG2jRR JmSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=UDYspgIL; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n66si16155389pfb.62.2019.04.04.02.06.38; Thu, 04 Apr 2019 02:06:53 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=UDYspgIL; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732001AbfDDJGG (ORCPT + 99 others); Thu, 4 Apr 2019 05:06:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:44442 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732246AbfDDJGF (ORCPT ); Thu, 4 Apr 2019 05:06:05 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 92FFA2147C; Thu, 4 Apr 2019 09:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554368764; bh=4AbC/Nh80mgP8FzSjcZB7AA4lKPM5IS98RuBhZLjq4w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UDYspgILdUEEP332vc53tid4vPh8MeTqA26wbJQDcm2DpCajbey34McFoPDDD18mu 15NeLJUycz5PzpFfsMh9mQqZ9RwpRBE5mvAKPLwPf3CpcbtN1qPRxXcU8uA2aPnRqa injb87ZTpsi5PMVa74bL720JMwtYt4TTL86UPAhs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joe Lawrence , Nicolai Stange , Michael Ellerman , Sasha Levin Subject: [PATCH 4.19 145/187] powerpc/64s: Clear on-stack exception marker upon exception return Date: Thu, 4 Apr 2019 10:48:02 +0200 Message-Id: <20190404084609.995590232@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190404084603.119654039@linuxfoundation.org> References: <20190404084603.119654039@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit eddd0b332304d554ad6243942f87c2fcea98c56b ] 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. 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 Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin --- arch/powerpc/kernel/entry_64.S | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index c806a3c12592..7a46e0e57a36 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -994,6 +994,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.19.1