On Fri, May 29, 2020 at 08:43:56AM -0700, Alexei Starovoitov wrote: > On Fri, May 29, 2020 at 5:50 AM zhujianwei (C) <zhujianwei7@xxxxxxxxxx> wrote: > > > > Hi, all > > > > We're using seccomp to increase container security, but bpf rules filter causes performance to deteriorate. So, is there a good solution to improve performance, or can we add a simplified seccomp mode to improve performance? Yes, there are already plans for a simple syscall bitmap[1] seccomp feature. > I don't think your hunch at where cpu is spending cycles is correct. > Could you please do two experiments: > 1. try trivial seccomp bpf prog that simply returns 'allow' > 2. replace bpf_prog_run_pin_on_cpu() in seccomp.c with C code > that returns 'allow' and make sure it's noinline or in a different C file, > so that compiler doesn't optimize the whole seccomp_run_filters() into a nop. > > Then measure performance of both. > I bet you'll see exactly the same numbers. Android has already done this, it appeared to not be the same. Calling into a SECCOMP_RET_ALLOW filter had a surprisingly high cost. I'll see if I can get you the numbers. I was frankly quite surprised -- I understood the bulk of the seccomp overhead to be in taking the TIF_WORK path, copying arguments, etc, but something else is going on there. -Kees [1] https://lore.kernel.org/lkml/202005181120.971232B7B@keescook/ -- Kees Cook
