From: Andy Lutomirski <luto@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Christian Brauner <christian@brauner.io>,
Sargun Dhillon <sargun@sargun.me>,
Tycho Andersen <tycho@tycho.ws>, Jann Horn <jannh@google.com>,
"zhujianwei (C)" <zhujianwei7@huawei.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Matthew Wilcox <willy@infradead.org>,
Andy Lutomirski <luto@kernel.org>, Will Drewry <wad@chromium.org>,
Shuah Khan <shuah@kernel.org>, Matt Denton <mpdenton@google.com>,
Chris Palmer <palmer@google.com>,
Jeffrey Vander Stoep <jeffv@google.com>,
Aleksa Sarai <cyphar@cyphar.com>,
Hehuazhen <hehuazhen@huawei.com>, X86 ML <x86@kernel.org>,
Linux Containers <containers@lists.linux-foundation.org>,
LSM List <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [RFC][PATCH 0/8] seccomp: Implement constant action bitmaps
Date: Tue, 16 Jun 2020 10:01:43 -0700 [thread overview]
Message-ID: <CALCETrVLA22khom-iSu5iTJGKfUykOnwyz8j7Tm9g6hWW_e0Aw@mail.gmail.com> (raw)
In-Reply-To: <20200616074934.1600036-1-keescook@chromium.org>
On Tue, Jun 16, 2020 at 12:49 AM Kees Cook <keescook@chromium.org> wrote:
>
> Hi,
>
> In order to build this mapping at filter attach time, each filter is
> executed for every syscall (under each possible architecture), and
> checked for any accesses of struct seccomp_data that are not the "arch"
> nor "nr" (syscall) members. If only "arch" and "nr" are examined, then
> there is a constant mapping for that syscall, and bitmaps can be updated
> accordingly. If any accesses happen outside of those struct members,
> seccomp must not bypass filter execution for that syscall, since program
> state will be used to determine filter action result.
>
> During syscall action probing, in order to determine whether other members
> of struct seccomp_data are being accessed during a filter execution,
> the struct is placed across a page boundary with the "arch" and "nr"
> members in the first page, and everything else in the second page. The
> "page accessed" flag is cleared in the second page's PTE, and the filter
> is run. If the "page accessed" flag appears as set after running the
> filter, we can determine that the filter looked beyond the "arch" and
> "nr" members, and exclude that syscall from the constant action bitmaps.
This is... evil. I don't know how I feel about it. It's also
potentially quite slow.
I don't suppose you could, instead, instrument the BPF code to get at
this without TLB hackery? Or maybe try to do some real symbolic
execution of the BPF code?
--Andy
next prev parent reply other threads:[~2020-06-16 17:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-16 7:49 [RFC][PATCH 0/8] seccomp: Implement constant action bitmaps Kees Cook
2020-06-16 7:49 ` [PATCH 1/8] selftests/seccomp: Improve calibration loop Kees Cook
2020-06-16 7:49 ` [PATCH 2/8] seccomp: Use pr_fmt Kees Cook
2020-06-16 7:49 ` [PATCH 3/8] seccomp: Introduce SECCOMP_PIN_ARCHITECTURE Kees Cook
2020-06-16 16:56 ` Andy Lutomirski
2020-06-17 15:25 ` Jann Horn
2020-06-17 15:29 ` Andy Lutomirski
2020-06-17 15:31 ` Jann Horn
2020-06-16 7:49 ` [PATCH 4/8] seccomp: Implement constant action bitmaps Kees Cook
2020-06-16 12:14 ` Jann Horn
2020-06-16 15:48 ` Kees Cook
2020-06-16 18:36 ` Jann Horn
2020-06-16 18:49 ` Kees Cook
2020-06-16 21:13 ` Andy Lutomirski
2020-06-16 14:40 ` Dave Hansen
2020-06-16 16:01 ` Kees Cook
2020-06-16 7:49 ` [PATCH 5/8] selftests/seccomp: Compare bitmap vs filter overhead Kees Cook
2020-06-16 7:49 ` [PATCH 6/8] x86: Provide API for local kernel TLB flushing Kees Cook
2020-06-16 16:59 ` Andy Lutomirski
2020-06-16 18:37 ` Kees Cook
2020-06-16 7:49 ` [PATCH 7/8] x86: Enable seccomp constant action bitmaps Kees Cook
2020-06-16 7:49 ` [PATCH 8/8] [DEBUG] seccomp: Report bitmap coverage ranges Kees Cook
2020-06-16 17:01 ` Andy Lutomirski [this message]
2020-06-16 18:35 ` [RFC][PATCH 0/8] seccomp: Implement constant action bitmaps Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrVLA22khom-iSu5iTJGKfUykOnwyz8j7Tm9g6hWW_e0Aw@mail.gmail.com \
--to=luto@kernel.org \
--cc=christian@brauner.io \
--cc=containers@lists.linux-foundation.org \
--cc=cyphar@cyphar.com \
--cc=dave.hansen@linux.intel.com \
--cc=hehuazhen@huawei.com \
--cc=jannh@google.com \
--cc=jeffv@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mpdenton@google.com \
--cc=palmer@google.com \
--cc=sargun@sargun.me \
--cc=shuah@kernel.org \
--cc=tycho@tycho.ws \
--cc=wad@chromium.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=zhujianwei7@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.