Date: Wed, 5 Jul 2023 09:34:54 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, ast@...nel.org,
 andrii@...nel.org, martin.lau@...ux.dev, razor@...ckwall.org,
 sdf@...gle.com, john.fastabend@...il.com, kuba@...nel.org, dxu@...uu.xyz,
 joe@...ium.io, toke@...nel.org, davem@...emloft.net, bpf@...r.kernel.org,
 netdev@...r.kernel.org, lmb@...valent.com
Subject: Re: [PATCH bpf-next v2 2/7] bpf: Add fd-based tcx multi-prog infra
 with link support

On 7/5/23 12:38 AM, Jamal Hadi Salim wrote:
> On Tue, Jul 4, 2023 at 6:01 PM Daniel Borkmann <daniel@...earbox.net> wrote:
>> On 7/4/23 11:36 PM, Jamal Hadi Salim wrote:
>>> On Thu, Jun 8, 2023 at 5:25 PM Andrii Nakryiko
>>> <andrii.nakryiko@...il.com> wrote:
>>>> On Thu, Jun 8, 2023 at 12:46 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>>>>> On Thu, Jun 8, 2023 at 6:12 AM Daniel Borkmann <daniel@...earbox.net> wrote:
>>>>>> On 6/8/23 3:25 AM, Jamal Hadi Salim wrote:
>> [...]
>>>>>> BPF links are supported for XDP today, just tc BPF is one of the few
>>>>>> remainders where it is not the case, hence the work of this series. What
>>>>>> XDP lacks today however is multi-prog support. With the bpf_mprog concept
>>>>>> that could be addressed with that common/uniform api (and Andrii expressed
>>>>>> interest in integrating this also for cgroup progs), so yes, various hook
>>>>>> points/program types could benefit from it.
>>>>>
>>>>> Is there some sample XDP related i could look at?  Let me describe our
>>>>> use case: lets say we load an ebpf program foo attached to XDP of a
>>>>> netdev  and then something further upstream in the stack is consuming
>>>>> the results of that ebpf XDP program. For some reason someone, at some
>>>>> point, decides to replace the XDP prog with a different one - and the
>>>>> new prog does a very different thing. Could we stop the replacement
>>>>> with the link mechanism you describe? i.e the program is still loaded
>>>>> but is no longer attached to the netdev.
>>>>
>>>> If you initially attached an XDP program using BPF link api
>>>> (LINK_CREATE command in bpf() syscall), then subsequent attachment to
>>>> the same interface (of a new link or program with BPF_PROG_ATTACH)
>>>> will fail until the current BPF link is detached through closing its
>>>> last fd.
>>>
>>> So this works as advertised. The problem is however not totally solved
>>> because it seems we need a process that's alive to hold the ownership.
>>> If we had a daemon then that would solve it i think (we dont).
>>> Alternatively,  you pin the link. The pinning part can be
>>> circumvented, unless i misunderstood i,e anybody with the right
>>> permissions can remove it.
>>>
>>> Am I missing something?
>>
>> It would be either of those depending on the use case, and for pinning
>> removal, it would require right permissions/acls. Keep in mind that for
>> your application you can also use your own bpffs mount, so you don't
>> need to use the default /sys/fs/bpf one in hostns.
> 
> This helps for sure - doesnt 100% solve it. It would really be nice if
> we could tie in a kerberos-like ticketing system for ownership of the
> mount or something even more fine grained like a link. Doesnt have to
> be kerberos but anything that would allow a digest of some verifiable
> credentials/token to be handed to the kernel for authorization...

What is your use-case, you don't want anyone except your own orchestration
application to access it, so any kind of ACLs, LSM policies or making the
mount only available to your container are not enough in this scenario you
have in mind?

I think the closest to that is probably the prototype which Lorenz recently
built where the user space application's digest is validated via IMA [0].

   [0] http://vger.kernel.org/bpfconf2023_material/Lorenz_Bauer_-_BPF_signing_using_fsverity_and_LSM_gatekeeper.pdf
       https://github.com/isovalent/bpf-verity

Powered by blists - more mailing lists