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@xxxxxxxxxxxxxxx> 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. >
