linux-kernel - Re: [PATCH] seccomp: allow BPF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Mar 2020 18:17:34 -0400
From:   Anton Protopopov <a.s.protopopov@...il.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>,
        open list <linux-kernel@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH] seccomp: allow BPF_MOD ALU instructions

пн, 16 мар. 2020 г. в 17:24, Kees Cook <keescook@...omium.org>:
>
> On Mon, Mar 16, 2020 at 04:36:46PM +0000, Anton Protopopov wrote:
> > The BPF_MOD ALU instructions could be utilized by seccomp classic BPF filters,
> > but were missing from the explicit list of allowed calls since its introduction
> > in the original e2cfabdfd075 ("seccomp: add system call filtering using BPF")
> > commit.  Add support for these instructions by adding them to the allowed list
> > in the seccomp_check_filter function.
> >
> > Signed-off-by: Anton Protopopov <a.s.protopopov@...il.com>
>
> This has been suggested in the past, but was deemed ultimately redundant:
> https://lore.kernel.org/lkml/201908121035.06695C79F@keescook/

Yeah, Paul told me this right after I submitted the patch.

> Is there a strong reason it's needed?

I really don't have such a strong need in BPF_MOD, but let me tell why
I wanted to use it in the first place.

I've used this operation to speedup processing linear blacklist
filters. Namely, if you have a list of syscall numbers to blacklist,
you can do, say,

ldw [0]
mod #4
jeq #1, case1
jeq #1, case2
jeq #1, case3
case0:
...

and in every case to walk only a corresponding factor-list. In my case
I had a list of ~40 syscall numbers and after this change filter
executed in 17.25 instructions on average per syscall vs. 45
instructions for the linear filter (so this removes about 30
instructions penalty per every syscall). To replace "mod #4" I
actually used "and #3", but this obviously doesn't work for
non-power-of-two divisors. If I would use "mod 5", then it would give
me about 15.5 instructions on average.

Thanks,
Anton

>
> Thanks!
>
> -Kees
>
> > ---
> >  kernel/seccomp.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index b6ea3dcb57bf..cae7561b44d4 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -206,6 +206,8 @@ static int seccomp_check_filter(struct sock_filter *filter, unsigned int flen)
> >               case BPF_ALU | BPF_MUL | BPF_X:
> >               case BPF_ALU | BPF_DIV | BPF_K:
> >               case BPF_ALU | BPF_DIV | BPF_X:
> > +             case BPF_ALU | BPF_MOD | BPF_K:
> > +             case BPF_ALU | BPF_MOD | BPF_X:
> >               case BPF_ALU | BPF_AND | BPF_K:
> >               case BPF_ALU | BPF_AND | BPF_X:
> >               case BPF_ALU | BPF_OR | BPF_K:
> > --
> > 2.19.1
>
> --
> Kees Cook