+ BPF maintainers On Wed, Oct 4, 2023 at 2:02 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Tue, Oct 03, 2023 at 08:38:34AM +0000, Hengqi Chen wrote: > > This patchset introduces two new operations which essentially > > splits the SECCOMP_SET_MODE_FILTER process into two steps: > > SECCOMP_LOAD_FILTER and SECCOMP_ATTACH_FILTER. > > > > The SECCOMP_LOAD_FILTER loads the filter and returns a fd > > which can be pinned to bpffs. This extends the lifetime of the > > filter and thus can be reused by different processes. > > With this new operation, we can eliminate a hot path of JITing > > BPF program (the filter) where we apply the same seccomp filter > > to thousands of micro VMs on a bare metal instance. > > > > The SECCOMP_ATTACH_FILTER is used to attach a loaded filter. > > The filter is represented by a fd which is either returned > > from SECCOMP_LOAD_FILTER or obtained from bpffs using bpf syscall. > > Interesting! I like this idea, thanks for writing it up. > > Two design notes: > > - Can you reuse/refactor seccomp_prepare_filter() instead of duplicating > the logic into two new functions? > Sure, will do. > - Is there a way to make sure the BPF program coming from the fd is one > that was built via SECCOMP_LOAD_FILTER? (I want to make sure we can > never confuse a non-seccomp program into getting loaded into seccomp.) > Maybe we can add a new prog type enum like BPF_PROG_TYPE_SECCOMP for seccomp filter. > -Kees > > -- > Kees Cook > Cheers, -- Hengqi
