From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>,
Daniel Borkmann <borkmann@iogearbox.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
brouer@redhat.com
Subject: Re: [PATCH bpf-next V2] bpf: Fix map_check_no_btf return code
Date: Thu, 28 May 2020 09:08:42 +0200 [thread overview]
Message-ID: <20200528090842.6fb4e42d@carbon> (raw)
In-Reply-To: <CAEf4Bzavr2hLv+Z0be0_uGRfPqNsBKAsQL7MpQUoXQX46rj4eA@mail.gmail.com>
On Wed, 27 May 2020 15:59:46 -0700
Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> But regardless, can you please reply on v1 thread why adding support
> for BTF to these special maps (that do not support BTF right now)
> won't be a better solution and won't work (as you claimed)?
(I will reply here instead of on v1) and I have not claimed it won't
work. It will work, but we loose an opportunity if we just allow BTF
across the board, without using it for per map validation.
We have an opportunity with these special maps, that do not support BTF
right now. The value field in these maps are actually a UAPI and also
kABI (Binary).
Simply describing the struct with BTF is nice, but only helpful to make
the end-user understand they binary layout. On the kernel side we are
still stuck with a kABI that can only be end-extended and size increased.
I want to use BTF on the kernel-side to validate and enforce that user
provided the expected "named" layout, and possibly reject it. This
gives us a layer that can provide a flexible kABI. From my current
understanding of the kernel side code that parse/walk BTF, I we can
actually have flexible offsets (for e.g. structs) in the binary value,
and remap those on the kernel side. Enforcing a named layout when we
enable BTF for these maps, will give us binary flexibility for future
changes. I hope you agree?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2020-05-28 7:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 11:33 [PATCH bpf-next V2] bpf: Fix map_check_no_btf return code Jesper Dangaard Brouer
2020-05-27 22:59 ` Andrii Nakryiko
2020-05-28 7:08 ` Jesper Dangaard Brouer [this message]
2020-05-28 18:21 ` Andrii Nakryiko
2020-05-28 18:38 ` Alexei Starovoitov
2020-05-28 19:41 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200528090842.6fb4e42d@carbon \
--to=brouer@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=borkmann@iogearbox.net \
--cc=bpf@vger.kernel.org \
--cc=kuba@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.