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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 20EA8C433E0 for ; Mon, 1 Jun 2020 23:18:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DA8A3207D5 for ; Mon, 1 Jun 2020 23:18:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="L3qZgGCD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA8A3207D5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 605CD80007; Mon, 1 Jun 2020 19:18:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58E158E0006; Mon, 1 Jun 2020 19:18:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45E7F80007; Mon, 1 Jun 2020 19:18:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id 29E9E8E0006 for ; Mon, 1 Jun 2020 19:18:43 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D9108180AD802 for ; Mon, 1 Jun 2020 23:18:42 +0000 (UTC) X-FDA: 76882209684.08.deer52_4c02faf234250 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id B76E51819E772 for ; Mon, 1 Jun 2020 23:18:42 +0000 (UTC) X-HE-Tag: deer52_4c02faf234250 X-Filterd-Recvd-Size: 5385 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 1 Jun 2020 23:18:42 +0000 (UTC) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EEDF7207DF for ; Mon, 1 Jun 2020 23:18:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591053521; bh=vG7dpOcajSi/mt4/We78ONhQ6W10E0sko1pNjj1dhKo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=L3qZgGCD1KwPW+AzHVpCLxbtFMIbF8YoDBXINYIN9StTf6HaAHbtZYUevfjha89GT P4SXM5QubUZ7cE7/FYz9/lp6VGJohG7ThZqriBrgsA5x6aZQ7dmbKCmUMCL7/mTr2i gwuBMglfxUU18LuGxEbZ0DAhZL3Wc7Y2BHOtUXKw= Received: by mail-wr1-f54.google.com with SMTP id j10so1463156wrw.8 for ; Mon, 01 Jun 2020 16:18:40 -0700 (PDT) X-Gm-Message-State: AOAM532to7qsd/PrdBD8+1ptkz+C6IwAdwXjwUtvsS5IGVS/EqEqwb6b kcNx41ckC1PF01d4BxCaXdnJZsrNHwOdNhrpQg47CQ== X-Google-Smtp-Source: ABdhPJwcrV44K9KnQPiete8Q8IGAa4fv5gTnd/zkm7UMyds9Aoe3lJR00gDthiHYjn5UnatttJZS0INS+BA4D1pJlvY= X-Received: by 2002:adf:ea11:: with SMTP id q17mr23050302wrm.75.1591053519479; Mon, 01 Jun 2020 16:18:39 -0700 (PDT) MIME-Version: 1.0 References: <85367hkl06.fsf@collabora.com> <079539BF-F301-47BA-AEAD-AED23275FEA1@amacapital.net> <50a9e680-6be1-ff50-5c82-1bf54c7484a9@gmail.com> <202006011306.2E31FDED@keescook> In-Reply-To: <202006011306.2E31FDED@keescook> From: Andy Lutomirski Date: Mon, 1 Jun 2020 16:18:27 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas To: Kees Cook Cc: Andy Lutomirski , Paul Gofman , Gabriel Krisman Bertazi , Linux-MM , LKML , kernel@collabora.com, Thomas Gleixner , Will Drewry , "H . Peter Anvin" , Zebediah Figura Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B76E51819E772 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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: On Mon, Jun 1, 2020 at 1:08 PM Kees Cook wrote: > > On Sun, May 31, 2020 at 02:03:48PM -0700, Andy Lutomirski wrote: > > 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 > > FWIW, I agree: something like this needs to use eBPF -- this isn't > being designed as a security boundary. It's more like eBPF ptrace. On a bit more consideration, I think that I have the model a bit wrong. We shouldn't think of this as a *syscall* filter but as a filter for architectural privilege transitions in general. After all, there is no particular guarantee that any given emulated program has a syscall ABI that is even remotely compatible with Linux. So maybe the filter is fed events like SYSCALL64, SYSCALL32, SYSENTER, #GP, #PF (the bad kind that would otherwise get a signal), #UD, etc. And the filter can examine process state and take some reasonable action. Think if it as a personality scheme that's programmable by user code. I imagine that even schemes like NaCl could make some use of this. This allows all kinds of interesting things. For example, it should give Wine a much nicer emulation of Windows SEH and vectored signals. And maybe it could finally allow Linux userspace to have some sensible equivalent of those Windows features -- being able to write library code that could sanely handle, say, math errors would be quite handy. This could be mocked up with cBPF, but I think a cBPF version will struggle to be a performant solution for Wine because it will have a hard time distinguishing between Windows and Linux syscalls. --Andy