linux-kernel - Re: [RFC PATCH 5/6] uprobes: add bp_vaddr argument to consumer handler

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: <50F5AACB.7000303@redhat.com>
Date:	Tue, 15 Jan 2013 11:15:23 -0800
From:	Josh Stone <jistone@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	Anton Arapov <anton@...hat.com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Frank Eigler <fche@...hat.com>
Subject: Re: [RFC PATCH 5/6] uprobes: add bp_vaddr argument to consumer handler

On 01/12/2013 09:06 AM, Oleg Nesterov wrote:
> On 01/10, Josh Stone wrote:
>> and for uretprobes we want the original return address.
> 
> Yes, Anton's v2 does this.
> 
> But. Don't you also need to know the address of function we are going
> to return from?
> 
> Probably you do not, uprobe_consumer should know which function (but
> not vaddr) it probes, but please confirm.

Right, this is fine.

The main reason we need a fixed-up IP is to have a consistent user state
for unwinding and evaluating other related DWARF expressions.

Setting regs->ip to the entry address of the function we just returned
from would actually be harmful, as it would be completely lying about
the current execution point, and the rest of the register and memory
state wouldn't match that point either.

Maybe it would be useful if regs->ip reflected the address of the RET
instruction we just executed, but only if e.g. regs->sp also got rewound
accordingly.  Since I don't think this is possible, just setting
regs->ip to the return target is good enough.

Josh
--
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/