linux-kernel - Re: HW breakpoints perf

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:	Mon, 18 Jan 2010 12:35:59 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Joshua Pincus <joshua.pincus@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	"K.Prasad" <prasad@...ux.vnet.ibm.com>, peterz@...radead.org,
	paulus@...ba.org, acme@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: HW breakpoints perf_events request

On Mon, Jan 18, 2010 at 12:04:07PM +0100, Frederic Weisbecker wrote:
> I don't quite understand what signals are masked here,

ptrace reports all signals to the tracer and only
delivers them on PTRACE_CONT. "Masking" is probably
not the right term for it.

This could be fixed relatively easily with a new signal
mask ptrace option I guess.

> actually I'm not sure what is the true problem with ptrace.
> Is it because a breakpoint in a thread is going to stop
> all thread in the process until the parent handles the
> signal?

I didn't think ptrace stopped all threads by its own,
it just stops the current one and also only until 
the problem is reported. And for a break point you
typically want (in fact need to) to stop until it is handled.

> 
> Anyway, although I first suggested extending perf, with
> more thoughts I now agree that perf should keep doing what
> it does currently (profiling) and not trying to become an
> messy mix of a profiler, debugger, etc...

I find it surprising that you say that -- my
impression is that whatever gets proposed recently: 
error injection, testing, error handling, any other event 
someone proposed perf as the answer.

"If all I got is a hammer everything starts to look like a thumb"

But yes I fully agree with you.

> What about extending ptrace to support a new type of
> breakpoint debugging interface?

There's this utrace interface, but it seems to be more
a in kernel layer with some "we can't make up our mind what
the interface to the user looks like" and a lot of
overengineering in interfaces thrown in.

ptrace in its current form is somewhat messy, but for
me it seems there isn't anything better. So yes extending
it would seem like a good idea.

A good starting point might be the debug store interfaces
that got recently added to ptrace.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/