Re: [PATCHv6 perf/core 10/22] uprobes/x86: Add support to optimize uprobes

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Wed, 2025-08-20 at 19:12 +0200, Peter Zijlstra wrote:
> > Are we effectively allowing arbitrary shadow stack push here? 
> 
> Yeah, why not? Userspace shadow stacks does not, and cannot, protect
> from the kernel being funneh. It fully relies on the kernel being
> trusted. So the kernel doing a shstk_{pop,push}() to make things line up
> properly shouldn't be a problem.

Emulating a call/ret should be fine.

> 
> > I see we need to be in in_uprobe_trampoline(), but there is no mmap
> > lock taken, so it's a racy check.
> 
> Racy how? Isn't this more or less equivalent to what a normal CALL
> instruction would do?

Racy in terms of the "is trampoline" check happening before the write to the
shadow stack. I was thinking like a TOCTOU thing. The "Allow execution only from
uprobe trampolines" check is not very strong.

As for call equivalence, args.retaddr comes from userspace, right?

> 
> > I'm questioning if the security posture tweak is worth thinking about for
> > whatever the level of intersection of uprobes usage and shadow stack is
> > today.
> 
> I have no idea how much code is built with shadow stack enabled today;
> but I see no point in not supporting uprobes on it. The whole of
> userspace shadow stacks only ever protects from userspace attacking
> other userspace -- and that protection isn't changed by this.

Isn't this just about whether to support an optimization for uprobes?