Re: Re: [PATCH 2/2] libbpf: BPF programs dynamic loading and attaching

[Martin Kelly <martin.kelly@crowdstrike.com>]

On Fri, 2025-01-24 at 10:31 -0800, Andrii Nakryiko wrote:
> > On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev
> > <slava.imameev@crowdstrike.com> wrote:
> > > > 
> > > > BPF programs designated as dynamically loaded can be loaded and
> > > > attached independently after the initial bpf_object loading and
> > > > attaching.
> > > > 
> > > > These programs can also be reloaded and reattached multiple
> > > > times,
> > > > enabling more flexible management of a resident BPF program
> > > > set.
> > > > 
> > > > A key motivation for this feature is to reduce load times for
> > > > utilities that include hundreds of BPF programs. When the
> > > > selection
> > > > of a resident BPF program set cannot be determined at the time
> > > > of
> > > > bpf_object loading and attaching, all BPF programs would
> > > > otherwise
> > > > need to be marked as autoload, leading to unnecessary overhead.
> > > > This patch addresses that inefficiency.
> > 
> > Can you elaborate on why it's impossible to determine which BPF
> > programs should be loaded before BPF object load step?
> > 

The main use case for this patch is large applications that need to
dynamically load/unload BPF programs. Our specific use case is a
continuously-running security application with a dynamically-
reconfigurable feature set. As part of that reconfiguration, BPF
programs may get loaded/unloaded on-the-fly. Restarting the entire
application during reconfiguration is undesirable, as critical state
data can be lost and loading hundreds of BPF programs is time-
consuming.

The above points apply more generically to *any* application that
requires dynamic loading/unloading. Reconfiguration can be done via a
restart, but that has drawbacks:
(a) Losing any non-persistent application state on restart. In our
case, this creates a lapse in security that could be exploited by
adversaries.
(b) In applications with many programs, load+attach can take a long
time. We measured load+attach of ~100 BPF programs taking ~10 seconds
when done with current libbpf serially. Dynamically loading only the
programs needed avoids wasting memory and CPU cycles.
(c) The application itself might take a long time to restart, separate
from the BPF load/attach time. By loading dynamically, the BPF programs
can take effect much sooner and avoid wasted restart cycles.

This patch set also permits loading BPF programs in parallel if the
application wishes. We tested parallel loading with 200+ BPF programs
and found the load time dropped from 18 seconds to 5 seconds when done
in parallel on a 6.8 kernel.

In the future, this approach could also allow maps to not be
autoloaded, further saving on memory if no program needs the underlying
map.

In summary, we believe dynamic loading of BPF programs is an important
capability that will improve the performance of CrowdStrike's security
applications as well as being useful to other applications that want to
avoid restarts.
>