linux-kernel - Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo

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]

Date:	Wed, 27 May 2015 08:30:57 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	He Kuang <hekuang@...wei.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	wangnan0@...wei.com, paulus@...ba.org, a.p.zijlstra@...llo.nl,
	mingo@...hat.com, acme@...nel.org, namhyung@...nel.org,
	jolsa@...nel.org, dsahern@...il.com, brendan.d.gregg@...il.com,
	daniel@...earbox.net
CC:	lizefan@...wei.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo

On 5/26/15 7:27 PM, He Kuang wrote:
> hi, Alexei
> 
> On 2015/5/27 1:50, Alexei Starovoitov wrote:
>> On 5/25/15 1:33 AM, He Kuang wrote:
>>> Right, I learnt regparm(3) is mandatory in x86_32, according to rules,
>>> the first three args will go to regparm(ax, dx, cx). But we should not
>>> refer arg1~3 to ax, dx, cx because of 64bit parameters (other reasons?).
>>>
>>> Consider this keyword is used for generating bpf prologue which fetches
>>> formal parameters when no debuginfo is provided, for this purpose, we can:
>>> 	1) We just help fetch the $regs or $regparms(If the keyword is
>>> $regparms, ax/dx/cx is fetched, nothing related to args) to bpf arglists
>>> and leave the rest things to bpf prog writer.
>>>
>>> 	2) Keep that on platforms like x86_64 and skip this feature on
>>> platforms like x86_32.
>>>
>>> or any other suggestions?
>>
>> Single argument like $regparam or whatever name cannot work on all
>> architectures, that's why in the very beginning I suggested
>> 'func(long, char, void*)' syntax to describe arguments when debuginfo
>> is not available. Calling convention for scalars is simple enough on
>> all major architectures. x64_64 - trivial, i64_32 - a bit more involved,
>> but simple enough so that list of types of arguments is enough to figure
>> out which register or register pair or stack should be used to fetch
>> argN.
>>
>>
> As Masami has reminded,  the use of 'asmlinkage' forces regparm=0, and
> we can't destinguish them without debuginfo, so 'func(long, char,
> void*)' syntax not work in everywhere.
> 
> In fact, all the context infos are there in bpf prog(pt_regs in arg1).
> To the non-debuginfo case, without the help of prologue, user steps
> following flow to fetch params:
> 
> 1. pt_regs(arg1) + architecture => calling regs
> 
> 2. calling regs + function prototype(SEC) + gcc attributes(like
> asmlinkage) => formal parameters
> 
>   '$regparms' do the 1st step, though not a full workaround. But for the
> lack of gcc attributes, it seems we can't do the 2nd step. Any ideas?

I don't think you can break it down in two steps like this.
There is no such thing as 'calling regs'. x86_32 with ax,dx,cx
are not 'calling regs'. 64-bit values will be passed in a pair.
Only 'pt_regs + arch + func_proto + asmlinkage' makes sense
from the user point of view.
Adding 'asmlinkage' attr is also trivial.
'func(long, char) asmlinkage' is easy to parse and the user
will be able to write programs that are architecture independent.
We already have 'struct pt_regs *' and $regparams don't buy us
anything extra. It may be useful for generic kprobe, but not for bpf.

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