linux-kernel - Re: [PATCH v2 08/11] kcov: add ioctl(KCOV_UNIQUE

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: <20250627082730.GS1613200@noisy.programming.kicks-ass.net>
Date: Fri, 27 Jun 2025 10:27:30 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Alexander Potapenko <glider@...gle.com>
Cc: quic_jiangenj@...cinc.com, linux-kernel@...r.kernel.org,
	kasan-dev@...glegroups.com, Aleksandr Nogikh <nogikh@...gle.com>,
	Andrey Konovalov <andreyknvl@...il.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Dmitry Vyukov <dvyukov@...gle.com>, Ingo Molnar <mingo@...hat.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Marco Elver <elver@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 08/11] kcov: add ioctl(KCOV_UNIQUE_ENABLE)

On Thu, Jun 26, 2025 at 03:41:55PM +0200, Alexander Potapenko wrote:
> ioctl(KCOV_UNIQUE_ENABLE) enables collection of deduplicated coverage
> in the presence of CONFIG_KCOV_ENABLE_GUARDS.
> 
> The buffer shared with the userspace is divided in two parts, one holding
> a bitmap, and the other one being the trace. The single parameter of
> ioctl(KCOV_UNIQUE_ENABLE) determines the number of words used for the
> bitmap.
> 
> Each __sanitizer_cov_trace_pc_guard() instrumentation hook receives a
> pointer to a unique guard variable. Upon the first call of each hook,
> the guard variable is initialized with a unique integer, which is used to
> map those hooks to bits in the bitmap. In the new coverage collection mode,
> the kernel first checks whether the bit corresponding to a particular hook
> is set, and then, if it is not, the PC is written into the trace buffer,
> and the bit is set.

I am somewhat confused; the clang documentation states that every edge
will have a guard variable.

So if I have code like:

foo:	Jcc	foobar
...
bar:	Jcc	foobar
...
foobar:

Then we get two guard variables for the one foobar target?

But from a coverage PoV you don't particularly care about the edges; you
only care you hit the instruction. Combined with the naming of the hook:
'trace_pc_guard', which reads to me like: program-counter guard, suggesting
the guard is in fact per PC or target node, not per edge.

So which is it?

Also, dynamic edges are very hard to allocate guard variables for, while
target guards are trivial, even in the face of dynamic edges.

A further consideration is that the number of edges can vastly outnumber
the number of nodes, again suggesting that node guards might be better.