From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90131C433E1 for ; Mon, 1 Jun 2020 18:06:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3C69D207D0 for ; Mon, 1 Jun 2020 18:06:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C69D207D0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A499580007; Mon, 1 Jun 2020 14:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FB6F8E0006; Mon, 1 Jun 2020 14:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9106980007; Mon, 1 Jun 2020 14:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 747FD8E0006 for ; Mon, 1 Jun 2020 14:06:36 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3070D8248047 for ; Mon, 1 Jun 2020 18:06:36 +0000 (UTC) X-FDA: 76881423192.13.owl70_73cc2b195a448 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 162D818140B74 for ; Mon, 1 Jun 2020 18:06:36 +0000 (UTC) X-HE-Tag: owl70_73cc2b195a448 X-Filterd-Recvd-Size: 4545 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Mon, 1 Jun 2020 18:06:35 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 3AFDB2A2AF4 From: Gabriel Krisman Bertazi To: Andy Lutomirski Cc: Paul Gofman , Linux-MM , LKML , kernel@collabora.com, Thomas Gleixner , Kees Cook , Will Drewry , "H . Peter Anvin" , Zebediah Figura Subject: Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas Organization: Collabora References: <85367hkl06.fsf@collabora.com> <079539BF-F301-47BA-AEAD-AED23275FEA1@amacapital.net> <50a9e680-6be1-ff50-5c82-1bf54c7484a9@gmail.com> Date: Mon, 01 Jun 2020 14:06:30 -0400 In-Reply-To: (Andy Lutomirski's message of "Sun, 31 May 2020 14:03:48 -0700") Message-ID: <85y2p664pl.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 162D818140B74 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Andy Lutomirski writes: > On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski wrote: >> >> >> 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. > > Let me try to flesh this out a little. > > A task could install a syscall emulation filter (maybe using the > seccomp() syscall, maybe using something else). There would be at > most one such filter per process. Upon doing a syscall, the kernel > will first do initial syscall fixups (e.g. SYSENTER/SYSCALL32 magic > argument translation) and would then invoke the filter. The filter is > an eBPF program (sorry Kees) and, as input, it gets access to the > task's register state and to an indication of which type of syscall > entry this was. This will inherently be rather architecture specific > -- x86 choices could be int80, int80(translated), and syscall64. (We > could expose SYSCALL32 separately, I suppose, but SYSENTER is such a > mess that I'm not sure this would be productive.) The program can > access user memory, and it returns one of two results: allow the > syscall or send SIGSYS. If the program tries to access user memory > and faults, the result is SIGSYS. > > (I would love to do this with cBPF, but I'm not sure how to pull this > off. Accessing user memory is handy for making the lookup flexible > enough to detect Windows vs Linux. It would be *really* nice to > finally settle the unprivileged eBPF subset discussion so that we can > figure out how to make eBPF work here.) > > execve() clears the filter. clone() copies the filter. > > Does this seem reasonable? Is the implementation complexity small > enough? Is the eBPF thing going to be a showstopper? > > Using a signal instead of a bespoke thunk simplifies a lot of thorny > details but is also enough slower that catching all syscalls might be > a performance problem. If we can have something close to the numbers you shared, it seems to be good for us. Using the thunk instead of a signal seems very interesting for performance. Though, I'm not convinced about this not being part of seccomp just because it is not security. The suggestion from Kees to convert seccomp to eBPF filters and stack them would provide similar semantics and reuse the infrastructure. Finnaly, as you said, I'm afraid that eBPF will be a show stopper, unless unpriviledged eBPF becomes a thing. Wine cannot count on CAP_SYS_ADMIN. -- Gabriel Krisman Bertazi