netdev - Re: [PATCH bpf-next v4 1/7] netkit, bpf: Add bpf programmable net device

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c2e0535d-8091-9504-4edd-9974f44c416c@iogearbox.net>
Date: Thu, 26 Oct 2023 14:11:39 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Jiri Pirko <jiri@...nulli.us>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, martin.lau@...ux.dev,
 razor@...ckwall.org, ast@...nel.org, andrii@...nel.org,
 john.fastabend@...il.com, sdf@...gle.com, toke@...nel.org, kuba@...nel.org,
 andrew@...n.ch, Toke Høiland-Jørgensen
 <toke@...hat.com>, joe@...ium.io
Subject: Re: [PATCH bpf-next v4 1/7] netkit, bpf: Add bpf programmable net
 device

On 10/26/23 7:18 AM, Jiri Pirko wrote:
> Wed, Oct 25, 2023 at 07:20:01PM CEST, daniel@...earbox.net wrote:
>> On 10/25/23 5:47 PM, Jiri Pirko wrote:
>>> Tue, Oct 24, 2023 at 11:48:58PM CEST, daniel@...earbox.net wrote:
>> [...]
>>>> comes with a primary and a peer device. Only the primary device, typically
>>>> residing in hostns, can manage BPF programs for itself and its peer. The
>>>> peer device is designated for containers/Pods and cannot attach/detach
>>>> BPF programs. Upon the device creation, the user can set the default policy
>>>> to 'pass' or 'drop' for the case when no BPF program is attached.
>>>
>>> It looks to me that you only need the host (primary) netdevice to be
>>> used as a handle to attach the bpf programs. Because the bpf program
>>> can (and probably in real use case will) redirect to uplink/another
>>> pod netdevice skipping the host (primary) netdevice, correct?
>>>
>>> If so, why can't you do just single device mode from start finding a
>>> different sort of bpf attach handle? (not sure which)
>>
>> The first point where we switch netns from a K8s Pod is out of the netdevice.
>> For the CNI case the vast majority has one but there could also be multi-
>> homing for Pods where there may be two or more, and from a troubleshooting
>> PoV aka tcpdump et al, it is the most natural point. Other attach handle
>> inside the Pod doesn't really fit given from policy PoV it also must be
>> unreachable for apps inside the Pod itself.
> 
> Okay. What is the usecase for the single device model then?

One immediate use case in the context of Cilium itself is to replace
and simplify our cilium_host/cilium_net pair which is in the hostns
and depending on the routing mode that Cilium is configured in handling
traffic/policy from host into Pods respectively from host or Pods into
collect_md encaps in order to route traffic E/W to other cluster nodes.
Going further, we were thinking also to have single dev and move it into
target netns with policy being configured from host.

Best,
Daniel