Re: [RFC PATCH seccomp 0/2] seccomp: Add bitmap cache of arg-independent filter results that allow syscalls

Kees Cook
2020-09-23T19:26:25Z

On Mon, Sep 21, 2020 at 12:35:16AM -0500, YiFei Zhu wrote:
> In the past Kees proposed [2] to have an "add this syscall to the
> reject bitmask". It is indeed much easier to securely make a reject
> accelerator to pre-filter syscalls before passing to the BPF
> filters, considering it could only strengthen the security provided
> by the filter. However, ultimately, filter rejections are an
> exceptional / rare case. Here, instead of accelerating what is
> rejected, we accelerate what is allowed. In order not to compromise
> the security rules the BPF filters defined, any accept-side
> accelerator must complement the BPF filters rather than replacing them.

Did you see the RFC series for this?

https://lore.kernel.org/lkml/20200616074934.1600036-1-keescook@chromium.org/

> Without cache, seccomp_benchmark:
> Current BPF sysctl settings:
> net.core.bpf_jit_enable = 1
> net.core.bpf_jit_harden = 0
> Calibrating sample size for 15 seconds worth of syscalls ...
> Benchmarking 23486415 syscalls...
> 16.079642020 - 1.013345439 = 15066296581 (15.1s)
> getpid native: 641 ns
> 32.080237410 - 16.080763500 = 15999473910 (16.0s)
> getpid RET_ALLOW 1 filter: 681 ns
> 48.609461618 - 32.081296173 = 16528165445 (16.5s)
> getpid RET_ALLOW 2 filters: 703 ns
> Estimated total seccomp overhead for 1 filter: 40 ns
> Estimated total seccomp overhead for 2 filters: 62 ns
> Estimated seccomp per-filter overhead: 22 ns
> Estimated seccomp entry overhead: 18 ns
>
> With cache:
> Current BPF sysctl settings:
> net.core.bpf_jit_enable = 1
> net.core.bpf_jit_harden = 0
> Calibrating sample size for 15 seconds worth of syscalls ...
> Benchmarking 23486415 syscalls...
> 16.059512499 - 1.014108434 = 15045404065 (15.0s)
> getpid native: 640 ns
> 31.651075934 - 16.060637323 = 15590438611 (15.6s)
> getpid RET_ALLOW 1 filter: 663 ns
> 47.367316169 - 31.652302661 = 15715013508 (15.7s)
> getpid RET_ALLOW 2 filters: 669 ns
> Estimated total seccomp overhead for 1 filter: 23 ns
> Estimated total seccomp overhead for 2 filters: 29 ns
> Estimated seccomp per-filter overhead: 6 ns
> Estimated seccomp entry overhead: 17 ns
>
> Depending on the run estimated seccomp overhead for 2 filters can be
> less than seccomp overhead for 1 filter, resulting in underflow to
> estimated seccomp per-filter overhead:
> Estimated total seccomp overhead for 1 filter: 27 ns
> Estimated total seccomp overhead for 2 filters: 21 ns
> Estimated seccomp per-filter overhead: 18446744073709551610 ns
> Estimated seccomp entry overhead: 33 ns

Which also includes updated benchmarking:

https://lore.kernel.org/lkml/20200616074934.1600036-6-keescook@chromium.org/

--
Kees Cook