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: <447af60b944e0f7a8ddf012973029430af834b2e.camel@intel.com>
Date: Wed, 20 Aug 2025 18:04:10 +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:43 +0200, Peter Zijlstra wrote:
> Yes. But supporting the shstk isn't hard (as per this patch), it exactly
> matches what it already does to the normal stack. So I don't see a
> reason not to do it.

Thanks for explaining, and sorry for being slow. Going to blame this head cold.

> 
> Anyway, I'm not a huge fan of any of this. I suspect FRED will make all
> this fancy code totally irrelevant. But until people have FRED enabled
> hardware in large quantities, I suppose this has a use.

It doesn't sound too unbounded and I guess as long as it's just an optimization
we can always back it out if someone finds a way to abuse it.