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@xxxxxxxxxxxx> wrote: > > Did you see the RFC series for this? > > > > https://lore.kernel.org/lkml/20200616074934.1600036-1-keescook@xxxxxxxxxxxx/ > > [...] > > Which also includes updated benchmarking: > > > > https://lore.kernel.org/lkml/20200616074934.1600036-6-keescook@xxxxxxxxxxxx/ > > 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@xxxxxxxxxxxx/ -- Kees Cook
