linux-kernel - Re: [PATCH v5 2/3] tracing: Add a tracepoint verification check at build time

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: <a1f2f201-61f9-4564-b0c8-45c4d912bd00@efficios.com>
Date: Fri, 25 Jul 2025 09:15:34 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Steven Rostedt <rostedt@...nel.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
 llvm@...ts.linux.dev
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Andrew Morton <akpm@...ux-foundation.org>, Arnd Bergmann <arnd@...db.de>,
 Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor
 <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>,
 Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
 Catalin Marinas <catalin.marinas@....com>,
 Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v5 2/3] tracing: Add a tracepoint verification check at
 build time

On 2025-07-24 22:51, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@...dmis.org>
> 
> If a tracepoint is defined via DECLARE_TRACE() or TRACE_EVENT() but never
> called (via the trace_<tracepoint>() function), its metadata is still
> around in memory and not discarded.
> 
> When created via TRACE_EVENT() the situation is worse because the
> TRACE_EVENT() creates metadata that can be around 5k per trace event.
> Having unused trace events causes several thousand of wasted bytes.
> 
> Add a verifier that injects a string of the name of the tracepoint it
> calls that is added to the discarded section "__tracepoint_check".
> For every builtin tracepoint, it's 

its

[...]

> +
> +#define for_each_shdr_str(len, ehdr, sec)	\
> +	for (const char *str = (void *)(ehdr) + shdr_offset(sec),	\
> +	                *end = (str) + shdr_size(sec);			\
> +	     len = strlen(str), (str) < end;				\
> +	     str += (len) + 1, len = strlen(str))
> +
> +static void make_trace_array(struct elf_tracepoint *etrace)
> +{
> +	Elf_Ehdr *ehdr = etrace->ehdr;
> +	const char **vals = NULL;
> +	int count = 0;
> +	int len;
> +
> +	etrace->array = NULL;
> +
> +	/*
> +	 * The __tracepoint_check section is filled with strings of the
> +	 * names of tracepoints (in tracepoint_strings). Create an array
> +	 * that points to each string and then sort the array.
> +	 */
> +	for_each_shdr_str(len, ehdr, check_data_sec) {
> +		if (!len)
> +			continue;

The len==0 case would be when this skips section alignment padding when
the linker decides to align the beginning of each .o sections, which
ends up appearing as zeroed padding within the resulting vmlinux.o
section after the individual sections have been stitched together, am I
correct ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com