netdev - Re: [RFC][PATCH bpf-next] libbpf: add bpf_object__open

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: <CAEf4Bza5+pCJUB048HXRx9w059t-RzXuv+mC_MH5akSsr78y4Q@mail.gmail.com>
Date:   Tue, 1 Oct 2019 11:59:24 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        KP Singh <kpsingh@...omium.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [RFC][PATCH bpf-next] libbpf: add bpf_object__open_{file,mem} w/
 sized opts

On Tue, Oct 1, 2019 at 9:48 AM Jesper Dangaard Brouer <brouer@...hat.com> wrote:
>
> On Mon, 30 Sep 2019 09:42:39 -0700
> Andrii Nakryiko <andriin@...com> wrote:
>
> > diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
> > index 2e83a34f8c79..1cf2cf8d80f3 100644
> > --- a/tools/lib/bpf/libbpf_internal.h
> > +++ b/tools/lib/bpf/libbpf_internal.h
> > @@ -47,6 +47,12 @@ do {                               \
> >  #define pr_info(fmt, ...)    __pr(LIBBPF_INFO, fmt, ##__VA_ARGS__)
> >  #define pr_debug(fmt, ...)   __pr(LIBBPF_DEBUG, fmt, ##__VA_ARGS__)
> >
> > +#define OPTS_VALID(opts) (!(opts) || (opts)->sz >= sizeof((opts)->sz))
>
> Do be aware that C sizeof() will include the padding the compiler does.
> Thus, when extending a struct (e.g. in a newer version) the size
> (sizeof) might not actually increase (if compiler padding room exist).

Yes, that's a very good point, thanks for bringing this up!

I was debating whether OPTS_VALID should validate (similar to kernel)
that all the bytes between user's struct size and our
latest-and-greatest struct definition size are set to zero. But this
padding issue just proves it has to be done always.

And it also shows that using struct initialization to zero (or using
macro with struct field initializers) is almost a must to avoid issue
like this. On libbpf side I think we can just provide helpful message
to user, otherwise it might be hair-pulling to figure out what's
wrong.

>
> > +#define OPTS_HAS(opts, field) \
> > +     ((opts) && opts->sz >= offsetofend(typeof(*(opts)), field))
> > +#define OPTS_GET(opts, field, fallback_value) \
> > +     (OPTS_HAS(opts, field) ? (opts)->field : fallback_value)
>
> I do think, that these two "accessor" defines address the padding issue
> I described above.
>
> p.s. I appreciate that you are working on this, and generally like the idea.

Thanks!

> --
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer