Re: bpf: Change structure passing and assignment

On Sat, Jan 13, 2018 at 02:42:19PM +0200, Karim Eshapa wrote: > I noticed that most of functions here have structure arguements and return > structure, all these structures passed and returned are delt in passing and > assignment like memcpy a structure.In addition it takes size in stack while

Re: bpf: Change structure passing and assignment

On Sat, Jan 13, 2018 at 02:42:19PM +0200, Karim Eshapa wrote: > I noticed that most of functions here have structure arguements and return > structure, all these structures passed and returned are delt in passing and > assignment like memcpy a structure.In addition it takes size in stack while

Re: [PATCH bpf-next v5 0/5] Separate error injection table from kprobes

On Sat, Jan 13, 2018 at 02:53:33AM +0900, Masami Hiramatsu wrote: > Hi, > > Here are the 5th version of patches to moving error injection > table from kprobes. This version fixes a bug and update > fail-function to support multiple function error injection. > > Here is the previous version: > >

Re: [PATCH bpf-next v5 0/5] Separate error injection table from kprobes

On Sat, Jan 13, 2018 at 02:53:33AM +0900, Masami Hiramatsu wrote: > Hi, > > Here are the 5th version of patches to moving error injection > table from kprobes. This version fixes a bug and update > fail-function to support multiple function error injection. > > Here is the previous version: > >

Re: linux-next: build failure after merge of the net-next tree

On Fri, Jan 12, 2018 at 05:21:54PM +0100, Daniel Borkmann wrote: > On 01/12/2018 04:56 PM, Alexei Starovoitov wrote: > > On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote: > >> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote: > >>> On Thu, Jan 11, 2

Re: linux-next: build failure after merge of the net-next tree

On Fri, Jan 12, 2018 at 05:21:54PM +0100, Daniel Borkmann wrote: > On 01/12/2018 04:56 PM, Alexei Starovoitov wrote: > > On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote: > >> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote: > >>> On Thu, Jan 11, 2

Re: linux-next: build failure after merge of the net-next tree

On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote: > On 01/12/2018 05:21 AM, Alexei Starovoitov wrote: > > On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > >> From: Alexei Starovoitov <alexei.starovoi...@gmail.com> > >> Date

Re: linux-next: build failure after merge of the net-next tree

On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote: > On 01/12/2018 05:21 AM, Alexei Starovoitov wrote: > > On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > >> From: Alexei Starovoitov > >> Date: Wed, 10 Jan 2018 17:58:54 -0800 > >>

Re: linux-next: build failure after merge of the net-next tree

On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > From: Alexei Starovoitov <alexei.starovoi...@gmail.com> > Date: Wed, 10 Jan 2018 17:58:54 -0800 > > > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > >> Hi all, > >> > &

Re: linux-next: build failure after merge of the net-next tree

On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote: > From: Alexei Starovoitov > Date: Wed, 10 Jan 2018 17:58:54 -0800 > > > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > >> Hi all, > >> > >> After merging the net-n

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:57:51AM -0800, Dave Hansen wrote: > On 01/11/2018 10:51 AM, Linus Torvalds wrote: > > On Thu, Jan 11, 2018 at 10:38 AM, Dave Hansen > > wrote: > >> On 01/11/2018 10:32 AM, Josh Poimboeuf wrote: > hmm. Exposing cr3 to user space will

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 10:57:51AM -0800, Dave Hansen wrote: > On 01/11/2018 10:51 AM, Linus Torvalds wrote: > > On Thu, Jan 11, 2018 at 10:38 AM, Dave Hansen > > wrote: > >> On 01/11/2018 10:32 AM, Josh Poimboeuf wrote: > hmm. Exposing cr3 to user space will make it trivial for user process

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 09:02:55AM -0800, Andy Lutomirski wrote: > On Thu, Jan 11, 2018 at 7:51 AM, Dave Hansen > wrote: > > On 01/11/2018 07:44 AM, Willy Tarreau wrote: > >>> I think we also need to be able to dump the actual > >>> CR3 value that we entered the

Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set

On Thu, Jan 11, 2018 at 09:02:55AM -0800, Andy Lutomirski wrote: > On Thu, Jan 11, 2018 at 7:51 AM, Dave Hansen > wrote: > > On 01/11/2018 07:44 AM, Willy Tarreau wrote: > >>> I think we also need to be able to dump the actual > >>> CR3 value that we entered the kernel with before we start doing

Re: linux-next: build failure after merge of the net-next tree

On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > kernel/bpf/verifier.o: In function `bpf_check': > verifier.c:(.text+0xd86e): undefined reference to

Re: linux-next: build failure after merge of the net-next tree

On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > kernel/bpf/verifier.o: In function `bpf_check': > verifier.c:(.text+0xd86e): undefined reference to

Re: [PATCH][bpf-next] bpf: fix spelling mistake: "obusing" -> "abusing"

On Wed, Jan 10, 2018 at 11:39:14AM +0100, Daniel Borkmann wrote: > On 01/10/2018 10:20 AM, Colin King wrote: > > From: Colin Ian King > > > > Trivial fix to spelling mistake in error message text. > > > > Signed-off-by: Colin Ian King > > ---

Re: [PATCH][bpf-next] bpf: fix spelling mistake: "obusing" -> "abusing"

On Wed, Jan 10, 2018 at 11:39:14AM +0100, Daniel Borkmann wrote: > On 01/10/2018 10:20 AM, Colin King wrote: > > From: Colin Ian King > > > > Trivial fix to spelling mistake in error message text. > > > > Signed-off-by: Colin Ian King > > --- > > kernel/bpf/verifier.c | 2 +- > > 1 file

Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

On Tue, Jan 09, 2018 at 06:22:09PM -0800, Dan Williams wrote: > > When you came up with that tweak you noted: > > "The following: > [..] > is generic and no speculative flows." I meant 'no speculative control flow' load speculation still happens. > > > This macro doesn't prevent speculation.

Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

On Tue, Jan 09, 2018 at 06:22:09PM -0800, Dan Williams wrote: > > When you came up with that tweak you noted: > > "The following: > [..] > is generic and no speculative flows." I meant 'no speculative control flow' load speculation still happens. > > > This macro doesn't prevent speculation.

Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

On Tue, Jan 09, 2018 at 04:48:24PM -0800, Dan Williams wrote: > > #define __nospec_array_ptr(base, idx, sz) \ > ({ \ > union { typeof([0]) _ptr; unsigned long _bit; } __u; \ >

Re: [PATCH 16/18] net: mpls: prevent bounds-check bypass via speculative execution

On Tue, Jan 09, 2018 at 04:48:24PM -0800, Dan Williams wrote: > > #define __nospec_array_ptr(base, idx, sz) \ > ({ \ > union { typeof([0]) _ptr; unsigned long _bit; } __u; \ >

[PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

ITs, consolidate in one place and remove this jit_init() function. Signed-off-by: Alexei Starovoitov <a...@kernel.org> --- init/Kconfig | 7 +++ kernel/bpf/core.c | 19 +++ lib/test_bpf.c | 11 +++ net/core/filter.c | 6 ++--

[PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

ITs, consolidate in one place and remove this jit_init() function. Signed-off-by: Alexei Starovoitov --- init/Kconfig | 7 +++ kernel/bpf/core.c | 19 +++ lib/test_bpf.c | 11 +++ net/core/filter.c | 6 ++ net/core/sysct

[PATCH v2 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

ill be sent when the trees are merged back to net-next Considered doing: int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT; but it seems better to land the patch as-is and in bpf-next remove bpf_jit_enable global variable from all JITs, consolidate in one place and remove this jit_init() functi

[PATCH v2 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

ill be sent when the trees are merged back to net-next Considered doing: int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT; but it seems better to land the patch as-is and in bpf-next remove bpf_jit_enable global variable from all JITs, consolidate in one place and remove this jit_init() functi

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

On Tue, Jan 09, 2018 at 11:21:25AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > tools/testing/selftests/bpf/test_align.c > > between commit: > > 2b36047e7889 ("selftests/bpf: fix test_align") > > from the bpf tree and

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

On Tue, Jan 09, 2018 at 11:21:25AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > tools/testing/selftests/bpf/test_align.c > > between commit: > > 2b36047e7889 ("selftests/bpf: fix test_align") > > from the bpf tree and

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, Jan 08, 2018 at 02:42:13AM -0800, Paul Turner wrote: > > kernel->kernel independent of SMEP: > While much harder to coordinate, facilities such as eBPF potentially > allow exploitable return targets to be created. > Generally speaking (particularly if eBPF has been disabled) the risk > is

Re: [PATCH v6 00/10] Retpoline: Avoid speculative indirect calls in kernel

On Mon, Jan 08, 2018 at 02:42:13AM -0800, Paul Turner wrote: > > kernel->kernel independent of SMEP: > While much harder to coordinate, facilities such as eBPF potentially > allow exploitable return targets to be created. > Generally speaking (particularly if eBPF has been disabled) the risk > is

Re: general protection fault in free_verifier_state (2)

On Mon, Jan 8, 2018 at 2:58 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 895c0dde398510a5b5ded60e5064c11b94bd30ca > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1

Re: general protection fault in free_verifier_state (2)

On Mon, Jan 8, 2018 at 2:58 AM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 895c0dde398510a5b5ded60e5064c11b94bd30ca > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/29/17 12:20 AM, Masami Hiramatsu wrote: Please run Josef's test in the !ftrace setup. Yes, I'll add the result of the test case. if Josef's test is passing in !ftrace config, please resend your patches. I think 2 and 3 were nice simplifications. and patch 1 is good too if it's passes

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/29/17 12:20 AM, Masami Hiramatsu wrote: Please run Josef's test in the !ftrace setup. Yes, I'll add the result of the test case. if Josef's test is passing in !ftrace config, please resend your patches. I think 2 and 3 were nice simplifications. and patch 1 is good too if it's passes

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 01:59:35PM +, Alan Cox wrote: > > which means that POC is relying 64-bit address speculation. > > In the places coverity found the user supplied value is 32-bit, > > People have 32bit computers as well as 64bit and in some cases 32bit is > fine for an attack depending

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 01:59:35PM +, Alan Cox wrote: > > which means that POC is relying 64-bit address speculation. > > In the places coverity found the user supplied value is 32-bit, > > People have 32bit computers as well as 64bit and in some cases 32bit is > fine for an attack depending

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 12:15:40PM -0800, Dan Williams wrote: > > I'm thinking we should provide the option to at least build the > hot-path nospec_array_ptr() usages without an lfence. > > CONFIG_SPECTRE1_PARANOIA_SAFE > CONFIG_SPECTRE1_PARANOIA_PERF SAFE vs PERF naming is problematic

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 12:15:40PM -0800, Dan Williams wrote: > > I'm thinking we should provide the option to at least build the > hot-path nospec_array_ptr() usages without an lfence. > > CONFIG_SPECTRE1_PARANOIA_SAFE > CONFIG_SPECTRE1_PARANOIA_PERF SAFE vs PERF naming is problematic

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 11:08:24AM +0100, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Alexei Starovoitov wrote: > > which clearly states that bpf_tail_call() was used in the attack. > > Yet none of the intel nor arm patches address speculation in > > this bpf helper! > &g

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 11:08:24AM +0100, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Alexei Starovoitov wrote: > > which clearly states that bpf_tail_call() was used in the attack. > > Yet none of the intel nor arm patches address speculation in > > this bpf helper! > &g

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 11:05:07PM +, Alan Cox wrote: > > Even if it would be practical the speed probably going to be in bytes per > > second, > > so to read anything meaningful an attack detection techniques (that people > > are actively working on) will be able to catch it. > > At the end

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 11:05:07PM +, Alan Cox wrote: > > Even if it would be practical the speed probably going to be in bytes per > > second, > > so to read anything meaningful an attack detection techniques (that people > > are actively working on) will be able to catch it. > > At the end

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 08:22:13PM +, Alan Cox wrote: > > "Value prediction consists of predicting entire 32- and 64-bit register > > values > > based on previously-seen values" > > For their implementation yes > > > > > > In other words there are at least two problems with Linus

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 08:22:13PM +, Alan Cox wrote: > > "Value prediction consists of predicting entire 32- and 64-bit register > > values > > based on previously-seen values" > > For their implementation yes > > > > > > In other words there are at least two problems with Linus

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 07:55:51PM +, Alan Cox wrote: > > cpus execute what they see. speculative execution does the same > > except results are not committed to visible registers and stay > > in renanmed/shadow set. There is no 'undo' of the speculative execution. > > The whole issue is that

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 07:55:51PM +, Alan Cox wrote: > > cpus execute what they see. speculative execution does the same > > except results are not committed to visible registers and stay > > in renanmed/shadow set. There is no 'undo' of the speculative execution. > > The whole issue is that

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote: > On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > [..] > >> retpoline is variant-2, this patch series is about variant-1. > > > > that's exactly t

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote: > On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov > wrote: > [..] > >> retpoline is variant-2, this patch series is about variant-1. > > > > that's exactly the point. Don't slow down the kernel with

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote: > On Sat, 6 Jan 2018 10:13:33 -0800 > Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > > > On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote: > > > On Fri, 5 Jan 2018 18:52:07 -0800 > &

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote: > On Sat, 6 Jan 2018 10:13:33 -0800 > Alexei Starovoitov wrote: > > > On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote: > > > On Fri, 5 Jan 2018 18:52:07 -0800 > > > Linus Torvalds wrote: > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 10:29:49AM -0800, Dan Williams wrote: > On Sat, Jan 6, 2018 at 10:13 AM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote: > >> On Fri, 5 Jan 2018 18:52:07 -0800 > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 10:29:49AM -0800, Dan Williams wrote: > On Sat, Jan 6, 2018 at 10:13 AM, Alexei Starovoitov > wrote: > > On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote: > >> On Fri, 5 Jan 2018 18:52:07 -0800 > >> Linus Torvalds wrote: > >>

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote: > On Fri, 5 Jan 2018 18:52:07 -0800 > Linus Torvalds wrote: > > > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams > > wrote: > > > From: Andi Kleen > > > > > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote: > On Fri, 5 Jan 2018 18:52:07 -0800 > Linus Torvalds wrote: > > > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams > > wrote: > > > From: Andi Kleen > > > > > > When access_ok fails we should always stop speculating. > > > Add the required

Re: [RFCv2 4/4] bpf: inhibit speculated out-of-bounds pointers

On Fri, Jan 05, 2018 at 02:57:50PM +, Mark Rutland wrote: > Note: this patch is an *example* use of the nospec API. It is understood > that this is incomplete, etc. > > Under speculation, CPUs may mis-predict branches in bounds checks. Thus, > memory accesses under a bounds check may be

Re: [RFCv2 4/4] bpf: inhibit speculated out-of-bounds pointers

On Fri, Jan 05, 2018 at 02:57:50PM +, Mark Rutland wrote: > Note: this patch is an *example* use of the nospec API. It is understood > that this is incomplete, etc. > > Under speculation, CPUs may mis-predict branches in bounds checks. Thus, > memory accesses under a bounds check may be

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 10:25:35AM -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 10:17 AM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > > > Clearly Paul's approach to retpoline without lfence is faster. > > I'm guessing it wasn't shar

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 10:25:35AM -0800, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 10:17 AM, Alexei Starovoitov > wrote: > > > > Clearly Paul's approach to retpoline without lfence is faster. > > I'm guessing it wasn't shared with amazon/intel until now and >

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 02:36:58PM +, David Woodhouse wrote: > Enable the use of -mindirect-branch=thunk-extern in newer GCC, and provide > the corresponding thunks. Provide assembler macros for invoking the thunks > in the same way that GCC does, from native and inline assembler. > > This

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

On Thu, Jan 04, 2018 at 02:36:58PM +, David Woodhouse wrote: > Enable the use of -mindirect-branch=thunk-extern in newer GCC, and provide > the corresponding thunks. Provide assembler macros for invoking the thunks > in the same way that GCC does, from native and inline assembler. > > This

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, Jan 04, 2018 at 02:15:53AM +, Alan Cox wrote: > > > > Elena has done the work of auditing static analysis reports to a dozen > > > or so locations that need some 'nospec' handling. > > > > How exactly is that related (especially in longer-term support terms) to > > BPF anyway? >

Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier

On Thu, Jan 04, 2018 at 02:15:53AM +, Alan Cox wrote: > > > > Elena has done the work of auditing static analysis reports to a dozen > > > or so locations that need some 'nospec' handling. > > > > How exactly is that related (especially in longer-term support terms) to > > BPF anyway? >

Re: WARNING in adjust_ptr_min_max_vals

On Tue, Jan 02, 2018 at 08:58:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 0e08c463db387a2adcb0243b15ab868a73f87807 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: WARNING in adjust_ptr_min_max_vals

On Tue, Jan 02, 2018 at 08:58:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 0e08c463db387a2adcb0243b15ab868a73f87807 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: general protection fault in copy_verifier_state

On Tue, Jan 02, 2018 at 02:58:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6bb8824732f69de0f233ae6b1a8158e149627b38 > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: general protection fault in copy_verifier_state

On Tue, Jan 02, 2018 at 02:58:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6bb8824732f69de0f233ae6b1a8158e149627b38 > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On 12/27/17 11:51 PM, Masami Hiramatsu wrote: Then what happen if the user set invalid retval to those functions? even if we limit the injectable functions, it can cause a problem, for example, obj = func_return_object(); if (!obj) { handling_error...; } obj->field = x; In this case,

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On 12/27/17 11:51 PM, Masami Hiramatsu wrote: Then what happen if the user set invalid retval to those functions? even if we limit the injectable functions, it can cause a problem, for example, obj = func_return_object(); if (!obj) { handling_error...; } obj->field = x; In this case,

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/28/17 12:20 AM, Masami Hiramatsu wrote: On Wed, 27 Dec 2017 20:32:07 -0800 Alexei Starovoitov <a...@fb.com> wrote: On 12/27/17 8:16 PM, Steven Rostedt wrote: On Wed, 27 Dec 2017 19:45:42 -0800 Alexei Starovoitov <a...@fb.com> wrote: I don't think that's the case. My readin

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/28/17 12:20 AM, Masami Hiramatsu wrote: On Wed, 27 Dec 2017 20:32:07 -0800 Alexei Starovoitov wrote: On 12/27/17 8:16 PM, Steven Rostedt wrote: On Wed, 27 Dec 2017 19:45:42 -0800 Alexei Starovoitov wrote: I don't think that's the case. My reading of current trace_kprobe_ftrace

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/27/17 8:16 PM, Steven Rostedt wrote: On Wed, 27 Dec 2017 19:45:42 -0800 Alexei Starovoitov <a...@fb.com> wrote: I don't think that's the case. My reading of current trace_kprobe_ftrace() -> arch_check_ftrace_location() is that it will not be true for old mcount case. In the o

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/27/17 8:16 PM, Steven Rostedt wrote: On Wed, 27 Dec 2017 19:45:42 -0800 Alexei Starovoitov wrote: I don't think that's the case. My reading of current trace_kprobe_ftrace() -> arch_check_ftrace_location() is that it will not be true for old mcount case. In the old mcount case,

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On 12/27/17 5:38 PM, Masami Hiramatsu wrote: On Wed, 27 Dec 2017 14:49:46 -0800 Alexei Starovoitov <a...@fb.com> wrote: On 12/27/17 12:09 AM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 18:12:56 -0800 Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Dec 26, 2

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On 12/27/17 5:38 PM, Masami Hiramatsu wrote: On Wed, 27 Dec 2017 14:49:46 -0800 Alexei Starovoitov wrote: On 12/27/17 12:09 AM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 18:12:56 -0800 Alexei Starovoitov wrote: On Tue, Dec 26, 2017 at 04:48:25PM +0900, Masami Hiramatsu wrote: Support

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/27/17 6:34 PM, Masami Hiramatsu wrote: On Wed, 27 Dec 2017 14:46:24 -0800 Alexei Starovoitov <a...@fb.com> wrote: On 12/26/17 9:56 PM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 17:57:32 -0800 Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Dec 26, 2017 a

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/27/17 6:34 PM, Masami Hiramatsu wrote: On Wed, 27 Dec 2017 14:46:24 -0800 Alexei Starovoitov wrote: On 12/26/17 9:56 PM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 17:57:32 -0800 Alexei Starovoitov wrote: On Tue, Dec 26, 2017 at 04:46:59PM +0900, Masami Hiramatsu wrote: Check

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On 12/27/17 12:09 AM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 18:12:56 -0800 Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Dec 26, 2017 at 04:48:25PM +0900, Masami Hiramatsu wrote: Support in-kernel fault-injection framework via debugfs. This allows you to

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On 12/27/17 12:09 AM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 18:12:56 -0800 Alexei Starovoitov wrote: On Tue, Dec 26, 2017 at 04:48:25PM +0900, Masami Hiramatsu wrote: Support in-kernel fault-injection framework via debugfs. This allows you to inject a conditional error to specified

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/26/17 9:56 PM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 17:57:32 -0800 Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: On Tue, Dec 26, 2017 at 04:46:59PM +0900, Masami Hiramatsu wrote: Check whether error injectable event is on function entry or not. Currently it

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On 12/26/17 9:56 PM, Masami Hiramatsu wrote: On Tue, 26 Dec 2017 17:57:32 -0800 Alexei Starovoitov wrote: On Tue, Dec 26, 2017 at 04:46:59PM +0900, Masami Hiramatsu wrote: Check whether error injectable event is on function entry or not. Currently it checks the event is ftrace-based kprobes

Re: [PATCH 4/4] libbpf: add missing SPDX-License-Identifier

On Wed, Dec 27, 2017 at 07:02:29PM +0100, Eric Leblond wrote: > Signed-off-by: Eric Leblond <e...@regit.org> thank you. Acked-by: Alexei Starovoitov <a...@kernel.org>

Re: [PATCH 4/4] libbpf: add missing SPDX-License-Identifier

On Wed, Dec 27, 2017 at 07:02:29PM +0100, Eric Leblond wrote: > Signed-off-by: Eric Leblond thank you. Acked-by: Alexei Starovoitov

Re: [PATCH 3/4] libbpf: break loop earlier

On Wed, Dec 27, 2017 at 07:02:28PM +0100, Eric Leblond wrote: > Get out of the loop when we have a match. > > Signed-off-by: Eric Leblond > --- > tools/lib/bpf/libbpf.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >

Re: [PATCH 3/4] libbpf: break loop earlier

On Wed, Dec 27, 2017 at 07:02:28PM +0100, Eric Leblond wrote: > Get out of the loop when we have a match. > > Signed-off-by: Eric Leblond > --- > tools/lib/bpf/libbpf.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > index

Re: [PATCH 1/4] libbpf: add function to setup XDP

On Wed, Dec 27, 2017 at 07:02:26PM +0100, Eric Leblond wrote: > Most of the code is taken from set_link_xdp_fd() in bpf_load.c and > slightly modified to be library compliant. > > Signed-off-by: Eric Leblond <e...@regit.org> Acked-by: Alexei Starovoitov <a...@kernel.org>

Re: [PATCH 1/4] libbpf: add function to setup XDP

On Wed, Dec 27, 2017 at 07:02:26PM +0100, Eric Leblond wrote: > Most of the code is taken from set_link_xdp_fd() in bpf_load.c and > slightly modified to be library compliant. > > Signed-off-by: Eric Leblond Acked-by: Alexei Starovoitov

Re: [PATCH 2/4] libbpf: add error reporting in XDP

On Wed, Dec 27, 2017 at 07:02:27PM +0100, Eric Leblond wrote: > Parse netlink ext attribute to get the error message returned by > the card. Code is partially take from libnl. > > Signed-off-by: Eric Leblond <e...@regit.org> Acked-by: Alexei Starovoitov <a...@kernel.org>

Re: [PATCH 2/4] libbpf: add error reporting in XDP

On Wed, Dec 27, 2017 at 07:02:27PM +0100, Eric Leblond wrote: > Parse netlink ext attribute to get the error message returned by > the card. Code is partially take from libnl. > > Signed-off-by: Eric Leblond Acked-by: Alexei Starovoitov

Re: [lkp-robot] [bpf] 82abbf8d2f: kernel_selftests.bpf.test_align.fail

On Wed, Dec 27, 2017 at 11:00:30AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: 82abbf8d2fc46d79611ab58daa7c608df14bb3ee ("bpf: do not allow root to > mangle valid pointers") >

Re: [lkp-robot] [bpf] 82abbf8d2f: kernel_selftests.bpf.test_align.fail

On Wed, Dec 27, 2017 at 11:00:30AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit (built with gcc-7): > > commit: 82abbf8d2fc46d79611ab58daa7c608df14bb3ee ("bpf: do not allow root to > mangle valid pointers") >

Re: [PATCH v2 bpf-next 2/2] tools/bpftool: fix bpftool build with bintutils >= 2.8

t; > > Fix this by adding a new "feature" to the tools/build/features > > infrastructure and make it responsible for decision which > > disassembler() function signature to use. > > > > Signed-off-by: Roman Gushchin <g...@fb.com> > > C

Re: [PATCH v2 bpf-next 2/2] tools/bpftool: fix bpftool build with bintutils >= 2.8

t; > Fix this by adding a new "feature" to the tools/build/features > > infrastructure and make it responsible for decision which > > disassembler() function signature to use. > > > > Signed-off-by: Roman Gushchin > > Cc: Jakub Kicinski > >

Re: [PATCH bpf-next 2/3] libbpf: add error reporting in XDP

On Mon, Dec 25, 2017 at 11:13:24PM +0100, Eric Leblond wrote: > Parse netlink ext attribute to get the error message returned by > the card. > > Signed-off-by: Eric Leblond ... > diff --git a/tools/lib/bpf/nlattr.c b/tools/lib/bpf/nlattr.c > new file mode 100644 > index

Re: [PATCH bpf-next 2/3] libbpf: add error reporting in XDP

On Mon, Dec 25, 2017 at 11:13:24PM +0100, Eric Leblond wrote: > Parse netlink ext attribute to get the error message returned by > the card. > > Signed-off-by: Eric Leblond ... > diff --git a/tools/lib/bpf/nlattr.c b/tools/lib/bpf/nlattr.c > new file mode 100644 > index

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On Tue, Dec 26, 2017 at 04:48:25PM +0900, Masami Hiramatsu wrote: > Support in-kernel fault-injection framework via debugfs. > This allows you to inject a conditional error to specified > function using debugfs interfaces. > > Signed-off-by: Masami Hiramatsu > --- >

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

On Tue, Dec 26, 2017 at 04:48:25PM +0900, Masami Hiramatsu wrote: > Support in-kernel fault-injection framework via debugfs. > This allows you to inject a conditional error to specified > function using debugfs interfaces. > > Signed-off-by: Masami Hiramatsu > --- >

Re: [RFC PATCH bpf-next v2 3/4] error-injection: Separate error-injection from kprobe

on name to override_function_with_return() >- Show only function name in the list, user don't have to care about > it's size, since function override only happens at the entry. looks like nice cleanup. Acked-by: Alexei Starovoitov <a...@kernel.org>

Re: [RFC PATCH bpf-next v2 3/4] error-injection: Separate error-injection from kprobe

tion_with_return() >- Show only function name in the list, user don't have to care about > it's size, since function override only happens at the entry. looks like nice cleanup. Acked-by: Alexei Starovoitov

Re: [RFC PATCH bpf-next v2 2/4] tracing/kprobe: bpf: Compare instruction pointer with original one

/ > - if (__this_cpu_read(bpf_kprobe_override)) { > - __this_cpu_write(bpf_kprobe_override, 0); > + if (orig_ip != instruction_pointer(regs)) { > reset_current_kprobe(); > + preempt_enable_no_resched(); This is great idea. Acked-by: Alexei Starovoitov <a...@kernel.org>

Re: [RFC PATCH bpf-next v2 2/4] tracing/kprobe: bpf: Compare instruction pointer with original one

rride)) { > - __this_cpu_write(bpf_kprobe_override, 0); > + if (orig_ip != instruction_pointer(regs)) { > reset_current_kprobe(); > + preempt_enable_no_resched(); This is great idea. Acked-by: Alexei Starovoitov

<    3   4   5   6   7   8   9   10   11   12   >