;hard_header_len are both unsigned.
That may lead to just returning an incorrect EMSGSIZE errno
to the user.
Signed-off-by: Alexander Drozdov
Looks good to me, thanks!
Acked-by: Daniel Borkmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On 07/16/2015 02:15 PM, Denys Vlasenko wrote:
On 07/16/2015 12:41 PM, Thomas Graf wrote:
On 07/16/15 at 12:02pm, Denys Vlasenko wrote:
+/* jhash - hash an arbitrary key
+ * @k: sequence of bytes as key
+ * @length: the length of the key
+ * @initval: the previous hash, or an arbitray value
+ *
On 05/06/2016 12:39 AM, Colin King wrote:
From: Colin Ian King
klogctl can fail and return -ve len, so check for this and
return NULL to avoid passing a (size_t)-1 to malloc.
Signed-off-by: Colin Ian King
[ would be nice to get Cc'ed in future ... ]
Acked-by: Daniel Borkmann
and epilogue. AAPCS reserves R9 ~ R15 for temp
registers which not need to be saved/restored during function call. So, replace
R23 and R24 to R10 and R11, and remove tmp_used flag to save 2 instructions for
some jited BPF program.
CC: Daniel Borkmann
Acked-by: Zi Shen Lim
Signed-off-by: Yang Shi
On 05/17/2016 03:38 PM, Catalin Marinas wrote:
On Tue, May 17, 2016 at 09:12:34AM +0200, Daniel Borkmann wrote:
On 05/17/2016 09:03 AM, Geert Uytterhoeven wrote:
[...]
Someone's not gonna be happy with commit 606b5908 ("bpf: split
HAVE_BPF_JIT into cBPF and eBPF variant") br
On 05/17/2016 02:24 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
arch/arm64/Kconfig
between commit:
8ee708792e1c ("arm64: Kconfig: remove redundant HAVE_ARCH_TRANSPARENT_HUGEPAGE
definition")
from the arm64 tree and commit:
6
On 05/17/2016 09:03 AM, Geert Uytterhoeven wrote:
[...]
Someone's not gonna be happy with commit 606b5908 ("bpf: split
HAVE_BPF_JIT into cBPF and eBPF variant") breaking the sort order again...
Wasn't aware of that. Maybe I'm missing something, but there appears
to be no throughout consiste
On 11/11/2015 12:58 PM, Will Deacon wrote:
On Wed, Nov 11, 2015 at 11:42:11AM +0100, Daniel Borkmann wrote:
On 11/11/2015 11:24 AM, Will Deacon wrote:
On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
On Tue, Nov 10, 2015 at 4:42
On 11/11/2015 01:58 PM, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 12:38:31PM +, Will Deacon wrote:
Hmm, gcc doesn't have an eBPF compiler backend, so this won't work on
gcc at all. The eBPF backend in LLVM recognizes the __sync_fetch_and_add()
keyword and maps that to a BPF_XADD version
On 11/11/2015 07:31 PM, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 10:11:33AM -0800, Alexei Starovoitov wrote:
On Wed, Nov 11, 2015 at 06:57:41PM +0100, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
From: Alexei Starovoitov
Date: Wed, 11 Nov 2015 09:27
On 11/11/2015 08:23 PM, Peter Zijlstra wrote:
On Wed, Nov 11, 2015 at 07:50:15PM +0100, Daniel Borkmann wrote:
Well, on that note, it's not like you just change the target to bpf in your
Makefile and can compile (& load into the kernel) anything you want with it.
You do have to wr
On 11/11/2015 11:24 PM, Kamal Mostafa wrote:
Use the local uapi headers to keep in sync with "recently" added #define's
(e.g. SKF_AD_VLAN_TPID). Refactored CFLAGS, and bpf_asm doesn't need -I.
Fixes: 3f356385e8a449e1d7cfc6b6f8d634ac4f5581a0
Signed-off-by: Kamal Mostafa
On 12/15/2015 12:21 PM, Ming Lei wrote:
...
+/* Called from syscall, and the code is borrowed from blk_mq */
+static int htab_pre_alloc_elems(struct bpf_htab *htab)
+{
+ const unsigned max_order = 4;
+ unsigned elem_size = htab->elem_size, i;
+ unsigned nr_entries = htab->map.ma
On 12/15/2015 12:21 PM, Ming Lei wrote:
...
+static int htab_init_elems_allocator(struct bpf_htab *htab)
+{
+ int ret = htab_pre_alloc_elems(htab);
+
+ if (ret)
+ return ret;
+
+ ret = percpu_ida_init(&htab->elems_pool, htab->map.max_entries);
+ if (ret)
+
On 12/16/2015 12:10 AM, Alexei Starovoitov wrote:
...
this rounding to cache line is great for performance, but it's extra
memory upfront which may not be needed. The per-allocation is a classic
performance vs memory trade-off. In other cases it may hurt.
So could you change the patch to do pre-a
On 12/16/2015 12:35 AM, Daniel Borkmann wrote:
On 12/15/2015 12:21 PM, Ming Lei wrote:
...
+static int htab_init_elems_allocator(struct bpf_htab *htab)
+{
+int ret = htab_pre_alloc_elems(htab);
+
+if (ret)
+return ret;
+
+ret = percpu_ida_init(&htab->elems_poo
On 12/18/2015 08:04 AM, Wangnan (F) wrote:
...
What I want to do in this patchset is not only removing original libbpf.c
and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
available library for other userspace tools (tc for example).
Having this as a possible user space lib
On 12/18/2015 12:18 PM, pi3orama wrote:
...
Get it, and I remember you told me about this once.
There's another goal. When someone introduces new functions to eBPF, like
object pin added in these days, switching samples to libbpf will lead he/she
to help me improve libbpf, because if a new sampl
a fix already, just noticed this during
review
on the other patch. We need something like this, will submit it properly in some
minutes:
From 5e5ac319463d27a744367eae183cda9c0759a0a1 Mon Sep 17 00:00:00 2001
Message-Id:
<5e5ac319463d27a744367eae183cda9c0759a0a1.1448880311.git.dan...@iogea
On 11/30/2015 01:59 AM, Alexei Starovoitov wrote:
[...]
For large map->value_size the user space can trigger memory allocation warnings
like:
[...]
To avoid never succeeding kmalloc with order >= MAX_ORDER check that
elem->value_size and computed elem_size are within limits for both hash and
On 11/30/2015 02:57 PM, Dmitry Vyukov wrote:
...
kamlloc produces a WARNING if you try to allocate more than it ever
possibly can (KMALLOC_SHIFT_MAX).
Sure, I understand that.
The kzalloc() in array_map_alloc() is however with __GFP_NOWARN flag already.
The warning only triggers in mm if:
W
On 11/30/2015 02:52 PM, Daniel Borkmann wrote:
On 11/30/2015 01:59 AM, Alexei Starovoitov wrote:
[...]
For large map->value_size the user space can trigger memory allocation warnings
like:
[...]
To avoid never succeeding kmalloc with order >= MAX_ORDER check that
elem->value
On 11/30/2015 07:13 PM, Alexei Starovoitov wrote:
On Mon, Nov 30, 2015 at 03:34:35PM +0100, Daniel Borkmann wrote:
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 3f4c99e06c6b..b1e53b79c586 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -28,11 +28,17
On 12/01/2015 11:46 AM, David Laight wrote:
From: Marcelo Ricardo Leitner
Sent: 30 November 2015 16:33
Dmitry Vyukov reported that the user could trigger a kernel warning by
using a large len value for getsockopt SCTP_GET_LOCAL_ADDRS, as that
value directly affects the value used as a kmalloc()
On 12/01/2015 02:36 PM, Eric Dumazet wrote:
On Tue, 2015-12-01 at 13:27 +0100, Dmitry Vyukov wrote:
Hello,
The following program causes a memory leak :
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
int
On 12/01/2015 03:16 PM, Eric Dumazet wrote:
On Tue, 2015-12-01 at 15:07 +0100, Daniel Borkmann wrote:
Yeah, we miss inet6_destroy_sock() in SCTP. :-(
Looks good to me.
OK, I will send a formal (and tested ;) ) patch.
I was shortly wondering whether there could be a use-after-free by
doing
On 12/01/2015 03:38 PM, Eric Dumazet wrote:
On Tue, 2015-12-01 at 15:24 +0100, Daniel Borkmann wrote:
On 12/01/2015 03:16 PM, Eric Dumazet wrote:
On Tue, 2015-12-01 at 15:07 +0100, Daniel Borkmann wrote:
Yeah, we miss inet6_destroy_sock() in SCTP. :-(
Looks good to me.
OK, I will send a
On 12/01/2015 04:20 PM, Eric Dumazet wrote:
From: Eric Dumazet
Dmitry Vyukov reported a memory leak using IPV6 SCTP sockets.
We need to call inet6_destroy_sock() to properly release
inet6 specific fields.
Reported-by: Dmitry Vyukov
Signed-off-by: Eric Dumazet
Acked-by: Daniel Borkmann
es on this with PTRACE_SECCOMP_NEXT_FILTER using
bpf(BPF_PROG_DUMP) to dump the actual program at each step.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
[.
.
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
---
include/uapi/linux/seccomp.h | 16 +
kernel/seccomp.c
Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
---
kernel/seccomp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 245df6b..afaeddf 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -378,6 +
filter
Signed-off-by: Tycho Andersen
CC: Kees Cook
CC: Will Drewry
CC: Oleg Nesterov
CC: Andy Lutomirski
CC: Pavel Emelyanov
CC: Serge E. Hallyn
CC: Alexei Starovoitov
CC: Daniel Borkmann
[...]
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index dc9b464..58ae9f4 100644
-
On 09/11/2015 04:44 PM, Tycho Andersen wrote:
On Fri, Sep 11, 2015 at 03:02:36PM +0200, Daniel Borkmann wrote:
On 09/11/2015 02:20 AM, Tycho Andersen wrote:
In the next patch, we're going to add a way to access the underlying
filters via bpf fds. This means that we need to ref-count bot
On 09/11/2015 07:33 PM, Tycho Andersen wrote:
On Fri, Sep 11, 2015 at 06:03:59PM +0200, Daniel Borkmann wrote:
On 09/11/2015 04:44 PM, Tycho Andersen wrote:
On Fri, Sep 11, 2015 at 03:02:36PM +0200, Daniel Borkmann wrote:
On 09/11/2015 02:20 AM, Tycho Andersen wrote:
In the next patch, we&#x
On 11/26/2015 01:01 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
kernel/bpf/syscall.c
between commit:
c9da161c6517 ("bpf: fix clearing on persistent program array maps")
from the net tree and commit:
f99bf205dab0 ("bpf: add sh
On 12/04/2015 08:10 PM, Alexei Starovoitov wrote:
On Fri, Dec 04, 2015 at 08:03:47PM +0100, Dmitry Vyukov wrote:
is it with some random seccomp program?
If normal libseccomp generates such programs than it needs to be fixed.
Yes, it is with completely random seccomp program.
Such shifts have
On 12/09/2015 06:11 PM, Marcelo Ricardo Leitner wrote:
Em 09-12-2015 14:31, David Laight escreveu:
From: Eric Dumazet [mailto:eric.duma...@gmail.com]
Sent: 09 December 2015 16:00
On Wed, 2015-12-09 at 15:49 +, David Laight wrote:
SCTP is lacking proper np->opt cloning at accept() time.
TC
On 12/04/2015 08:06 PM, Alexei Starovoitov wrote:
On Fri, Dec 04, 2015 at 01:23:33PM -0500, Dave Jones wrote:
Trinity had aparently created a bpf program that upset things greatly.
I guess I need to find a way to make it record those somewhere for replaying
later.
Alexei, any ideas ?
variants,
and take a reference.
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
include/linux/bpf.h | 2 +-
kernel/bpf/syscall.c | 41 +++--
kernel/bpf/verifier.c | 3 +--
3 files changed, 25 insertions(+), 21 deletions(-)
diff --git a
_OBJ_GET.
Big thanks also to Alexei and Hannes who significantly contributed
in the design discussion that eventually let us end up with this
architecture here.
Reference: https://lkml.org/lkml/2015/10/15/925
Signed-off-by: Daniel Borkmann
Signed-off-by: Alexei Starovoitov
Signed-off-by: Hannes
-F /sys/fs/bpf/p2 -P -p -o ./sockex1_kern.o
bpf: prog fd:5 (Success)
bpf: pin ret:(0,Success)
bpf: sock:3 <- fd:5 attached ret:(0,Success)
# ./fds_example -F /sys/fs/bpf/p2 -G -p
bpf: get fd:3 (Success)
bpf: sock:4 <- fd:3 attached ret:(0,Success)
Signed-off-by: Daniel Borkmann
A
d-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
kernel/bpf/syscall.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 687dd6c..2b89ef0 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -
t;bpf: Need to call bpf_prog_uncharge_memlock
from bpf_prog_put") if we would have had only a single, common path.
We can simplify it further by assigning aux->prog only once during
allocation time.
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
kernel/bpf/core.c|
This set adds support for persistent maps/progs. Please see
individual patches for further details. A man-page update
to bpf(2) will be sent later on, also a iproute2 patch for
support in tc.
Thanks!
v1 -> v2:
- Reworked most of patch 4 and 5
- Rebased to latest net-next
Daniel Borkmann
Hi Michael,
is there any update on the bpf(2) man-page since last time, wrt
having an initial version in your tree?
Thanks again,
Daniel
--
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:/
On 07/22/2015 11:23 AM, Konstantin Khlebnikov wrote:
In dev_queue_xmit() net_cls protected with rcu-bh.
...
Signed-off-by: Konstantin Khlebnikov
---
net/core/netclassid_cgroup.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/core/netclassid_cgroup.c b/net/core/
On 07/22/2015 02:03 PM, Konstantin Khlebnikov wrote:
On 22.07.2015 14:56, Daniel Borkmann wrote:
On 07/22/2015 11:23 AM, Konstantin Khlebnikov wrote:
In dev_queue_xmit() net_cls protected with rcu-bh.
...
Signed-off-by: Konstantin Khlebnikov
---
net/core/netclassid_cgroup.c |3 ++-
1
so we can whitelist the function.
Signed-off-by: Josh Poimboeuf
Cc: Alexei Starovoitov
Cc: net...@vger.kernel.org
Fine by me:
Acked-by: Daniel Borkmann
On 01/22/2016 06:35 PM, Adam Jackson wrote:
On Fri, 2016-01-22 at 14:22 -0300, Arnaldo Carvalho de Melo wrote:
the 'bpf' target for clang is being used together with perf to
build scriptlets into object code that then gets uploaded to the kernel
via sys_bpf(), was the decision not to in
On 01/23/2016 08:25 PM, Florian Westphal wrote:
Dmitry Vyukov wrote:
[ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ]
The following program causes GPF in netlink_getsockbyportid:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
On 02/18/2016 10:27 PM, Tom Zanussi wrote:
On Tue, 2016-02-16 at 20:51 -0800, Alexei Starovoitov wrote:
On Tue, Feb 16, 2016 at 04:35:27PM -0600, Tom Zanussi wrote:
On Sun, 2016-02-14 at 01:02 +0100, Alexei Starovoitov wrote:
[...]
Take a look at all the tools written on top of it:
https://gi
On 02/26/2016 01:13 AM, Stephen Rothwell wrote:
[...]
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Looks good to me, thanks Stephen!
Best,
Daniel
On 11/19/2014 05:47 PM, John Fastabend wrote:
On 11/18/2014 12:26 PM, SF Markus Elfring wrote:
From: Markus Elfring
...
if (fp_old)
bpf_prog_destroy(fp_old);
-if (bpf_old)
-kfree(bpf_old);
+kfree(bpf_old);
return 0;
Maybe I need some coffee but I can'
On 11/19/2014 07:49 PM, SF Markus Elfring wrote:
Marcus, what tree are you looking at?
I dared to base this update suggestion on the source files
for Linux 3.17.3. Are newer software developments relevant here?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/net/sched/
P
On 11/20/2014 09:47 AM, Julia Lawall wrote:
On Wed, 19 Nov 2014, SF Markus Elfring wrote:
Marcus, what tree are you looking at?
I dared to base this update suggestion on the source files
for Linux 3.17.3. Are newer software developments relevant here?
You should always use linux-next. You
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback han
On 11/12/2014 05:54 PM, Stephan Mueller wrote:
Am Mittwoch, 12. November 2014, 17:15:52 schrieb Daniel Borkmann:
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data wi
On 11/12/2014 06:46 PM, Stephan Mueller wrote:
...
* I unconditionally use the memset after memcpy as you indicated. Once
the cryptodev tree contains the memzero_explicit call, I will start
picking up that function.
Herbert merged it actually in this morning, so it's already part of
the cryptod
On 11/28/2014 06:55 AM, Alexei Starovoitov wrote:
On Thu, Nov 27, 2014 at 1:52 AM, Daniel Borkmann wrote:
On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
classic BPF has a restriction that last insn is always BPF_RET.
eBPF doesn't have BPF_RET instruction and this restriction.
I
On 12/01/2014 11:27 AM, Dan Carpenter wrote:
On Mon, Aug 25, 2014 at 10:01:39PM +0200, Daniel Borkmann wrote:
zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being
On 12/01/2014 12:29 PM, Dan Carpenter wrote:
On Mon, Dec 01, 2014 at 12:04:57PM +0100, Daniel Borkmann wrote:
Well, BSD has helpers such as bzero_explicit() for such cases to work
around this, which memzero_explicit() similarly does; see also [1].
[1] https://gcc.gnu.org/ml/gcc-help/2014-10
On 12/01/2014 12:38 PM, Dan Carpenter wrote:
On Mon, Dec 01, 2014 at 02:29:57PM +0300, Dan Carpenter wrote:
On Mon, Dec 01, 2014 at 12:04:57PM +0100, Daniel Borkmann wrote:
Well, BSD has helpers such as bzero_explicit() for such cases to work
around this, which memzero_explicit() similarly
On 12/01/2014 05:49 PM, Robert Święcki wrote:
I don't have much more, cause my kernel is kASLRNized and gdb cannot
handle that, but pasting output from kdb. Maybe somebody will be able
to see something obvious.
<0>[93699.703244] skbuff: skb_under_panic: text:83cff03e
len:104 put:56 hea
ate a repro (userland code) which
can trigger this, I can give it a try.
Did by accident trinity create tunnels? It looks that upper layer
protocols (except SCTP) all allocate and reserve MAX_HEADER to
accommodate enough head room in worst case for possible tunnels.
2014-12-01 18:36 GMT+01:00 D
On 12/01/2014 08:00 PM, Robert Święcki wrote:
2014-12-01 19:08 GMT+01:00 Daniel Borkmann :
Thanks for looking into it. I can try with your patch, but no
guarantees that the fuzzer will hit the same condition in some
reasonable time-frame. Will get back in some time with results.
Ok, thanks
On 12/01/2014 08:17 PM, Robert Święcki wrote:
Not sure, but I run it inside a pid/ipc/uts/etc/user-namespaces where
it operates with a full set of capabilities, so most of the SOCK_RAW
and tunnel-like-creating calls succeed, so maybe..
Ok thanks, can you post your .config?
http://alt.swiecki
On 11/11/2014 05:16 AM, Stephan Mueller wrote:
...
That is a good idea.
Herbert: I can prepare a patch that uses memzero_explicit. However, your
current tree does not yet implement that function as it was added to Linus'
tree after you pulled from it.
Yep, Ted took it [1] on top of the random
Hi Stephan,
On 11/11/2014 05:37 AM, Stephan Mueller wrote:
Zeroize the buffer holding the message digest calculated for the
consumer before the buffer is released by the hash AF_ALG interface
handler.
Signed-off-by: Stephan Mueller
---
crypto/algif_hash.c | 2 ++
1 file changed, 2 insertion
On 11/26/2014 05:58 PM, Joe Perches wrote:
...
imo existing code is fine and I don't think the time spent
reviewing such changes is worth it when there is no
improvement in readability.
+1
Is there any value in reordering these tests for frequency
or maybe using | instead of || to avoid multi
On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
classic BPF has a restriction that last insn is always BPF_RET.
eBPF doesn't have BPF_RET instruction and this restriction.
It has BPF_EXIT insn which can appear anywhere in the program
one or more times and it doesn't have to be last insn.
Fix eB
On 11/27/2014 02:35 PM, Дениска-редиска wrote:
hello,
i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
Time to time the server where ipvs runs master IP (VIP) get general protection
fault. Switching master to another server make no difference - after some time
GPF come. So
suggested by Daniel Borkmann
Signed-off-by: Julia Lawall
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
Why? There's no dependancy on anything in the cryptodev tree,
memzero_explicit is in Linus's tree now.
Sorry, I guess this was n
On 10/20/2014 03:58 PM, Andrey Ryabinin wrote:
On 10/20/2014 04:49 PM, Theodore Ts'o wrote:
On Mon, Oct 20, 2014 at 03:03:22PM +0400, Andrey Ryabinin wrote:
Hi, Theodore.
I've got this while booting kernel with ubsan:
[0.00]
==
ind before jumping into the next program.
...
Signed-off-by: Alexei Starovoitov
LGTM, thanks!
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
More majordomo info at http
egating to the kernel BPF
interpreter in that case is a more straight forward, minimal fix and
easy to backport.
Signed-off-by: Nicolas Schichan
Fix looks good to me.
Fixes: ddecdfcea0ae ("ARM: 7259/3: net: JIT compiler for packet filters")
Acked-by: Daniel Borkmann
--
To unsubscribe
have an ecc at hand (unsure if that's still used in the
field?) and only found this by accident during code review, a revert
of that cleanup would be simplest option.
Fixes: 73679e508201 ("compiler-intel.h: Remove duplicate definition")
Signed-off-by: Daniel Borkmann
Reviewed-by: Pran
lexei Starovoitov
Cc: Will Deacon
Signed-off-by: Xi Wang
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
tprint and consequently also don't have a sk_classid member;
probing for sk_classid member there could potentially lead to a
crash.
Fixes: a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf
hooks")
Cc: Alexey Perevalov
Signed-off-by: Daniel Borkmann
Signed-
On 03/28/2015 06:21 PM, Alexei Starovoitov wrote:
On 3/28/15 4:36 AM, He Kuang wrote:
Hi, Alexei
In our end-end IO module project, we use bpf maps to record
configurations. According to current bpf syscall interface, we
should specify map_fd to lookup/update bpf maps, so we are
restricted to do
[ Cc'ing Cesar ]
On 03/18/2015 10:53 AM, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect
memory cleansing against things like dead store optimization:
void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
OPT
On 03/18/2015 11:50 AM, Hannes Frederic Sowa wrote:
On Wed, Mar 18, 2015, at 10:53, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777 to protect
memory cleansing against things like dead store optimization:
void memzero_explicit(void *s, size_t count)
{
, Stephan Mueller wrote:
Am Mittwoch, 18. März 2015, 11:56:43 schrieb Daniel Borkmann:
On 03/18/2015 11:50 AM, Hannes Frederic Sowa wrote:
On Wed, Mar 18, 2015, at 10:53, mancha wrote:
Hi.
The kernel RNG introduced memzero_explicit in d4c5efdb9777 to
protect
memory cleansing against things like
On 03/18/2015 06:14 PM, mancha wrote:
...
Patch 0001 fixes the dead store issue in memzero_explicit().
Thanks! I have issued the fix for the memzero bug to Herbert in
your authorship as discussed, also giving some more context.
For the 2nd issue, lets wait for Cesar.
Thanks again!
--
To unsub
On 03/13/2015 03:21 AM, Alexei Starovoitov wrote:
introduce user accessible mirror of in-kernel 'struct sk_buff':
struct __sk_buff {
__u32 len;
__u32 pkt_type;
__u32 mark;
__u32 ifindex;
__u32 queue_mapping;
};
bpf programs can do:
struct __sk_buff *ptr;
var = ptr->pkt_t
On 03/13/2015 03:21 AM, Alexei Starovoitov wrote:
...
Daniel,
patch 1 includes a bit of code that does prog_realloc and branch adjustment
to make room for new instructions. I think you'd need the same for your
'constant blinding' work. If indeed that would be the case, we'll make it
into a helper
On 03/13/2015 05:22 PM, Alexei Starovoitov wrote:
On 3/13/15 2:57 AM, Daniel Borkmann wrote:
On 03/13/2015 03:21 AM, Alexei Starovoitov wrote:
introduce user accessible mirror of in-kernel 'struct sk_buff':
For each member, I'd also add BUILD_BUG_ON()s similarl
On 03/13/2015 07:57 PM, Alexei Starovoitov wrote:
introduce user accessible mirror of in-kernel 'struct sk_buff':
struct __sk_buff {
__u32 len;
__u32 pkt_type;
__u32 mark;
__u32 queue_mapping;
};
bpf programs can do:
int bpf_prog(struct __sk_buff *skb)
{
__u32 var = skb
On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...
Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/
Alternative is to move all of them into a central place, something like
in twsk_build_assert() or __mld2_query_bugs[].
--
To
On 03/14/2015 03:08 AM, Alexei Starovoitov wrote:
On 3/13/15 7:06 PM, Daniel Borkmann wrote:
On 03/14/2015 02:46 AM, Daniel Borkmann wrote:
...
Previously, it was much more consistent, which I like better. And only
because of the simple BUILD_BUG_ON()? :/
Alternative is to move all of them
On 03/14/2015 05:59 AM, Alexei Starovoitov wrote:
On 3/13/15 7:27 PM, Alexei Starovoitov wrote:
On 3/13/15 7:16 PM, Daniel Borkmann wrote:
On 03/14/2015 03:08 AM, Alexei Starovoitov wrote:
On 3/13/15 7:06 PM, Daniel Borkmann wrote:
On 03/14/2015 02:46 AM, Daniel Borkmann wrote
On 03/14/2015 04:55 PM, Alexei Starovoitov wrote:
...
so from there I saw two options: either copy paste all
build_bug_on and have the same *insn=... and build_bug_on in
two places or consolidate them in single helper function.
Obviously single helper function is a preferred method.
I'm not sure
On 03/03/2015 06:29 PM, Michel Machado wrote:
...
We're fine with clearly marking Linux XIA as being under staging as well as
helping to define this review process for network stacks.
With regard to staging, the code there is usually horrible and I'm
not sure anyone really looks there, tha
On 02/21/2015 04:36 PM, Shachar Raindel wrote:
...
This is most likely rhashtable related. The fixes for the
use-after-free issues have been merged Feb 6 so they are probably
not included in the Feb 04 snapshot that you use.
The relevant net-next commits are:
commit 020219a69d40a205dad12b0ea1e6a
On 02/21/2015 09:55 PM, Sasha Levin wrote:
Commit "rhashtable: Introduce rhashtable_walk_*" forgot to initialize the
members of struct rhashtable_walker after allocating it, which caused
an undefined value for 'resize' which is used later on.
Signed-off-by: Sasha Levin
---
lib/rhashtable.c |
preted and
JIT'ed) images from malicious modifications or bugs.
Outside of eBPF scope, I believe also other set_memory_* functions should
be unexported on arm64 for modules.
Signed-off-by: Daniel Borkmann
Cc: Laura Abbott
Cc: Will Deacon
Cc: linux-kernel@vger.kernel.org
Acked-by: Ale
o not want modules
to use these functions, as they i.e. protect eBPF (interpreted & JIT'ed)
images from malicious modifications or bugs.
Outside of eBPF scope, I believe also other set_memory_* functions should
be unexported on x86 for modules.
Signed-off-by: Daniel Borkmann
Cc: Bruce Allan
C
On 02/27/2015 08:54 PM, Will Deacon wrote:
...
Looks good to me. Can this be applied independently, or does it need to
remain part of your series?
Ideally, it should be seen as part of this series, but I have no problem
if this one goes via arm64 tree, instead. What Dave and you prefer. ;)
Tha
Hi Will,
On 02/27/2015 09:05 PM, Daniel Borkmann wrote:
On 02/27/2015 08:54 PM, Will Deacon wrote:
...
Looks good to me. Can this be applied independently, or does it need to
remain part of your series?
Ideally, it should be seen as part of this series, but I have no problem
if this one goes
in mainline and it's unclear if they would ever get there.
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
Acked-by: Laura Abbott
---
arch/arm64/mm/pageattr.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index bb0
On 03/02/2015 11:53 AM, Masami Hiramatsu wrote:
...
> Hmm, it seems that this still doesn't hide some APIs which is provided
> only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
> I think all those APIs should be hidden in #ifdef or at least be commented
> so that the user doesn't
601 - 700 of 1281 matches
Mail list logo
