Message ID | 20191024225132.13410-10-samitolvanen@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2,01/17] arm64: mm: don't use x18 in idmap_kpti_install_ng_mappings | expand |
On Thu, Oct 24, 2019 at 03:51:24PM -0700, samitolvanen@google.com wrote: > With CONFIG_FUNCTION_GRAPH_TRACER, function return addresses are > modified in ftrace_graph_caller and prepare_ftrace_return to redirect > control flow to ftrace_return_to_handler. This is incompatible with > SCS. I'm guessing it's difficult to always figure out the SCS slot for an instrumented callsite unless we pass this explicitly from the ftrace entry code, so we'd probably have to change some common infrastructure for that. We have a similar issue with pointer authentication, and we're solving that with -fpatchable-function-entry, which allows us to hook the callsite before it does anything with the return address. IIUC we could use the same mechanism here (and avoid introducing a third). Are there plans to implement -fpatchable-function-entry on the clang side? Thanks, Mark. > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com> > --- > arch/arm64/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 3f047afb982c..8cda176dad9a 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -148,7 +148,7 @@ config ARM64 > select HAVE_FTRACE_MCOUNT_RECORD > select HAVE_FUNCTION_TRACER > select HAVE_FUNCTION_ERROR_INJECTION > - select HAVE_FUNCTION_GRAPH_TRACER > + select HAVE_FUNCTION_GRAPH_TRACER if !SHADOW_CALL_STACK > select HAVE_GCC_PLUGINS > select HAVE_HW_BREAKPOINT if PERF_EVENTS > select HAVE_IRQ_TIME_ACCOUNTING > -- > 2.24.0.rc0.303.g954a862665-goog >
On Fri, Oct 25, 2019 at 4:03 AM Mark Rutland <mark.rutland@arm.com> wrote: > I'm guessing it's difficult to always figure out the SCS slot for an > instrumented callsite unless we pass this explicitly from the ftrace > entry code, so we'd probably have to change some common infrastructure > for that. > > We have a similar issue with pointer authentication, and we're solving > that with -fpatchable-function-entry, which allows us to hook the > callsite before it does anything with the return address. IIUC we could > use the same mechanism here (and avoid introducing a third). > > Are there plans to implement -fpatchable-function-entry on the clang > side? I'm not sure if there are plans at the moment, but if this feature is needed for PAC, adding it to clang shouldn't be a problem. Nick, did you have any thoughts on this? Sami
On Tue, Oct 29, 2019 at 10:45 AM Sami Tolvanen <samitolvanen@google.com> wrote: > > On Fri, Oct 25, 2019 at 4:03 AM Mark Rutland <mark.rutland@arm.com> wrote: > > We have a similar issue with pointer authentication, and we're solving > > that with -fpatchable-function-entry, which allows us to hook the > > callsite before it does anything with the return address. IIUC we could > > use the same mechanism here (and avoid introducing a third). > > > > Are there plans to implement -fpatchable-function-entry on the clang > > side? > > I'm not sure if there are plans at the moment, but if this feature is > needed for PAC, adding it to clang shouldn't be a problem. Nick, did > you have any thoughts on this? I didn't see anything explicitly in LLVM's issue tracker. I also didn't see -fpatchable-function-entry currently in -next other than under arch/parisc. Are there patches I can look at? Has ARM's kernel team expressed the need to ARM's LLVM team?
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3f047afb982c..8cda176dad9a 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -148,7 +148,7 @@ config ARM64 select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_ERROR_INJECTION - select HAVE_FUNCTION_GRAPH_TRACER + select HAVE_FUNCTION_GRAPH_TRACER if !SHADOW_CALL_STACK select HAVE_GCC_PLUGINS select HAVE_HW_BREAKPOINT if PERF_EVENTS select HAVE_IRQ_TIME_ACCOUNTING
With CONFIG_FUNCTION_GRAPH_TRACER, function return addresses are modified in ftrace_graph_caller and prepare_ftrace_return to redirect control flow to ftrace_return_to_handler. This is incompatible with SCS. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> --- arch/arm64/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)