From: Paul Moore <paul@paul-moore.com> To: Kees Cook <keescook@chromium.org>, Tom Hromatka <tom.hromatka@oracle.com> Cc: Andrea Arcangeli <aarcange@redhat.com>, Giuseppe Scrivano <gscrivan@redhat.com>, Will Drewry <wad@chromium.org>, bpf <bpf@vger.kernel.org>, Jann Horn <jannh@google.com>, YiFei Zhu <yifeifz2@illinois.edu>, Linux API <linux-api@vger.kernel.org>, Linux Containers <containers@lists.linux-foundation.org>, Tobin Feldman-Fitzthum <tobin@ibm.com>, Hubertus Franke <frankeh@us.ibm.com>, Andy Lutomirski <luto@amacapital.net>, Valentin Rothberg <vrothber@redhat.com>, Dimitrios Skarlatos <dskarlat@cs.cmu.edu>, Jack Chen <jianyan2@illinois.edu>, Josep Torrellas <torrella@illinois.edu>, Tianyin Xu <tyxu@illinois.edu>, kernel list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 4/6] seccomp: Emulate basic filters for constant action results Date: Thu, 24 Sep 2020 11:28:55 -0400 [thread overview] Message-ID: <CAHC9VhQpto1KuL7PhjtdjtAjJ2nC+rZNSM7+nSZ_ksqGXbhY+Q@mail.gmail.com> (raw) In-Reply-To: <202009240038.864365E@keescook> On Thu, Sep 24, 2020 at 3:46 AM Kees Cook <keescook@chromium.org> wrote: > On Thu, Sep 24, 2020 at 01:47:47AM +0200, Jann Horn wrote: > > On Thu, Sep 24, 2020 at 1:29 AM Kees Cook <keescook@chromium.org> wrote: > > > This emulates absolutely the most basic seccomp filters to figure out > > > if they will always give the same results for a given arch/nr combo. > > > > > > Nearly all seccomp filters are built from the following ops: > > > > > > BPF_LD | BPF_W | BPF_ABS > > > BPF_JMP | BPF_JEQ | BPF_K > > > BPF_JMP | BPF_JGE | BPF_K > > > BPF_JMP | BPF_JGT | BPF_K > > > BPF_JMP | BPF_JSET | BPF_K > > > BPF_JMP | BPF_JA > > > BPF_RET | BPF_K > > > > > > These are now emulated to check for accesses beyond seccomp_data::arch > > > or unknown instructions. > > > > > > Not yet implemented are: > > > > > > BPF_ALU | BPF_AND (generated by libseccomp and Chrome) > > > > BPF_AND is normally only used on syscall arguments, not on the syscall > > number or the architecture, right? And when a syscall argument is > > loaded, we abort execution anyway. So I think there is no need to > > implement those? > > Is that right? I can't actually tell what libseccomp is doing with > ALU|AND. It looks like it's using it for building jump lists? There is an ALU|AND op in the jump resolution code, but that is really just if libseccomp needs to fixup the accumulator because a code block is expecting a masked value (right now that would only be a syscall argument, not the syscall number itself). > Paul, Tom, under what cases does libseccomp emit ALU|AND into filters? Presently the only place where libseccomp uses ALU|AND is when the masked equality comparison is used for comparing syscall arguments (SCMP_CMP_MASKED_EQ). I can't honestly say I have any good information about how often that is used by libseccomp callers, but if I do a quick search on GitHub for "SCMP_CMP_MASKED_EQ" I see 2k worth of code hits; take that for whatever it is worth. Tom may have some more/better information. Of course no promises on future use :) As one quick example, I keep thinking about adding the instruction pointer to the list of things that can be compared as part of a libseccomp rule, and if we do that I would expect that we would want to also allow a masked comparison (and utilize another ALU|AND bpf op there). However, I'm not sure how useful that would be in practice. -- paul moore www.paul-moore.com _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul@paul-moore.com> To: Kees Cook <keescook@chromium.org>, Tom Hromatka <tom.hromatka@oracle.com> Cc: Jann Horn <jannh@google.com>, YiFei Zhu <yifeifz2@illinois.edu>, Christian Brauner <christian.brauner@ubuntu.com>, Tycho Andersen <tycho@tycho.pizza>, Andy Lutomirski <luto@amacapital.net>, Will Drewry <wad@chromium.org>, Andrea Arcangeli <aarcange@redhat.com>, Giuseppe Scrivano <gscrivan@redhat.com>, Tobin Feldman-Fitzthum <tobin@ibm.com>, Dimitrios Skarlatos <dskarlat@cs.cmu.edu>, Valentin Rothberg <vrothber@redhat.com>, Hubertus Franke <frankeh@us.ibm.com>, Jack Chen <jianyan2@illinois.edu>, Josep Torrellas <torrella@illinois.edu>, Tianyin Xu <tyxu@illinois.edu>, bpf <bpf@vger.kernel.org>, Linux Containers <containers@lists.linux-foundation.org>, Linux API <linux-api@vger.kernel.org>, kernel list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 4/6] seccomp: Emulate basic filters for constant action results Date: Thu, 24 Sep 2020 11:28:55 -0400 [thread overview] Message-ID: <CAHC9VhQpto1KuL7PhjtdjtAjJ2nC+rZNSM7+nSZ_ksqGXbhY+Q@mail.gmail.com> (raw) In-Reply-To: <202009240038.864365E@keescook> On Thu, Sep 24, 2020 at 3:46 AM Kees Cook <keescook@chromium.org> wrote: > On Thu, Sep 24, 2020 at 01:47:47AM +0200, Jann Horn wrote: > > On Thu, Sep 24, 2020 at 1:29 AM Kees Cook <keescook@chromium.org> wrote: > > > This emulates absolutely the most basic seccomp filters to figure out > > > if they will always give the same results for a given arch/nr combo. > > > > > > Nearly all seccomp filters are built from the following ops: > > > > > > BPF_LD | BPF_W | BPF_ABS > > > BPF_JMP | BPF_JEQ | BPF_K > > > BPF_JMP | BPF_JGE | BPF_K > > > BPF_JMP | BPF_JGT | BPF_K > > > BPF_JMP | BPF_JSET | BPF_K > > > BPF_JMP | BPF_JA > > > BPF_RET | BPF_K > > > > > > These are now emulated to check for accesses beyond seccomp_data::arch > > > or unknown instructions. > > > > > > Not yet implemented are: > > > > > > BPF_ALU | BPF_AND (generated by libseccomp and Chrome) > > > > BPF_AND is normally only used on syscall arguments, not on the syscall > > number or the architecture, right? And when a syscall argument is > > loaded, we abort execution anyway. So I think there is no need to > > implement those? > > Is that right? I can't actually tell what libseccomp is doing with > ALU|AND. It looks like it's using it for building jump lists? There is an ALU|AND op in the jump resolution code, but that is really just if libseccomp needs to fixup the accumulator because a code block is expecting a masked value (right now that would only be a syscall argument, not the syscall number itself). > Paul, Tom, under what cases does libseccomp emit ALU|AND into filters? Presently the only place where libseccomp uses ALU|AND is when the masked equality comparison is used for comparing syscall arguments (SCMP_CMP_MASKED_EQ). I can't honestly say I have any good information about how often that is used by libseccomp callers, but if I do a quick search on GitHub for "SCMP_CMP_MASKED_EQ" I see 2k worth of code hits; take that for whatever it is worth. Tom may have some more/better information. Of course no promises on future use :) As one quick example, I keep thinking about adding the instruction pointer to the list of things that can be compared as part of a libseccomp rule, and if we do that I would expect that we would want to also allow a masked comparison (and utilize another ALU|AND bpf op there). However, I'm not sure how useful that would be in practice. -- paul moore www.paul-moore.com
next prev parent reply other threads:[~2020-09-24 15:29 UTC|newest] Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-23 23:29 [PATCH v1 0/6] seccomp: Implement constant action bitmaps Kees Cook 2020-09-23 23:29 ` Kees Cook 2020-09-23 23:29 ` [PATCH 1/6] seccomp: Introduce SECCOMP_PIN_ARCHITECTURE Kees Cook 2020-09-23 23:29 ` Kees Cook 2020-09-24 0:41 ` Jann Horn via Containers 2020-09-24 0:41 ` Jann Horn 2020-09-24 7:11 ` Kees Cook 2020-09-24 7:11 ` Kees Cook 2020-09-23 23:29 ` [PATCH 2/6] x86: Enable seccomp architecture tracking Kees Cook 2020-09-23 23:29 ` Kees Cook 2020-09-24 0:45 ` Jann Horn via Containers 2020-09-24 0:45 ` Jann Horn 2020-09-24 7:12 ` Kees Cook 2020-09-24 7:12 ` Kees Cook 2020-09-23 23:29 ` [PATCH 3/6] seccomp: Implement constant action bitmaps Kees Cook 2020-09-23 23:29 ` Kees Cook 2020-09-24 0:25 ` Jann Horn via Containers 2020-09-24 0:25 ` Jann Horn 2020-09-24 7:36 ` Kees Cook 2020-09-24 7:36 ` Kees Cook 2020-09-24 8:07 ` YiFei Zhu 2020-09-24 8:07 ` YiFei Zhu 2020-09-24 8:15 ` Kees Cook 2020-09-24 8:15 ` Kees Cook 2020-09-24 8:22 ` YiFei Zhu 2020-09-24 8:22 ` YiFei Zhu 2020-09-24 12:28 ` Jann Horn via Containers 2020-09-24 12:28 ` Jann Horn 2020-09-24 12:37 ` David Laight 2020-09-24 12:37 ` David Laight 2020-09-24 12:56 ` Jann Horn via Containers 2020-09-24 12:56 ` Jann Horn [not found] ` <DM6PR11MB271492D0565E91475D949F5DEF390@DM6PR11MB2714.namprd11.prod.outlook.com> 2020-09-24 0:36 ` YiFei Zhu 2020-09-24 0:36 ` YiFei Zhu 2020-09-24 7:38 ` Kees Cook 2020-09-24 7:38 ` Kees Cook 2020-09-24 7:51 ` YiFei Zhu 2020-09-24 7:51 ` YiFei Zhu 2020-09-23 23:29 ` [PATCH 4/6] seccomp: Emulate basic filters for constant action results Kees Cook 2020-09-23 23:29 ` Kees Cook 2020-09-23 23:47 ` Jann Horn via Containers 2020-09-23 23:47 ` Jann Horn 2020-09-24 7:46 ` Kees Cook 2020-09-24 7:46 ` Kees Cook 2020-09-24 15:28 ` Paul Moore [this message] 2020-09-24 15:28 ` Paul Moore 2020-09-24 19:52 ` Kees Cook 2020-09-24 19:52 ` Kees Cook 2020-09-24 20:46 ` Paul Moore 2020-09-24 20:46 ` Paul Moore 2020-09-24 21:35 ` Kees Cook 2020-09-24 21:35 ` Kees Cook 2020-09-24 13:16 ` kernel test robot 2020-09-23 23:29 ` [PATCH 5/6] selftests/seccomp: Compare bitmap vs filter overhead Kees Cook 2020-09-23 23:29 ` Kees Cook 2020-09-23 23:29 ` [PATCH 6/6] [DEBUG] seccomp: Report bitmap coverage ranges Kees Cook 2020-09-23 23:29 ` Kees Cook 2020-09-24 13:40 ` [PATCH v1 0/6] seccomp: Implement constant action bitmaps Rasmus Villemoes 2020-09-24 13:40 ` Rasmus Villemoes 2020-09-24 13:58 ` YiFei Zhu 2020-09-24 13:58 ` YiFei Zhu 2020-09-25 5:56 ` Rasmus Villemoes 2020-09-25 5:56 ` Rasmus Villemoes 2020-09-25 7:07 ` YiFei Zhu 2020-09-25 7:07 ` YiFei Zhu 2020-09-26 18:11 ` YiFei Zhu 2020-09-26 18:11 ` YiFei Zhu 2020-09-28 20:04 ` Kees Cook 2020-09-28 20:04 ` Kees Cook 2020-09-28 20:16 ` YiFei Zhu 2020-09-28 20:16 ` YiFei Zhu 2020-09-24 14:05 ` Jann Horn via Containers 2020-09-24 14:05 ` Jann Horn 2020-09-24 18:57 ` Andrea Arcangeli 2020-09-24 18:57 ` Andrea Arcangeli 2020-09-24 19:18 ` Jann Horn via Containers 2020-09-24 19:18 ` Jann Horn [not found] ` <9dbe8e3bbdad43a1872202ff38c34ca2@DM5PR11MB1692.namprd11.prod.outlook.com> 2020-09-24 19:48 ` Tianyin Xu 2020-09-24 19:48 ` Tianyin Xu 2020-09-24 20:00 ` Kees Cook 2020-09-24 20:00 ` 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=CAHC9VhQpto1KuL7PhjtdjtAjJ2nC+rZNSM7+nSZ_ksqGXbhY+Q@mail.gmail.com \ --to=paul@paul-moore.com \ --cc=aarcange@redhat.com \ --cc=bpf@vger.kernel.org \ --cc=containers@lists.linux-foundation.org \ --cc=dskarlat@cs.cmu.edu \ --cc=frankeh@us.ibm.com \ --cc=gscrivan@redhat.com \ --cc=jannh@google.com \ --cc=jianyan2@illinois.edu \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=tobin@ibm.com \ --cc=tom.hromatka@oracle.com \ --cc=torrella@illinois.edu \ --cc=tyxu@illinois.edu \ --cc=vrothber@redhat.com \ --cc=wad@chromium.org \ --cc=yifeifz2@illinois.edu \ /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: linkBe 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.