Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 26 Mar 2020 at 00:16, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
>
[...]
>
> Those same folks have similar concern with XDP. In the world where
> container management installs "root" XDP program which other user
> applications can plug into (libxdp use case, right?), it's crucial to
> ensure that this root XDP program is not accidentally overwritten by
> some well-meaning, but not overly cautious developer experimenting in
> his own container with XDP programs. This is where bpf_link ownership
> plays a huge role. Tupperware agent (FB's container management agent)
> would install root XDP program and will hold onto this bpf_link
> without sharing it with other applications. That will guarantee that
> the system will be stable and can't be compromised.

Thanks for the extensive explanation Andrii.

This is what I imagine you're referring to: Tupperware creates a new network
namespace ns1 and a veth0<>veth1 pair, moves one of the veth devices
(let's says veth1) into ns1 and runs an application in ns1. On which veth
would the XDP program go?

The way I understand it, veth1 would have XDP, and the application in ns1 would
be prevented from attaching a new program? Maybe you can elaborate on this
a little.

Lorenz

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux