From: Daniel Borkmann <daniel@iogearbox.net>
To: Nicolas Schichan <nschichan@freebox.fr>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@amacapital.net>,
Will Drewry <wad@chromium.org>,
linux-kernel@vger.kernel.org, ast@plumgrid.com,
davem@davemloft.net
Subject: Re: [PATCH 2/4] seccomp: rework seccomp_prepare_filter().
Date: Thu, 30 Apr 2015 14:46:37 +0200 [thread overview]
Message-ID: <5542242D.1090502@iogearbox.net> (raw)
In-Reply-To: <55421FA5.2070906@freebox.fr>
On 04/30/2015 02:27 PM, Nicolas Schichan wrote:
...
> I'll take more care about the receiver list for the v2 of this serie.
Ok, cool.
>> I see, you need that to make it available to the old bpf_jit_compile()
>> for probing on classic JITs. Actually, I really would prefer, if instead
>> of duplicating that code, you could export bpf_prepare_filter() and
>> pass seccomp_check_filter() as an argument to bpf_prepare_filter().
>
> Just to be sure you want me to pass a pointer to seccomp_check_filter to
> bpf_prepare_filter so that it can run it between bpf_check_classic() and
> bpf_jit_compile ?
For example, what comes to mind is something along these lines:
struct bpf_prog *
bpf_prepare_filter(struct bpf_prog *fp,
int (*aux_trans_classic)(struct sock_filter *filter,
unsigned int flen))
{
int err;
fp->bpf_func = NULL;
fp->jited = false;
err = bpf_check_classic(fp->insns, fp->len);
if (err) {
__bpf_prog_release(fp);
return ERR_PTR(err);
}
/* There might be additional checks and transformations
* needed on classic filters, f.e. in case of seccomp.
*/
if (aux_trans_classic) {
err = aux_trans_classic(fp->insns,
fp->len);
if (err) {
__bpf_prog_release(fp);
return ERR_PTR(err);
}
}
/* Probe if we can JIT compile the filter and if so, do
* the compilation of the filter.
*/
bpf_jit_compile(fp);
/* JIT compiler couldn't process this filter, so do the
* internal BPF translation for the optimized interpreter.
*/
if (!fp->jited)
fp = bpf_migrate_filter(fp);
return fp;
}
From seccomp side, you invoke:
... bpf_prepare_filter(fp, seccomp_check_filter);
I would actually like to see that customized code in seccomp_prepare_filter()
further reduced instead of increased, would certainly make it easier to
maintain and understand.
Do you think something like the above is possible?
>> Otherwise, in case bpf_prepare_filter() changes, people will easily
>> forget to update seccomp related code, really.
>
> Fair point.
>
> Thanks,
Thanks a lot,
Daniel
next prev parent reply other threads:[~2015-04-30 12:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-29 13:37 [PATCH 0/4] Seccomp filter JIT support on ARM Nicolas Schichan
2015-04-29 13:37 ` Nicolas Schichan
2015-04-29 13:37 ` [PATCH 1/4] net: filter: make bpf_migrate_filter available outside of net/core/filter.c Nicolas Schichan
2015-04-29 13:37 ` [PATCH 2/4] seccomp: rework seccomp_prepare_filter() Nicolas Schichan
2015-04-29 17:12 ` Daniel Borkmann
2015-04-30 12:27 ` Nicolas Schichan
2015-04-30 12:46 ` Daniel Borkmann [this message]
2015-04-30 14:12 ` Nicolas Schichan
2015-04-29 13:37 ` [PATCH 3/4] ARM: net: add JIT support for loads from struct seccomp_data Nicolas Schichan
2015-04-29 13:37 ` Nicolas Schichan
2015-04-29 13:37 ` [PATCH 4/4] ARM: net fix emit_udiv() for BPF_ALU | BPF_DIV | BPF_K intruction Nicolas Schichan
2015-04-29 13:37 ` Nicolas Schichan
2015-05-01 17:37 ` Russell King - ARM Linux
2015-05-01 17:37 ` Russell King - ARM Linux
2015-05-04 16:16 ` Nicolas Schichan
2015-05-04 16:16 ` Nicolas Schichan
2015-05-04 17:57 ` Russell King - ARM Linux
2015-05-04 17:57 ` Russell King - ARM Linux
2015-04-29 16:37 ` [PATCH 0/4] Seccomp filter JIT support on ARM Daniel Borkmann
2015-04-29 16:37 ` Daniel Borkmann
2015-04-30 12:35 ` Nicolas Schichan
2015-04-30 12:35 ` Nicolas Schichan
2015-04-30 12:51 ` Daniel Borkmann
2015-04-30 12:51 ` Daniel Borkmann
2015-04-30 17:17 ` Alexei Starovoitov
2015-04-30 17:17 ` Alexei Starovoitov
2015-04-29 16:46 ` Alexei Starovoitov
2015-04-29 16:46 ` Alexei Starovoitov
2015-04-29 16:46 ` Alexei Starovoitov
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=5542242D.1090502@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=ast@plumgrid.com \
--cc=davem@davemloft.net \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=nschichan@freebox.fr \
--cc=wad@chromium.org \
/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.