On 06/04/2018 01:04 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
> On Fri, 1 Jun 2018 14:15:58 +0200
> Sebastiano Miano via iovisor-dev wrote:
>
>> Dear all,
>>
>> We have noticed that the bpf_redirect_map returns an error when it is
>> called after a tail call.
>> The xdp_redirect_map progr
On 04/24/2018 03:06 PM, Paul Chaignon wrote:
> Currently, helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE
> can only access stack and packet memory. This patchset allows these
> helpers to directly access map values by passing registers of type
> PTR_TO_MAP_VALUE.
>
> The first pa
On 04/22/2018 11:52 PM, Paul Chaignon wrote:
> Helpers that expect ARG_PTR_TO_MAP_KEY and ARG_PTR_TO_MAP_VALUE can only
> access stack and packet memory. Allow these helpers to directly access
> map values by passing registers of type PTR_TO_MAP_VALUE.
>
> This change removes the need for an extr
On 04/18/2018 10:03 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
[...]
> What does bpftool use BFD for?
It's used for the prog JIT dump in order to disassemble the instructions.
___
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://list
On 04/09/2018 01:26 PM, Jesper Dangaard Brouer wrote:
> On Fri, 6 Apr 2018 12:36:18 +0200
> Daniel Borkmann wrote:
[...]
>> [...]
>> The underlying problem is effectively the decoupling of program
>> verification that doesn't have/know the context of where it is being
>> attached to in this case.
On 04/05/2018 10:51 PM, Jesper Dangaard Brouer wrote:
> On Thu, 5 Apr 2018 12:37:19 +0200
> Daniel Borkmann wrote:
>
>> On 04/04/2018 02:28 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
>>> Hi Suricata people,
>>>
>>> When Eric Leblond (and I helped) integrated XDP in Suricata, we ran
>>> int
On 04/04/2018 02:28 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
> Hi Suricata people,
>
> When Eric Leblond (and I helped) integrated XDP in Suricata, we ran
> into the issue, that at Suricata load/start time, we cannot determine
> if the chosen XDP config options, like xdp-cpu-redirect[1],
On 01/15/2018 09:33 PM, Daniel Borkmann via iovisor-dev wrote:
> On 01/15/2018 09:13 PM, David Miller wrote:
>> From: Daniel Borkmann via iovisor-dev
>> Date: Mon, 15 Jan 2018 21:11:06 +0100
>>
>>> On 01/15/2018 06:24 PM, Daniel Borkmann via iovisor-dev wrot
On 01/15/2018 09:13 PM, David Miller wrote:
> From: Daniel Borkmann via iovisor-dev
> Date: Mon, 15 Jan 2018 21:11:06 +0100
>
>> On 01/15/2018 06:24 PM, Daniel Borkmann via iovisor-dev wrote:
>>> On 01/11/2018 07:05 AM, Sandipan Das via iovisor-dev wrote:
>>> [.
On 01/15/2018 06:24 PM, Daniel Borkmann via iovisor-dev wrote:
> On 01/11/2018 07:05 AM, Sandipan Das via iovisor-dev wrote:
> [...]
>> Any ideas about why this is happening? Also, it would be really helpful
>> if someone can translate the Pyroute2 calls in the test script to th
On 01/11/2018 07:05 AM, Sandipan Das via iovisor-dev wrote:
[...]
> Any ideas about why this is happening? Also, it would be really helpful
> if someone can translate the Pyroute2 calls in the test script to the
> corresponding tc commands.
I can trigger it as well, so I should have something very
On 12/20/2017 02:32 AM, Y Song via iovisor-dev wrote:
> There are a few examples under examples/networking with
> bpf_clone_redirect helper to redirect a packet from one
> interface to another.
Right, and there's also bpf_redirect() directly out of cls_bpf where you
don't need to go and clone the
On 09/28/2017 11:31 AM, Paul Chaignon via iovisor-dev wrote:
On Tue, Sep 26, 2017 at 10:44 AM, Alban Crequy via iovisor-dev <
iovisor-dev@lists.iovisor.org> wrote:
On Fri, Sep 22, 2017 at 5:43 PM, zhiting zhu via iovisor-dev
wrote:
Dear All,
I have a question about what language people use to
On 09/21/2017 10:02 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
Hi Daniel,
My very simple program is getting rejected on bpf loading time. When
using another map as input for a decision, for map type BPF_MAP_TYPE_DEVMAP.
SEC("xdp_redirect_map_rr")
int xdp_prog_redirect_map_rr(struct xdp_
On 09/21/2017 08:56 PM, Alexei Starovoitov wrote:
On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote:
On 18/09/2017 22:29, Daniel Borkmann wrote:
On 09/18/2017 10:47 PM, Jiong Wang wrote:
Hi,
Currently, LLVM eBPF backend always generate code in 64-bit mode,
this ma
On 09/20/2017 01:20 AM, Jiong Wang wrote:
On 18/09/2017 22:29, Daniel Borkmann wrote:
[...]
Great to see work in this direction! Can we also enable to use / emit
all the 32bit BPF_ALU instructions whenever possible for the currently
available bpf targets while at it (which only use BPF_ALU64 ri
On 09/18/2017 10:47 PM, Jiong Wang wrote:
Hi,
Currently, LLVM eBPF backend always generate code in 64-bit mode, this may
cause troubles when JITing to 32-bit targets.
For example, it is quite common for XDP eBPF program to access some packet
fields through base + offset that the default e
On 09/01/2017 01:30 PM, William Tu wrote:
This patch adds two BPF conntrack helper functions, bpf_ct_lookup()
and bpf_ct_commit(), to enable the possibility of BPF stateful firewall.
There are two ways to implement BPF conntrack. One way is to not
rely on helpers but implement the conntrack sta
On 08/24/2017 06:17 PM, Y Song wrote:
CC to bcc mailing list as well.
bpf_probe_read is not allowed in XDP programs.
Your comparison may need to comparison not just starting offset, but
also including the memory size so the
whole write won't fall beyond the "data_end".
Regarding to bcc transla
On 08/23/2017 04:11 PM, Edward Cree wrote:
The liveness tracking algorithm is quite subtle; add comments to explain it.
Signed-off-by: Edward Cree
Acked-by: Daniel Borkmann
___
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.io
On 08/23/2017 04:10 PM, Edward Cree wrote:
The fact that writes occurred in reaching the continuation state does
not screen off its reads from us, because we're not really its parent.
So detect 'not really the parent' in do_propagate_liveness, and ignore
write marks in that case.
Fixes: dc50
On 08/23/2017 04:10 PM, Edward Cree wrote:
The optimisation it does is broken when the 'new' register value has a
variable offset and the 'old' was constant. I broke it with my pointer
types unification (see Fixes tag below), before which the 'new' value
would have type PTR_TO_MAP_VALUE_AD
On 08/23/2017 04:10 PM, Edward Cree wrote:
From: Alexei Starovoitov
The test makes a read through a map value pointer, then considers pruning
a branch where the register holds an adjusted map value pointer. It
should not prune, but currently it does.
Signed-off-by: Alexei Starovoitov
[ec
On 08/23/2017 04:09 PM, Edward Cree wrote:
Writes in straight-line code should not prevent reads from propagating
along jumps. With current verifier code, the jump from 3 to 5 does not
add a read mark on 3:R0 (because 5:R0 has a write mark), meaning that
the jump from 1 to 3 gets pruned as
On 08/21/2017 10:44 PM, Edward Cree wrote:
On 21/08/17 21:27, Daniel Borkmann wrote:
On 08/21/2017 08:36 PM, Edward Cree wrote:
On 19/08/17 00:37, Alexei Starovoitov wrote:
[...]
I'm tempted to just rip out env->varlen_map_value_access and always check
the whole thing, because honestly I d
On 08/21/2017 08:36 PM, Edward Cree wrote:
On 19/08/17 00:37, Alexei Starovoitov wrote:
[...]
I'm tempted to just rip out env->varlen_map_value_access and always check
the whole thing, because honestly I don't know what it was meant to do
originally or how it can ever do any useful pruning.
On 08/15/2017 09:34 PM, Edward Cree wrote:
State of a register doesn't matter if it wasn't read in reaching an exit;
a write screens off all reads downstream of it from all explored_states
upstream of it.
This allows us to prune many more branches; here are some processed insn
counts for so
On 08/15/2017 03:53 PM, Edward Cree wrote:
State of a register doesn't matter if it wasn't read in reaching an exit;
a write screens off all reads downstream of it from all explored_states
upstream of it.
This allows us to prune many more branches; here are some processed insn
counts for so
On 08/14/2017 07:55 PM, Edward Cree wrote:
State of a register doesn't matter if it wasn't read in reaching an exit;
a write screens off all reads downstream of it from all explored_states
upstream of it.
This allows us to prune many more branches; here are some processed insn
counts for so
On 08/07/2017 04:21 PM, Edward Cree wrote:
This series simplifies alignment tracking, generalises bounds tracking and
fixes some bounds-tracking bugs in the BPF verifier. Pointer arithmetic on
packet pointers, stack pointers, map value pointers and context pointers has
been unified, and bo
On 08/03/2017 06:11 PM, Edward Cree wrote:
Unifies adjusted and unadjusted register value types (e.g. FRAME_POINTER is
now just a PTR_TO_STACK with zero offset).
Tracks value alignment by means of tracking known & unknown bits. This
also replaces the 'reg->imm' (leading zero bits) calculatio
On 07/21/2017 03:37 PM, Edward Cree wrote:
We have to subtract the src max from the dst min, and vice-versa, since
(e.g.) the smallest result comes from the largest subtrahend.
Fixes: 484611357c19 ("bpf: allow access into map value arrays")
Signed-off-by: Edward Cree
LGTM, thanks for the fi
On 07/21/2017 03:36 PM, Edward Cree wrote:
There is a bug in the verifier's handling of BPF_SUB: [a,b] - [c,d] yields
was [a-c, b-d] rather than the correct [a-d, b-c]. So here is a test
which, with the bogus handling, will produce ranges of [0,0] and thus
allowed accesses; whereas the cor
On 07/07/2017 02:50 PM, Edward Cree wrote:
On 07/07/17 10:14, Daniel Borkmann wrote:
But this means the bpf_lxc_* cases increase quite significantly,
arguably one of them is pretty close already, but the other one not
so much, meaning while 142k would shoot over the 128k target quite a
bit, the
On 07/06/2017 08:27 PM, Edward Cree wrote:
On 04/07/17 23:28, Daniel Borkmann wrote:
Have you tried with cilium's BPF code? The kernel selftests are quite small,
so not really pushing processed insns too far. I can send you a BPF obj file
if that's easier for testing.
Results from the next (in-
On 07/04/2017 09:22 PM, Edward Cree wrote:
On 30/06/17 19:15, Alexei Starovoitov wrote:
On 6/30/17 9:44 AM, Edward Cree wrote:
I haven't measured the test_progs ones, because I *still* haven't gotten
around to actually setting up a BPF toolchain (it doesn't help that I'm
building everything
On 06/27/2017 02:57 PM, Edward Cree wrote:
Signed-off-by: Edward Cree
Acked-by: Daniel Borkmann
___
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
On 06/28/2017 04:11 PM, Edward Cree wrote:
On 28/06/17 14:50, Daniel Borkmann wrote:
Hi Edward,
Did you also have a chance in the meantime to look at reducing complexity
along with your unification? I did run the cilium test suite with your
latest set from here and current # worst case processe
On 06/28/2017 06:07 PM, Edward Cree wrote:
On 28/06/17 16:15, Daniel Borkmann wrote:
On 06/27/2017 02:56 PM, Edward Cree wrote:
Tracks value alignment by means of tracking known & unknown bits.
Tightens some min/max value checks and fixes a couple of bugs therein.
You mean the one in relation
On 06/27/2017 02:56 PM, Edward Cree wrote:
Tracks value alignment by means of tracking known & unknown bits.
Tightens some min/max value checks and fixes a couple of bugs therein.
If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES,
treat the pointer as an unknown scalar a
On 06/27/2017 02:56 PM, Edward Cree wrote:
Tracks value alignment by means of tracking known & unknown bits.
Tightens some min/max value checks and fixes a couple of bugs therein.
You mean the one in relation to patch 1/12? Would be good to elaborate
here since otherwise this gets forgotten few
Hi Edward,
On 06/27/2017 02:53 PM, Edward Cree wrote:
This series simplifies alignment tracking, generalises bounds tracking and
fixes some bounds-tracking bugs in the BPF verifier. Pointer arithmetic on
packet pointers, stack pointers, map value pointers and context pointers has
been uni
On 06/27/2017 02:56 PM, Edward Cree wrote:
Currently fails due to bug in verifier bounds handling.
Signed-off-by: Edward Cree
Acked-by: Daniel Borkmann
___
iovisor-dev mailing list
iovisor-dev@lists.iovisor.org
https://lists.iovisor.org/mailman/lis
On 06/08/2017 06:45 PM, Alexei Starovoitov wrote:
[...]
I think Daniel will be happy to test your next rev of the patches.
I'll test them as well.
At least 'insn_processed' from C code in tools/testing/selftests/bpf/
is a good estimate of how these changes affect pruning.
Without having looked
On 04/05/2017 02:09 PM, Paul Chaignon via iovisor-dev wrote:
[...]
Although it's not yet listed on the bcc repository, the Netronome nfp
driver does have support for XDP:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/commit/?id=ecd63a0217d5f1e8a92f7516f5586d1177b95de2
If y
On 04/03/2017 03:40 PM, Mauricio Vasquez via iovisor-dev wrote:
Dear All,
I am trying to inject a BPF_PROG_TYPE_SCHED_ACT program and attach it to the TC
using C++.
Out of curiosity, why not .._SCHED_CLS program in direct-action mode
(same functionality wrt BPF and would save you additional l
On 03/29/2017 09:00 PM, Alexei Starovoitov via iovisor-dev wrote:
On Tue, Mar 28, 2017 at 7:08 PM, Marek VavruĊĦa via iovisor-dev
wrote:
Hi,
so I was tinkering with programs attached to reuseport groups again, and
simple decisions work as expected.
The problem comes when I want to make decision
On 03/07/2017 12:07 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
On Mon, 6 Mar 2017 16:14:06 -0800
Alexei Starovoitov via iovisor-dev wrote:
[...]
that's practically impossible to know in advance, since hardening and
start address randomization will play a role.
Or use sysctl net.core.bpf
On 02/23/2017 11:00 PM, William Tu wrote:
Hi Daniel,
Thanks for the reply! I understand the workaround, can you suggest a
way to try it? Should I compile the C source into llvm IR bitcode, add
thie "r0 &= 0x", then assembly it to bpf target binary.
Hmm, problem with C code is that we might
On 02/17/2017 06:07 PM, William Tu via iovisor-dev wrote:
Hi,
I encountered another BPF verifier issue related to my previous one
https://lists.iovisor.org/pipermail/iovisor-dev/2017-January/000603.html
My guess is that when register spills to stack and restore, the state
of imm upper zero bits
On 02/09/2017 04:23 PM, William Tu wrote:
On Thu, Feb 9, 2017 at 5:11 AM, Daniel Borkmann wrote:
On 02/08/2017 09:22 PM, William Tu via iovisor-dev wrote:
Hi,
I have a program which I use around at most 300byte of local stack as
below. The largest struct is the "struct Headers" which is arou
On 02/08/2017 09:22 PM, William Tu via iovisor-dev wrote:
Hi,
I have a program which I use around at most 300byte of local stack as
below. The largest struct is the "struct Headers" which is around 80
byte. However, when loading into the verifier, it says
393: (7b) *(u64 *)(r10 -56) = r1
394: (
On 02/02/2017 06:00 PM, Jesper Dangaard Brouer via iovisor-dev wrote:
On Thu, 2 Feb 2017 11:56:19 +0100
Jesper Dangaard Brouer wrote:
On Tue, 31 Jan 2017 20:54:10 -0800
Alexei Starovoitov wrote:
On Tue, Jan 31, 2017 at 9:54 AM, Jesper Dangaard Brouer via
iovisor-dev wrote:
On Sat, 28 Jan
On 01/24/2017 10:52 AM, Jesper Dangaard Brouer via iovisor-dev wrote:
Hi IOvisor-group,
I'm playing with kernels samples/bpf, and want so advice on debugging
eBPF programs.
First question: I noticed bpf_trace_printk(), but nothing shows up when
I'm using it... what did I miss/forget?
Depends
On 01/19/2017 04:53 PM, William Tu wrote:
thanks for the patch, it works.
Thanks a lot, I'll see to cook a proper patch then.
from 52 to 80: R0=imm1,min_value=1,max_value=1 R1=pkt(id=0,off=0,r=34)
R2=pkt_end R3=inv R4=imm272 R5=inv56,min_value=17,max_value=17
R6=pkt(id=0,off=26,r=34) R10=fp
8
On 01/18/2017 06:29 PM, William Tu wrote:
Hi Daniel,
Thanks for the patch. Yes, it solves my issue. Then there is another
related due to BPF_AND
LBB0_12:
; if (ebpf_packetEnd < ebpf_packetStart + BYTES(ebpf_packetOffsetInBits + 64)) {
from 52 to 80: R0=imm1,min_value=1,max_value=1 R1=pkt(id=0,o
On 01/12/2017 07:50 PM, William Tu via iovisor-dev wrote:
Hi,
I observed that for direct packet access, we have to use this data and
data_end checking pattern:
int xdp_prog1(struct xdp_md *ctx)
{
void *data_end = (void *)(long)ctx->data_end;
void *data = (void *)(long)ctx->data;
Hi William,
On 01/12/2017 07:32 PM, William Tu via iovisor-dev wrote:
Hi,
I encounter the following BPF verifier error:
from 28 to 30: R0=imm1,min_value=1,max_value=1 R1=pkt(id=0,off=0,r=22)
R2=pkt_end R3=imm144,min_value=144,max_value=144
R4=imm0,min_value=0,max_value=0 R5=inv48,min_value=2054
On 01/11/2017 10:51 PM, Mauricio Vasquez wrote:
Hi Daniel,
On 01/10/2017 04:49 AM, Daniel Borkmann wrote:
On 01/09/2017 04:48 PM, Mauricio Vasquez via iovisor-dev wrote:
Hello,
I am trying to implement an eBPF program that trims an UDP packet to a predefined
length. I am able to trim the pac
On 01/09/2017 04:48 PM, Mauricio Vasquez via iovisor-dev wrote:
Hello,
I am trying to implement an eBPF program that trims an UDP packet to a predefined
length. I am able to trim the packet (using the bpf_change_tail helper) and also to
update the ip->len and udp->length fields. After changing
On 10/25/2016 08:00 PM, Chandrasekar Kannan via iovisor-dev wrote:
[...]
But when I try to run the sample from the linux source tree under release
(v4.8),
I get some strange errors.
"Error fetching program/map!
Failed to retrieve (e)BPF data!"
Details here : http://pastebin.com/raw/CTfq65ap
An
On 07/02/2016 11:29 PM, Thomas Graf wrote:
Hi
When using direct packet access I noticed that the verifier cannot
cary the packet length validation check across tail calls. This is
mainly a burden for L4 where L3 may require some more expensive logic
to handle variable length headers.
Yeah, che
On 06/16/2016 10:59 PM, Richard Henderson wrote:
On 06/16/2016 12:55 PM, Daniel Borkmann wrote:
+ EM_BPF = 0xeb9f, // Linux kernel bpf virtual machine
Great, can that be assumed the final magic e_machine number for the ELF
header that eBPF loaders can check for as well then (I do li
On 06/16/2016 06:57 PM, Richard Henderson via iovisor-dev wrote:
On 06/15/2016 10:14 PM, Alexei Starovoitov wrote:
On Wed, Jun 15, 2016 at 2:37 PM, Richard Henderson via iovisor-dev
wrote:
This same value for EM_BPF is being propagated to glibc,
elfutils, and binutils.
great!
Can you share t
64 matches
Mail list logo
