linux-kernel - Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace

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: <24E50A07-EC58-4864-9DB3-E5DB869AD030@gmail.com>
Date: Fri, 29 Aug 2025 14:57:57 -0300
From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Steven Rostedt <rostedt@...dmis.org>
CC: Steven Rostedt <rostedt@...nel.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org, x86@...nel.org,
 Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
 Andrii Nakryiko <andrii@...nel.org>, Indu Bhagat <indu.bhagat@...cle.com>,
 "Jose E. Marchesi" <jemarch@....org>,
 Beau Belgrave <beaub@...ux.microsoft.com>, Jens Remus <jremus@...ux.ibm.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Florian Weimer <fweimer@...hat.com>, Sam James <sam@...too.org>,
 Kees Cook <kees@...nel.org>, Carlos O'Donell <codonell@...hat.com>
Subject: Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace

On August 29, 2025 2:13:33 PM GMT-03:00, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>On Fri, 29 Aug 2025 at 10:02, Steven Rostedt <rostedt@...dmis.org> wrote:
>>
>> Note, the ring buffer can be mapped to user space. So anything written into
>> the buffer is already exposed.
>
>Oh, good point. Yeah, that means that you have to do the hashing
>immediately. Too bad. Because while 'vma->vm_file' is basically free
>(since you have to access the vma for other reasons anyway), a good
>hash isn't.

Can't we continue with that idea by using some VMA sequential number that don't expose anything critical to user space but allows us to match stack entries to mmap records?

Deferring the heavily lift to when needed is great.

- Arnaldo 

>
>siphash is good and fast for being what it is, but it's not completely
>free. It's something like 50 shift/xor pairs, and it obviously needs
>to also access that secret hash value that is likely behind a cache
>miss..
>
>Still, I suspect it's the best we've got.
>
>(If hashing is noticeable, it *might* be worth it to use
>'siphash_1u32()' and only hash 32 bits of the pointers. That makes the
>hashing slightly cheaper, and since the low bits of the pointer will
>be zero anyway due to alignment, and the high bits don't have a lot of
>information in them either, it doesn't actually remove much
>information. You might get collissions if the two pointers are exactly
>32 GB apart or whatever, but that sounds really really unlucky)
>
>                Linus

- Arnaldo