Messages in this thread | | | Date | Mon, 4 Nov 2013 19:57:54 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6) |
| |
On 11/04, Oleg Nesterov wrote: > > On 11/04, Oleg Nesterov wrote: > > > > On 11/04, Oleg Nesterov wrote: > > > > > > But in any case, I strongly believe that it doesn't make any sense to > > > rely on tu->inode in get_user_vaddr(). > > > > Hmm. But I forgot about the case when you probe the function in libc > > and want to dump the variable in libc... > > > > So probably I was wrong and this all needs more thinking. Damn. > > Perhaps we really need to pass @file/offset, but it is not clear what > > we can do with bss/anon-mapping. > > Or. Not that I really like this, but just for discussion... > > How about > > static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr) > { > return (void __force __user *)addr + instruction_pointer(regs); > } > > ? > > This should solve the problems with relocations/randomization/bss. > > The obvious disadvantage is that it is not easy to calculate the > offset we need to pass as an argument, it depends on the probed > function.
forgot to mention... and instruction_pointer() can't work in ret-probe, we need to pass the "unsigned long func" arg somehow...
> > And this still doesn't allow to, say, probe the executable but read > the data from libc. Unless, again, we attach to the running process > or randomize_va_space = 0, so we can know it in advance. But otherwise > I do not think there is any solution. > > Oleg.
| |