On Wed, Nov 09, 2022 at 06:33:25AM IST, Alexei Starovoitov wrote:
> On Tue, Nov 8, 2022 at 4:23 PM Andrii Nakryiko
> <andrii.nakryiko@xxxxxxxxx> wrote:
> > > > > struct bpf_offload_dev;
> > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > index 94659f6b3395..dd381086bad9 100644
> > > > > --- a/include/uapi/linux/bpf.h
> > > > > +++ b/include/uapi/linux/bpf.h
> > > > > @@ -6887,6 +6887,16 @@ struct bpf_dynptr {
> > > > > __u64 :64;
> > > > > } __attribute__((aligned(8)));
> > > > >
> > > > > +struct bpf_list_head {
> > > > > + __u64 :64;
> > > > > + __u64 :64;
> > > > > +} __attribute__((aligned(8)));
> > > > > +
> > > > > +struct bpf_list_node {
> > > > > + __u64 :64;
> > > > > + __u64 :64;
> > > > > +} __attribute__((aligned(8)));
> > > >
> > > > Dave mentioned that this `__u64 :64` trick makes vmlinux.h lose the
> > > > alignment information, as the struct itself is empty, and so there is
> > > > nothing indicating that it has to be 8-byte aligned.
>
> Since it's not a new issue let's fix it for all.
> Whether it's a combination of pahole + bpftool or just pahole.
>
Would it make sense to do that as a follow up? The selftest does work right now
because I specified __attribute__((aligned(8))) manually for the variables.
> > > >
> > > > So what if we have
> > > >
> > > > struct bpf_list_node {
> > > > __u64 __opaque[2];
> > > > } __attribute__((aligned(8)));
> > > >
> > > > ?
> > > >
> > >
> > > Yep, can do that. Note that it's also potentially an issue for existing cases,
> > > like bpf_spin_lock, bpf_timer, bpf_dynptr, etc. Not completely sure if changing
> > > things now is possible, but if it is, we should probably make it for all of
> > > them?
> >
> > Why not? We are not removing anything or changing sizes, so it's
> > backwards compatible.
> > But I have a suspicion Alexei might not like
> > this __opaque field, so let's see what he says.
>
> I prefer to fix them all at once without adding a name.
>
> >
> > > > > off = vsi->offset;
> > > > > + if (i && !off)
> > > > > + return -EFAULT;
> > > >
> > > > similarly, I'd say that either we'd need to calculate the exact
> > > > expected offset, or just not do anything here?
> > > >
> > >
> > > This thread is actually what prompted this check:
> > > https://lore.kernel.org/bpf/CAEf4Bza7ga2hEQ4J7EtgRHz49p1vZtaT4d2RDiyGOKGK41Nt=Q@xxxxxxxxxxxxxx
> > >
> > > Unless loaded using libbpf all offsets are zero. So I think we need to reject it
> > > here, but I think the same zero sized field might be an issue for this as well,
> > > so maybe we remember the last field size and check whether it was zero or not?
> > >
> > > I'll also include some more tests for these cases.
> >
> > The question is whether this affects correctness from the verifier
> > standpoint? If it does, there must be some other place where this will
> > cause problem and should be caught and reported.
The problem here is that if the BTF is incorrect like this, where you have same
off for multiple items (bpf_spin_lock, bpf_list_head, etc.) like off=0 here,
they essentially get the same offset in our btf_record array.
I can check for it when appending items to the array (i.e. next offset must be
atleast prev_off + prev_sz at the very minimum).
>
> If it's an issue with BTF then we should probably check it
> during generic datasec verification.
> Here it's kinda late to warn.
>
There's also a concern that clang produces this BTF by default. If you're not
using libbpf as a loader, BTF that loaded previously will fail now (since
DATASEC var offs are always 0 and we will complain during validation and return
an error). Not sure what the impact will be, but just putting it out there.
Let me know what should be better. In either case I'll add a test case.
