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: <ZyuxmsK0jfKa7NKK@elver.google.com>
Date: Wed, 6 Nov 2024 19:12:42 +0100
From: Marco Elver <elver@...gle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Kees Cook <keescook@...omium.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org,
	Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com
Subject: Re: [PATCH] tracing: Add task_prctl_unknown tracepoint

On Wed, Nov 06, 2024 at 10:28AM -0500, Steven Rostedt wrote:
> On Wed, 6 Nov 2024 10:18:23 -0500
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > > Some trial and error led me to conclude it's a race between the logic
> > > looking up the comm and the process exiting: If the test program exits
> > > soon after the traced event, it doesn't print the comm. Adding a
> > > generous usleep() before it exits reliably prints the comm.  
> > 
> > Thanks for letting me know. Let me see if I can fix that!
> 
> Hmm, that still doesn't make sense. Is this just a single line or do you
> have other events being recorded?
> 
> The way the caching works is during the sched_switch tracepoint which still
> gets called when the task exits. If a trace event is triggered, it sets a
> per cpu flags to have the next sched_switch record the comm for both the
> previous and next tasks.
> 
> Now the reason it can miss is that there's contention on the lock that
> saves the comms (it does a trylock and if it fails, it just skips it). Or
> if another task hits the same "comm cache line".
> 
> This is why I wonder if you have other events being traced.

No other events should be traced. This is the test program I've used:

	#include <sys/prctl.h>
	#include <unistd.h>

	int main(int argc, char *argv[])
	{
	  prctl(1234, 101, 102, 103, 104);
	  if (argc > 1)
	    usleep(1000);
	  return 0;
	}

Kernel config is x86_64 default + CONFIG_FUNCTION_TRACER=y +
CONFIG_FTRACE_SYSCALLS=y. For the test, once booted all I do is:

	% echo 1 > /sys/kernel/debug/tracing/events/task/task_prctl_unknown/enable
	% cat /sys/kernel/debug/tracing/trace_pipe
	... wait for output ...

That's pretty much it. I've attached my kernel config just in case I
missed something.

View attachment ".config" of type "text/plain" (144430 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ