linux-kernel - Re: [RFC][PATCH] Make ftrace able to trace function return

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:	Thu, 30 Oct 2008 16:30:12 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] Make ftrace able to trace function return


On Thu, 30 Oct 2008, Frederic Weisbecker wrote:
> 
> So the idea is to allocate a general set of slots on which we can save our original
> return address and the call time. After that we change the return address of the
> hooked function to jump on a trampoline which will push the offset for us
> to retrieve the slot on the set for this function call. Then the trampoline
> will call a return handler that will trace the return time and send all of these
> informations to a specific tracer. And then the return handler will return to the
> original return address.
> 
> To determine quickly which slot is free, I use a bitmap of 32 bits. 
> Perhaps it is a bad assumption but I could enlarge it and there is an overrun
> counter. This is the only point which needs to be protected against 
> concurrent access.
> 


What about storing the return addresses on the bottom of the stack?
That is, start at task->stack + sizeof(thread_info), and stack up on that. 
Be careful, there might already be users of that area. This will also need 
to be arch dependent.

Note, more is needed than what I wrote above, I'm just suggesting another 
approach.

-- 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/