All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Wang ShaoBo <bobo.shaobowang@huawei.com>,
	cj.chengjian@huawei.com, huawei.libin@huawei.com,
	xiexiuqi@huawei.com, liwei391@huawei.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	will@kernel.org, zengshun.wu@outlook.com,
	Jiri Olsa <jolsa@kernel.org>
Subject: Re: [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines
Date: Wed, 11 May 2022 23:34:50 +0900	[thread overview]
Message-ID: <20220511233450.40136cdf6a53eb32cd825be8@kernel.org> (raw)
In-Reply-To: <20220510104446.6d23b596@gandalf.local.home>

On Tue, 10 May 2022 10:44:46 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 10 May 2022 18:10:12 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > >
> > > This was suggested by both Peter Zijlstra and Thomas Gleixner when I
> > > introduced FTRACE_WITH_ARGS, where all functions can now get the arguments
> > > from fregs, but not the full pt_regs.  
> > 
> > Hmm, I thought the ftrace_get_regs() is the all-or-nothing interface, or
> > is there any way to get the arguments from fregs?
> 
> Not yet generically. But that can easily be added. If you look at x86 live
> patching, since it is arch specific, it just took the regs parameter
> directly, knowing that the args were already set up. That is, ftrace_regs is
> just a wrapper around pt_regs with just the regs for the arguments and stack
> initialized. If you get regs from ftrace_get_regs(fregs) it will return
> NULL if it wasn't full set of regs. But we can add generic functions to get
> the parameters.
> 
> That is, we can create a ftrace_get_kernel_argument() function that takes
> fregs instead of pt_regs, and produce the same thing as
> regs_get_kernel_argument().
> 
> x86 live kernel patching has this:
> 
> arch/x86/include/asm/ftrace.h:
> 
>  #define ftrace_instruction_pointer_set(fregs, _ip)     \
>        do { (fregs)->regs.ip = (_ip); } while (0)
> 
> 
> arch/x86/include/asm/livepatch.h:
> 
>  static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned long ip)
>  {
>         ftrace_instruction_pointer_set(fregs, ip);
>  }
> 
> Where fregs is not a full set of regs.

OK, so fregs::regs will have a subset of pt_regs, and accessibility of
the registers depends on the architecture. If we can have a checker like

ftrace_regs_exist(fregs, reg_offset)

kprobe on ftrace or fprobe user (BPF) can filter user's requests.
I think I can introduce a flag for kprobes so that user can make a
kprobe handler only using a subset of registers. 
Maybe similar filter code is also needed for BPF 'user space' library
because this check must be done when compiling BPF.

Thank you,


> > 
> > > If a ftrace_ops has the REGS flag set
> > > (using ftrace_regs_caller), the ftrace_get_regs(fregs) will return the
> > > pt_regs, or it will return NULL if ftrace_regs_caller was not used.
> > > 
> > > This way the same parameter can provide full pt_regs or a subset, and have
> > > an generic interface to tell the difference.  
> > 
> > If it can provide a partial (subset of) pt_regs, that could be good for me
> > too, since at least kprobe-events on ftrace can check the traced register
> > is in the subset or not and reject it if it doesn't saved.
> 
> That's exactly the use case for ftrace_regs.
> 
> -- Steve


-- 
Masami Hiramatsu <mhiramat@kernel.org>

WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Wang ShaoBo <bobo.shaobowang@huawei.com>,
	cj.chengjian@huawei.com, huawei.libin@huawei.com,
	xiexiuqi@huawei.com, liwei391@huawei.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	will@kernel.org, zengshun.wu@outlook.com,
	Jiri Olsa <jolsa@kernel.org>
Subject: Re: [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines
Date: Wed, 11 May 2022 23:34:50 +0900	[thread overview]
Message-ID: <20220511233450.40136cdf6a53eb32cd825be8@kernel.org> (raw)
In-Reply-To: <20220510104446.6d23b596@gandalf.local.home>

On Tue, 10 May 2022 10:44:46 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 10 May 2022 18:10:12 +0900
> Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > >
> > > This was suggested by both Peter Zijlstra and Thomas Gleixner when I
> > > introduced FTRACE_WITH_ARGS, where all functions can now get the arguments
> > > from fregs, but not the full pt_regs.  
> > 
> > Hmm, I thought the ftrace_get_regs() is the all-or-nothing interface, or
> > is there any way to get the arguments from fregs?
> 
> Not yet generically. But that can easily be added. If you look at x86 live
> patching, since it is arch specific, it just took the regs parameter
> directly, knowing that the args were already set up. That is, ftrace_regs is
> just a wrapper around pt_regs with just the regs for the arguments and stack
> initialized. If you get regs from ftrace_get_regs(fregs) it will return
> NULL if it wasn't full set of regs. But we can add generic functions to get
> the parameters.
> 
> That is, we can create a ftrace_get_kernel_argument() function that takes
> fregs instead of pt_regs, and produce the same thing as
> regs_get_kernel_argument().
> 
> x86 live kernel patching has this:
> 
> arch/x86/include/asm/ftrace.h:
> 
>  #define ftrace_instruction_pointer_set(fregs, _ip)     \
>        do { (fregs)->regs.ip = (_ip); } while (0)
> 
> 
> arch/x86/include/asm/livepatch.h:
> 
>  static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned long ip)
>  {
>         ftrace_instruction_pointer_set(fregs, ip);
>  }
> 
> Where fregs is not a full set of regs.

OK, so fregs::regs will have a subset of pt_regs, and accessibility of
the registers depends on the architecture. If we can have a checker like

ftrace_regs_exist(fregs, reg_offset)

kprobe on ftrace or fprobe user (BPF) can filter user's requests.
I think I can introduce a flag for kprobes so that user can make a
kprobe handler only using a subset of registers. 
Maybe similar filter code is also needed for BPF 'user space' library
because this check must be done when compiling BPF.

Thank you,


> > 
> > > If a ftrace_ops has the REGS flag set
> > > (using ftrace_regs_caller), the ftrace_get_regs(fregs) will return the
> > > pt_regs, or it will return NULL if ftrace_regs_caller was not used.
> > > 
> > > This way the same parameter can provide full pt_regs or a subset, and have
> > > an generic interface to tell the difference.  
> > 
> > If it can provide a partial (subset of) pt_regs, that could be good for me
> > too, since at least kprobe-events on ftrace can check the traced register
> > is in the subset or not and reject it if it doesn't saved.
> 
> That's exactly the use case for ftrace_regs.
> 
> -- Steve


-- 
Masami Hiramatsu <mhiramat@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-11 14:35 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 10:01 [RFC PATCH -next v2 0/4] arm64/ftrace: support dynamic trampoline Wang ShaoBo
2022-03-16 10:01 ` Wang ShaoBo
2022-03-16 10:01 ` [RFC PATCH -next v2 1/4] arm64: introduce aarch64_insn_gen_load_literal Wang ShaoBo
2022-03-16 10:01   ` Wang ShaoBo
2022-03-16 10:01 ` [RFC PATCH -next v2 2/4] arm64/ftrace: introduce ftrace dynamic trampoline entrances Wang ShaoBo
2022-03-16 10:01   ` Wang ShaoBo
2022-03-16 10:01 ` [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines Wang ShaoBo
2022-03-16 10:01   ` Wang ShaoBo
2022-04-21 13:10   ` Mark Rutland
2022-04-21 13:10     ` Mark Rutland
2022-04-21 14:06     ` Steven Rostedt
2022-04-21 14:06       ` Steven Rostedt
2022-04-21 14:08       ` Steven Rostedt
2022-04-21 14:08         ` Steven Rostedt
2022-04-21 15:14       ` Mark Rutland
2022-04-21 15:14         ` Mark Rutland
2022-04-21 15:42         ` Steven Rostedt
2022-04-21 15:42           ` Steven Rostedt
2022-04-21 16:27           ` Mark Rutland
2022-04-21 16:27             ` Mark Rutland
2022-04-21 17:06             ` Steven Rostedt
2022-04-21 17:06               ` Steven Rostedt
2022-04-22 10:12               ` Mark Rutland
2022-04-22 10:12                 ` Mark Rutland
2022-04-22 15:45                 ` Steven Rostedt
2022-04-22 15:45                   ` Steven Rostedt
2022-04-22 17:27                   ` Mark Rutland
2022-04-22 17:27                     ` Mark Rutland
2022-04-26  8:47                     ` Masami Hiramatsu
2022-04-26  8:47                       ` Masami Hiramatsu
2022-05-04 10:24                       ` Mark Rutland
2022-05-04 10:24                         ` Mark Rutland
2022-05-05  3:15                         ` Masami Hiramatsu
2022-05-05  3:15                           ` Masami Hiramatsu
2022-05-09 18:22                           ` Steven Rostedt
2022-05-09 18:22                             ` Steven Rostedt
2022-05-10  9:10                             ` Masami Hiramatsu
2022-05-10  9:10                               ` Masami Hiramatsu
2022-05-10 14:44                               ` Steven Rostedt
2022-05-10 14:44                                 ` Steven Rostedt
2022-05-11 14:34                                 ` Masami Hiramatsu [this message]
2022-05-11 14:34                                   ` Masami Hiramatsu
2022-05-11 15:12                                   ` Steven Rostedt
2022-05-11 15:12                                     ` Steven Rostedt
2022-05-12 12:02                                     ` Masami Hiramatsu
2022-05-12 12:02                                       ` Masami Hiramatsu
2022-05-12 13:50                                       ` Steven Rostedt
2022-05-12 13:50                                         ` Steven Rostedt
2022-05-25 12:17                                       ` Mark Rutland
2022-05-25 12:17                                         ` Mark Rutland
2022-05-25 13:43                                         ` Steven Rostedt
2022-05-25 13:43                                           ` Steven Rostedt
2022-05-25 17:12                                           ` Mark Rutland
2022-05-25 17:12                                             ` Mark Rutland
2022-05-30  1:03                                         ` Masami Hiramatsu
2022-05-30  1:03                                           ` Masami Hiramatsu
2022-05-30 12:38                                           ` Jiri Olsa
2022-05-30 12:38                                             ` Jiri Olsa
2022-05-31  1:00                                             ` Masami Hiramatsu
2022-05-31  1:00                                               ` Masami Hiramatsu
2022-05-04 12:43               ` Mark Rutland
2022-05-04 12:43                 ` Mark Rutland
2022-05-05  2:57             ` Wangshaobo (bobo)
2022-05-05  2:57               ` Wangshaobo (bobo)
2022-05-25 12:27               ` Mark Rutland
2022-05-25 12:27                 ` Mark Rutland
2022-04-27  8:54       ` Wangshaobo (bobo)
2022-04-27  8:54         ` Wangshaobo (bobo)
2022-03-16 10:01 ` [RFC PATCH -next v2 4/4] arm64/ftrace: implement long jump for dynamic trampolines Wang ShaoBo
2022-03-16 10:01   ` Wang ShaoBo
2022-04-21 13:47   ` Mark Rutland
2022-04-21 13:47     ` Mark Rutland
2022-03-16 14:29 ` [RFC PATCH -next v2 0/4] arm64/ftrace: support dynamic trampoline Steven Rostedt
2022-03-16 14:29   ` Steven Rostedt
2022-04-20 18:11 ` Steven Rostedt
2022-04-20 18:11   ` Steven Rostedt
2022-04-21  1:13   ` Wangshaobo (bobo)
2022-04-21  1:13     ` Wangshaobo (bobo)
2022-04-21 12:37     ` Steven Rostedt
2022-04-21 12:37       ` Steven Rostedt
2022-05-25 12:45       ` Mark Rutland
2022-05-25 12:45         ` Mark Rutland
2022-05-25 13:58         ` Steven Rostedt
2022-05-25 13:58           ` Steven Rostedt
2022-05-25 17:26           ` Mark Rutland
2022-05-25 17:26             ` Mark Rutland
2022-04-21 12:53 ` Mark Rutland
2022-04-21 12:53   ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220511233450.40136cdf6a53eb32cd825be8@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=bobo.shaobowang@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=cj.chengjian@huawei.com \
    --cc=huawei.libin@huawei.com \
    --cc=jolsa@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwei391@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=will@kernel.org \
    --cc=xiexiuqi@huawei.com \
    --cc=zengshun.wu@outlook.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.