linux-kernel - Re: [PATCH bpf-next] libbpf: Support riscv USDT argument parsing logic

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] [day] [month] [year] [list]
Message-ID: <ef4ffe1f-1f3b-e98e-fc5f-26150e22871f@huawei.com>
Date:   Tue, 19 Apr 2022 21:00:15 +0800
From:   Pu Lehui <pulehui@...wei.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
CC:     bpf <bpf@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        <linux-riscv@...ts.infradead.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin Lau <kafai@...com>, Song Liu <songliubraving@...com>,
        Yonghong Song <yhs@...com>,
        john fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>
Subject: Re: [PATCH bpf-next] libbpf: Support riscv USDT argument parsing
 logic



On 2022/4/19 12:33, Andrii Nakryiko wrote:
> On Sun, Apr 17, 2022 at 8:53 PM Pu Lehui <pulehui@...wei.com> wrote:
>>
>> Add riscv-specific USDT argument specification parsing logic.
>> riscv USDT argument format is shown below:
>> - Memory dereference case:
>>    "size@off(reg)", e.g. "-8@-88(s0)"
>> - Constant value case:
>>    "size@val", e.g. "4@5"
>> - Register read case:
>>    "size@reg", e.g. "-8@a1"
>>
>> s8 will be marked as poison while it's a reg of riscv, we need
>> to alias it in advance.
>>
>> Signed-off-by: Pu Lehui <pulehui@...wei.com>
>> ---
> 
> Can you please mention briefly the testing you performed as I'm not
> able to test this locally.
> 
Both RV32 and RV64 have been tested. I will attach the test result in 
v2. Meanwhile, I found a small problem with libbpf USDT, and will be 
post in v2.
>>   tools/lib/bpf/usdt.c | 107 +++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 107 insertions(+)
>>
>> diff --git a/tools/lib/bpf/usdt.c b/tools/lib/bpf/usdt.c
>> index 934c25301ac1..b8af409cc763 100644
>> --- a/tools/lib/bpf/usdt.c
>> +++ b/tools/lib/bpf/usdt.c
>> @@ -10,6 +10,11 @@
>>   #include <linux/ptrace.h>
>>   #include <linux/kernel.h>
>>
>> +/* s8 will be marked as poison while it's a reg of riscv */
>> +#if defined(__riscv)
>> +#define rv_s8 s8
>> +#endif
>> +
>>   #include "bpf.h"
>>   #include "libbpf.h"
>>   #include "libbpf_common.h"
>> @@ -1400,6 +1405,108 @@ static int parse_usdt_arg(const char *arg_str, int arg_num, struct usdt_arg_spec
>>          return len;
>>   }
>>
>> +#elif defined(__riscv)
>> +
>> +static int calc_pt_regs_off(const char *reg_name)
>> +{
>> +       static struct {
>> +               const char *name;
>> +               size_t pt_regs_off;
>> +       } reg_map[] = {
>> +               { "ra", offsetof(struct user_regs_struct, ra) },
>> +               { "sp", offsetof(struct user_regs_struct, sp) },
>> +               { "gp", offsetof(struct user_regs_struct, gp) },
>> +               { "tp", offsetof(struct user_regs_struct, tp) },
>> +               { "t0", offsetof(struct user_regs_struct, t0) },
>> +               { "t1", offsetof(struct user_regs_struct, t1) },
>> +               { "t2", offsetof(struct user_regs_struct, t2) },
>> +               { "s0", offsetof(struct user_regs_struct, s0) },
>> +               { "s1", offsetof(struct user_regs_struct, s1) },
>> +               { "a0", offsetof(struct user_regs_struct, a0) },
>> +               { "a1", offsetof(struct user_regs_struct, a1) },
>> +               { "a2", offsetof(struct user_regs_struct, a2) },
>> +               { "a3", offsetof(struct user_regs_struct, a3) },
>> +               { "a4", offsetof(struct user_regs_struct, a4) },
>> +               { "a5", offsetof(struct user_regs_struct, a5) },
>> +               { "a6", offsetof(struct user_regs_struct, a6) },
>> +               { "a7", offsetof(struct user_regs_struct, a7) },
>> +               { "s2", offsetof(struct user_regs_struct, s2) },
>> +               { "s3", offsetof(struct user_regs_struct, s3) },
>> +               { "s4", offsetof(struct user_regs_struct, s4) },
>> +               { "s5", offsetof(struct user_regs_struct, s5) },
>> +               { "s6", offsetof(struct user_regs_struct, s6) },
>> +               { "s7", offsetof(struct user_regs_struct, s7) },
>> +               { "s8", offsetof(struct user_regs_struct, rv_s8) },
>> +               { "s9", offsetof(struct user_regs_struct, s9) },
>> +               { "s10", offsetof(struct user_regs_struct, s10) },
>> +               { "s11", offsetof(struct user_regs_struct, s11) },
>> +               { "t3", offsetof(struct user_regs_struct, t3) },
>> +               { "t4", offsetof(struct user_regs_struct, t4) },
>> +               { "t5", offsetof(struct user_regs_struct, t5) },
>> +               { "t6", offsetof(struct user_regs_struct, t6) },
> 
> would it make sense to order registers a bit more "logically"? Like
> s0-s11, t0-t6, etc. Right now it looks very random and it's hard to
> see if all the registers from some range of registers are defined.
> 
I code it according to the RISCV specification, and for sure, we can 
make it more intuitive.

Thanks,
Lehui
>> +       };
>> +       int i;
>> +
> 
> [...]
> .
>