[GIT PULL] probes: Updates for v6.11

[GIT PULL] probes: Updates for v6.11

[Masami Hiramatsu]

Hi Linus,

Probes updates for v6.11:

Uprobes:
- x86/shstk: Make return uprobe work with shadow stack.
- Add uretprobe syscall which speeds up the uretprobe 10-30% faster. This
  syscall is automatically used from user-space trampolines which are
  generated by the uretprobe. If this syscall is used by normal
  user program, it will cause SIGILL. Note that this is currently only
  implemented on x86_64.
  (This also has 2 fixes for adjusting the syscall number to avoid conflict
   with new *attrat syscalls.)
- uprobes/perf: fix user stack traces in the presence of pending uretprobe.
  This corrects the uretprobe's trampoline address in the stacktrace with
  correct return address.
- selftests/x86: Add a return uprobe with shadow stack test.
- selftests/bpf: Add uretprobe syscall related tests.
  . test case for register integrity check.
  . test case with register changing case.
  . test case for uretprobe syscall without uprobes (expected to be failed).
  . test case for uretprobe with shadow stack.
- selftests/bpf: add test validating uprobe/uretprobe stack traces
- MAINTAINERS: Add uprobes entry. This does not specify the tree but to
  clarify who maintains and reviews the uprobes.

Kprobes:
- tracing/kprobes: Test case cleanups. Replace redundant WARN_ON_ONCE() +
  pr_warn() with WARN_ONCE() and remove unnecessary code from selftest.
- tracing/kprobes: Add symbol counting check when module loads. This
  checks the uniqueness of the probed symbol on modules. The same check
  has already done for kernel symbols.
  (This also has a fix for build error with CONFIG_MODULES=n)

Cleanup:
- Add MODULE_DESCRIPTION() macros for fprobe and kprobe examples.


Please pull the latest probes-v6.11 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
probes-v6.11

Tag SHA1: aa4c31f7638918b4fe22ccea2bc9469721ee95cd
Head SHA1: c26b1b89b8a9fd8665e79cd798bd970e233772b6


Andrii Nakryiko (2):
      perf,uprobes: fix user stack traces in the presence of pending uretprobes
      selftests/bpf: add test validating uprobe/uretprobe stack traces

Jeff Johnson (2):
      fprobe: add missing MODULE_DESCRIPTION() macro
      samples: kprobes: add missing MODULE_DESCRIPTION() macros

Jiri Olsa (10):
      x86/shstk: Make return uprobe work with shadow stack
      uprobe: Wire up uretprobe system call
      uprobe: Add uretprobe syscall to speed up return probe
      selftests/x86: Add return uprobe shadow stack test
      selftests/bpf: Add uretprobe syscall test for regs integrity
      selftests/bpf: Add uretprobe syscall test for regs changes
      selftests/bpf: Add uretprobe syscall call from user space test
      selftests/bpf: Add uretprobe shadow stack test
      uprobe: Change uretprobe syscall scope and number
      selftests/bpf: Change uretprobe syscall number in uprobe_syscall test

Masami Hiramatsu (Google) (5):
      tracing/kprobe: Integrate test warnings into WARN_ONCE
      tracing/kprobe: Remove cleanup code unrelated to selftest
      tracing/kprobes: Add symbol counting check when module loads
      tracing/kprobes: Fix build error when find_module() is not available
      MAINTAINERS: Add uprobes entry

----
 MAINTAINERS                                        |  13 +
 arch/x86/entry/syscalls/syscall_64.tbl             |   1 +
 arch/x86/include/asm/shstk.h                       |   4 +
 arch/x86/kernel/shstk.c                            |  16 +
 arch/x86/kernel/uprobes.c                          | 124 ++++++-
 include/linux/syscalls.h                           |   2 +
 include/linux/uprobes.h                            |   3 +
 include/uapi/asm-generic/unistd.h                  |   5 +-
 kernel/events/callchain.c                          |  43 ++-
 kernel/events/uprobes.c                            |  33 +-
 kernel/sys_ni.c                                    |   2 +
 kernel/trace/trace_kprobe.c                        | 192 +++++-----
 samples/fprobe/fprobe_example.c                    |   1 +
 samples/kprobes/kprobe_example.c                   |   1 +
 samples/kprobes/kretprobe_example.c                |   1 +
 tools/include/linux/compiler.h                     |   4 +
 .../selftests/bpf/bpf_testmod/bpf_testmod.c        | 123 ++++++-
 .../selftests/bpf/prog_tests/uprobe_syscall.c      | 385 +++++++++++++++++++++
 .../selftests/bpf/prog_tests/uretprobe_stack.c     | 186 ++++++++++
 tools/testing/selftests/bpf/progs/uprobe_syscall.c |  15 +
 .../selftests/bpf/progs/uprobe_syscall_executed.c  |  17 +
 .../testing/selftests/bpf/progs/uretprobe_stack.c  |  96 +++++
 tools/testing/selftests/x86/test_shadow_stack.c    | 145 ++++++++
 23 files changed, 1320 insertions(+), 92 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/uretprobe_stack.c
 create mode 100644 tools/testing/selftests/bpf/progs/uprobe_syscall.c
 create mode 100644 tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c
 create mode 100644 tools/testing/selftests/bpf/progs/uretprobe_stack.c

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [GIT PULL] probes: Updates for v6.11

[pr-tracker-bot]

The pull request you sent on Tue, 16 Jul 2024 23:44:45 +0900:

> git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git probes-v6.11

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/91bd008d4e2b4962ecb9a10e40c2fb666b0aeb92

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] probes: Updates for v6.11

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

Hi Linus,

On Tue, 16 Jul 2024 23:44:45 +0900 Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> Probes updates for v6.11:
> 
> Uprobes:
> - x86/shstk: Make return uprobe work with shadow stack.
> - Add uretprobe syscall which speeds up the uretprobe 10-30% faster. This
>   syscall is automatically used from user-space trampolines which are
>   generated by the uretprobe. If this syscall is used by normal
>   user program, it will cause SIGILL. Note that this is currently only
>   implemented on x86_64.
>   (This also has 2 fixes for adjusting the syscall number to avoid conflict
>    with new *attrat syscalls.)

But another fix that I have been carrying was missed:

https://lore.kernel.org/lkml/20240717132155.6ca2ce47@canb.auug.org.au/

Just the added change to scripts/syscall.tbl (and obviously needs
adjusting because the *xattrat* syscalss have not been merged yet).
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] probes: Updates for v6.11

[Linus Torvalds]

On Thu, 18 Jul 2024 at 17:28, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> But another fix that I have been carrying was missed:

Hmm. I'm starting to absolutely hate that "generic" syscall.tbl file,
and it was literally merged just two days ago.

That may not be a new record - I'm sure there have been other things
that I started hating even more quickly - but it's certainly up there
with the best (worst?) of them.

It's now come up twice in just this merge window for different
reasons, and I think both cases showed that it's just fundamentally
bogus.

There are system calls that are architecture-specific (the whole vdso
thing), and nothing is ever going to change that.

Others may not be as fundamentally tied to certain architectures -
like this uprobes thing - but will simply be introduced at different
times because they still need possibly a lot of architecture support.

So considering that it was added this merge window, and already is
showing all these issues before the merge window is even over, I'm not
at all convinced "scripts/syscall.tbl" has a future.

Now, I do think we should strive to unify the system call table
generation under one syntax. I don't think *that* is a bad idea.

But I'm not AT ALL convinced we should strive to unify the numbering,
and do it in one file.

In fact, I think that the numbering should not exist at all in that
"unified table syntax", because the number itself is causing problems.

That whole "the numbers themselves are a problem" is not a new issue,
we've seen all these silly renumbering issues forever, just look at
something like this:

  git log --oneline --merges --cc arch/x86/entry/syscalls/syscall_64.tbl

and that's with people often _trying_ to work together.  So I think
'scripts/syscall.tbl' is actively detrimental, because it introduces
*new* problems, and it doesn't actually solve that *old* problem.

So I think this needs to be re-visited.

One possible model might be:

 - remove the numbering from the syscall.tbl (because the numbers
_are_ going to be different)

 - make it really easy to add actual generic new system calls in one
place, for when the system call is NOT something that needs
architecture-specific trampolines and stuff

 - make the common infrastructure generate the numbers

because I think the current model of "let's share a table with
numbers" is already dead in the water before we have even completed a
single merge window with it.

Other ideas? Arnd?

             Linus

Re: [GIT PULL] probes: Updates for v6.11

[Linus Torvalds]

On Thu, 18 Jul 2024 at 17:49, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> One possible model might be:
>
>  - remove the numbering from the syscall.tbl (because the numbers
> _are_ going to be different)

Just to clarify: the way I envision this "remove the numbering" is to
just make the numbering itself be the result of running scripts on the
system call table files.

And then different architectures could have different areas for "these
are the generic system calls" (and some kind of support to 'include' a
common file listing those), and the "these are my own system calls"
area.

x86 kind of has some of that kind of thing with the whole "system
calls above 512 are magic for x32".

Of course, *that* then failed too, but I don't think the concept is
necessarily completely broken.

             Linus

Re: [GIT PULL] probes: Updates for v6.11

[Masami Hiramatsu]

On Fri, 19 Jul 2024 10:28:24 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Linus,
> 
> On Tue, 16 Jul 2024 23:44:45 +0900 Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> >
> > Probes updates for v6.11:
> > 
> > Uprobes:
> > - x86/shstk: Make return uprobe work with shadow stack.
> > - Add uretprobe syscall which speeds up the uretprobe 10-30% faster. This
> >   syscall is automatically used from user-space trampolines which are
> >   generated by the uretprobe. If this syscall is used by normal
> >   user program, it will cause SIGILL. Note that this is currently only
> >   implemented on x86_64.
> >   (This also has 2 fixes for adjusting the syscall number to avoid conflict
> >    with new *attrat syscalls.)
> 
> But another fix that I have been carrying was missed:
> 
> https://lore.kernel.org/lkml/20240717132155.6ca2ce47@canb.auug.org.au/
> 
> Just the added change to scripts/syscall.tbl (and obviously needs
> adjusting because the *xattrat* syscalss have not been merged yet).

Ah, I thought that was for helping Linus when he merge the commits.
And actually, this number is used in other part (e.g. testing), I added it.
When xattarat syscalls are merged (until -rc1?), this difference is solved,
isn't it?

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [GIT PULL] probes: Updates for v6.11

[Masami Hiramatsu]

On Fri, 19 Jul 2024 10:28:24 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Linus,
> 
> On Tue, 16 Jul 2024 23:44:45 +0900 Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> >
> > Probes updates for v6.11:
> > 
> > Uprobes:
> > - x86/shstk: Make return uprobe work with shadow stack.
> > - Add uretprobe syscall which speeds up the uretprobe 10-30% faster. This
> >   syscall is automatically used from user-space trampolines which are
> >   generated by the uretprobe. If this syscall is used by normal
> >   user program, it will cause SIGILL. Note that this is currently only
> >   implemented on x86_64.
> >   (This also has 2 fixes for adjusting the syscall number to avoid conflict
> >    with new *attrat syscalls.)
> 
> But another fix that I have been carrying was missed:
> 
> https://lore.kernel.org/lkml/20240717132155.6ca2ce47@canb.auug.org.au/
> 
> Just the added change to scripts/syscall.tbl (and obviously needs
> adjusting because the *xattrat* syscalss have not been merged yet).

Ah, I missed "script/syscall.tbl". Yes, I need to update it to reserve
the syscall number on it. (But that did not exist on my tree...) I'll send
a fix. BTW should I wait for xattrat series being merged?

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [GIT PULL] probes: Updates for v6.11

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Hi Masami,

On Fri, 19 Jul 2024 10:52:42 +0900 Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> Ah, I missed "script/syscall.tbl". Yes, I need to update it to reserve
> the syscall number on it. (But that did not exist on my tree...) I'll send
> a fix. BTW should I wait for xattrat series being merged?

No need to wait.  At worst it will cause a minor conflict.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [GIT PULL] probes: Updates for v6.11

[Masami Hiramatsu]

On Fri, 19 Jul 2024 14:44:55 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Masami,
> 
> On Fri, 19 Jul 2024 10:52:42 +0900 Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> >
> > Ah, I missed "script/syscall.tbl". Yes, I need to update it to reserve
> > the syscall number on it. (But that did not exist on my tree...) I'll send
> > a fix. BTW should I wait for xattrat series being merged?
> 
> No need to wait.  At worst it will cause a minor conflict.

OK, here is the fix.

From 5c28424e9a348f95e3c634fe2ed6da8af29cc870 Mon Sep 17 00:00:00 2001
From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Date: Fri, 19 Jul 2024 14:35:51 +0900
Subject: [PATCH] syscalls: Fix to add sys_uretprobe to syscall.tbl

Add sys_uretprobe entry to scripts/syscall.tbl as same as
arch/x86/entry/syscalls/syscall_64.tbl.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/all/20240719102824.1e086a40@canb.auug.org.au/
Fixes: 63ded110979b ("uprobe: Change uretprobe syscall scope and number")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
 scripts/syscall.tbl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/syscall.tbl b/scripts/syscall.tbl
index 797e20ea99a2..591d85e8ca7e 100644
--- a/scripts/syscall.tbl
+++ b/scripts/syscall.tbl
@@ -402,3 +402,4 @@
 460	common	lsm_set_self_attr		sys_lsm_set_self_attr
 461	common	lsm_list_modules		sys_lsm_list_modules
 462	common	mseal				sys_mseal
+467	common	uretprobe			sys_uretprobe
-- 
2.34.1


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

Re: [GIT PULL] probes: Updates for v6.11

[Arnd Bergmann]

On Fri, Jul 19, 2024, at 02:49, Linus Torvalds wrote:
> On Thu, 18 Jul 2024 at 17:28, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> There are system calls that are architecture-specific (the whole vdso
> thing), and nothing is ever going to change that.
>
> Others may not be as fundamentally tied to certain architectures -
> like this uprobes thing - but will simply be introduced at different
> times because they still need possibly a lot of architecture support.
>
> So considering that it was added this merge window, and already is
> showing all these issues before the merge window is even over, I'm not
> at all convinced "scripts/syscall.tbl" has a future.
>
> Now, I do think we should strive to unify the system call table
> generation under one syntax. I don't think *that* is a bad idea.
>
> But I'm not AT ALL convinced we should strive to unify the numbering,
> and do it in one file.

The unified syntax is all that is new though, the unified numbering
is what we've been doing since the time32 syscalls (403+) in 2019.

The unified table across all /new/ architectures has been in place
since e64a1617eca3 ("asm-generic: add a generic unistd.h") back
in 2009, so the eight newest architectures, plus a few that have
come and gone again, have been sharing the same numbers for
the past 15 years.

> In fact, I think that the numbering should not exist at all in that
> "unified table syntax", because the number itself is causing problems.
>
> That whole "the numbers themselves are a problem" is not a new issue,
> we've seen all these silly renumbering issues forever, just look at
> something like this:
>
>   git log --oneline --merges --cc arch/x86/entry/syscalls/syscall_64.tbl
>
> and that's with people often _trying_ to work together.  So I think
> 'scripts/syscall.tbl' is actively detrimental, because it introduces
> *new* problems, and it doesn't actually solve that *old* problem.
>
> So I think this needs to be re-visited.

The syscall.tbl file itself is just a replacement for
include/uapi/asm-generic/unistd.h, which I would like to remove
in the next step, it's already unused.

I was planning as one of the future steps to move numbers
403 through 467 into a file that is actually shared, to make
it easier to coordinate the addition of system calls:
any addition would only get added once instead of 19 times.
I have not tried implementing this yet, the open questions
here are how to handle alpha with its different numbers
(offset by 110) and x32 with the preassigned numbers 512-547.

This has always been something that others have asked me
for since we started using the syscall.tbl format on most
architectures, but I don't actually care about this part too
much, compared to other things I would like to implement
based on the syscall.tbl format like a machine-readable
ABI description that contains both the syscall numbers and
the argument types.

> One possible model might be:
>
>  - remove the numbering from the syscall.tbl (because the numbers
> _are_ going to be different)
>
>  - make it really easy to add actual generic new system calls in one
> place, for when the system call is NOT something that needs
> architecture-specific trampolines and stuff
>
>  - make the common infrastructure generate the numbers
>
> because I think the current model of "let's share a table with
> numbers" is already dead in the water before we have even completed a
> single merge window with it.
>
> Other ideas? Arnd?

I don't think we have to abandon the common numbering now, given
that this is the part that has mostly worked out fine, with
architecture specific syscalls being really rare in practice.
We have been dealing with them already for 15 years, and this
hasn't really changed with my recent patches either.

a) numbers 244 through 259 are reserved for architecture specific
   calls. A typical example of this is "cacheflush", which is
   used on four architectures. Architectures with a custom
   syscall.tlb file can instead use the available numbers below
   403 where needed.

b) clone3 is still missing on four architectures but should be
   implemented there. This used to require defining
   __ARCH_WANT_SYS_CLONE3 on all architectures, but I've turned
   it around now so architectures that are missing it instead
   define __ARCH_BROKEN_SYS_CLONE3.

c) memfd_secret is only used only on x86, arm64, riscv and s390.
   With the new table format, this now requires adding the keyword
   in arch*/kernel/Makefile.syscalls, e.g. for riscv as
   syscall_abis_32 += riscv memfd_secret
   syscall_abis_64 += riscv newstat rlimit memfd_secret

I discussed all three methods with Jiri when looking at his
uretprobe patches. I recommended using b) at the time since
I wanted to avoid the extra keyword from c), but it sounds
like you would be happier with a). If you like, I can send
a patch to move it to number 335 for x86, or you can move
it yourself if that addresses the specific problem with
the uretprobe.

      Arnd