Re: linux-next: add utrace tree
Hi! Right, so you're going to love uprobes, which does exactly that. The current proposal is overwriting the target instruction with an INT3 and injecting an extra vma into the target process's address space containing the original instruction(s) and possible jumps back to the old code stream. Just out of interest, how does it handle the threading issue? Last I saw, at least some CPU people were _very_ nervous about overwriting instructions if another CPU might be just about to execute them. I think the issue was that ring 0 was never meant to do that, where as, ring 3 does it all the time. Doesn't the dynamic library modify its text? No, it has nothing to do with ring. It has to do with modifying code that another CPU could be executing at the same time, and with modifying code on the same processor through another virtual alias (they are different issues.) The same issues apply regardless of the CPL of the processor. ...but these are always 'there could be cpu bugs around' issues, right? Like amd k6. AFAICT x86 always supported self-modifying code without any extra barriers needed... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: linux-next: add utrace tree
On Fri 2010-01-22 08:43:18, valdis.kletni...@vt.edu wrote: On Fri, 22 Jan 2010 10:51:39 +0530, Ananth N Mavinakayanahalli said: FWIW, Oleg's implementation of ptrace over utrace is 100% compatible with legacy ptrace; gdb testsuite indicates that (http://lkml.org/lkml/2009/12/21/98). No, that only proves it's compatible enough for gdb to not care. The problem is all those *other* packages that abuse ptrace in totally crackhead ways. (No, I can't name them - but ptrace is the sort of interface that almost encourages its use for things somewhere between crackhead and mad-scientist, so they're almost certainly out there.. WAY out there.. :) strace, subterfugue, ltrace, ...? Plus various homegrown sandboxing tools... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On Sun 2010-01-17 16:01:46, Peter Zijlstra wrote: On Sun, 2010-01-17 at 16:56 +0200, Avi Kivity wrote: On 01/17/2010 04:52 PM, Peter Zijlstra wrote: Also, if its fixed size you're imposing artificial limits on the number of possible probes. Obviously we'll need a limit, a uprobe will also take kernel memory, we can't allow people to exhaust it. Only if its unprivilidged, kernel and root should be able to place as many probes until the machine keels over. Well, it is address space that limits you in both cases... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC,PATCH 0/14] utrace/ptrace
On Wed 2009-11-25 16:48:18, Christoph Hellwig wrote: On Tue, Nov 24, 2009 at 09:01:27PM +0100, Oleg Nesterov wrote: Hello. This is the new iteration of Roland's utrace patch, this time with rewrite-ptrace-via-utrace + cleanups in utrace core. 1-7 are already in -mm tree, I am sending them to simplify the review. 8-12 don not change the behaviour, simple preparations. 13-14 add utrace-ptrace and utrace Skipped over it very, very briefly. One thing I really hate about this is that it introduces two ptrace implementation by adding the new one without removing the old one. Given that's it's pretty much too later for the 2.6.33 cycle anyway I'd suggest you make sure the remaining two major architectures (arm and mips) get converted, and if the remaining minor architectures don't manage to get their homework done they're left without ptrace. I don't think introducing regressions to force people to rewrite code is a good way to go... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
