[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKU6vyaWgj4kKq0pBUYHa2hDMDOgtVghCWqpaD7riVe+KduOUA@mail.gmail.com>
Date: Mon, 29 Apr 2013 03:48:29 -0400
From: Xi Wang <xi.wang@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Daniel Borkmann <dborkman@...hat.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Will Drewry <wad@...omium.org>,
Eric Dumazet <edumazet@...gle.com>,
Russell King <linux@....linux.org.uk>,
David Laight <david.laight@...lab.com>,
"David S. Miller" <davem@...emloft.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Nicolas Schichan <nschichan@...ebox.fr>
Subject: Re: [PATCH v2 net-next 2/3] x86: bpf_jit_comp: support
BPF_S_ANC_SECCOMP_LD_W instruction
On Sat, Apr 27, 2013 at 9:21 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> I would feel more comfortable if you added :
>
> if (seen & SEEN_DATAREF) {
> pr_err_once("SECCOMP_LD_W assertion failed\n"):
> goto out;
> }
>
> This way, if BPF is changed in the future, but not the x86 JIT, we
> can have a working kernel.
>
> Ideally, we should add a SEEN_SKBREF to make sure rdi value can be
> scratched, or you just push %rdi/pop %rdi, its only one byte
> instructions.
Adding SEEN_SKBREF sounds like a good idea. :)
> Or completely optimize the thing and not call seccomp_bpf_load() at all.
This would be cool.
> (current would be loaded once in r9, task_pt_regs() would be loaded once
> in r8)
Both syscall_get_arch() and syscall_get_arguments() need to test for
the TS_COMPAT bit (in task_thread_info(current)->status); we should
load that once, too.
Thanks for the comments. Will try a v3.
- xi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists