Re: [PATCH v3 net-next 1/1] bpf32->bpf64 mapper and bpf64 interpreter

2014-02-28 Thread Daniel Borkmann
On 02/28/2014 09:53 PM, Alexei Starovoitov wrote: On Fri, Feb 28, 2014 at 4:45 AM, Daniel Borkmann wrote: ... Did you also test that seccomp-BPF still works out? yes. Have a prototype, but it needs a bit more cleanup. Here's [1] actually some code snippet for user space for prctl()

Re: Experimental Privacy Functions and TCP SYN Payloads

2014-02-12 Thread Daniel Borkmann
(please cc netdev) On 02/12/2014 11:25 AM, Quinn Wood wrote: If program on host A spoofs the source address of an outgoing IPv4 packet then places that address in the first 32 bits of a UDP payload, a program on host B that is aware of these behaviors can still reply to the program on host A. [1

Re: [BUG] at include/linux/page-flags.h:415 (PageTransHuge)

2014-02-12 Thread Daniel Borkmann
Hi Vlastimil, On 02/07/2014 07:58 PM, Hannes Frederic Sowa wrote: On Fri, Jan 31, 2014 at 03:40:38PM +0100, Vlastimil Babka wrote: From: Vlastimil Babka Date: Fri, 31 Jan 2014 11:50:21 +0100 Subject: [PATCH] mm: include VM_MIXEDMAP flag in the VM_SPECIAL list to avoid m(un)locking Daniel

[PATCH akpm-next] random32: minor cleanups and kdoc fix

2014-02-12 Thread Daniel Borkmann
x27;s done everywhere else. random_get_entropy() results mostly into get_cycles() which returns unsigned long whereas seed is given in u32. Last but not least for readability, add some newlines. Signed-off-by: Daniel Borkmann --- lib/random32.c | 15 +-- 1 file changed, 9 insertions(+), 6

[PATCH akpm-next v2] random32: minor cleanups and kdoc fix

2014-02-13 Thread Daniel Borkmann
x27;s done everywhere else. Also, use the normal comment style for the header comment. Last but not least for readability, add some newlines. Signed-off-by: Daniel Borkmann --- v1->v2: - Applied most of Joe's feedback lib/random32.c | 76 ++--

Re: [BISECTED] Linux 3.12.7 introduces page map handling regression

2014-01-22 Thread Daniel Borkmann
On 01/22/2014 08:29 AM, Steven Noonan wrote: On Wed, Jan 22, 2014 at 12:02:15AM -0500, Konrad Rzeszutek Wilk wrote: On Tue, Jan 21, 2014 at 07:20:45PM -0800, Steven Noonan wrote: On Tue, Jan 21, 2014 at 06:47:07PM -0800, Linus Torvalds wrote: On Tue, Jan 21, 2014 at 5:49 PM, Greg Kroah-Hartman

Re: [PATCH 1/1] Per socket value for max datagram queue length

2014-01-22 Thread Daniel Borkmann
On 01/22/2014 04:11 PM, Dan Ballard wrote: Provides a new option for setsockopt SO_MAX_DGRAM_QLEN that sets and gets a socket specific max datagram queue length. Currently each socket has one but it's only ever initialized from /proc/sys/net/unix/max_dgram_qlen and then never adjustable later. No

Re: [PATCH] cpts: add missing

2014-04-06 Thread Daniel Borkmann
On 04/06/2014 01:55 PM, Sergei Trofimovich wrote: From: Sergei Trofimovich gcc complains as: drivers/net/ethernet/ti/cpts.c: In function 'cpts_match': drivers/net/ethernet/ti/cpts.c:266:12: error: 'ETH_HLEN' undeclared (first use in this function) drivers/net/ethernet/ti/cpts.c:

Re: [PATCH] cpts: Fix missing includes

2014-04-06 Thread Daniel Borkmann
On 04/06/2014 07:34 PM, Vincent Stehlé wrote: The ETH_HLEN and VLAN_HLEN definitions are not in if.h any more. Add the necessary includes to fix the following compilation errors: drivers/net/ethernet/ti/cpts.c: In function ‘cpts_match’: drivers/net/ethernet/ti/cpts.c:266:12: error: ‘ETH_HL

Re: 3.14 tc oops

2014-04-07 Thread Daniel Borkmann
[Kelly, please also cc netdev] On 04/07/2014 07:56 AM, Cong Wang wrote: On Thu, Apr 3, 2014 at 9:24 AM, Cong Wang wrote: On Wed, Apr 2, 2014 at 7:24 AM, Kelly Anderson wrote: Hi, I hit a kernel oops when starting traffic control on my armv7 router, I don't think the architecture is related,

Re: proc net statistics

2014-04-07 Thread Daniel Borkmann
On 04/07/2014 07:19 PM, Cong Wang wrote: On Mon, Apr 7, 2014 at 10:10 AM, Ken O'Brien wrote: Ok, so then, is there a way to read per process network statistics in the proc filesystem? AFAIK, we only have per-socket and per-netdev statistics, there is no per-process one, you probably want to

Re: linux-next: manual merge of the bluetooth tree with the net/net-next trees

2014-01-07 Thread Daniel Borkmann
On 01/07/2014 02:54 AM, Stephen Rothwell wrote: Hi Gustavo, Today's linux-next merge of the bluetooth tree got a conflict in net/ieee802154/6lowpan.c between commit 965801e1eb62 ("net: 6lowpan: fix lowpan_header_create non-compression memcpy call") from the tree and commit 8df8c56a5abc ("6lowpa

[BUG] at include/linux/page-flags.h:415 (PageTransHuge)

2014-01-10 Thread Daniel Borkmann
This is being reliably triggered for each mmaped() packet(7) socket from user space, basically during unmapping resp. closing the TX socket. I believe due to some change in transparent hugepages code ? When I disable transparent hugepages, everything works fine, no BUG triggered. I'd be happy t

Re: [BUG] at include/linux/page-flags.h:415 (PageTransHuge)

2014-01-11 Thread Daniel Borkmann
On 01/11/2014 07:22 AM, Andrew Morton wrote: On Fri, 10 Jan 2014 19:23:26 +0100 Daniel Borkmann wrote: This is being reliably triggered for each mmaped() packet(7) socket from user space, basically during unmapping resp. closing the TX socket. I believe due to some change in transparent

Re: [PATCH 1/1] When timestamping is enabled, stmmac_tx_clean will call stmmac_get_tx_hwtstamp to get tx TS. It's possible that skb is NULL because there are other network frames that use several desc

2014-01-12 Thread Daniel Borkmann
On 01/12/2014 10:39 AM, Bruce Liu wrote: When timestamping is enabled, stmmac_tx_clean will call stmmac_get_tx_hwtstamp to get tx TS. It's possible that skb is NULL because there are other network frames that use several descriptors. So we must return immediately in stmmac_get_tx_hwtstamp

Re: [PATCH v3] crypto: more robust crypto_memneq

2013-11-26 Thread Daniel Borkmann
On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote: Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE

Re: [PATCH v3] crypto: more robust crypto_memneq

2013-11-27 Thread Daniel Borkmann
On 11/26/2013 10:44 PM, Cesar Eduardo Barros wrote: Em 26-11-2013 17:27, Daniel Borkmann escreveu: On 11/26/2013 01:00 AM, Cesar Eduardo Barros wrote: Compile-tested on x86_64. Actually with yet another version, I hoped that the "compile-tested"-only statement would eventually disa

Re: [BUG] at include/linux/page-flags.h:415 (PageTransHuge)

2014-01-13 Thread Daniel Borkmann
On 01/13/2014 11:16 AM, Vlastimil Babka wrote: On 01/11/2014 02:32 PM, Daniel Borkmann wrote: On 01/11/2014 07:22 AM, Andrew Morton wrote: On Fri, 10 Jan 2014 19:23:26 +0100 Daniel Borkmann wrote: This is being reliably triggered for each mmaped() packet(7) socket from user space

Re: [BUG] at include/linux/page-flags.h:415 (PageTransHuge)

2014-01-15 Thread Daniel Borkmann
[keeping netdev in loop as well] On 01/15/2014 03:27 PM, Vlastimil Babka wrote: On 01/13/2014 12:39 PM, Daniel Borkmann wrote: On 01/13/2014 11:16 AM, Vlastimil Babka wrote: On 01/11/2014 02:32 PM, Daniel Borkmann wrote: On 01/11/2014 07:22 AM, Andrew Morton wrote: On Fri, 10 Jan 2014 19:23

Re: linux-next: manual merge of the random tree with the net-next tree

2013-11-12 Thread Daniel Borkmann
Hi Stephen, On 11/12/2013 05:55 AM, Stephen Rothwell wrote: Hi Ted, Today's linux-next merge of the random tree got a conflict in drivers/char/random.c between commit 0244ad004a54 ("random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized") from the net-next tree a

Re: [PATCH 1/1] net: sctp: bug fixing when sctp path recovers

2013-11-13 Thread Daniel Borkmann
On 11/13/2013 03:54 AM, Chang wrote: On 11/13/2013 03:37 AM, Vlad Yasevich wrote: On 11/12/2013 08:34 PM, Chang Xiangzhong wrote: Look for the __two__ most recently used path/transport and set to active_path and retran_path respectively Please also for the log, elaborate a bit more, explainin

Re: [PATCH] crypto: more robust crypto_memneq

2013-11-25 Thread Daniel Borkmann
On 11/25/2013 04:59 PM, James Yonan wrote: On 24/11/2013 14:12, Cesar Eduardo Barros wrote: Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a d

Re: [PATCH v2] crypto: more robust crypto_memneq

2013-11-25 Thread Daniel Borkmann
-independent timing) even if it is inlined at its call sites. That can be done later in a followup patch. Compile-tested on x86_64. Signed-off-by: Cesar Eduardo Barros Acked-by: Daniel Borkmann Looks good, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu

[PATCH net-next 2/5] lib: crc32: add functionality to combine two crc32{,c}s in GF(2)

2013-10-30 Thread Daniel Borkmann
insufficient as two crcs and the length of the second piece is needed for merging. The code is made generic, so that only polynomials need to be passed for crc32_le resp. crc32c_le. Signed-off-by: Daniel Borkmann Cc: linux-kernel@vger.kernel.org --- include/linux/crc32.h | 40

[PATCH net-next 3/5] lib: crc32: add test cases for crc32{,c}_combine routines

2013-10-30 Thread Daniel Borkmann
tests passed [ 17.633089] alg: No test for crc32 (crc32-pclmul) Signed-off-by: Daniel Borkmann Cc: linux-kernel@vger.kernel.org --- lib/crc32.c | 72 + 1 file changed, 72 insertions(+) diff --git a/lib/crc32.c b/lib/crc32.c index

[PATCH net-next 1/5] lib: crc32: clean up spacing in test cases

2013-10-30 Thread Daniel Borkmann
This is nothing more but a whitepace cleanup, as 80 chars is not a hard but soft limit, and otherwise makes the test cases arrary really look ugly. So fix it up. Signed-off-by: Daniel Borkmann Cc: linux-kernel@vger.kernel.org --- lib/crc32.c | 300

Re: [PATCH net-next 1/5] lib: crc32: clean up spacing in test cases

2013-10-30 Thread Daniel Borkmann
On 10/30/2013 03:10 PM, David Laight wrote: + {0x674bf11d, 0x0038, 0x0542, 0x0af6d466, 0xd8b6e4c1, 0xf6e93d6c}, these could be + {0x674bf11d, 0x38, 0x542, 0x0af6d466, 0xd8b6e4c1, 0xf6e93d6c}, Or even: #define X(a, b, c, d, e, f) {0x##a, 0x##b, 0x##c, 0x##d, 0x##e. 0x##f}

Re: [PATCH net-next v2 1/2] lib: introduce arch optimized hash library

2013-12-12 Thread Daniel Borkmann
On 12/12/2013 06:54 PM, Nicolas Dichtel wrote: ... Is it possible to trace that this comes from the DPDK? At least in the commit log, like it was done in the v1. Hm, that got lost; but we can put that back into the commit log. In any case, we properly included the header comment, of course. +

Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)

2014-09-16 Thread Daniel Borkmann
On 09/17/2014 02:39 AM, Alexei Starovoitov wrote: add optional attributes for BPF_PROG_LOAD syscall: union bpf_attr { struct { ... __u32 log_level; /* verbosity level of eBPF verifier */ __u32 log_size; /* size of user buffer */ __aligned_u64

Re: [PATCH v11 net-next 12/12] bpf: mini eBPF library, test stubs and verifier testsuite

2014-09-17 Thread Daniel Borkmann
On 09/10/2014 08:08 PM, Alexei Starovoitov wrote: On Wed, Sep 10, 2014 at 4:35 AM, Daniel Borkmann wrote: Since we already have an extensive BPF test suite, that is, lib/test_bpf.c, which currently also does sanity checks for the classic BPF verifier, is there a reason these verifier test

Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)

2014-09-17 Thread Daniel Borkmann
On 09/17/2014 06:08 PM, Alexei Starovoitov wrote: On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann wrote: /* last field in 'union bpf_attr' used by this command */ -#defineBPF_PROG_LOAD_LAST_FIELD license +#defineBPF_PROG_LOAD_LAST_FIELD log_buf I was looking

Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)

2014-09-17 Thread Daniel Borkmann
On 09/17/2014 07:03 PM, Daniel Borkmann wrote: On 09/17/2014 06:08 PM, Alexei Starovoitov wrote: On Tue, Sep 16, 2014 at 11:51 PM, Daniel Borkmann wrote: /* last field in 'union bpf_attr' used by this command */ -#defineBPF_PROG_LOAD_LAST_FIELD licens

Re: [PATCH v11 net-next 12/12] bpf: mini eBPF library, test stubs and verifier testsuite

2014-09-17 Thread Daniel Borkmann
On 09/17/2014 06:17 PM, Alexei Starovoitov wrote: On Wed, Sep 17, 2014 at 12:16 AM, Daniel Borkmann wrote: That actually still doesn't answer my question why the test stub cannot live in lib/test_bpf where we have our actual testing framework for eBPF/BPF, also since you exactly only

Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)

2014-09-17 Thread Daniel Borkmann
On 09/18/2014 01:45 AM, Alexei Starovoitov wrote: On Wed, Sep 17, 2014 at 12:37 PM, Alexei Starovoitov wrote: Hm, thinking out loudly ... perhaps this could be made a library problem. Such that the library which wraps the syscall needs to be aware of a marker where the initial version ends, a

Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)

2014-09-18 Thread Daniel Borkmann
On 09/18/2014 04:34 PM, Alexei Starovoitov wrote: On Wed, Sep 17, 2014 at 11:44 PM, Daniel Borkmann wrote: ... Sure, you will never get a full compatibility on that regard while backwards compatibility needs to be guaranteed on the other hand. I looked at perf_copy_attr() implementation and I

Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)

2014-09-18 Thread Daniel Borkmann
On 09/18/2014 05:24 PM, Alexei Starovoitov wrote: ... solve or not. If we decide to solve it, we need to have a plan to solve it all the way. Partial fix for size of bpf_attr is not a plan. It's something that is not addressing the problem completely. Little bit of help is not useful for userspac

[PATCH net-next 0/2] reciprocal_divide updates

2014-01-15 Thread Daniel Borkmann
Set is on top of Eric's BPF fix, that is: http://patchwork.ozlabs.org/patch/311163/ Daniel Borkmann (1): random32: add prandom_u32_lt_N and convert "misuses" of reciprocal_divide Hannes Frederic Sowa (1): reciprocal_divide: correction/update of the algorithm driv

[PATCH net-next 1/2] random32: add prandom_u32_lt_N and convert "misuses" of reciprocal_divide

2014-01-15 Thread Daniel Borkmann
Eric Dumazet Cc: linux-kernel@vger.kernel.org Signed-off-by: Hannes Frederic Sowa Signed-off-by: Daniel Borkmann --- drivers/net/team/team_mode_random.c | 8 +--- include/linux/random.h | 19 ++- include/net/codel.h | 4 +--- net/packet/af_packet.c

[PATCH net-next 2/2] reciprocal_divide: correction/update of the algorithm

2014-01-15 Thread Daniel Borkmann
))>>sh_2 The assembler implementation from Agner Fog [6] also helped a lot while implementing. We have tested the implementation on x86_64, ppc64, i686, s390x; on x86_64/haswell we're still half the latency compared to normal divide. Joint work with Daniel Borkmann. [1] http://www

Re: [PATCH net-next 1/2] random32: add prandom_u32_lt_N and convert "misuses" of reciprocal_divide

2014-01-16 Thread Daniel Borkmann
On 01/16/2014 01:29 AM, Joe Perches wrote: On Thu, 2014-01-16 at 00:23 +0100, Daniel Borkmann wrote: Many functions have open coded a function that return a random number in range [0,N-1]. Also, only because we have a function that is named reciprocal_divide(), it has not much to do with the

Re: [PATCH net-next 1/2] random32: add prandom_u32_lt_N and convert "misuses" of reciprocal_divide

2014-01-16 Thread Daniel Borkmann
On 01/16/2014 04:14 AM, Eric Dumazet wrote: On Thu, 2014-01-16 at 00:23 +0100, Daniel Borkmann wrote: @@ -1220,7 +1219,7 @@ static unsigned int fanout_demux_hash(struct packet_fanout *f, struct sk_buff *skb, unsigned

Re: [PATCH net-next v2 2/3] net: add trim helper and convert users

2014-01-17 Thread Daniel Borkmann
On 01/17/2014 10:52 AM, David Laight wrote: From: Hannes Frederic Sowa ... +/** + * trim - perform a reciprocal multiplication in order to "clamp" a + *value into range [0, ep_ro), where the upper interval + *endpoint is right-open. This is useful, e.g. for accessing + *a

Re: [PATCH 1/6] cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of tristate

2014-01-18 Thread Daniel Borkmann
On 01/18/2014 02:08 AM, Li Zefan wrote: > Cc: Daniel Borkmann > > On 2014/1/18 2:11, Tejun Heo wrote: >> net_cls and net_prio are the only cgroups which are allowed to be >> built as modules. The savings from allowing the two controllers to be >> built as modules are

Re: [PATCH 1/6] cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of tristate

2014-01-18 Thread Daniel Borkmann
On 01/18/2014 04:10 PM, Tejun Heo wrote: Hey, On Sat, Jan 18, 2014 at 09:08:49AM +0800, Li Zefan wrote: Cc: Daniel Borkmann On 2014/1/18 2:11, Tejun Heo wrote: net_cls and net_prio are the only cgroups which are allowed to be built as modules. The savings from allowing the two controllers

Re: [PATCH 1/6] cgroup: make CONFIG_NET_CLS_CGROUP and CONFIG_NETPRIO_CGROUP bool instead of tristate

2014-01-18 Thread Daniel Borkmann
On 01/18/2014 04:28 PM, Tejun Heo wrote: On Sat, Jan 18, 2014 at 04:26:24PM +0100, Daniel Borkmann wrote: Unless there's gonna be another rc, I think it's already a bit too late for 3.14 anyway. I'll drop the net_cls part and rebase the changes on top of rc1 later on. I think

[PATCH net-next v3 1/3] random32: add prandom_u32_max and convert open coded users

2014-01-18 Thread Daniel Borkmann
zet Cc: linux-kernel@vger.kernel.org Signed-off-by: Hannes Frederic Sowa Signed-off-by: Daniel Borkmann --- drivers/net/team/team_mode_random.c | 8 +--- include/linux/random.h | 18 +- net/packet/af_packet.c | 2 +- net/sched/sch_choke.c |

[PATCH net-next v3 2/3] net: introduce reciprocal_scale helper and convert users

2014-01-18 Thread Daniel Borkmann
owa. [1] http://homepage.cs.uiowa.edu/~jones/bcd/divide.html Suggested-by: David Laight Cc: Jakub Zawadzki Cc: Eric Dumazet Cc: linux-kernel@vger.kernel.org Signed-off-by: Hannes Frederic Sowa Signed-off-by: Daniel Borkmann --- include/linux/kernel.h | 19 +++ include/n

[PATCH net-next v3 3/3] reciprocal_divide: update/correction of the algorithm

2014-01-18 Thread Daniel Borkmann
2 The assembler implementation from Agner Fog [6] also helped a lot while implementing. We have tested the implementation on x86_64, ppc64, i686, s390x; on x86_64/haswell we're still half the latency compared to normal divide. Joint work with Daniel Borkmann. [1] http://www.wireshark.org/~darkj

Re: [PATCH v14 net-next 00/11] eBPF syscall, verifier, testsuite

2014-09-22 Thread Daniel Borkmann
On 09/22/2014 02:06 AM, Alexei Starovoitov wrote: ... v13 -> v14: - small change to 1st patch to ease 'new userspace with old kernel' problem (done similar to perf_copy_attr()) (suggested by Daniel) Thanks for taking care of it. -- To unsubscribe from this list: send the line "unsubscribe li

Re: [PATCH v11 net-next 11/12] net: filter: move eBPF instruction macros

2014-09-10 Thread Daniel Borkmann
On 09/10/2014 08:16 PM, Alexei Starovoitov wrote: On Wed, Sep 10, 2014 at 4:24 AM, Daniel Borkmann wrote: On 09/10/2014 07:10 AM, Alexei Starovoitov wrote: move instruction macros (like BPF_MOV64_REG or BPF_ALU32_IMM) from linux/filter.h into uapi/linux/bpf.h so that userspace programs can

[PATCH arm64-next] net: bpf: arm64: fix module memory leak when JIT image build fails

2014-09-11 Thread Daniel Borkmann
offsets, but not the actual allocated target image where opcodes are being stored. Fix it by calling module_free() on dismantle time in case of errors. Signed-off-by: Daniel Borkmann Cc: Zi Shen Lim Cc: Alexei Starovoitov Cc: Will Deacon --- [ Compile-tested only. ] arch/arm64/net

Re: [PATCH v11 net-next 00/12] eBPF syscall, verifier, testsuite

2014-09-11 Thread Daniel Borkmann
On 09/10/2014 07:32 PM, Alexei Starovoitov wrote: On Wed, Sep 10, 2014 at 2:03 AM, Daniel Borkmann wrote: struct { /* anonymous struct used by BPF_PROG_LOAD command */ enum bpf_prog_typeprog_type; __u32 insn_cnt

Re: [PATCH v11 net-next 00/12] eBPF syscall, verifier, testsuite

2014-09-11 Thread Daniel Borkmann
On 09/10/2014 10:21 PM, Alexei Starovoitov wrote: ... char bpf_log_buf[LOG_BUF_SIZE]; What happens if the size isn't LOG_BUF_SIZE? would do you mean? LOG_BUF_SIZE is just a user defined macro. Can be anything. I believe, Andy means, what would happen if log_level > 0 but the

[PATCH arm64-next] net: bpf: arm64: address randomize and write protect JIT code

2014-09-12 Thread Daniel Borkmann
g structure, but instead bpf_prog_unlock_free() through a different allocator. JIT tested on aarch64 with BPF test suite. Reference: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html Signed-off-by: Daniel Borkmann Reviewed-by: Zi Shen Lim Cc: Will Deacon

Re: [PATCH arm64-next] net: bpf: arm64: address randomize and write protect JIT code

2014-09-12 Thread Daniel Borkmann
On 09/12/2014 06:03 PM, Catalin Marinas wrote: Daniel, On Fri, Sep 12, 2014 at 08:11:37AM +0100, Daniel Borkmann wrote: Will, Catalin, Dave, this is more or less a heads-up: when net-next and arm64-next tree will get both merged into Linus' tree, we will run into a 'sil

Re: [PATCH arm64-next] net: bpf: arm64: address randomize and write protect JIT code

2014-09-12 Thread Daniel Borkmann
On 09/12/2014 06:46 PM, Catalin Marinas wrote: On Fri, Sep 12, 2014 at 05:21:27PM +0100, Daniel Borkmann wrote: On 09/12/2014 06:03 PM, Catalin Marinas wrote: On Fri, Sep 12, 2014 at 08:11:37AM +0100, Daniel Borkmann wrote: Will, Catalin, Dave, this is more or less a heads-up: when net

[PATCH arm64-next v2] net: bpf: arm64: address randomize and write protect JIT code

2014-09-12 Thread Daniel Borkmann
g structure, but instead bpf_prog_unlock_free() through a different allocator. JIT tested on aarch64 with BPF test suite. Reference: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html Signed-off-by: Daniel Borkmann Cc: Zi Shen Lim Cc: Will Deacon Cc: Cat

Re: [PATCH arm64-next] net: bpf: arm64: address randomize and write protect JIT code

2014-09-12 Thread Daniel Borkmann
On 09/12/2014 07:21 PM, Catalin Marinas wrote: ... We don't have a brk instruction for arm32 but we have guaranteed undefined space. Have a look at the kgdb support for example (or grep for register_undef_hook under arch/arm) to get an idea. Will do, thanks! Last but not least ;), if I would

Re: [PATCH] net: bpf: correctly handle errors in sk_attach_filter()

2014-09-13 Thread Daniel Borkmann
e() the vmalloc()ed memory, and leak the internal bpf_work_struct. Signed-off-by: Sasha Levin [ This patch is for net-next. ] Acked-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org Mor

Re: [PATCH arm64-next v2] net: bpf: arm64: address randomize and write protect JIT code

2014-09-15 Thread Daniel Borkmann
On 09/13/2014 06:32 AM, Z Lim wrote: On Fri, Sep 12, 2014 at 10:35 AM, Daniel Borkmann wrote: This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf jit against spraying attacks"). Thanks to commit 11d91a770f1f ("arm64: Add CONFIG_DEBUG_SET_MODULE_RONX suppor

[PATCH arm64-next v3] net: bpf: arm64: address randomize and write protect JIT code

2014-09-15 Thread Daniel Borkmann
fferent allocator. JIT tested on aarch64 with BPF test suite. Reference: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html Signed-off-by: Daniel Borkmann Cc: Zi Shen Lim Cc: Will Deacon Cc: Catalin Marinas Cc: David S. Miller Cc: Alexei Starovoitov

Re: [PATCH arm64-next v3] net: bpf: arm64: address randomize and write protect JIT code

2014-09-15 Thread Daniel Borkmann
On 09/15/2014 11:30 PM, Will Deacon wrote: Hi Daniel, One small comment than I forgot to mention before (see below). On Mon, Sep 15, 2014 at 09:20:23PM +0100, Daniel Borkmann wrote: This is the ARM64 variant for 314beb9bcab ("x86: bpf_jit_comp: secure bpf jit against spraying at

[PATCH arm64-next v4] net: bpf: arm64: address randomize and write protect JIT code

2014-09-16 Thread Daniel Borkmann
fferent allocator. JIT tested on aarch64 with BPF test suite. Reference: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html Signed-off-by: Daniel Borkmann Cc: Zi Shen Lim Cc: Will Deacon Cc: Catalin Marinas Cc: David S. Miller Cc: Alexei Starovoitov -

Re: [PATCH v7 net-next 1/3] filter: add Extended BPF interpreter and converter

2014-03-09 Thread Daniel Borkmann
can be loaded through old sk_attach_filter() and sk_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

Re: [PATCH v7 net-next 1/3] filter: add Extended BPF interpreter and converter

2014-03-09 Thread Daniel Borkmann
On 03/09/2014 06:08 PM, Alexei Starovoitov wrote: On Sun, Mar 9, 2014 at 5:29 AM, Daniel Borkmann wrote: On 03/09/2014 12:15 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

Re: [PATCH] MAINTAINERS: Add tools/net to NETWORKING [GENERAL]

2014-03-11 Thread Daniel Borkmann
On 03/11/2014 12:06 PM, Tobias Klauser wrote: Make sure patches for these tools go to the netdev list as well. References: https://marc.info/?l=linux-kernel&m=139450284501328&w=2 Cc: David S. Miller Cc: Daniel Borkmann Signed-off-by: Tobias Klauser Acked-by: Daniel Borkmann T

Re: [PATCH] MAINTAINERS: Add tools/net to NETWORKING [GENERAL]

2014-03-11 Thread Daniel Borkmann
On 03/11/2014 12:06 PM, Tobias Klauser wrote: Make sure patches for these tools go to the netdev list as well. References: https://marc.info/?l=linux-kernel&m=139450284501328&w=2 Cc: David S. Miller Cc: Daniel Borkmann Signed-off-by: Tobias Klauser --- MAINTAINERS |1 + 1 file

Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

2014-02-13 Thread Daniel Borkmann
On 02/07/2014 02:20 AM, Alexei Starovoitov wrote: ... Hi Daniel, Thanks for your answer and sorry for the late reply. Thank you for taking a look. Good questions. I had the same concerns. Old BPF was carefully extended in specific places. End result may look big at first glance, but every ext

Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

2014-02-13 Thread Daniel Borkmann
On 02/13/2014 09:20 PM, Daniel Borkmann wrote: On 02/07/2014 02:20 AM, Alexei Starovoitov wrote: ... Hi Daniel, Thanks for your answer and sorry for the late reply. Thank you for taking a look. Good questions. I had the same concerns. Old BPF was carefully extended in specific places. End

Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

2014-02-13 Thread Daniel Borkmann
On 02/13/2014 11:32 PM, H. Peter Anvin wrote: On 02/06/2014 05:20 PM, Alexei Starovoitov wrote: I believe that old BPF outlived itself and BPF64 should replace it in all current use cases plus a lot more. It just cannot happen at once. BPF64 can come in. bpf32->bpf64 converter functioning. JIT

Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

2014-02-13 Thread Daniel Borkmann
On 02/13/2014 11:47 PM, H. Peter Anvin wrote: On 02/13/2014 02:44 PM, Daniel Borkmann wrote: Well, if that would be the case, then seccomp would have had JIT support long ago. ;-) Right now BPF filters with seccomp are not JIT compiled for _any_ architecture. Really, I was under the

Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

2014-02-14 Thread Daniel Borkmann
On 02/14/2014 01:59 AM, Alexei Starovoitov wrote: ... I'm very curious, do you also have any performance numbers, e.g. for networking by taking JIT'ed/non-JIT'ed BPF filters and compare them against JIT'ed/non-JIT'ed eBPF filters to see how many pps we gain or loose e.g. for a scenario with a mid

Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

2014-02-14 Thread Daniel Borkmann
On 02/14/2014 05:47 AM, Alexei Starovoitov wrote: ... Do you see a possibility to integrate your work step by step? That is, Sure. let's see how we can do it. to first integrate the interpreter part only; meaning, to detect "old" BPF programs e.g. coming from SO_ATTACH_FILTER et al and run th

Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

2014-02-15 Thread Daniel Borkmann
On 02/14/2014 06:55 PM, Alexei Starovoitov wrote: On Fri, Feb 14, 2014 at 9:02 AM, Daniel Borkmann wrote: On 02/14/2014 01:59 AM, Alexei Starovoitov wrote: ... I'm very curious, do you also have any performance numbers, e.g. for networking by taking JIT'ed/non-JIT'ed BPF filt

Re: [PATCH] csum_partial_copy_from_user: clean up inconsistencies in implementations

2014-02-17 Thread Daniel Borkmann
On 02/17/2014 11:20 PM, Mikulas Patocka wrote: ... The proper way to add commentary is to put it after the "---" delimiter at the end of the commit message and before the actual patch. Interesting - I used "---" as a delimiter between the commentary and the git message in the past and some peop

[PATCH net-next 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set

2014-03-21 Thread Daniel Borkmann
[kernel.kallsyms] [k] __secure_computing 0.93% bench [kernel.kallsyms] [k] sys_getuid BPF filters generated by seccomp are very branchy, so the new internal BPF performance is better than the old one. Performance gains will be even higher when BPF JIT is committed for the new structure, wh

[PATCH net-next v2 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set

2014-03-25 Thread Daniel Borkmann
[kernel.kallsyms] [k] __secure_computing 0.93% bench [kernel.kallsyms] [k] sys_getuid BPF filters generated by seccomp are very branchy, so the new internal BPF performance is better than the old one. Performance gains will be even higher when BPF JIT is committed for the new structure, wh

[PATCH net-next v3 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set

2014-03-26 Thread Daniel Borkmann
the new structure, which is planned in future work (as successive JIT migrations). BPF has also been stress-tested with trinity's BPF fuzzer. Joint work with Daniel Borkmann. References: http://thread.gmane.org/gmane.linux.kernel/1665858 Signed-off-by: Alexei Starovoitov Signed-off-by: Da

Re: [PATCH] random32: avoid attempt to late reseed if in the middle of seeding

2014-03-26 Thread Daniel Borkmann
On 03/26/2014 06:12 PM, Sasha Levin wrote: Commit 4af712e8df ("random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized") has added a late reseed stage that happens as soon as the nonblocking pool is marked as initialized. This fails in the case that the nonblocking

Re: [PATCH] random32: avoid attempt to late reseed if in the middle of seeding

2014-03-26 Thread Daniel Borkmann
On 03/27/2014 12:35 AM, Sasha Levin wrote: On 03/26/2014 07:18 PM, Daniel Borkmann wrote: On 03/26/2014 06:12 PM, Sasha Levin wrote: Commit 4af712e8df ("random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized") has added a late reseed stage that happe

Re: [PATCH v2] random32: avoid attempt to late reseed if in the middle of seeding

2014-03-27 Thread Daniel Borkmann
reseed if a reseed is already occuring. Signed-off-by: Sasha Levin Looks better now, thanks! Fixes: 4af712e8df99 ("random32: add prandom_reseed_late() and call when nonblocking pool becomes initialized") Acked-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsub

Re: [PATCH] random32: avoid attempt to late reseed if in the middle of seeding

2014-03-27 Thread Daniel Borkmann
On 03/27/2014 03:21 AM, Hannes Frederic Sowa wrote: On Wed, Mar 26, 2014 at 07:35:01PM -0400, Sasha Levin wrote: On 03/26/2014 07:18 PM, Daniel Borkmann wrote: On 03/26/2014 06:12 PM, Sasha Levin wrote: Commit 4af712e8df ("random32: add prandom_reseed_late() and call when nonblocking

Re: [PATCH] random32: avoid attempt to late reseed if in the middle of seeding

2014-03-27 Thread Daniel Borkmann
On 03/27/2014 10:18 AM, Hannes Frederic Sowa wrote: On Thu, Mar 27, 2014 at 10:04:03AM +0100, Daniel Borkmann wrote: On 03/27/2014 03:21 AM, Hannes Frederic Sowa wrote: On Wed, Mar 26, 2014 at 07:35:01PM -0400, Sasha Levin wrote: On 03/26/2014 07:18 PM, Daniel Borkmann wrote: On 03/26/2014

Re: [RFC PATCH 00/28] ktap: A lightweight dynamic tracing tool for Linux

2014-04-14 Thread Daniel Borkmann
On 04/14/2014 05:11 PM, Ingo Molnar wrote: * Jovi Zhangwei wrote: Obviously many people love ktap nowadays even though it's not a C-family language, [...] Imagine how much more widespread it would become amongst kernel developers if it had C syntax - see PeterZ's reply for example. +1 I t

Re: [PATCH] seccomp: fix memory leak on filter attach

2014-04-14 Thread Daniel Borkmann
l+0x3bb/0x4a0 [] system_call_fastpath+0x1a/0x1f [] 0x Reported-by: Masami Ichikawa Signed-off-by: Kees Cook Cc: sta...@vger.kernel.org Acked-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord.

[PATCH] seccomp: fix populating a0-a5 syscall args in 32-bit x86 BPF

2014-04-14 Thread Daniel Borkmann
slow ssh X forwarding, but it fixes the issue on my side. So fix it up by storing args in type correct variables, gcc is clever and optimizes the copy away in other cases, e.g. x86_64. Fixes: bd4cf0ed331a ("net: filter: rework/optimize internal BPF interpreter's instruction set")

Re: [net] b58537a1f56: +89.2% netperf.Throughput_Mbps

2014-06-18 Thread Daniel Borkmann
On 06/18/2014 10:29 PM, David Rientjes wrote: On Wed, 18 Jun 2014, Jet Chen wrote: Hi Daniel, FYI, we noticed the below changes on commit b58537a1f5629bdc98a8b9dc2051ce0e952f6b4b ("net: sctp: fix permissions for rto_alpha and rto_beta knobs") There's no way this is legitimate, that commit c

Re: [PATCH] net: filter: fix upper BPF instruction limit

2014-06-18 Thread Daniel Borkmann
Fixes: bd4cf0ed331a ("net: filter: rework/optimize internal BPF interpreter's instruction set") Signed-off-by: Kees Cook Acked-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel

Re: [net] b58537a1f56: +89.2% netperf.Throughput_Mbps

2014-06-19 Thread Daniel Borkmann
On 06/18/2014 10:41 PM, David Rientjes wrote: On Wed, 18 Jun 2014, Daniel Borkmann wrote: One assumption could be that netperf was setting this knob internally and ignoring the result of it (error/success), but that we might need to look up in netperf source to confirm. Confirmed netperf

Re: [PATCH] net: filter: fix upper BPF instruction limit

2014-06-20 Thread Daniel Borkmann
Hi Kees, On 06/19/2014 01:28 AM, Kees Cook wrote: On Wed, Jun 18, 2014 at 4:19 PM, Alexei Starovoitov wrote: On Wed, Jun 18, 2014 at 3:55 PM, Kees Cook wrote: On Wed, Jun 18, 2014 at 3:48 PM, Alexei Starovoitov wrote: On Wed, Jun 18, 2014 at 3:34 PM, Kees Cook wrote: ... I wonder how di

Re: [PATCH] net: filter: fix upper BPF instruction limit

2014-06-20 Thread Daniel Borkmann
On 06/20/2014 06:48 PM, Kees Cook wrote: ... Are there any plans to put and extend test cases from [1] via user space side into the kernel self-test directory, i.e. into something like tools/testing/selftests/seccomp/ so that in future new tests can be added or run from there? Might be worth to c

Re: [PATCH net-next] net: filter: rename 'struct sk_filter' to 'struct bpf_prog'

2014-07-25 Thread Daniel Borkmann
[ also Cc'ing Willem, Pablo ] On 07/25/2014 10:04 AM, Alexei Starovoitov wrote: 'sk_filter' name is used as 'struct sk_filter', function sk_filter() and as variable 'sk_filter', which makes code hard to read. Also it's easily confused with 'struct sock_filter' Rename 'struct sk_filter' to 'struc

Re: [PATCH net-next] net: filter: rename 'struct sk_filter' to 'struct bpf_prog'

2014-07-25 Thread Daniel Borkmann
On 07/25/2014 01:54 PM, Pablo Neira Ayuso wrote: On Fri, Jul 25, 2014 at 01:25:35PM +0200, Daniel Borkmann wrote: [ also Cc'ing Willem, Pablo ] On 07/25/2014 10:04 AM, Alexei Starovoitov wrote: 'sk_filter' name is used as 'struct sk_filter', function sk_filter() a

Re: [PATCH RFC net-next 00/14] BPF syscall, maps, verifier, samples

2014-07-01 Thread Daniel Borkmann
On 07/01/2014 01:09 AM, Kees Cook wrote: On Fri, Jun 27, 2014 at 5:05 PM, Alexei Starovoitov wrote: Hi All, this patch set demonstrates the potential of eBPF. First patch "net: filter: split filter.c into two files" splits eBPF interpreter out of networking into kernel/bpf/. The goal for BPF

Re: [PATCH RFC net-next 08/14] bpf: add eBPF verifier

2014-07-01 Thread Daniel Borkmann
On 06/28/2014 02:06 AM, Alexei Starovoitov wrote: Safety of eBPF programs is statically determined by the verifier, which detects: - loops - out of range jumps - unreachable instructions - invalid instructions - uninitialized register access - uninitialized stack access - misaligned stack access

Re: [PATCH RFC net-next 11/14] tracing: allow eBPF programs to be attached to events

2014-07-01 Thread Daniel Borkmann
On 06/28/2014 02:06 AM, Alexei Starovoitov wrote: User interface: cat bpf_123 > /sys/kernel/debug/tracing/__event__/filter where 123 is an id of the eBPF program priorly loaded. __event__ is static tracepoint event. (kprobe events will be supported in the future patches) eBPF programs can call

Re: [PATCH net-next] net: filter: move load_pointer() into filter.h

2014-07-03 Thread Daniel Borkmann
Hi Zi, On 07/03/2014 09:52 AM, Zi Shen Lim wrote: load_pointer() is already a static inline function. Let's move it into filter.h so BPF JIT implementations can reuse this function. Signed-off-by: Zi Shen Lim --- This patch is based on discussion with Alexei in the context of reusing load_poin

Re: [PATCH RFC] arm64: eBPF JIT compiler

2014-07-03 Thread Daniel Borkmann
On 07/03/2014 11:14 AM, Will Deacon wrote: On Wed, Jul 02, 2014 at 06:20:24AM +0100, Zi Shen Lim wrote: The JIT compiler emits A64 instructions. It supports eBPF only. Legacy BPF is supported thanks to conversion by BPF core. JIT is enabled in the same way as for other architectures:

Re: [PATCHv2 net-next] net: filter: move load_pointer() into filter.h

2014-07-03 Thread Daniel Borkmann
by: Zi Shen Lim Reviewed-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v6 net-next 1/4] net: flow_dissector: avoid multiple calls in eBPF

2014-06-27 Thread Daniel Borkmann
On 06/26/2014 12:00 AM, Chema Gonzalez wrote: ... There's still the problem of whether we want to obsolete classic BPF in the kernel before the tools (libpcap mainly) accept eBPF. This can take a lot. Finally, what's the user's CLI interface you have in mind? Right now, tcpdump expressions are v

<    1   2   3   4   5   6   7   8   9   10   >