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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <62574323ba73b0fec42a106ccc29f707b5696094.camel@intel.com>
Date: Wed, 20 Aug 2025 17:26:38 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "peterz@...radead.org" <peterz@...radead.org>
CC: "songliubraving@...com" <songliubraving@...com>, "alan.maguire@...cle.com"
	<alan.maguire@...cle.com>, "mhiramat@...nel.org" <mhiramat@...nel.org>,
	"andrii@...nel.org" <andrii@...nel.org>, "john.fastabend@...il.com"
	<john.fastabend@...il.com>, "mingo@...nel.org" <mingo@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>, "David.Laight@...lab.com"
	<David.Laight@...lab.com>, "yhs@...com" <yhs@...com>, "oleg@...hat.com"
	<oleg@...hat.com>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"thomas@...ch.de" <thomas@...ch.de>, "jolsa@...nel.org" <jolsa@...nel.org>,
	"haoluo@...gle.com" <haoluo@...gle.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCHv6 perf/core 10/22] uprobes/x86: Add support to optimize
 uprobes

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?