Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6729766imu; Wed, 30 Jan 2019 21:47:50 -0800 (PST) X-Google-Smtp-Source: ALg8bN762rEDfAso44d8/2qlHtKwCqwbjaVnpNZBPG0eLqSLl7HxZJFZgWEiOI0G6XfRFTBRNA4x X-Received: by 2002:a62:4e83:: with SMTP id c125mr33894896pfb.101.1548913670583; Wed, 30 Jan 2019 21:47:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548913670; cv=none; d=google.com; s=arc-20160816; b=GnlNb6iAzLLkkvTf51btrObVGUQSsAVIMflKwL4vJcKqCVf9WxtY98SaZZw2TnXGrk n8uhqcKy9/bK2yrhbk6yxNJIxhwHRFRo086HM24WGUR1NBujNl6GYWkgzggNqzGzOBmE +OIZrYAYtfKGGPlFGIhOTp1IR9T5ISTlL2adiNlfvJjN5m2J3jacbKCpKEugpGQo/6od znn9b7xMR5KzyPz3Sq7iMdOShfzIovN+eDYqgcIocbuiEYbEIb1aj5J+IPN+Ync+UPJZ s/NNXG5kPhQW5L9UHjeQpX74uZWDand4JSBxyuRrvlJMiBZRNHGsGbyVWVCFOo523liJ Yo6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=YFGr8EiJO3lnDvk1HTGNQvVylh3oXkeBak1NCSoYTnI=; b=Y5Cs8/daVz+rCfcSgJOToN9nJHtGitTuz+WvSSds8fIM40bJh5dFWVeEJ0iM/0kJBy M0T+N/CapNG7nY/CkEFxARUffHz+/A7MIvnFlUNhr1OZzTn3Xd2p0yXRUj52QIkl8P7v x11yc4GJPyeltQKaF9GlORNuN9qCqrYAlblR5RNPRhZCizOuend32oReH8owFBTDvNYG S7UuPNLTdJjuojC8tL/TRsNnjoYrYIxgBH/vsQXXzU2smo6ubbxUSXcavXF0PPKaZFbk /C6NT9TumLL412Rhp8kBKz5WPVG6fxfjmw+t0Ts383187S0uLeokuQ5N7J4kyHX7g/ak vvJg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d17si3796262pfm.40.2019.01.30.21.47.35; Wed, 30 Jan 2019 21:47:50 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726539AbfAaFqJ (ORCPT + 99 others); Thu, 31 Jan 2019 00:46:09 -0500 Received: from ozlabs.org ([203.11.71.1]:53417 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725857AbfAaFqJ (ORCPT ); Thu, 31 Jan 2019 00:46:09 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43qq3K6r8jz9sDX; Thu, 31 Jan 2019 16:46:05 +1100 (AEDT) From: Michael Ellerman To: Nicolai Stange Cc: Joe Lawrence , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, live-patching@vger.kernel.org, Balbir Singh , Jiri Kosina , Josh Poimboeuf , Nicolai Stange , Torsten Duwe Subject: Re: [PATCH 1/4] powerpc/64s: Clear on-stack exception marker upon exception return In-Reply-To: <87a7jirrn6.fsf@suse.de> References: <20190122155724.27557-1-joe.lawrence@redhat.com> <20190122155724.27557-2-joe.lawrence@redhat.com> <87tvhqpbzd.fsf@concordia.ellerman.id.au> <87a7jirrn6.fsf@suse.de> Date: Thu, 31 Jan 2019 16:46:05 +1100 Message-ID: <87zhrhnzvm.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nicolai Stange writes: > Michael Ellerman writes: > >> Joe Lawrence writes: >>> 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. >> >> That has nothing to do with the fix and should really be in a separate >> patch. >> >> I can split it when applying. > > If you don't mind, that would be nice! Or simply drop that > chunk... Otherwise, let me know if I shall send a split v2 for this > patch [1/4] only. No worries, I split it out: commit a50d3250d7ae34c561177a1f9cfb79816fcbcff1 Author: Nicolai Stange AuthorDate: Thu Jan 31 16:41:50 2019 +1100 Commit: Michael Ellerman CommitDate: Thu Jan 31 16:43:29 2019 +1100 powerpc/64s: Make reliable stacktrace dependency clearer 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. Signed-off-by: Nicolai Stange Signed-off-by: Joe Lawrence [mpe: Split out of larger patch] Signed-off-by: Michael Ellerman 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 cheers