netdev - Re: [RFC PATCH bpf-next 1/2] bpf: add bpf

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: <CAADnVQJv1NXV2ZHRQZu8YqOdQzdtD+Ydezoh-usvYvVdqyc0Gw@mail.gmail.com>
Date:   Sat, 6 Nov 2021 13:32:35 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Hou Tao <houtao1@...wei.com>, Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>, Yonghong Song <yhs@...com>,
        Song Liu <songliubraving@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [RFC PATCH bpf-next 1/2] bpf: add bpf_strncmp helper

On Sat, Nov 6, 2021 at 1:07 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> On Sat, Nov 6, 2021 at 12:26 PM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Sat, Nov 06, 2021 at 09:28:21PM +0800, Hou Tao wrote:
> > > The helper compares two strings: one string is a null-terminated
> > > read-only string, and another one has const max storage size. And
> > > it can be used to compare file name in tracing or LSM program.
> > >
> > > We don't check whether or not s2 in bpf_strncmp() is null-terminated,
> > > because its content may be changed by malicous program, and we only
> > > ensure the memory accessed is bounded by s2_sz.
> >
> > I think "malicous" adjective is unnecessary and misleading.
> > It's also misspelled.
> > Just mention that 2nd argument doesn't have to be null terminated.
> >
> > > + * long bpf_strncmp(const char *s1, const char *s2, u32 s2_sz)
> > ...
> > > +BPF_CALL_3(bpf_strncmp, const char *, s1, const char *, s2, size_t, s2_sz)
> >
> > probably should match u32 instead of size_t.
> >
> > > @@ -1210,6 +1210,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> > >               return &bpf_get_branch_snapshot_proto;
> > >       case BPF_FUNC_trace_vprintk:
> > >               return bpf_get_trace_vprintk_proto();
> > > +     case BPF_FUNC_strncmp:
> > > +             return &bpf_strncmp_proto;
> >
> > why tracing only?
> > Should probably be in bpf_base_func_proto.
> >
> > I was thinking whether the proto could be:
> > long bpf_strncmp(const char *s1, u32 s1_sz, const char *s2)
> > but I think your version is better though having const string as 1st arg
> > is a bit odd in normal C.
>
> Why do you think it's better? This is equivalent to `123 == x` if it
> was integer comparison, so it feels like bpf_strncmp(s, sz, "blah") is
> indeed more natural. No big deal, just curious what's better about it.

Only that helper implementation has two less register moves.
which makes it 51%/49% win for me.