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: <CANFS6bYRS24woCsuqKdfZxTNFzNNS-honfKPyPPGLTiP1fnBEQ@mail.gmail.com>
Date:	Wed, 26 Sep 2012 15:55:23 +0900
From:	Hyeoncheol Lee <hyc.lee@...il.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	srikar@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	yrl.pp-manager.tt@...achi.com
Subject: Re: [QUESTION] Can uprobe_event support @ADDR, $retval, offs(FETCHARG)?

Hi,

2012/9/26 Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>:
> (2012/09/26 11:52), Hyeoncheol Lee wrote:
>> Hi,
>>
>> uprobe_event only supports %REG arguments. I think that memory fetch,
>> return value fetch, memory dereference functions in
>> kernel/trace/trace_probe.c are good for uprobe_event. So with a little
>> modification of parse_probe_arg(), uprobe_event can support @ADDR,
>> $retval, offs(FETCHARGS) except @SYM, $stack, $stackN. Is it right?
>
> Hi Hyeoncheol,
>
> Perhaps, it is not so small things, but at least, we can try.
> In the userspace, memories(pages) can be paged out on swap or
> files. In that case, memory dereference function needs to track
> down the data on the disk and it causes I/O. This means we will
> see the visible performance degradation with tracing.
> And also, sometime a pointer value (address) is broken, in that
> case we have to ensure the address is actually valid before
> accessing it.
>
> Of cause, without tracking paged-out data, it is easy
> to support, because that is already done in kprobe event.
> I'm not sure how it is useful, because sometimes it will
> fail to access gather the data.
> However it is good for the first step, I think.

Yes, we should consider paged-out data. I forgot this.

>
> Srikar, what would you think?
>
> BTW, if we can support offs(FETCHARGS), $stack and $stackN
> are also available. ;)

Yes, but we should check whether the given address is in an user stack
or not. and these require CPU architecture dependent codes.

>
> Thank you,
>
> --
> Masami HIRAMATSU
> Software Platform Research Dept. Linux Technology Center
> Hitachi, Ltd., Yokohama Research Laboratory
> E-mail: masami.hiramatsu.pt@...achi.com
>
>

Thanks for your answer. It is very help to me. ;)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ