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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAGMVDEEtNXWp4xOhC+EMa_Z_1KMQhKQohCKVY=Z70wTuLr5X+g@mail.gmail.com>
Date:   Thu, 24 Sep 2020 14:48:37 -0500
From:   Tianyin Xu <tyxu@...inois.edu>
To:     Jann Horn <jannh@...gle.com>
Cc:     Andrea Arcangeli <aarcange@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        "Zhu, YiFei" <yifeifz2@...inois.edu>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Tycho Andersen <tycho@...ho.pizza>,
        Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>,
        Giuseppe Scrivano <gscrivan@...hat.com>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Dimitrios Skarlatos <dskarlat@...cmu.edu>,
        Valentin Rothberg <vrothber@...hat.com>,
        Hubertus Franke <frankeh@...ibm.com>,
        "Chen, Jianyan" <jianyan2@...inois.edu>,
        "Torrellas, Josep" <torrella@...inois.edu>,
        bpf <bpf@...r.kernel.org>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Linux API <linux-api@...r.kernel.org>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/6] seccomp: Implement constant action bitmaps

On Thu, Sep 24, 2020 at 2:19 PM Jann Horn <jannh@...gle.com> wrote:
>
> On Thu, Sep 24, 2020 at 8:57 PM Andrea Arcangeli <aarcange@...hat.com> wrote:
> >
> > 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@chromium.org/
> > > alternative: https://lore.kernel.org/containers/cover.1600661418.git.yifeifz2@illinois.edu/
> > > 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@chromium.org/
> >
> > 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/

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/