linux-kernel - Re: [PATCH 0/3] tracing: Fix some selftest issues

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: <20240610111001.5ed3e97f6383915fcba87e31@kernel.org>
Date: Mon, 10 Jun 2024 11:10:01 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Tom Zanussi <tom.zanussi@...ux.intel.com>, LKML
 <linux-kernel@...r.kernel.org>, Linux Trace Kernel
 <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] tracing: Fix some selftest issues

On Fri, 31 May 2024 03:24:25 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Fri, 31 May 2024 11:37:21 +0900
> Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
> 
> > So, in summary, it is designed to be a module. Steve, I think these tests
> > should be kept as modules. There are many reason to do so.
> > 
> >  - This test is designed to be used as module.
> >  - This can conflict with other boot time selftest if it is embedded.
> >  - We can make these tests and boot time selftest mutable exclusive but
> >    if we make these tests as modules, we can build and run both tests
> >    safely.
> >  - Embedding these tests leave new events when the kernel boot, which
> >    user must be cleaned up by manual.
> > 
> > What would you think?
> 
> I was mostly following what Ingo told me long ago, where having it
> built in is just one more way to test it ;-)
> 
> But that said, from your first patch, you show the stack dump and
> mention:
> 
> > Since the kprobes and synth event generation tests adds and enable
> > generated events in init_module() and delete it in exit_module(),
> > if we make it as built-in, those events are left in kernel and cause
> > kprobe event self-test failure.
> 
> But you don't explain what exactly the conflict is. What about those
> events causes kprobe selftests to fail?

I also found another problem on these modules. These modules get trace
event file references to prevent removing probes. Therefore, if we
embed these modules, we can not remove these events forever!

        /*
         * Now get the gen_kprobe_test event file.  We need to prevent
         * the instance and event from disappearing from underneath
         * us, which trace_get_event_file() does (though in this case
         * we're using the top-level instance which never goes away).
         */
        gen_kprobe_test = trace_get_event_file(NULL, "kprobes",
                                               "gen_kprobe_test");
        if (IS_ERR(gen_kprobe_test)) {
                ret = PTR_ERR(gen_kprobe_test);
                goto delete;
        }

This means most ftracetest fails because we can not clean up the
tracing state by removing dynamic events, which are installed while
booting.
Note that these references (locks) will be removed when the module
is unloaded.

Thanks,

> 
> 
> -- Steve


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>