Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas
Date:   Sun, 31 May 2020 18:51:40 -0700
Message-Id: <53C0BD81-A942-4BB3-8538-D5107E84C5CD@amacapital.net>
References: <8DF2868F-E756-4B33-A7AE-C61F4AB9ABB9@codeweavers.com>
Cc:     Andy Lutomirski <luto@kernel.org>, Paul Gofman <gofmanp@gmail.com>,
        Gabriel Krisman Bertazi <krisman@collabora.com>,
        Linux-MM <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>, kernel@collabora.com,
        Thomas Gleixner <tglx@linutronix.de>,
        Kees Cook <keescook@chromium.org>,
        Will Drewry <wad@chromium.org>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Zebediah Figura <zfigura@codeweavers.com>
In-Reply-To: <8DF2868F-E756-4B33-A7AE-C61F4AB9ABB9@codeweavers.com>
To:     Brendan Shanks <bshanks@codeweavers.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 31, 2020, at 4:50 PM, Brendan Shanks <bshanks@codeweavers.com> wrot=
e:
>=20
> =EF=BB=BF
>> On May 31, 2020, at 11:57 AM, Andy Lutomirski <luto@kernel.org> wrote:
>>=20
>> Using SECCOMP_RET_USER_NOTIF is likely to be considerably more
>> expensive than my scheme.  On a non-PTI system, my approach will add a
>> few tens of ns to each syscall.  On a PTI system, it will be worse.
>> But using any kind of notifier for all syscalls will cause a context
>> switch to a different user program for each syscall, and that will be
>> much slower.
>=20
> There=E2=80=99s also no way (at least to my understanding) to modify regis=
ter state from SECCOMP_RET_USER_NOTIF, which is how the existing -staging SI=
GSYS handler works:
>=20
> <https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-Sy=
scall_Emulation/0001-ntdll-Support-x86_64-syscall-emulation.patch#L62>
>=20
>> I think that the implementation may well want to live in seccomp, but
>> doing this as a seccomp filter isn't quite right.  It's not a security
>> thing -- it's an emulation thing.  Seccomp is all about making
>> inescapable sandboxes, but that's not what you're doing at all, and
>> the fact that seccomp filters are preserved across execve() sounds
>> like it'll be annoying for you.
>=20
> Definitely. Regardless of what approach is taken, we don=E2=80=99t want it=
 to persist across execve.
>=20
>> What if there was a special filter type that ran a BPF program on each
>> syscall, and the program was allowed to access user memory to make its
>> decisions, e.g. to look at some list of memory addresses.  But this
>> would explicitly *not* be a security feature -- execve() would remove
>> the filter, and the filter's outcome would be one of redirecting
>> execution or allowing the syscall.  If the "allow" outcome occurs,
>> then regular seccomp filters run.  Obviously the exact semantics here
>> would need some care.
>=20
> Although if that=E2=80=99s running a BPF filter on every syscall, wouldn=E2=
=80=99t it also incur the ~10% overhead that Paul and Gabriel have seen with=
 existing seccomp?
>=20
>=20

Unlikely. Some benchmarking is needed, but the seccomp ptrace overhead is li=
kely *huge* compared to the overhead of just a filter.

As wild guess numbers on made up modern hardware, cache hot:

Empty syscall: 50ns, or 300ns with PTI

Empty syscall accepted by simple seccomp filter: 10ns more than an empty sys=
call without seccomp

Seccomp ptrace round trip: 6 us  Worse with PTI

Seccomp user notif round trip: 4 us

Syscall hypothetically redirected back to same process: about the same as an=
 empty filtered accepted syscall, plus however long it takes to run the hand=
ler. Add 900ns if using SIGSYS instead of plain redirection. Add an extra 50=
0ns on current kernels because signal delivery sucks, but I can fix this.

Take these numbers with a huge grain of salt.  But the point is that the BPF=
 part is the least of your worries.=