Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3774372imu; Mon, 14 Jan 2019 08:49:01 -0800 (PST) X-Google-Smtp-Source: ALg8bN5CRiJ7UWqrS1SBML3lhh+JBIQoqwtylQubi9kjEY8wI7mhHcHBN+knYZnCRzq71ThHpTHQ X-Received: by 2002:a17:902:7107:: with SMTP id a7mr26143640pll.290.1547484541650; Mon, 14 Jan 2019 08:49:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547484541; cv=none; d=google.com; s=arc-20160816; b=s3ftB4em+L/EWQvX5WXY5hZGeUyW2HRxGzKcBogIqDXtn0fHeYLOnppPNjYC65jKCM JgXJ9f+eZT0qIS0Jp/bbBoU//avin6DxH2WHSvGlRaz5JiegOZ3y5943vM2O/63ayAq8 9UegleO3AJ2J8E5F1Onnt3HVYbACUCuhgraSCxlLjth19sX/I9urK6VsWZNM3h/3Q7UM y5kjjA6eK5pvQWGHpmioKotc8qlJFnnfBPR/QUsG3S7fr0f5o+wGYhE+LKFq87/niRXy stDgXFWHenT9va8K7DJC8rHDXSnYG4S7ftb7j4ZLPKh6MyByU1Yo8/ZdGmaEL5l3CnFX LgIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=rowbrSfiMIEg3tb8IeRATxWPbZHx8QWFvj81T5fha+A=; b=XuRyZ3J5GIJGyt57DBIfGJpTRVKFSNJpF1OHNBJdala/b+Bt+OlbGok2gw1O+tSamv fxzsmLd7AeriTfRDRD5cZnLcULN1/TtvvzHB9WZYCtewmKqX0hSE373fGD2wWSUgTmua 0nLJC4PpEhnLi91zn2xg21xRmuHZuGgECBoN8JPeDT7YMaDPPqgQG5KQGLqcc5Y7UzCA 3G3Zsvnrq5B9Uz1omNMS+NlbN3S+8B3bfc8ddfSugCLrph3+DgOfTI6mSfiWx+OQb3of Gd6FlMfXiRKeK2BFagcm2A/du0/y3SrYtpgJIRiYRVfus4xscLLDkscg4LGiytGmcAMg l7MQ== 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 q26si710997pgk.162.2019.01.14.08.48.45; Mon, 14 Jan 2019 08:49:01 -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 S1726782AbfANQrD (ORCPT + 99 others); Mon, 14 Jan 2019 11:47:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51444 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726724AbfANQrD (ORCPT ); Mon, 14 Jan 2019 11:47:03 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5C4FB8553D; Mon, 14 Jan 2019 16:47:02 +0000 (UTC) Received: from redhat.com (dhcp-17-208.bos.redhat.com [10.18.17.208]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 40A7619C7C; Mon, 14 Jan 2019 16:47:01 +0000 (UTC) Date: Mon, 14 Jan 2019 11:46:59 -0500 From: Joe Lawrence To: Nicolai Stange Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, live-patching@vger.kernel.org, Torsten Duwe , Michael Ellerman , Jiri Kosina , Balbir Singh Subject: Re: ppc64le reliable stack unwinder and scheduled tasks Message-ID: <20190114164659.GA18643@redhat.com> References: <7f468285-b149-37e2-e782-c9e538b997a9@redhat.com> <87bm4ocbbt.fsf@suse.de> <20190111010808.GA17858@redhat.com> <87fttzbpid.fsf@suse.de> <20190114040937.GA6739@redhat.com> <877ef7bt6j.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877ef7bt6j.fsf@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 14 Jan 2019 16:47:02 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 14, 2019 at 08:21:40AM +0100, Nicolai Stange wrote: > Joe Lawrence writes: > > > We should be careful when inspecting the bottom-most stack frame (the > > first to be unwound), particularly for scheduled-out tasks. As Nicolai > > Stange explains, "If I'm reading the code in _switch() correctly, the > > first frame is completely uninitialized except for the pointer back to > > the caller's stack frame." If a previous do_IRQ() invocation, for > > example, has left a residual exception-marker on the first frame, the > > stack tracer would incorrectly report this task's trace as unreliable. > > > > FWIW, it's not been do_IRQ() who wrote the exception marker, but it's > caller hardware_interrupt_common(), more specifically the > EXCEPTION_PROLOG_COMMON_3 part therof. > Hi Nicolai, Yeah, I was sloppy with the description there. :) > I thought about this a little more and can't see anything that would > prevent higher, i.e. non-_switch() frames to also alias with prior > exception frames. That STACK_FRAME_REGS_MARKER is written to a stack > frame's "parameter area" and most functions probably don't initialize > this either. So, AFAICS, higher stack frames could potentially be > affected by the very same problem. Hmm, I suppose a callee could leave that stack-word untouched and then make subsquent calls, which would be confusing for the unwinder. > I think the best solution would be to clear the STACK_FRAME_REGS_MARKER > upon exception return. I have a patch ready for that and will post it > after it has passed some basic testing -- hopefully later this day. > I agree that this seems like the simplest way to clean up the exception stack frame state. > That being said, I still think that your patch should also get applied > in some form -- looking at unitialized memory is just not a good thing > to do. > > [ ... snip ...] > I would perhaps not limit this to the STACK_FRAME_REGS_MARKER, but also > not emit the ip obtained from the first frame into the resulting trace. > > I.e., how about moving all the sp/newsp handling to the beginning of the > loop and doing an 'if (firstframe) continue;' right after that? Good point, there is a bunch of ip and trace entries bookkeeping that shouldn't apply in this case. I gave the following some very light testing (5.0.0-rc2 + Petr's atomic patches as to include and run the selftests) ... if you want to take a bigger hammer to refactor some of the sp/newsp code (perhaps it could be incorporated into the for() loop itself), feel free to go for it. You could add something like this as a 2nd patch to the previously mentioned STACK_FRAME_REGS_MARKER cleanup fix. Thanks, -- Joe -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- From b87f9e81cf59a6e7e2309400e1b417562414cd5c Mon Sep 17 00:00:00 2001 From: Joe Lawrence Date: Sun, 13 Jan 2019 21:02:01 -0500 Subject: [PATCH] powerpc/livepatch: relax reliable stack tracer checks for first-frame The bottom-most stack frame (the first to be unwound) may be largely uninitialized, for the "Power Architecture 64-Bit ELF V2 ABI" only requires its backchain pointer to be set. The reliable stack tracer should be careful when verifying this frame: skip checks on STACK_FRAME_LR_SAVE and STACK_FRAME_MARKER offsets that may contain uninitialized residual data. Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for the consistency model") Suggested-by: Nicolai Stange Signed-off-by: Joe Lawrence --- arch/powerpc/kernel/stacktrace.c | 33 +++++++++++++++++++++----------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c index e2c50b55138f..46096687a5a8 100644 --- a/arch/powerpc/kernel/stacktrace.c +++ b/arch/powerpc/kernel/stacktrace.c @@ -84,6 +84,12 @@ save_stack_trace_regs(struct pt_regs *regs, struct stack_trace *trace) EXPORT_SYMBOL_GPL(save_stack_trace_regs); #ifdef CONFIG_HAVE_RELIABLE_STACKTRACE +/* + * This function returns an error if it detects any unreliable features of the + * stack. Otherwise it guarantees that the stack trace is reliable. + * + * If the task is not 'current', the caller *must* ensure the task is inactive. + */ int save_stack_trace_tsk_reliable(struct task_struct *tsk, struct stack_trace *trace) @@ -142,12 +148,6 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk, if (sp & 0xF) return 1; - /* Mark stacktraces with exception frames as unreliable. */ - if (sp <= stack_end - STACK_INT_FRAME_SIZE && - stack[STACK_FRAME_MARKER] == STACK_FRAME_REGS_MARKER) { - return 1; - } - newsp = stack[0]; /* Stack grows downwards; unwinder may only go up. */ if (newsp <= sp) @@ -158,11 +158,21 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk, return 1; /* invalid backlink, too far up. */ } + /* We can only trust the bottom frame's backlink, the rest + * of the frame may be uninitialized, continue to the next. */ + if (firstframe--) + goto next; + + /* Mark stacktraces with exception frames as unreliable. */ + if (sp <= stack_end - STACK_INT_FRAME_SIZE && + stack[STACK_FRAME_MARKER] == STACK_FRAME_REGS_MARKER) { + return 1; + } + /* Examine the saved LR: it must point into kernel code. */ ip = stack[STACK_FRAME_LR_SAVE]; - if (!firstframe && !__kernel_text_address(ip)) + if (!__kernel_text_address(ip)) return 1; - firstframe = 0; /* * FIXME: IMHO these tests do not belong in @@ -183,12 +193,13 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk, else trace->skip--; - if (newsp == stack_end) - break; - if (trace->nr_entries >= trace->max_entries) return -E2BIG; +next: + if (newsp == stack_end) + break; + sp = newsp; } return 0; -- 2.20.1