linux-kernel - Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)

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]

Message-ID: <87a9hj1s2q.fsf@sejong.aot.lge.com>
Date:	Tue, 05 Nov 2013 11:49:01 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Namhyung Kim <namhyung.kim@....com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Hyeoncheol Lee <cheol.lee@....com>,
	Hemant Kumar <hkshaw@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	"zhangwei\(Jovi\)" <jovi.zhangwei@...wei.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)

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

Right.  I think this approach is more reliable than playing with vma.

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

Well, maybe it's not that hard if we use symbol address in elf image
rather than file offset for the data.

IOW we can get the base mapping address by subtracting tu->offset from
instruction pointer.  And then adding symbol address of the data should
give us the final virtual address, yay!

I'll try to play with it after lunch.

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

Yes, cross-fetching is hard, let's go lunch. :)

Thanks,
Namhyung
--
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/