Message ID | 20221209143402.3332369-1-ardb@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp813685wrr; Fri, 9 Dec 2022 06:39:06 -0800 (PST) X-Google-Smtp-Source: AA0mqf5BAQThFMaaYi5zVuo25Vryz0ZkMYIcdtg1i29BlqH23aBvSP6zadTPnHk0zL+wqZ8b3MDe X-Received: by 2002:a17:90a:d146:b0:219:3c9a:b1e4 with SMTP id t6-20020a17090ad14600b002193c9ab1e4mr6066749pjw.29.1670596746265; Fri, 09 Dec 2022 06:39:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670596746; cv=none; d=google.com; s=arc-20160816; b=CSp+w652DI7EVIKhZfHW468LO4y0r/XzIKE1C1rUWi5fv3OzQ0URgwwItJdGG2mATX yP59leELqnslx+VmY1k1YCp+GzfsX18KpMcwYqPumYQM047WMDHu5tpmEr08NCQM3L2R s6TcnRe5T9cqUjWavFE69HsVoNKUpBzxsOpAkZkCuym5tvNapXx1TSXtQwIkG1CPlbmh m3cjoiSyUoEywNocIF4yFKMbMi/uIbrw11DPfhv083sRnRXoqvy7WdHTSqqUMLWQYTji GzKFjElMRQHPJr/EGbKis3s/C92y/Usygp5uFBXLDJ9xP9HyMhflNxiiXAu8kMxeQay2 Zngw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=onUYfFujs51eHcfLJ3Lut0MGbbUTzTLqYlN2WsAIvFg=; b=oRt6T/5jZm14QbgZAl8jkeS3EbPQpHXxxdzw7Ixrt4Y6lqmsxxTZX7SA37LAge6zxU DFJ9MMW9qQhh2Xx9fmX0iHLPFZlgnC8DvyfzWegds97/J5qJ5IvbOqtdhpSHQSrO6slR gb54ULnxNtkEdKb8jnL/M9uJ4TmA86SMWJRtmoUIliXaPLqBQIOMyGqqWwBz7StHdHNN Gaoh4J3VG4zhH1/cDkeuAkggkiDTfTxj7wIX0mptLHZtWhsyoFEODvsfR8Y/wQD+Arw9 BZA2a38bCqoZVmGJrRrQCtDL2D0/K/YRv/FF19Xmse4CUyiG/4+fzt7LOANR5LuAunH2 bdqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qeTmW4fZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ml23-20020a17090b361700b0021a04add441si2103197pjb.104.2022.12.09.06.38.52; Fri, 09 Dec 2022 06:39:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qeTmW4fZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229696AbiLIOeL (ORCPT <rfc822;sophiezhao968@gmail.com> + 99 others); Fri, 9 Dec 2022 09:34:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbiLIOeK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 9 Dec 2022 09:34:10 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE93413F31 for <linux-kernel@vger.kernel.org>; Fri, 9 Dec 2022 06:34:09 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3F7CB6225E for <linux-kernel@vger.kernel.org>; Fri, 9 Dec 2022 14:34:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABB7AC433EF; Fri, 9 Dec 2022 14:34:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670596448; bh=pLXGrv6QU5pjiha0Gmm0P9l4TU00BqZ7toYM+O8aNqo=; h=From:To:Cc:Subject:Date:From; b=qeTmW4fZNzcLD+0x8ka17uR60lVLqxsaCPD/GA94JUzMp6LwnhJegYFZw2mR5PWct MFH2e7Yc7hapk000BPRdCPosicpsYKGqMUygDgKVX0SBwlz1mle56kWt+p0Bz8vPHz 807O5Q1uxHLJC8nwDhfLXFsYNuDdVuz4cxUAgVRbQcYj1ssOhPFIH1bXdn/WvzcXLm V0RvL7NUvjAOP2LGlLrhO+ZcoVvr1aVt5xL9otfNUYr4RYD/DbNcW/d/j//DAj7RF+ A5tmSVU8PqqZLXAbcwNvpmK851ObKOa0C+cDYO9hZ56CLriD9FZAZcbnodxiDnyS8v 5dxiIqQcsKm6A== From: Ard Biesheuvel <ardb@kernel.org> To: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, will@kernel.org, rostedt@goodmis.org, samitolvanen@google.com, keescook@chromium.org, mhiramat@kernel.org, Ard Biesheuvel <ardb@kernel.org> Subject: [PATCH] ftrace: Allow WITH_ARGS flavour of graph tracer with shadow call stack Date: Fri, 9 Dec 2022 15:34:02 +0100 Message-Id: <20221209143402.3332369-1-ardb@kernel.org> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1349; i=ardb@kernel.org; h=from:subject; bh=pLXGrv6QU5pjiha0Gmm0P9l4TU00BqZ7toYM+O8aNqo=; b=owEB7QES/pANAwAKAcNPIjmS2Y8kAcsmYgBjk0dZBTgLiAH9vDjLSbo2y5Awsx6gYL476wnx23X/ vVWfK2iJAbMEAAEKAB0WIQT72WJ8QGnJQhU3VynDTyI5ktmPJAUCY5NHWQAKCRDDTyI5ktmPJBk6C/ 9V27+4l/iFZaaoDRAUTOz3OgxvFfNA10/QjiK8UWS5UpGRiq3KTKllk6hQIuovBv3jWyjo+1s2sz/R 3lp+oF4ka95H9eAvWQADNqgFsNLoBJxVQD0FCU7keE54ZnH1dGkw0u4QDU7k3nmCCwUsrbIOngyRz5 W+QrfzKrdn/p5G0YpdUHEFjm+xJbBODLgEenBvYcZgrgAMrLj+wLITAZLr3nqtntxG0XQnFFyT85Dx 9GAXqd+2rYwrZzRikexo+mBq+4ohaVr8UHAloUZwaxLCoErUIemtosQkeK3araw+/2Jj7uD7/u4iki 9UAI8m3i0paF2DiK51kmQQqo22G9ZENYrAbH2jJSbIILaNljFNJ7xr616S5F9oMJolm0uFxKP5uyUu fBYvUs0Ocwb5A362NHKED8wjnR+mfuvtqETlYjB7qndNr2D/HmeitbRFf49W6SLva8OJUbaWl20nX6 vke8SrRzXQGa+znEWjir6ka3BSLI/Pp/oqIcEqdAY8958= X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751747653788121249?= X-GMAIL-MSGID: =?utf-8?q?1751747653788121249?= |
Series |
ftrace: Allow WITH_ARGS flavour of graph tracer with shadow call stack
|
|
Commit Message
Ard Biesheuvel
Dec. 9, 2022, 2:34 p.m. UTC
The recent switch on arm64 from DYNAMIC_FTRACE_WITH_REGS to
DYNAMIC_FTRACE_WITH_ARGS failed to take into account that we currently
require the former in order to allow the function graph tracer to be
enabled in combination with shadow call stacks. This means that this is
no longer permitted at all, in spite of the fact that either flavour of
ftrace works perfectly fine in this combination.
Given that arm64 is the only arch that implements shadow call stacks in
the first place, let's update the condition to just reflect the arm64
change. When other architectures adopt shadow call stack support, this
can be revisited if needed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Fri, Dec 09, 2022 at 03:34:02PM +0100, Ard Biesheuvel wrote: > The recent switch on arm64 from DYNAMIC_FTRACE_WITH_REGS to > DYNAMIC_FTRACE_WITH_ARGS failed to take into account that we currently > require the former in order to allow the function graph tracer to be > enabled in combination with shadow call stacks. This means that this is > no longer permitted at all, in spite of the fact that either flavour of > ftrace works perfectly fine in this combination. > > Given that arm64 is the only arch that implements shadow call stacks in > the first place, let's update the condition to just reflect the arm64 > change. When other architectures adopt shadow call stack support, this > can be revisited if needed. > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> My bad; sorry about this, and thanks for the fix! Acked-by: Mark Rutland <mark.rutland@arm.com> We should probably also add: Fixes: 26299b3f6ba26bfc ("ftrace: arm64: move from REGS to ARGS") Mark. > --- > arch/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/Kconfig b/arch/Kconfig > index 072a1b39e3afd0d1..683f365b5e31c856 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -635,7 +635,7 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK > config SHADOW_CALL_STACK > bool "Shadow Call Stack" > depends on ARCH_SUPPORTS_SHADOW_CALL_STACK > - depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER > + depends on DYNAMIC_FTRACE_WITH_ARGS || !FUNCTION_GRAPH_TRACER > help > This option enables the compiler's Shadow Call Stack, which > uses a shadow stack to protect function return addresses from > -- > 2.35.1 >
On Fri, 9 Dec 2022 14:40:25 +0000 Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Dec 09, 2022 at 03:34:02PM +0100, Ard Biesheuvel wrote: > > The recent switch on arm64 from DYNAMIC_FTRACE_WITH_REGS to > > DYNAMIC_FTRACE_WITH_ARGS failed to take into account that we currently > > require the former in order to allow the function graph tracer to be > > enabled in combination with shadow call stacks. This means that this is > > no longer permitted at all, in spite of the fact that either flavour of > > ftrace works perfectly fine in this combination. > > > > Given that arm64 is the only arch that implements shadow call stacks in > > the first place, let's update the condition to just reflect the arm64 > > change. When other architectures adopt shadow call stack support, this > > can be revisited if needed. > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > My bad; sorry about this, and thanks for the fix! > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > We should probably also add: > > Fixes: 26299b3f6ba26bfc ("ftrace: arm64: move from REGS to ARGS") Actually, I believe it is: Fixes: ddc9863e9e90 ("scs: Disable when function graph tracing is enabled") As according to the comments, scs is broken with function graph unless function graph is using the ftrace mechanism. And that is only true if WITH_ARGS is set, not REGS. Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> -- Steve
On Fri, 9 Dec 2022 15:34:02 +0100 Ard Biesheuvel <ardb@kernel.org> wrote: > The recent switch on arm64 from DYNAMIC_FTRACE_WITH_REGS to > DYNAMIC_FTRACE_WITH_ARGS failed to take into account that we currently > require the former in order to allow the function graph tracer to be > enabled in combination with shadow call stacks. This means that this is > no longer permitted at all, in spite of the fact that either flavour of > ftrace works perfectly fine in this combination. > > Given that arm64 is the only arch that implements shadow call stacks in > the first place, let's update the condition to just reflect the arm64 > change. When other architectures adopt shadow call stack support, this > can be revisited if needed. This brings a question. Is the SCS safe if kretprobe(rethook) is enabled? it also changes the stack entry after a calling function. Thank you, > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > --- > arch/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/Kconfig b/arch/Kconfig > index 072a1b39e3afd0d1..683f365b5e31c856 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -635,7 +635,7 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK > config SHADOW_CALL_STACK > bool "Shadow Call Stack" > depends on ARCH_SUPPORTS_SHADOW_CALL_STACK > - depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER > + depends on DYNAMIC_FTRACE_WITH_ARGS || !FUNCTION_GRAPH_TRACER > help > This option enables the compiler's Shadow Call Stack, which > uses a shadow stack to protect function return addresses from > -- > 2.35.1 >
On Fri, Dec 09, 2022 at 04:51:39PM -0500, Steven Rostedt wrote: > On Fri, 9 Dec 2022 14:40:25 +0000 > Mark Rutland <mark.rutland@arm.com> wrote: > > > On Fri, Dec 09, 2022 at 03:34:02PM +0100, Ard Biesheuvel wrote: > > > The recent switch on arm64 from DYNAMIC_FTRACE_WITH_REGS to > > > DYNAMIC_FTRACE_WITH_ARGS failed to take into account that we currently > > > require the former in order to allow the function graph tracer to be > > > enabled in combination with shadow call stacks. This means that this is > > > no longer permitted at all, in spite of the fact that either flavour of > > > ftrace works perfectly fine in this combination. > > > > > > Given that arm64 is the only arch that implements shadow call stacks in > > > the first place, let's update the condition to just reflect the arm64 > > > change. When other architectures adopt shadow call stack support, this > > > can be revisited if needed. > > > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > > > My bad; sorry about this, and thanks for the fix! > > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > > > We should probably also add: > > > > Fixes: 26299b3f6ba26bfc ("ftrace: arm64: move from REGS to ARGS") > > Actually, I believe it is: > > Fixes: ddc9863e9e90 ("scs: Disable when function graph tracing is enabled") Ah; it's slightly more subtle since these were on different branches that got merged. Either's correct in its own branch, and the merge is where things went wrong. I think the overall least confusing thing is to bite the bullet and list both REGS and ARGS, i.e. depends on DYNAMIC_FTRACE_WITH_ARGS || DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER ... and for the fixes tag have: Fixes: ddc9863e9e90 ("scs: Disable when function graph tracing is enabled") That way the commit is correct regardless of the REGS -> ARGS conversion, and will work if backported independently. Thanks, Mark.
On Sun, Dec 11, 2022 at 12:27:31PM +0900, Masami Hiramatsu wrote: > On Fri, 9 Dec 2022 15:34:02 +0100 > Ard Biesheuvel <ardb@kernel.org> wrote: > > > The recent switch on arm64 from DYNAMIC_FTRACE_WITH_REGS to > > DYNAMIC_FTRACE_WITH_ARGS failed to take into account that we currently > > require the former in order to allow the function graph tracer to be > > enabled in combination with shadow call stacks. This means that this is > > no longer permitted at all, in spite of the fact that either flavour of > > ftrace works perfectly fine in this combination. > > > > Given that arm64 is the only arch that implements shadow call stacks in > > the first place, let's update the condition to just reflect the arm64 > > change. When other architectures adopt shadow call stack support, this > > can be revisited if needed. > > This brings a question. Is the SCS safe if kretprobe(rethook) is enabled? > it also changes the stack entry after a calling function. That should be safe. The SCS push is just an instruction somewhere in the function, and since kretprobe instruments the first instruction of a function, that intrumentation will run *before* the SCS push occurs, and so it can safely override the return address. The difficulty with ftrace is that the old mcount implementation calls into ftrace *after* the function prologue, after saving some GPRs to the stack, signing the return address with pointer authentication, and/or pushing the return address to the SCS. The DYNAMIC_FTRACE_WITH_{ARGS,REGS} forms use patchable-function-entry to hook functions *before* any of that happens, and are safe for the same reason as kretprobes. Thanks, Mark. > > Thank you, > > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > --- > > arch/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > index 072a1b39e3afd0d1..683f365b5e31c856 100644 > > --- a/arch/Kconfig > > +++ b/arch/Kconfig > > @@ -635,7 +635,7 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK > > config SHADOW_CALL_STACK > > bool "Shadow Call Stack" > > depends on ARCH_SUPPORTS_SHADOW_CALL_STACK > > - depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER > > + depends on DYNAMIC_FTRACE_WITH_ARGS || !FUNCTION_GRAPH_TRACER > > help > > This option enables the compiler's Shadow Call Stack, which > > uses a shadow stack to protect function return addresses from > > -- > > 2.35.1 > > > > > -- > Masami Hiramatsu (Google) <mhiramat@kernel.org>
On Mon, Dec 12, 2022 at 10:36:23AM +0000, Mark Rutland wrote: > On Fri, Dec 09, 2022 at 04:51:39PM -0500, Steven Rostedt wrote: > > On Fri, 9 Dec 2022 14:40:25 +0000 > > Mark Rutland <mark.rutland@arm.com> wrote: > > > > > On Fri, Dec 09, 2022 at 03:34:02PM +0100, Ard Biesheuvel wrote: > > > > The recent switch on arm64 from DYNAMIC_FTRACE_WITH_REGS to > > > > DYNAMIC_FTRACE_WITH_ARGS failed to take into account that we currently > > > > require the former in order to allow the function graph tracer to be > > > > enabled in combination with shadow call stacks. This means that this is > > > > no longer permitted at all, in spite of the fact that either flavour of > > > > ftrace works perfectly fine in this combination. > > > > > > > > Given that arm64 is the only arch that implements shadow call stacks in > > > > the first place, let's update the condition to just reflect the arm64 > > > > change. When other architectures adopt shadow call stack support, this > > > > can be revisited if needed. > > > > > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > > > > > My bad; sorry about this, and thanks for the fix! > > > > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > > > > > We should probably also add: > > > > > > Fixes: 26299b3f6ba26bfc ("ftrace: arm64: move from REGS to ARGS") > > > > Actually, I believe it is: > > > > Fixes: ddc9863e9e90 ("scs: Disable when function graph tracing is enabled") > > Ah; it's slightly more subtle since these were on different branches that got > merged. Either's correct in its own branch, and the merge is where things went > wrong. > > I think the overall least confusing thing is to bite the bullet and list both > REGS and ARGS, i.e. > > depends on DYNAMIC_FTRACE_WITH_ARGS || DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER > > ... and for the fixes tag have: > > Fixes: ddc9863e9e90 ("scs: Disable when function graph tracing is enabled") > > That way the commit is correct regardless of the REGS -> ARGS conversion, and > will work if backported independently. Ard -- please can you respin as per Mark's suggestion above? I can then send it as a fix later this week. Cheers, Will
diff --git a/arch/Kconfig b/arch/Kconfig index 072a1b39e3afd0d1..683f365b5e31c856 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -635,7 +635,7 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK config SHADOW_CALL_STACK bool "Shadow Call Stack" depends on ARCH_SUPPORTS_SHADOW_CALL_STACK - depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER + depends on DYNAMIC_FTRACE_WITH_ARGS || !FUNCTION_GRAPH_TRACER help This option enables the compiler's Shadow Call Stack, which uses a shadow stack to protect function return addresses from