linux-kernel - Re: [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol device drivers

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: <aGIvjrrSRPJQpNy7@google.com>
Date: Mon, 30 Jun 2025 06:32:46 +0000
From: Tzung-Bi Shih <tzungbi@...nel.org>
To: Daniel Latypov <dlatypov@...gle.com>
Cc: bleung@...omium.org, brendan.higgins@...ux.dev, davidgow@...gle.com,
	rmoar@...gle.com, rostedt@...dmis.org, mhiramat@...nel.org,
	naveen@...nel.org, anil.s.keshavamurthy@...el.com,
	davem@...emloft.net, chrome-platform@...ts.linux.dev,
	linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol
 device drivers

On Tue, May 20, 2025 at 09:04:53AM -0700, Daniel Latypov wrote:
> On Tue, May 20, 2025 at 1:25 AM 'Tzung-Bi Shih' via KUnit Development
> <kunit-dev@...glegroups.com> wrote:
> > [...]
> > Questions:
> > - Are we going to support ftrace stub so that tests can use it?
> >
> > - If ftrace stub isn't on the plate (e.g. due to too many dependencies), how
> >   about the kprobes stub?  Is it something we could pursue?
> 
> Quick comment,
> If I recall, the thought process was that we could consider it in the
> future if there was enough demand for it.

Sorry for the late reply. I was doing some more experiments and stuck by
some else.

> We have these drawbacks with the current ftrace stubs:
> * doesn't compile on all arches
> * silently doesn't work on inlined functions <== scariest one to me

I see. I did some experiments and realized that kprobe stubs also share
the same concern. Thus I'm wondering if there is a way that kprobe stub
detects the redirection may fail, at least it can skip the test case
(e.g. register_kprobe() returns -ENOENT when it can't find the symbol
via kprobe_lookup_name()). But it seems no way if the target function
is partially inlined.

> You mention you don't like how static stubs requires modifying the
> code-under-test.
> Since it gets eliminated by the preprocessor unless you're compiling
> for KUnit, is the concern more so about how it conceptually feels
> wrong to do so?
> For the Android GKI kernel, they have (or had) KUnit enabled so there
> is potentially concern about real runtime cost there, not sure if you
> have something similar in mind.

Not exactly. Ideally, I think we shouldn't modify the CUT. I'm wondering
if there is a way to not change the CUT but also break the external
dependencies.

> But stepping back, ftrace_stubs technically require modifying the code
> to make sure funcs are marked as `noinline`, which this patch series
> does not do.
> I've not looked at cros_ec_{un,}register() to check if they're at risk
> of inlining, but wanted to call that out, that ftrace stubs
> technically don't handle your usage pattern 100% properly.

True. They could be partially inlined even though they are exported symbols.