Hello, I'm posting this only for the record, feel free to ignore. On Wed, Sep 23, 2020 at 04:29:17PM -0700, Kees Cook wrote: > rfc: https://lore.kernel.org/lkml/20200616074934.1600036-1-keescook@xxxxxxxxxxxx/ > alternative: https://lore.kernel.org/containers/cover.1600661418.git.yifeifz2@xxxxxxxxxxxx/ > v1: > - rebase to for-next/seccomp > - finish X86_X32 support for both pinning and bitmaps It's pretty clear the O(1) seccomp filter bitmap was first was proposed by your RFC in June (albeit it was located in the wrong place and is still in the wrong place in v1). > - replace TLB magic with Jann's emulator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's a pretty fundamental change in v1 compared to your the non-competing TLB magic technique you used in the RFC last June. The bitmap isn't the clever part of the patch, the bitmap can be reviewed in seconds, the difficult part to implement and to review is how you fill the bitmap and in that respect there's absolutely nothing in common in between the "rfc:" and the "alternative" link. In June your bitmap-filling engine was this: https://lore.kernel.org/lkml/20200616074934.1600036-5-keescook@xxxxxxxxxxxx/ Then on Sep 21 YiFei Zhu posted his new innovative BPF emulation innovation that obsoleted your TLB magic of June: https://lists.linuxfoundation.org/pipermail/containers/2020-September/042153.html And on Sep 23 instead of collaborating and helping YiFei Zhu to improve his BPF emulator, you posted the same technique that looks remarkably similar without giving YiFei Zhu any attribution and you instead attribute the whole idea to Jann Horn: https://lkml.kernel.org/r/20200923232923.3142503-5-keescook@xxxxxxxxxxxx Thanks, Andrea
