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

Kees Cook
2020-09-24T06:52:26Z

On Wed, Sep 23, 2020 at 05:54:51PM -0500, YiFei Zhu wrote:
> On Wed, Sep 23, 2020 at 2:26 PM Kees Cook <keescook@chromium.org> wrote:
> > Did you see the RFC series for this?
> >
> > https://lore.kernel.org/lkml/20200616074934.1600036-1-keescook@chromium.org/
> > [...]
> > Which also includes updated benchmarking:
> >
> > https://lore.kernel.org/lkml/20200616074934.1600036-6-keescook@chromium.org/
>
> Nice. I was not aware of that series. Looking at it, it seems that our
> reasoning for checking arch and nr only, and verify if the filter
> accesses anything else, is the same. However, the approach in that RFC
> used was some page table dark magic, and it has been concluded that an
> emulator is superior. Was there a seperate patch series with emulator?
> If not, would you mind me cherry-picking some of your changes in that
> series?

I've sent that series refreshed with Jann's emulator now[1]. (Which I
see you've replied to as well, but I figured I'd just link these threads
for any future archaeology. ;)

> Also, I see that BPF_AND is said to be used in the discussion of the
> linked series. I think it wouldn't hurt to emulate a few BPF_ALU so
> I'll add that.

If you could add ALU|AND, that would get us complete coverage for
libseccomp and Chrome. I don't want the emulator to get any more complex
than that, as I view it as fairly high risk part. As you can see, I
tried really hard to _not_ use an emulator in the RFC. ;)

[1] https://lore.kernel.org/lkml/20200923232923.3142503-1-keescook@chromium.org/

--
Kees Cook