On Tue, Nov 10, 2020 at 1:04 AM Xin Yin wrote:
>
> For lru_percpu_map update elem, prealloc_lru_pop() may return
> an unclear elem, if the func called by bpf prog and "onallcpus"
> set to false, it may update an elem whith dirty data.
>
> Clear percpu value of the elem, before use it.
>
> Signed-o
a
> stub that will be ignored in the callback loop, and it will be cleaned up
> on the next modification of the array.
>
> Link: https://lore.kernel.org/r/20201115055256.65625-1-mmull...@mmlx.us
> Link: https://lkml.kernel.org/r/20201116175107.02db3...@gandalf.local.home
>
> Cc: M
On Wed, Nov 18, 2020 at 6:22 AM Steven Rostedt wrote:
>
> Thus, all functions will be non-variadic in these cases.
That's not the only case where it will blow up.
Try this on sparc:
struct foo {
int a;
};
struct foo foo_struct(void) {
struct foo f = {};
return f;
}
int foo_int(void) {
return 0;
On Wed, Dec 9, 2020 at 2:32 PM Steven Rostedt wrote:
>
> On Wed, Dec 09, 2020 at 06:05:52PM +, Christoph Hellwig wrote:
> > On Wed, Dec 09, 2020 at 04:51:48PM +0100, Stanislaw Gruszka wrote:
> > > On Wed, Dec 09, 2020 at 03:08:26PM +, Matthew Wilcox wrote:
> > > > On Wed, Dec 09, 2020 at 0
On Wed, Dec 9, 2020 at 6:31 PM Steven Rostedt wrote:
>
> On Wed, 9 Dec 2020 17:12:43 -0800
> Alexei Starovoitov wrote:
>
> > > > > > FWIW, I intend to do some consolidation/renaming in this area. I
> > > > > > trust that will not be a problem?
&
On Thu, Nov 19, 2020 at 7:46 AM Jakub Kicinski wrote:
>
> On Wed, 18 Nov 2020 17:26:53 -0800 Guenter Roeck wrote:
> > On Wed, Nov 18, 2020 at 05:01:19PM -0800, Guenter Roeck wrote:
> > > On Wed, Nov 18, 2020 at 03:42:53PM -0800, Tao Ren wrote:
> > > > On Thu, Nov 19, 2020 at 12:27:19AM +0100, Andr
On Thu, Nov 19, 2020 at 6:59 AM Steven Rostedt wrote:
> Linux obviously
> supports multiple architectures (more than any other OS), but it is pretty
> stuck to gcc as a compiler (with LLVM just starting to work too).
>
> We are fine with being stuck to a compiler if it gives us what we want.
I be
On Tue, Nov 17, 2020 at 12:14 PM Alexei Starovoitov
wrote:
>
> On Tue, Nov 17, 2020 at 12:05 PM Daniel Xu wrote:
> >
> > This commit uses the proper word-at-a-time APIs to avoid overcopying.
>
> that part of the commit log is no longer correct. I can fix it up whil
On Thu, Nov 19, 2020 at 10:40:21AM -0800, Linus Torvalds wrote:
> On Thu, Nov 19, 2020 at 10:34 AM Alexei Starovoitov
> wrote:
> >
> > ping.
>
> I'm ok with this series that adds explanations for why you care and
> what bpf does that makes it valid.
Great.
>
On Mon, Nov 30, 2020 at 05:23:22PM +0100, Florent Revest wrote:
> On Sat, 2020-11-28 at 17:07 -0800, Alexei Starovoitov wrote:
> > On Thu, Nov 26, 2020 at 05:57:47PM +0100, Florent Revest wrote:
> > > This helper exposes the kallsyms_lookup function to eBPF tracing
> > >
On Fri, Nov 20, 2020 at 01:17:07PM +, KP Singh wrote:
> +
> +static bool bpf_ima_inode_hash_allowed(const struct bpf_prog *prog)
> +{
> + return bpf_lsm_is_sleepable_hook(prog->aux->attach_btf_id);
> +}
> +
> +BTF_ID_LIST_SINGLE(bpf_ima_inode_hash_btf_ids, struct, inode)
> +
> +const static
On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
>
>
> On 12/17/20 7:31 AM, Florent Revest wrote:
> > On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
> > > On 12/11/20 6:40 AM, Florent Revest wrote:
> > > > On Wed, Dec 2, 2020 at 10:18
On Fri, Dec 18, 2020 at 10:53:57AM -0800, Andrii Nakryiko wrote:
> On Thu, Dec 17, 2020 at 7:20 PM Alexei Starovoitov
> wrote:
> >
> > On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
> > >
> > >
> > > On 12/17/20 7:31 AM, Florent Reves
On Tue, Dec 1, 2020 at 4:12 AM Brendan Jackman wrote:
>
> On Sat, Nov 28, 2020 at 05:14:05PM -0800, Alexei Starovoitov wrote:
> > On Fri, Nov 27, 2020 at 05:57:27PM +, Brendan Jackman wrote:
> > > The JIT case for encoding atomic ops is about to get more
> > >
On Tue, Dec 1, 2020 at 4:14 AM Brendan Jackman wrote:
>
> On Sat, Nov 28, 2020 at 05:15:52PM -0800, Alexei Starovoitov wrote:
> > On Fri, Nov 27, 2020 at 05:57:26PM +, Brendan Jackman wrote:
> > > +/* Emit the ModR/M byte for addressing *(r1 + off) and r2
On Tue, Dec 1, 2020 at 4:38 AM Brendan Jackman wrote:
>
> I guess it's also worth remembering other archs might have an atomic
> subtract.
which one?
arm64 LSE implements atomic_fetch_sub as neg+ldadd.
imo x64 and arm64 example outweighs choices by other archs if there are such.
Even without LSE
On Wed, Dec 2, 2020 at 2:52 AM Brendan Jackman wrote:
>
> Tue, Dec 01, 2020 at 09:50:00PM -0800, Alexei Starovoitov wrote:
> > On Tue, Dec 1, 2020 at 4:14 AM Brendan Jackman wrote:
> > >
> > > On Sat, Nov 28, 2020 at 05:15:52PM -0800, Alexei Starovoitov wrote:
>
On Wed, Dec 2, 2020 at 12:32 PM Florent Revest wrote:
>
> On Tue, 2020-12-01 at 16:55 -0800, Andrii Nakryiko wrote:
> > On Fri, Nov 27, 2020 at 8:09 AM Yonghong Song wrote:
> > >
> > >
> > > On 11/27/20 3:20 AM, KP Singh wrote:
> > > > On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote:
> > > >
On Tue, Dec 1, 2020 at 1:59 PM Roman Gushchin wrote:
>
> 5) Cryptic -EPERM is returned on exceeding the limit. Libbpf even had
>a function to "explain" this case for users.
...
> v9:
> - always charge the saved memory cgroup, by Daniel, Toke and Alexei
> - added bpf_map_kzalloc()
> - reb
On Thu, Dec 03, 2020 at 10:22:34AM +, Brendan Jackman wrote:
> Add missing newlines and fix polarity of strerror argument.
>
> Signed-off-by: Brendan Jackman
Applied, Thanks
On Wed, Jan 20, 2021 at 9:08 AM KP Singh wrote:
>
> On Tue, Jan 19, 2021 at 5:00 PM Florent Revest wrote:
> >
> > This builds up on the existing socket cookie test which checks whether
> > the bpf_get_socket_cookie helpers provide the same value in
> > cgroup/connect6 and sockops programs for a s
tun_prog __rcu **prog_p,
> > > prog = NULL;
> > > } else {
> > > prog = bpf_prog_get_type(fd, BPF_PROG_TYPE_SOCKET_FILTER);
> > > + if (IS_ERR(prog))
> > > + prog = bpf_prog_get_type(fd,
> >
On Wed, Jan 20, 2021 at 6:22 AM angkery wrote:
>
> From: Junlin Yang
>
> Change 'exeeds' to 'exceeds'.
>
> Signed-off-by: Junlin Yang
The patch didn't reach patchwork.
Please reduce cc list and resubmit to bpf@vger only.
Also pls mention [PATCH bpf-next] in the subject.
> ---
> tools/testing/
On Tue, Jan 19, 2021 at 4:03 AM Pan Bian wrote:
>
> Put file f if inode_storage_ptr() returns NULL.
>
> Signed-off-by: Pan Bian
> ---
> kernel/bpf/bpf_inode_storage.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/bpf_inode_storage.c b/kernel/bpf/bpf_ino
On Mon, Jan 18, 2021 at 04:06:13PM +, Brendan Jackman wrote:
> When BPF_FETCH is set, atomic instructions load a value from memory
> into a register. The current verifier code first checks via
> check_mem_access whether we can access the memory, and then checks
> via check_reg_arg whether we ca
On Wed, Jan 20, 2021 at 11:57 AM Lukas Bulwahn wrote:
>
> On Wed, Jan 20, 2021 at 2:39 PM Brendan Jackman wrote:
> >
> > Alexei pointed out [1] that this wording is pretty confusing. Here's
> > an attempt to be more explicit and clear.
> >
> > [1]
> > https://lore.kernel.org/bpf/CAADnVQJVvwoZsE1
On Wed, Mar 10, 2021 at 6:29 AM Peter Zijlstra wrote:
>
> On Wed, Mar 10, 2021 at 09:13:24AM -0500, Steven Rostedt wrote:
> > On Wed, 10 Mar 2021 11:22:48 +0100
> > Peter Zijlstra wrote:
> >
> > > After this FEATURE_NOPL is unused except for required-features for
> > > x86_64. FEATURE_K8 is only
On Thu, Jan 21, 2021 at 10:54 AM Jonathan Corbet wrote:
>
> On Wed, 20 Jan 2021 13:39:44 +
> Brendan Jackman wrote:
>
> > Difference from v2->v3 [1]:
> >
> > * Just fixed a commite message, rebased, and added Lukas' review tag -
> > thanks
> >Lukas!
> >
> > Difference from v1->v2 [1]:
>
On Tue, Mar 9, 2021 at 12:03 PM Steven Rostedt wrote:
>
> On Tue, 9 Mar 2021 12:53:37 -0700
> David Ahern wrote:
>
> > Changing the order of the fields will impact any bpf programs expecting
> > the existing format
>
> I thought bpf programs were not API.
That is correct.
On Tue, Mar 9, 2021 at 12:18 PM David Ahern wrote:
>
> On 3/9/21 1:02 PM, Steven Rostedt wrote:
> > On Tue, 9 Mar 2021 12:53:37 -0700
> > David Ahern wrote:
> >
> >> Changing the order of the fields will impact any bpf programs expecting
> >> the existing format
> >
> > I thought bpf programs wer
On Tue, Mar 9, 2021 at 12:37 PM Steven Rostedt wrote:
>
> The size of the fields and order changes all the time in various events. I
> recommend doing so *all the time*. If you upgrade a kernel, then all the bpf
> programs you have for that kernel should also be updated. You can't rely on
> fields
On Sun, Feb 7, 2021 at 10:21 AM Dave Hansen wrote:
>
> On 2/7/21 9:58 AM, Borislav Petkov wrote:
> > On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
> >> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
> >>> - Disable CET instrumentation in the kernel so that gcc doesn't add
On Mon, Jan 4, 2021 at 10:29 AM Qais Yousef wrote:
>
> On 09/08/20 09:19, Phil Auld wrote:
> > Hi Quais,
> >
> > On Mon, Sep 07, 2020 at 12:02:24PM +0100 Qais Yousef wrote:
> > > On 09/02/20 09:54, Phil Auld wrote:
> > > > >
> > > > > I think this decoupling is not necessary. The natural place for
On Mon, Jan 04, 2021 at 03:26:31PM +, Alan Maguire wrote:
>
> ksnoop can be used to show function signatures; for example:
>
> $ ksnoop info ip_send_skb
> int ip_send_skb(struct net * net, struct sk_buff * skb);
>
> Then we can trace the function, for example:
>
> $ ksnoop trace ip_send_
On Tue, Jan 5, 2021 at 3:39 AM Qais Yousef wrote:
>
> On 01/04/21 10:59, Alexei Starovoitov wrote:
> > > > > I did have a patch that allowed that. It might be worth trying to
> > > > > upstream it.
> > > > > It just required a new macro wh
On Tue, Jan 05, 2021 at 02:24:12PM +0200, Yuri Benditovich wrote:
> This program type can set skb hash value. It will be useful
> when the tun will support hash reporting feature if virtio-net.
>
> Signed-off-by: Yuri Benditovich
> ---
> drivers/net/tun.c | 2 ++
> 1 file changed, 2 insertions(+
On Tue, Jan 5, 2021 at 12:00 AM Xichen Lin wrote:
>
> From: Xichen Lin
>
> Check the signature of a BPF program against the same set of keys for
> module signature checking.
>
> Currently the format of a signed BPF program is similar to that of
> a signed kernel module, composed of BPF bytecode,
On Wed, Dec 16, 2020 at 10:07:37AM +, Christophe Leroy wrote:
> Implement Extended Berkeley Packet Filter on Powerpc 32
>
> Test result with test_bpf module:
>
> test_bpf: Summary: 378 PASSED, 0 FAILED, [354/366 JIT'ed]
nice!
> Registers mapping:
>
> [BPF_REG_0] = r11-r12
>
On Wed, Nov 25, 2020 at 6:30 PM Roman Gushchin wrote:
>
> I did consider this option. There are pros and cons. In general we tend to
> charge the cgroup
> which actually allocates the memory, and I decided to stick with this rule. I
> agree, it's fairly
> easy to come with arguments why always c
On Thu, Nov 26, 2020 at 05:57:47PM +0100, Florent Revest wrote:
> This helper exposes the kallsyms_lookup function to eBPF tracing
> programs. This can be used to retrieve the name of the symbol at an
> address. For example, when hooking into nf_register_net_hook, one can
> audit the name of the re
On Fri, Nov 27, 2020 at 05:57:27PM +, Brendan Jackman wrote:
> The JIT case for encoding atomic ops is about to get more
> complicated. In order to make the review & resulting code easier,
> let's factor out some shared helpers.
>
> Signed-off-by: Brendan Jackman
> ---
> arch/x86/net/bpf_jit
On Fri, Nov 27, 2020 at 05:57:26PM +, Brendan Jackman wrote:
> +/* Emit the ModR/M byte for addressing *(r1 + off) and r2 */
> +static void emit_modrm_dstoff(u8 **pprog, u32 r1, u32 r2, int off)
same concern as in the another patch. If you could avoid intel's puzzling names
like above it will
On Fri, Nov 27, 2020 at 05:57:33PM +, Brendan Jackman wrote:
>
> /* atomic op type fields (stored in immediate) */
> -#define BPF_FETCH0x01/* fetch previous value into src reg */
> +#define BPF_XCHG (0xe0 | BPF_FETCH) /* atomic exchange */
> +#define BPF_CMPXCHG (0xf0 | BPF
On Fri, Nov 27, 2020 at 09:39:10PM -0800, Yonghong Song wrote:
>
>
> On 11/27/20 9:57 AM, Brendan Jackman wrote:
> > This adds instructions for
> >
> > atomic[64]_[fetch_]and
> > atomic[64]_[fetch_]or
> > atomic[64]_[fetch_]xor
> >
> > All these operations are isomorphic enough to implement wit
On Fri, Nov 27, 2020 at 09:35:07PM -0800, Yonghong Song wrote:
>
>
> On 11/27/20 9:57 AM, Brendan Jackman wrote:
> > Including only interpreter and x86 JIT support.
> >
> > x86 doesn't provide an atomic exchange-and-subtract instruction that
> > could be used for BPF_SUB | BPF_FETCH, however we
On Fri, Nov 27, 2020 at 09:53:05PM -0800, Yonghong Song wrote:
>
>
> On 11/27/20 9:57 AM, Brendan Jackman wrote:
> > Status of the patches
> > =
> >
> > Thanks for the reviews! Differences from v1->v2 [1]:
> >
> > * Fixed mistakes in the netronome driver
> >
> > * Addd sub,
On Thu, Nov 19, 2020 at 09:37:52AM -0800, Roman Gushchin wrote:
> static void bpf_map_put_uref(struct bpf_map *map)
> @@ -619,7 +562,7 @@ static void bpf_map_show_fdinfo(struct seq_file *m,
> struct file *filp)
> "value_size:\t%u\n"
> "max_entries:\t%u\n"
>
On Wed, Nov 6, 2013 at 11:28 AM, Eric Dumazet wrote:
> Actually, the new way [1] of doing this would be to use the 'Fixes:' tag
> as in :
>
> Fixes: <12 digits SHA1> ("net: fix unsafe set_memory_rw from softirq")
>
> [1] As discussed at last Kernel Summit
thx. good to know.
Unfortunately 2013 Ker
+0x5d/0x190
> [] sock_setsockopt+0x991/0x9e0
> [] SyS_setsockopt+0xb6/0xd0
> [] system_call_fastpath+0x16/0x1b
> [] 0x
>
> v2: add extra { } after else
>
> Fixes: d45ed4a4e33a ("net: fix unsafe set_memory_rw from softirq")
> Acked-by: Daniel Borkmann
On Wed, Mar 12, 2014 at 12:22 PM, David Miller wrote:
> From: Alexei Starovoitov
> Date: Mon, 10 Mar 2014 21:41:30 -0700
>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 1a869488b8ae..2c13d000389c 100644
>> --- a/include/linux/netdevi
r bpf_jit_enable
removed 64-bit requirement from XADD_DW ebpf insn
- silenced gcc warning in arch/arm/net/bpf_jit due to missing seccomp_data
- cleaned up stack[64] with stack[ARRAY_SIZE(stack)]
2/3 and 3/3: no changes
x86_64, i386 and arm32 look clean.
Thanks!
Alexei Starovoitov (3):
bc-2.17.so [.] syscall
1.77% bench [kernel.kallsyms] [k] __secure_computing
0.93% bench [kernel.kallsyms] [k] sys_getuid
BPF filters generated by seccomp are very branchy, so ext BPF
performance is better than old BPF.
Performance gains will be even higher when extended BPF JIT
is committed.
k_unattached_filter_create()
interfaces
3. tracing filters systemtap-like with extended BPF
4. OVS with extended BPF
5. nftables with extended BPF
Signed-off-by: Alexei Starovoitov
Acked-by: Hagen Paul Pfeifer
Reviewed-by: Daniel Borkmann
---
arch/arm/net/bpf_jit_32.c |3 +-
Signed-off-by: Alexei Starovoitov
Reviewed-by: Daniel Borkmann
---
Documentation/networking/filter.txt | 181 +++
1 file changed, 181 insertions(+)
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index a06b48d2f5cc
On Wed, Mar 12, 2014 at 3:16 PM, Cong Wang wrote:
> (Sorry for jumping into this thread late.)
>
> On Mon, Mar 10, 2014 at 9:41 PM, Alexei Starovoitov wrote:
>>
>> 3. tracing filters systemtap-like with extended BPF
>>
>> 4. OVS with extended BPF
>>
>
On Wed, Mar 12, 2014 at 2:15 AM, Pablo Neira Ayuso wrote:
> Hi!
>
> I'm going to reply to Daniel and you in the same email, see below.
>
> struct sk_filter
> {
> atomic_trefcnt;
> - unsigned intlen;/* Number of filter blocks */
> + /* len - num
On Thu, Mar 13, 2014 at 5:29 AM, Pablo Neira Ayuso wrote:
> On Wed, Mar 12, 2014 at 08:29:07PM -0700, Alexei Starovoitov wrote:
>> On Wed, Mar 12, 2014 at 2:15 AM, Pablo Neira Ayuso
>> wrote:
> [...]
It seems you're assuming that ebpf inherited all the shortcomings
of bp
On Fri, Mar 14, 2014 at 5:58 AM, Pablo Neira Ayuso wrote:
> On Wed, Mar 12, 2014 at 02:43:32PM -0700, Alexei Starovoitov wrote:
>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>> index e568c8ef896b..6e6aab5e062b 100644
>> --- a/include/linux/filter.h
&
On Fri, Mar 14, 2014 at 8:37 AM, Alexei Starovoitov wrote:
> On Fri, Mar 14, 2014 at 5:58 AM, Pablo Neira Ayuso
> wrote:
>> On Wed, Mar 12, 2014 at 02:43:32PM -0700, Alexei Starovoitov wrote:
>>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>>> in
On Fri, Mar 14, 2014 at 11:16 AM, Pablo Neira Ayuso wrote:
> On Fri, Mar 14, 2014 at 08:28:05AM -0700, Alexei Starovoitov wrote:
>> On Thu, Mar 13, 2014 at 5:29 AM, Pablo Neira Ayuso
>> wrote:
>> > On Wed, Mar 12, 2014 at 08:29:07PM -0700, Alexei Starovoitov wrote:
>&
On Sat, Mar 15, 2014 at 12:03 PM, Pablo Neira Ayuso wrote:
> On Fri, Mar 14, 2014 at 09:04:50PM -0700, Alexei Starovoitov wrote:
> [...]
>> In the patches I sent, ebpf is _not_ exposed to the user.
>
> From your last patch: http://patchwork.ozlabs.org/patch/329713/
>
> d
Signed-off-by: Alexei Starovoitov
---
Documentation/networking/filter.txt | 181 +++
1 file changed, 181 insertions(+)
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index a06b48d2f5cc..c3f687bf8e82 100644
--- a
ext BPF
performance is better than old BPF.
Performance gains will be even higher when extended BPF JIT
is committed.
Signed-off-by: Alexei Starovoitov
---
This patch is an RFC to use extended BPF in seccomp.
Change it to do it conditionally with bpf_ext_enable knob ?
---
include/linux/seccom
design doc
Please review.
Thanks!
Alexei Starovoitov (3):
Extended BPF interpreter and converter
RFC: convert seccomp to use extended BPF
Extended BPF documentation
Documentation/networking/filter.txt | 181
include/linux/filter.h |8 +-
include/linux/netdevice.h
th trinify BPF fuzzer
Future work:
0. seccomp
1. add extended BPF JIT for x86_64
2. add inband old/new demux and extended BPF verifier, so that new programs
can be loaded through old sk_attach_filter() and
sk_unattached_filter_create()
interfaces
3. tracing filters systemtap-like with ex
On Tue, Mar 4, 2014 at 1:59 AM, Daniel Borkmann wrote:
> On 03/04/2014 06:18 AM, Alexei Starovoitov wrote:
>>
>> Extended BPF extends old BPF in the following ways:
>> - from 2 to 10 registers
>>Original BPF has two registers (A and X) and hidden frame pointer.
On Tue, Mar 4, 2014 at 6:28 AM, Hagen Paul Pfeifer wrote:
> If all issues raised by Daniel are addresed:
>
> Acked-by: Hagen Paul Pfeifer
Thanks!
> But ...
>
>>Future work:
>>
>>0. seccomp
>>
>>1. add extended BPF JIT for x86_64
>>
>>2. add inband old/new demux and extended BPF verifier, so tha
design doc
V5 summary:
- fixed commit one-liner, removed empty line
- added Hagen's ack
Please review.
Thanks!
Alexei Starovoitov (3):
filter: add Extended BPF interpreter and converter
[RFC] seccomp: convert seccomp to use extended BPF
doc: filter: add Extended BPF document
Signed-off-by: Alexei Starovoitov
---
Documentation/networking/filter.txt | 181 +++
1 file changed, 181 insertions(+)
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index a06b48d2f5cc..c3f687bf8e82 100644
--- a
ext BPF
performance is better than old BPF.
Performance gains will be even higher when extended BPF JIT
is committed.
Signed-off-by: Alexei Starovoitov
---
This patch is an RFC to use extended BPF in seccomp.
Change it to do it conditionally with bpf_ext_enable knob ?
---
include/linux/seccom
th trinify BPF fuzzer
Future work:
0. seccomp
1. add extended BPF JIT for x86_64
2. add inband old/new demux and extended BPF verifier, so that new programs
can be loaded through old sk_attach_filter() and
sk_unattached_filter_create()
interfaces
3. tracing filters systemtap-like with exten
On Tue, Mar 4, 2014 at 2:17 PM, Alexei Starovoitov wrote:
> use sk_convert_filter() to convert seccomp BPF into extended BPF
>
> 05-sim-long_jumps.c of libseccomp was used as micro-benchmark:
> seccomp_rule_add_exact(ctx,...
> seccomp_rule_add_exact(ctx,...
> rc = seccomp_
On Wed, Mar 5, 2014 at 1:24 AM, Daniel Borkmann wrote:
> On 03/04/2014 11:17 PM, Alexei Starovoitov wrote:
>>
>> Extended BPF extends old BPF in the following ways:
>> - from 2 to 10 registers
>>Original BPF has two registers (A and X) and hidden frame pointer.
On Wed, Mar 5, 2014 at 1:42 PM, Kees Cook wrote:
> On Tue, Mar 4, 2014 at 7:11 PM, Alexei Starovoitov wrote:
>> On Tue, Mar 4, 2014 at 2:17 PM, Alexei Starovoitov wrote:
>>> use sk_convert_filter() to convert seccomp BPF into extended BPF
>>>
>>> 05-sim-lo
bc-2.17.so [.] syscall
1.77% bench [kernel.kallsyms] [k] __secure_computing
0.93% bench [kernel.kallsyms] [k] sys_getuid
BPF filters generated by seccomp are very branchy, so ext BPF
performance is better than old BPF.
Performance gains will be even higher when extended BPF JIT
is committed.
ET in sk_convert_filter()
- updated commit log
- added Daniel's Reviewed-by
- added Kees's Reviewed-by
x86_64, i386 and arm32 look clean.
Thanks!
Alexei Starovoitov (3):
filter: add Extended BPF interpreter and converter
seccomp: convert seccomp to use extended BPF
doc: filter: a
rfaces
3. tracing filters systemtap-like with extended BPF
4. OVS with extended BPF
5. nftables with extended BPF
Signed-off-by: Alexei Starovoitov
Acked-by: Hagen Paul Pfeifer
Reviewed-by: Daniel Borkmann
---
include/linux/filter.h |6 +-
include/linux/netdevice.h |1 +
includ
Signed-off-by: Alexei Starovoitov
Reviewed-by: Daniel Borkmann
---
Documentation/networking/filter.txt | 181 +++
1 file changed, 181 insertions(+)
diff --git a/Documentation/networking/filter.txt
b/Documentation/networking/filter.txt
index a06b48d2f5cc
omp and negative
offsets yet, fix that
- add 32-bit subregs to BPF64 x86_64 JIT and LLVM backend
- add bpf64 verifier, so that tcpdump/cls/xt and others can
insert both bpf32 and bpf64 programs through the same interface
- add bpf tables, complete 'dropmonitor' and get back to
syst
of available functions
and alter BPF machinery for specific use case.
BPF64 instruction set is designed for efficient mapping to native
instructions on 64-bit CPUs
Old BPF instructions are remapped on the fly to BPF64
when sysctl net.core.bpf64_enable=1
Signed-off-by: Alexei Starovoitov
On Fri, Feb 28, 2014 at 4:45 AM, Daniel Borkmann wrote:
> Hi Alexei,
>
> [also cc'ing Hagen and Jesse]
>
> Just some minor comments below ... let me know what you think.
Thank you for review! Comments below.
> On 02/27/2014 03:38 AM, Alexei Starovoitov wrote:
>>
&
On Fri, Feb 28, 2014 at 12:53 PM, Alexei Starovoitov wrote:
> On Fri, Feb 28, 2014 at 4:45 AM, Daniel Borkmann wrote:
>> Hi Alexei,
>>
>> [also cc'ing Hagen and Jesse]
>>
>> Just some minor comments below ... let me know what you think.
>
> Thank y
On Mon, Mar 3, 2014 at 2:05 AM, Hagen Paul Pfeifer wrote:
> * Daniel Borkmann | 2014-03-01 01:30:00 [+0100]:
>
as in 'struct bpf_insn' the immediate value is 32 bit, so for 64 bit
comparisons, you'd still need to load to immediate values, right?
>>>
>>>there is no insn that use 64-bit imme
On Tue, Jan 21, 2014 at 8:10 PM, dormando wrote:
>
>
> On Tue, 21 Jan 2014, Alexei Starovoitov wrote:
>
>> On Tue, Jan 21, 2014 at 5:39 PM, dormando wrote:
>> >
>> > > On Fri, Jan 17, 2014 at 11:16 PM, dormando wrote:
>> > > >&
On Tue, Jan 21, 2014 at 10:02 PM, Alexei Starovoitov
wrote:
> On Tue, Jan 21, 2014 at 8:10 PM, dormando wrote:
>>
>>
>> On Tue, 21 Jan 2014, Alexei Starovoitov wrote:
>>
>>> On Tue, Jan 21, 2014 at 5:39 PM, dormando wrote:
>>> >
>>&
+0x56/0xb0
[ 2247.965037] [] ? trace_hardirqs_on_caller+0x10d/0x1d0
[ 2247.965039] [] do_notify_resume+0x88/0xb0
[ 2247.965041] [] retint_signal+0x4d/0x92
[ 2247.965042] ---[ end trace 6709608ef3de895e ]---
On Mon, Dec 9, 2013 at 6:38 PM, Alexei Starovoitov wrote:
> Hi,
>
> seeing the
On Mon, Mar 31, 2014 at 9:47 PM, Jovi Zhangwei wrote:
> Hi Alexei,
>
> On Tue, Apr 1, 2014 at 5:29 AM, Alexei Starovoitov wrote:
>> On Mon, Mar 31, 2014 at 3:01 AM, Jovi Zhangwei
>> wrote:
>>> Hi Ingo,
>>>
>>> On Mon, Mar 31, 2014 at 3:17 P
It seems commit f4d4ffc03efc ("kbuild: dtbs_install: new make target")
breaks 'fakeroot make-kpkg' package creation on ubuntu.
Didn't investigate the root cause yet, just heads up.
The errors I see:
update-initramfs: Generating
/w/net/debian/linux-image-3.14.0+//boot/initrd.img-3.14.0+
grep: /boot
On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei wrote:
> Hi Alexei,
>
> We talked a lot on ktap and ebpf integration in these days,
> Now I think we can put into deeply to thinking out some
> technical issues in there.
>
> Firstly, I want to make sure you are support this ktap and
> ebpf integration
On Fri, Apr 4, 2014 at 1:46 AM, Jovi Zhangwei wrote:
> On Fri, Apr 4, 2014 at 3:48 PM, Ingo Molnar wrote:
>>
>> * Jovi Zhangwei wrote:
>>
>>> On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov
>>> wrote:
>>> > On Thu, Apr 3, 2014 at 6:2
On Fri, Apr 4, 2014 at 7:20 AM, Andi Kleen wrote:
> BTW I agree that EBPF won't work for ktap. The models
> (static vs dynamic typing etc.) are just too different.
If you meant 'static vs dynamic safety checking' then yes.
This is a main difference between bpf and ktap approach to safety.
bpf en
On Fri, Apr 4, 2014 at 1:17 PM, Theodore Ts'o wrote:
> On Fri, Apr 04, 2014 at 03:44:26PM -0400, Steven Rostedt wrote:
>> I saw one commenter say that this was a kernel bug because writing to
>> kmsg shouldn't cause the system to hang.
>>
>> The rate-limit patch would go along with that idea, and
On Sat, Apr 5, 2014 at 7:23 AM, Jovi Zhangwei wrote:
> On Sat, Apr 5, 2014 at 1:28 AM, Alexei Starovoitov wrote:
>>
>> 'ktap syntax' from user space point of view, can use ibpf as-is.
>> Show me the script and I can show how ibpf can run it.
>
> Well, plea
On Fri, Apr 4, 2014 at 8:27 AM, Jason Cooper wrote:
> Alexei,
>
> Thanks for the heads up.
>
> On Thu, Apr 03, 2014 at 03:12:38PM -0700, Alexei Starovoitov wrote:
>> It seems commit f4d4ffc03efc ("kbuild: dtbs_install: new make target")
>> breaks 'fake
er_ex1.bpf
(final filter check always happens in kernel)
bpf/llvm - placeholder for LLVM-BPF backend
Signed-off-by: Alexei Starovoitov
---
GCC-BPF backend is available on github
(since gcc plugin infrastructure doesn't allow for out-of-tree backends)
LLVM plugin infra is very flexible
net_device'
Since its prototype is 'int dst_discard(struct sk_buff *skb);'
'skb' pointer is in 'rdi' register on x86_64
bpf_load_pointer() will try to fetch 'dev' field of 'sk_buff'
structure and will suppress page-fault if pointer is incorre
etween old BPF and extended BPF.
Original BPF has two 32-bit registers.
Extended BPF has ten 64-bit registers.
That is the main difference.
Old BPF was using jt/jf fields for jump-insn only.
New BPF combines them into generic 'off' field for jump and non-jump insns.
k==imm field has the s
efficient mapping to native
instructions on 64-bit CPUs
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h| 149 +++
include/linux/bpf_jit.h| 129 ++
kernel/Makefile|1 +
kernel/bpf_jit/Makefile|3 +
kernel/bpf_jit/bpf_check.c | 1054
Signed-off-by: Alexei Starovoitov
---
Documentation/bpf_jit.txt | 204 +
1 file changed, 204 insertions(+)
create mode 100644 Documentation/bpf_jit.txt
diff --git a/Documentation/bpf_jit.txt b/Documentation/bpf_jit.txt
new file mode 100644
index
n maps directly to x86-64 calling convention.
Allowing zero-overhead calls between BPF filter and safe kernel functions
Signed-off-by: Alexei Starovoitov
---
arch/x86/Kconfig |1 +
arch/x86/net/Makefile |1 +
arch/x86/net/bpf64_jit_comp.c | 625 ++
601 - 700 of 2341 matches
Mail list logo
