On Mon, Apr 15, 2024 at 1:25 AM Jiri Olsa wrote:
>
> On Tue, Apr 02, 2024 at 11:33:00AM +0200, Jiri Olsa wrote:
>
> SNIP
>
> > #include
> > #include
> > @@ -308,6 +309,88 @@ static int uprobe_init_insn(struct arch_uprobe
> > *auprobe, struct insn *insn, bool
> > }
> >
> > #ifdef
On Tue, Apr 02, 2024 at 11:33:00AM +0200, Jiri Olsa wrote:
SNIP
> #include
> #include
> @@ -308,6 +309,88 @@ static int uprobe_init_insn(struct arch_uprobe *auprobe,
> struct insn *insn, bool
> }
>
> #ifdef CONFIG_X86_64
> +
> +asm (
> + ".pushsection .rodata\n"
> + ".global
On Mon, Apr 08, 2024 at 06:22:59PM +0200, Oleg Nesterov wrote:
> On 04/08, Jiri Olsa wrote:
> >
> > On Fri, Apr 05, 2024 at 01:02:30PM +0200, Oleg Nesterov wrote:
> > >
> > > And what should sys_uretprobe() do if it is not called from the
> > > trampoline?
> > > I'd prefer force_sig(SIGILL) to
On Tue, Apr 09, 2024 at 09:34:39AM +0900, Masami Hiramatsu wrote:
SNIP
> > >
> > > > this can be fixed by checking the syscall is called from the trampoline
> > > > and prevent handle_trampoline call if it's not
> > >
> > > Yes, but I still do not think this makes a lot of sense. But I won't
On Mon, 8 Apr 2024 18:02:13 +0200
Jiri Olsa wrote:
> On Fri, Apr 05, 2024 at 01:02:30PM +0200, Oleg Nesterov wrote:
> > On 04/05, Jiri Olsa wrote:
> > >
> > > On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> > > >
> > > > I think this expects setjmp/longjmp as below
> > > >
>
On 04/08, Jiri Olsa wrote:
>
> On Fri, Apr 05, 2024 at 01:02:30PM +0200, Oleg Nesterov wrote:
> >
> > And what should sys_uretprobe() do if it is not called from the trampoline?
> > I'd prefer force_sig(SIGILL) to punish the abuser ;) OK, OK, EINVAL.
>
> so the similar behaviour with int3 ends up
On Fri, Apr 05, 2024 at 01:02:30PM +0200, Oleg Nesterov wrote:
> On 04/05, Jiri Olsa wrote:
> >
> > On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> > >
> > > I think this expects setjmp/longjmp as below
> > >
> > > foo() { <- retprobe1
> > > setjmp()
> > > bar() { <-
On Sat, 6 Apr 2024 19:55:59 +0200
Oleg Nesterov wrote:
> On 04/06, Masami Hiramatsu wrote:
> >
> > On Fri, 5 Apr 2024 13:02:30 +0200
> > Oleg Nesterov wrote:
> >
> > > With or without this patch userpace can also do
> > >
> > > foo() { <-- retprobe1
> > > bar() {
> > >
On Fri, 5 Apr 2024 10:56:15 +0200
Jiri Olsa wrote:
> >
> > Can we avoid this with below strict check?
> >
> > if (ri->stack != regs->sp + expected_offset)
> > goto sigill;
>
> hm the current uprobe 'alive' check makes sure the return_instance is above
> or at the same stack address, not
On 04/06, Masami Hiramatsu wrote:
>
> On Fri, 5 Apr 2024 13:02:30 +0200
> Oleg Nesterov wrote:
>
> > With or without this patch userpace can also do
> >
> > foo() { <-- retprobe1
> > bar() {
> > jump to xol_area
> > }
> > }
> >
> >
On Fri, 5 Apr 2024 13:02:30 +0200
Oleg Nesterov wrote:
> On 04/05, Jiri Olsa wrote:
> >
> > On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> > >
> > > I think this expects setjmp/longjmp as below
> > >
> > > foo() { <- retprobe1
> > > setjmp()
> > > bar() { <- retprobe2
>
On 04/05, Jiri Olsa wrote:
>
> On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> >
> > I think this expects setjmp/longjmp as below
> >
> > foo() { <- retprobe1
> > setjmp()
> > bar() { <- retprobe2
> > longjmp()
> > }
> > } <- return to trampoline
> >
> >
On Fri, Apr 05, 2024 at 10:22:03AM +0900, Masami Hiramatsu wrote:
> On Thu, 4 Apr 2024 18:11:09 +0200
> Oleg Nesterov wrote:
>
> > On 04/05, Masami Hiramatsu wrote:
> > >
> > > Can we make this syscall and uprobe behavior clearer? As you said, if
> > > the application use sigreturn or longjump,
On Thu, 4 Apr 2024 18:11:09 +0200
Oleg Nesterov wrote:
> On 04/05, Masami Hiramatsu wrote:
> >
> > Can we make this syscall and uprobe behavior clearer? As you said, if
> > the application use sigreturn or longjump, it may skip returns and
> > shadow stack entries are left in the kernel. In such
On 04/05, Masami Hiramatsu wrote:
>
> Can we make this syscall and uprobe behavior clearer? As you said, if
> the application use sigreturn or longjump, it may skip returns and
> shadow stack entries are left in the kernel. In such cases, can uretprobe
> detect it properly, or just crash the
On Thu, 4 Apr 2024 13:58:43 +0200
Jiri Olsa wrote:
> On Wed, Apr 03, 2024 at 07:00:07PM -0700, Andrii Nakryiko wrote:
>
> SNIP
>
> > Check rt_sigreturn syscall (manpage at [0], for example).
> >
> >sigreturn() exists only to allow the implementation of signal
> >handlers. It
On Wed, 3 Apr 2024 19:00:07 -0700
Andrii Nakryiko wrote:
> On Wed, Apr 3, 2024 at 5:58 PM Masami Hiramatsu wrote:
> >
> > On Wed, 3 Apr 2024 09:58:12 -0700
> > Andrii Nakryiko wrote:
> >
> > > On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu
> > > wrote:
> > > >
> > > > On Wed, 3 Apr 2024
On Wed, Apr 03, 2024 at 07:00:07PM -0700, Andrii Nakryiko wrote:
SNIP
> Check rt_sigreturn syscall (manpage at [0], for example).
>
>sigreturn() exists only to allow the implementation of signal
>handlers. It should never be called directly. (Indeed, a simple
>
On Wed, Apr 3, 2024 at 5:58 PM Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 09:58:12 -0700
> Andrii Nakryiko wrote:
>
> > On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
> > >
> > > On Wed, 3 Apr 2024 11:47:41 +0200
> > > Jiri Olsa wrote:
> > >
> > > > On Wed, Apr 03, 2024 at
On Wed, 3 Apr 2024 09:58:12 -0700
Andrii Nakryiko wrote:
> On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
> >
> > On Wed, 3 Apr 2024 11:47:41 +0200
> > Jiri Olsa wrote:
> >
> > > On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> > > > Hi Jiri,
> > > >
> > > > On Tue,
On Wed, Apr 3, 2024 at 7:09 AM Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 11:47:41 +0200
> Jiri Olsa wrote:
>
> > On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> > > Hi Jiri,
> > >
> > > On Tue, 2 Apr 2024 11:33:00 +0200
> > > Jiri Olsa wrote:
> > >
> > > > Adding
Again, I leave this to you and Jiri, but
On 04/03, Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 11:47:41 +0200
> > > set in the user function, what happen if the user function directly
> > > calls this syscall? (maybe it consumes shadow stack?)
> >
> > the process should receive SIGILL if
On Wed, 3 Apr 2024 11:47:41 +0200
Jiri Olsa wrote:
> On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> > Hi Jiri,
> >
> > On Tue, 2 Apr 2024 11:33:00 +0200
> > Jiri Olsa wrote:
> >
> > > Adding uretprobe syscall instead of trap to speed up return probe.
> >
> > This is
I leave this to you and Masami, but...
On 04/03, Jiri Olsa wrote:
>
> On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> >
> > This is interesting approach. But I doubt we need to add additional
> > syscall just for this purpose. Can't we use another syscall or ioctl?
>
> so the
On Wed, Apr 03, 2024 at 10:07:08AM +0900, Masami Hiramatsu wrote:
> Hi Jiri,
>
> On Tue, 2 Apr 2024 11:33:00 +0200
> Jiri Olsa wrote:
>
> > Adding uretprobe syscall instead of trap to speed up return probe.
>
> This is interesting approach. But I doubt we need to add additional
> syscall just
Hi Jiri,
On Tue, 2 Apr 2024 11:33:00 +0200
Jiri Olsa wrote:
> Adding uretprobe syscall instead of trap to speed up return probe.
This is interesting approach. But I doubt we need to add additional
syscall just for this purpose. Can't we use another syscall or ioctl?
Also, we should run
Adding uretprobe syscall instead of trap to speed up return probe.
At the moment the uretprobe setup/path is:
- install entry uprobe
- when the uprobe is hit, it overwrites probed function's return address
on stack with address of the trampoline that contains breakpoint
instruction
27 matches
Mail list logo