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
| ||
|
Date: Thu, 14 Jan 2010 09:44:25 +0100 From: Peter Zijlstra <peterz@...radead.org> To: Joshua Pincus <joshua.pincus@...il.com> Cc: Frederic Weisbecker <fweisbec@...il.com>, "K.Prasad" <prasad@...ux.vnet.ibm.com>, paulus@...ba.org, acme@...hat.com, linux-kernel@...r.kernel.org Subject: Re: HW breakpoints perf_events request On Wed, 2010-01-13 at 17:45 -0800, Joshua Pincus wrote: > However, there's nothing yet in place to allow a > signal to be sent to the thread when a breakpoint > has been hit. Put another way, there's nothing here > which affects execution flow of the user-app when the CPU > traps due to a HW breakpoint. > > Currently, the perf events infrastructure allows me > to mmap() a block of memory and to poll() on it, waiting > and watching for events to be described in that mmap'd > buffer. That will not be sufficient for what we need > to do. We need to have the ability to specify that > execution of the thread should be interrupted, just as it > would under ptrace(), and have a signal be delivered. > Delivery of the signal must be received and processed > by the application before the thread will be allowed to > proceed to the nPC after the PC which caused the > HW breakpoint event. > > Is this possible? Can we architect this feature into > the perf_events infrastructure? We have fnctl() managing signal support, but that will only interrupt the observing thread, not the threads being observed (unless they are one and the same -- but using inheritance precludes that from being true). I'm not sure I'm willing to go in this direction with perf, the idea is to have a minimum impact on the observed threads, explicitly sending them signals and disturbing their execution goes against this. -- 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/
Powered by blists - more mailing lists