linux-kernel - Re: [PATCH 39/40] debug_core: Turn off tracing while in the debugger

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]

Date:	Fri, 15 Jan 2010 10:04:37 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jason Wessel <jason.wessel@...driver.com>
Cc:	linux-kernel@...r.kernel.org, kgdb-bugreport@...ts.sourceforge.net,
	mingo@...e.hu
Subject: Re: [PATCH 39/40] debug_core: Turn off tracing while in the
 debugger

On Fri, 2010-01-15 at 08:03 -0600, Jason Wessel wrote:

> What else do you imagine would turn on tracing, or what might break?
> 
> At the point in time that this is called all the slave CPUs are rounded
> up, and a single CPU remains executing as the "master" cpu inside the
> debug core.  There are two exit points from this context depending on
> the state of how you are resuming system, where we turn tracing back on,
> if it was on prior to entry to the kernel debug context.
> 
> I debated about using an atomic_inc and also allowing the slave_cpu
> entry to turn it off, because that actually happens first, and you can
> actually see that in the function tracer log up to the point that the
> master turns off tracing.
> 
> The approach employed by this patch seemed the most simplistic, and
> definitely stopped the trace log, while the debugger was active.  This
> particular problem with having tracing active while in the kernel debug
> context was not even discovered until kdb ftdump was implemented.  We
> don't really want to do much of anything except keep minimal HW alive
> while in the kernel debugger context.  I am open to suggestions if you
> think we need something more here.  I can also hard code a test if you
> believe there is a condition that requires some investigation.

Ah, if this is done by stopping the box, then it should be pretty safe.
There's two other ways that tracing can be enabled.

One, if someone modifies the kernel and adds "tracing_on()" somewhere.
Which, if happens, is the users fault. You change the kernel, you are
responsible for the consequences.

The other, which can happen from user land, is the "function:traceon"
feature.

# echo 'schedule:traceon' > /sys/kernel/debug/tracing/set_ftrace_filter

This will not add schedule to the ftrace filter, but instead it will
attach a check to schedule that will make the tracer enabled.

If someone attaches a "traceon" command to a function that might be
called by the kernel debugger, then you may have an issue. But this too,
may just be blamed on the user.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/