Re: [PATCH v1 0/6] seccomp: Implement constant action bitmaps

On Thu, Sep 24, 2020 at 2:19 PM Jann Horn [off-list ref] wrote:

On Thu, Sep 24, 2020 at 8:57 PM Andrea Arcangeli [off-list ref] wrote:

quoted

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:

quoted

rfc: https://lore.kernel.org/lkml/20200616074934.1600036-1-keescook@chromium.org/ (local)
alternative: https://lore.kernel.org/containers/cover.1600661418.git.yifeifz2@illinois.edu/ (local)
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).

quoted

- 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@chromium.org/ (local)

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@chromium.org

You're missing that I did suggest the BPF emulation approach (with
code very similar to Kees' current code) back in June:
https://lore.kernel.org/lkml/CAG48ez1p=dR_2ikKq=xVxkoGg0fYpTBpkhJSv1w-6BG=76PAvw@mail.gmail.com/ (local)

I don't see it's a bad thing that two (or three?) teams come up with
the same ideas,
and I'm actually happy that the final solution is largely converging,
thanks to all the discussions so far.

It's better to collaborate and help each other, instead of racing on
two separate patches,
and everyone involved should be acknowledged.

Not sure if it matters, we actually started working on seccomp cache
in the end of 2018,
and our idea is to also support arguments in the cache.
We still have the paper draft sent to an academic conference at Apr 2019 :)
Unfortunately, our paper kept being rejected until recently.
Sadly, as academics, we prioritized papers over upstream.

I'm disclosing these not to dismiss anyone's innovations and hardwork.
I do really think we should work together to merge the right pieces of code,
instead of competing or ignoring others' effort.

--
Tianyin Xu
University of Illinois at Urbana-Champaign
https://tianyin.github.io/