Hi Oleg,
On Tue, 12 Nov 2013 17:00:01 +0900, Namhyung Kim wrote:
> For @+addr syntax: user-space uses relative symbol address from a loaded
>base address and kernel calculates the base address
>using "current->utask->vaddr - tu->offset".
I tried this approa
Hi Namhyung,
On 11/12, Namhyung Kim wrote:
>
> Let me clarify what I understand.
>
> For @addr syntax: kernel does no translation and uses given address
Yes,
> For @+addr syntax: user-space uses relative symbol address from a loaded
>base address and kernel calculates the bas
Hi Oleg and Masami,
On Sat, 9 Nov 2013 16:23:13 +0100, Oleg Nesterov wrote:
> On 11/09, Masami Hiramatsu wrote:
>>
>> In that case, I suggest you to use "@+addr" for the relative address,
>> since that is an offset, isn't that? :)
>
> Agreed, @+addr looks better!
Looks good to me too.
>
>> BTW,
Hi Oleg,
On Fri, 8 Nov 2013 18:00:17 +0100, Oleg Nesterov wrote:
> On 11/07, Namhyung Kim wrote:
>>
>> On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
>> >
>> > Note that instruction_pointer_set() is not really nice in any case,
>> > this can obviously confuse FETCH_MTD_reg("ip").
>>
>> Ye
On 11/09, Masami Hiramatsu wrote:
>
> In that case, I suggest you to use "@+addr" for the relative address,
> since that is an offset, isn't that? :)
Agreed, @+addr looks better!
> BTW, it seems that @addr syntax is hard to use for uprobes, because
> current uprobes is based on a binary, not a pr
(2013/11/07 17:48), Namhyung Kim wrote:
> On Wed, 6 Nov 2013 18:37:54 +0100, Oleg Nesterov wrote:
>> On 11/06, Namhyung Kim wrote:
>>>
>>> On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
On 11/05, Oleg Nesterov wrote:
>
> As for "-= tu->offset"... Can't we avoid it? User-space
On 11/07, Namhyung Kim wrote:
>
> On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
> >
> > Note that instruction_pointer_set() is not really nice in any case,
> > this can obviously confuse FETCH_MTD_reg("ip").
>
> Yes.
>
> >
> > But lets ignore this. The solution is simple, we can pass/use
Hi Namhyung,
sorry for delay.
On 11/07, Namhyung Kim wrote:
>
> >> > As for "-= tu->offset"... Can't we avoid it? User-space needs to
> >> > calculate
> >> > the "@" argument anyway, why it can't also substruct this offset?
> >>
> >> Hmm.. it makes sense too. :)
> >
> > I am no longer sure ;)
>
On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
> Forgot to mention,
>
> On 11/06, Oleg Nesterov wrote:
>>
>> I meant,
>>
>> saved_ip = instruction_pointer(regs);
>>
>> // pass the "ip" which was used to calculate
>> // the @addr argument to fetch_*()
On Wed, 6 Nov 2013 18:37:54 +0100, Oleg Nesterov wrote:
> On 11/06, Namhyung Kim wrote:
>>
>> On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
>> > On 11/05, Oleg Nesterov wrote:
>> >>
>> >> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
>> >> the "@" argument any
Hi Oleg,
On Wed, 6 Nov 2013 17:28:06 +0100, Oleg Nesterov wrote:
> On 11/06, Namhyung Kim wrote:
>>
>> On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
>> > On 11/05, Namhyung Kim wrote:
>> >>
>> >> This is what I have for now:
>> >>
>> >> static void __user *get_user_vaddr(struct pt_regs *
Forgot to mention,
On 11/06, Oleg Nesterov wrote:
>
> I meant,
>
> saved_ip = instruction_pointer(regs);
>
> // pass the "ip" which was used to calculate
> // the @addr argument to fetch_*() methods
>
> temp_ip = is_ret_probe(tu) ? func : sav
On 11/06, Namhyung Kim wrote:
>
> On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
> > On 11/05, Oleg Nesterov wrote:
> >>
> >> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
> >> the "@" argument anyway, why it can't also substruct this offset?
> >>
> >> Or perha
On 11/06, Namhyung Kim wrote:
>
> On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
> > On 11/05, Namhyung Kim wrote:
> >>
> >> This is what I have for now:
> >>
> >> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
> >> addr,
> >> struct t
On Tue, 5 Nov 2013 20:24:01 +0100, Oleg Nesterov wrote:
> On 11/05, Oleg Nesterov wrote:
>>
>> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
>> the "@" argument anyway, why it can't also substruct this offset?
>>
>> Or perhaps we can change parse_probe_arg("@") to updat
On Tue, 5 Nov 2013 18:45:35 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> This is what I have for now:
>>
>> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
>> struct trace_uprobe *tu)
>> {
>> unsigned long base_a
On Tue, 5 Nov 2013 17:41:02 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
>> >>
>> >> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
>> >> addr)
>> >> {
>> >> return (void __force __us
On Tue, 5 Nov 2013 17:33:41 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
>> >
>> > So probably I was wrong and this all needs more thinking. Damn.
>>
>> :)
>
> Don't laugh at me ;)
:)
(And now I'm feeling guilty..)
>
>>
Hi Oleg,
On Tue, 5 Nov 2013 17:28:20 +0100, Oleg Nesterov wrote:
> On 11/05, Namhyung Kim wrote:
>>
>> On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
>> > Or the syntax should be "name=probe @file/addr" or something like this.
>>
>> Okay. Let's call this kind of thing "cross-fetch" (or a
On 11/05, Oleg Nesterov wrote:
>
> As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
> the "@" argument anyway, why it can't also substruct this offset?
>
> Or perhaps we can change parse_probe_arg("@") to update "param" ? Yes,
> in this case it needs another argument, not
On 11/05, Namhyung Kim wrote:
>
> This is what I have for now:
>
> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
> struct trace_uprobe *tu)
> {
> unsigned long base_addr;
> unsigned long vaddr;
>
> base_addr = instruc
On 11/05, Namhyung Kim wrote:
>
> On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
> > Or the syntax should be "name=probe @file/addr" or something like this.
>
> Okay. Let's call this kind of thing "cross-fetch" (or a better name can
> be suggested).
Yes ;) and I am afraid there was some
On 11/05, Namhyung Kim wrote:
>
> On Mon, 4 Nov 2013 17:22:29 +0100, Oleg Nesterov wrote:
> >
> > So probably I was wrong and this all needs more thinking. Damn.
>
> :)
Don't laugh at me ;)
> > Perhaps we really need to pass @file/offset, but it is not clear what
> > we can do with bss/anon-mappi
On 11/05, Namhyung Kim wrote:
>
> On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
> >>
> >>static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
> >> addr)
> >>{
> >>return (void __force __user *)addr + instruction_pointer(regs);
> >>}
> >>
> >> ?
>
This is what I have for now:
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long addr,
struct trace_uprobe *tu)
{
unsigned long base_addr;
unsigned long vaddr;
base_addr = instruction_pointer(regs) - tu->offset;
On Mon, 4 Nov 2013 19:57:54 +0100, Oleg Nesterov wrote:
> 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().
>>
On Mon, 4 Nov 2013 19:47:41 +0100, 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 p
On Mon, 4 Nov 2013 17:22:29 +0100, 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
On Mon, 4 Nov 2013 16:51:31 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>> On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
>> > On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> >> - this only allows to read the data from the same binary.
>> >
>> > Right. This is a
On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>>
>> On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> >
>> > This does not look right to me.
>> >
>> > - get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
>> > ->i_mmap_mutex.
>>
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 functio
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
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 need
On 11/04, Namhyung Kim wrote:
> On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
> > On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
> >> - this only allows to read the data from the same binary.
> >
> > Right. This is also an unnecessary restriction. We should be able to
> > acces
On 11/04, Namhyung Kim wrote:
>
> On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
> >
> > This does not look right to me.
> >
> > - get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
> > ->i_mmap_mutex.
>
> Hmm.. yes, I think this is not needed. I guess it should looku
On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
> On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> - this only allows to read the data from the same binary.
>
> Right. This is also an unnecessary restriction. We should be able to
> access data in other binary.
Hmm.. I guess thi
On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
> Hello,
>
> Let me first apologize again if this was already discussed. And I also
> need to mention that I know almost nothing about elf/randomization/etc.
No no, this was not discussed enough. And I really appreciate your
thorough review!
Hello,
Let me first apologize again if this was already discussed. And I also
need to mention that I know almost nothing about elf/randomization/etc.
However,
On 10/29, Namhyung Kim wrote:
>
> # nm foo | grep -e glob$ -e str -e foo
> 006008bc D foo
> 006008a8 D glob
> 000
(2013/10/29 15:53), Namhyung Kim wrote:
> Hello,
>
> This patchset implements memory (address), stack[N], deference,
> bitfield and retval (it needs uretprobe tho) fetch methods for
> uprobes. It's based on the previous work [1] done by Hyeoncheol Lee.
>
> Now kprobes and uprobes have their own
Hello,
This patchset implements memory (address), stack[N], deference,
bitfield and retval (it needs uretprobe tho) fetch methods for
uprobes. It's based on the previous work [1] done by Hyeoncheol Lee.
Now kprobes and uprobes have their own fetch_type_tables and, in turn,
memory and stack acces
40 matches
Mail list logo
