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 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 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: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: correctness of BPF stack size checking logic for multi-function programs?

On Fri, Dec 22, 2017 at 02:14:45AM +0100, Jann Horn wrote: > Hi! > > I saw the recently-added support for multiple functions in a single > program in BPF. I've stumbled over something that looks like it might > be a bug; I haven't verified it yet, but I thought I should give you a > heads-up

kasan for bpf

Hi All, the recent bugs make people question the safety of bpf and not a surprise that some folks propose to set kernel.unprivileged_bpf_disabled = 1 by default. I think it will be wrong long term decision, since it will steer bpf into "root only" mentality. The verifier checks will become

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

[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 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 ++--

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: [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 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 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 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: 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 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 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][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: 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: 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: [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 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 v4 00/10] prevent bounds-check bypass via speculative execution

On Fri, Jan 19, 2018 at 10:58:44PM -0800, Dan Williams wrote: > On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams > wrote: > > Changes since v3 [1] > > * Drop 'ifence_array_ptr' and associated compile-time + run-time > > switching and just use the masking approach all the

Re: [PATCH v4 00/10] prevent bounds-check bypass via speculative execution

On Sat, Jan 20, 2018 at 8:56 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Fri, Jan 19, 2018 at 10:58:44PM -0800, Dan Williams wrote: >> On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams <dan.j.willi...@intel.com> >> wrote: >> > Changes since

Re: [PATCH net-next v1] bpf: Use the IS_FD_ARRAY() macro in map_update_elem()

On Fri, Jan 26, 2018 at 12:54:02AM +0100, Mickaël Salaün wrote: > Make the code more readable. > > Signed-off-by: Mickaël Salaün <m...@digikod.net> > Cc: Alexei Starovoitov <a...@kernel.org> > Cc: Daniel Borkmann <dan...@iogearbox.net> > --- > kernel/bpf/s

Re: [PATCH net-next v1] samples/bpf: Partially fixes the bpf.o build

pf/ and convert to use libbpf.a instead of obsolete bpf_load.c Please use this approach for landlock as well. > Signed-off-by: Mickaël Salaün <m...@digikod.net> > Cc: Alexei Starovoitov <a...@kernel.org> > Cc: Daniel Borkmann <dan...@iogearbox.net> > --- > > This is

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

On Wed, Jan 17, 2018 at 03:47:35PM -0500, Theodore Ts'o wrote: > On Wed, Jan 17, 2018 at 12:09:18PM +0100, Dmitry Vyukov wrote: > > On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann > > wrote: > > > Don't know if there's such a possibility, but it would be nice if we could

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] kernel:bpf Remove structure passing and assignment to save stack and no coping structures

On Sun, Jan 14, 2018 at 01:18:35PM +0200, Karim Eshapa wrote: > >> Use pointers to structure as arguments to function instead of coping > >> structures and less stack size. Also transfer TNUM(_v, _m) to > >> tnum.h file to be used in differnet files for creating anonymous structures > >>

Re: [PATCH] bpf/stackmap: Implement bpf_get_next_key

stackmaps independent of other maps. > > Tested on x86 and arm64 machines. > > [1] https://lwn.net/Articles/744522/ > [2] https://github.com/joelagnel/bpfd/issues/8 > > Cc: Alexei Starovoitov <a...@kernel.org> > Cc: Daniel Borkmann <dan...@iogearbox.net> > Cc: B

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: [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: [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 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: 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: suspicious RCU usage at ./include/linux/rcupdate.h:LINE (4)

On Fri, Feb 02, 2018 at 06:58:01AM -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on bpf-next commit > b2fe5fa68642860e7de76167c3111623aa0d5de1 (Wed Jan 31 22:31:10 2018 +) > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next > > So far this crash happened

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

On Wed, Jan 31, 2018 at 05:53:13PM +0100, Daniel Borkmann wrote: > On 01/30/2018 09:50 PM, Eric Leblond wrote: > > Hello Daniel, > > > > No problem with the delay in the answer. I'm doing far worse. > > > > Here is an updated version: > > - add if_link.h in uapi and remove the definition > > -

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

On Sun, Feb 04, 2018 at 12:57:47PM +0900, Masami Hiramatsu wrote: > > > I based some of the code from kprobes too. But I wanted this to be > > simpler, and as such, not as powerful as kprobes. More of a "poor mans" > > kprobe ;-) Where you are limited to functions and their arguments. If > > you

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

On Sat, Feb 03, 2018 at 04:08:24PM -0500, Steven Rostedt wrote: > On Sat, 3 Feb 2018 12:52:08 -0800 > Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > > > On Sat, Feb 03, 2018 at 02:02:17PM -0500, Steven Rostedt wrote: > > > > > > From those that

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

On Sat, Feb 03, 2018 at 04:17:32PM -0500, Steven Rostedt wrote: > On Sat, 3 Feb 2018 12:52:08 -0800 > Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > > > It's a user space job. > > BTW, I asked around at DevConf.cz, and nobody I talked with (besides

Re: [PATCH 00/18] [ANNOUNCE] Dynamically created function based events

On Sat, Feb 03, 2018 at 02:02:17PM -0500, Steven Rostedt wrote: > > From those that were asking about having "trace markers" (ie. > Facebook), they told us they can cope with kernel changes. There is some misunderstanding here. We never asked for this interface. We're perfectly fine with

Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):

On Mon, Feb 12, 2018 at 09:28:33AM +0100, Daniel Borkmann wrote: > On 02/12/2018 06:47 AM, Yonghong Song wrote: > > On 2/11/18 11:18 AM, Mathieu Malaterre wrote: > >> On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov > >> <alexei.starovoi...@gmail.com> wrote: &

Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):

On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre wrote: > Alexei, > > Could you please comment on why I am seeing those memleaks being > reported on my ppc32 system ? Should they be marked as false positive > ? > > System is Mac Mini G4, git/master (4.15.0+), ppc. > > Thanks

Re: [Resend] Question: kselftests: bpf/test_maps failed

On Fri, Feb 09, 2018 at 03:01:57PM +0100, Daniel Borkmann wrote: > On 02/09/2018 06:14 AM, Li Zhijian wrote: > > Hi > > > > INTEL 0-Day noticed that bpf/test_maps has different results at different > > platforms. > > when it fails, the details are like > > Sorry for the late reply and thanks

Re: [tip:perf/core] perf/headers: Sync new perf_event.h with the tools/include/uapi version

lt;pet...@infradead.org> > Reviewed-by: Yonghong Song <y...@fb.com> > Reviewed-by: Josef Bacik <jba...@fb.com> > Acked-by: Alexei Starovoitov <a...@kernel.org> > Cc: <dan...@iogearbox.net> > Cc: <da...@davemloft.net> > Cc: <kernel-t...@fb.com>

Re: [PATCH] selftests/bpf/test_maps: exit child process without error in ENOMEM case

_maps.c:955: run_parallel: Assertion `status == 0' failed. > Aborted > not ok 1..3 selftests: test_maps [FAIL] > --- > after this patch, the rest tests will be continue when it occurs a ENOMEM > failure > > CC: Alexei Starovoitov <alexei.starovoi..

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 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: 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: 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: [PATCH] bpf: selftest for late caller stack size increase

On Fri, Dec 22, 2017 at 07:12:35PM +0100, Jann Horn wrote: > This checks that it is not possible to bypass the total stack size check in > update_stack_depth() by calling a function that uses a large amount of > stack memory *before* using a large amount of stack memory in the caller. > >

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 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: [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: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

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 or not, > but that is wrong. It should check if the event is on the entry > of target function. Since error

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 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 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 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 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 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 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

tracepoint_probe_register and bpf. Was: [PATCH tip 0/3] Improvements of scheduler related Tracepoints

On Mon, Dec 18, 2017 at 10:11:57AM +0100, Peter Zijlstra wrote: > On Fri, Dec 15, 2017 at 09:09:51AM -0800, Alexei Starovoitov wrote: > > > yeah. Currently bpf progs are called at the end of > > perf_trace_##call() > > { > > .. regular tracepoint copy craft &

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: [PATCH bpf-next 0/4] Convert filter.txt to RST

On Fri, Aug 10, 2018 at 5:57 AM Jonathan Corbet wrote: > > The objective actually is to have SPDX tags in all files in the kernel. > That includes documentation, even though people, as always, care less > about the docs than they do the code. right, but let's do that as a separate patch set. In

Re: [PATCH] tracing: Add SPDX License format to bpf_trace.c

mpliance management. > > Cc: Alexei Starovoitov ohh. did you get a reply from that address? ;) > Cc: Daniel Borkmann > Signed-off-by: Steven Rostedt (VMware) Acked-by: Alexei Starovoitov

Re: [PATCH] kernel:bpf Remove structure passing and assignment to save stack and no coping structures

On Sun, Jan 14, 2018 at 12:03:42AM +0200, Karim Eshapa wrote: > Use pointers to structure as arguments to function instead of coping > structures and less stack size. Also transfer TNUM(_v, _m) to > tnum.h file to be used in differnet files for creating anonymous structures > statically. > >

Re: [PATCH bpf-next 0/4] libbpf: add XDP binding support

On Sat, Jan 20, 2018 at 03:00:37AM +0100, Daniel Borkmann wrote: > On 01/19/2018 12:43 AM, Eric Leblond wrote: > > Hello, > > > > This patchset rebases the libbpf code on latest bpf-next code and addresses > > remarks by Daniel. > > Ok, I think it's a good start. We should later on clean up the

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

combining multiple answers... On 3/6/18 3:05 AM, Greg KH wrote: Any chance you can add a field to your "umh module" type such that a normal 'modinfo' program will be able to notice it is different easily? ok. handling of modinfo turned out to be straightforward. kmod tooling worked fine with

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/9/18 10:23 AM, Andy Lutomirski wrote: On Mar 9, 2018, at 10:15 AM, Greg KH wrote: Oh, and for the record, I like Andy's proposal as well as dumping this into a kernel module "blob" with the exception that this now would take up unswapable memory, which

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/9/18 10:50 AM, Linus Torvalds wrote: On Fri, Mar 9, 2018 at 10:43 AM, Kees Cook wrote: Module loading (via kernel_read_file()) already uses deny_write_access(), and so does do_open_execat(). As long as module loading doesn't call allow_write_access() before the

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/12/18 5:02 AM, Edward Cree wrote: On 09/03/18 18:58, Alexei Starovoitov wrote: It's not waiting for the whole thing, because once bpfilter starts it stays running/sleeping because it's stateful. So, this has been bugging me a bit. If bpfilter takes a signal and crashes, all that state

Re: [PATCH 11/13] perf bpf: Add helper header files

On Mon, Mar 12, 2018 at 10:43:11AM +0100, Jiri Olsa wrote: > diff --git a/tools/perf/util/bpf-userapi.h b/tools/perf/util/bpf-userapi.h > new file mode 100644 > index ..63f2b4c13a5c > --- /dev/null > +++ b/tools/perf/util/bpf-userapi.h > @@ -0,0 +1,11 @@ > +#ifndef __BPF_USERAPI_H >

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/10/18 7:34 AM, Luis R. Rodriguez wrote: Also, Alexei you never answered my questions out aliases with the umh modules. Long term this important to consider. aliases always felt like a crutch to me. I can see an argument when they're used as 'alias pci:* foo' but the way it's used in

[PATCH bpf-next 3/5] bpf: introduce BPF_RAW_TRACEPOINT

and all attached bpf programs. In the future bpf_raw_tracepoints can be extended with query/introspection logic. Signed-off-by: Alexei Starovoitov <a...@kernel.org> --- include/linux/bpf_types.h| 1 + include/linux/trace_events.h | 57 include/trace/bpf_probe.h| 87 +++

[PATCH bpf-next 5/5] samples/bpf: raw tracepoint test

empty raw_tracepoint bpf program to test overhead Signed-off-by: Alexei Starovoitov <a...@kernel.org> --- samples/bpf/Makefile| 1 + samples/bpf/bpf_load.c | 13 + samples/bpf/test_overhead_raw_tp_kern.c | 17 + sampl

[PATCH bpf-next 2/5] tracepoint: compute num_args at build time

it more useful with ability to stop for_each() loop depending via callback return value. In such form it's used in subsequent patch. Signed-off-by: Alexei Starovoitov <a...@kernel.org> --- include/linux/tracepoint-defs.h | 1 + include/linux/tracepoint.h

[PATCH bpf-next 1/5] treewide: remove struct-pass-by-value from tracepoints arguments

patch enforces that all tracepoints args are either integers or pointers and fit into 64-bit. Signed-off-by: Alexei Starovoitov <a...@kernel.org> --- arch/x86/xen/mmu_pv.c| 16 +- drivers/gpu/drm/i915/i915_trace.h| 13 +++-- drivers/infiniband/hw/hfi1/file

[PATCH bpf-next 0/5] bpf, tracing: introduce bpf raw tracepoints

89K 697K750K755K Alexei Starovoitov (5): treewide: remove struct-pass-by-value from tracepoints arguments tracepoint: compute num_args at build time bpf: introduce BPF_RAW_TRACEPOINT libbpf: add bpf_raw_tracepoint_open helper samples/bpf: raw tracepoint test arch/x86/xe

[PATCH bpf-next 4/5] libbpf: add bpf_raw_tracepoint_open helper

Signed-off-by: Alexei Starovoitov <a...@kernel.org> --- tools/include/uapi/linux/bpf.h | 11 +++ tools/lib/bpf/bpf.c| 10 ++ tools/lib/bpf/bpf.h| 1 + 3 files changed, 22 insertions(+) diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/7/18 5:23 PM, Luis R. Rodriguez wrote: request_module() has its own world though too. How often in your proof of concept is request_module() called? How many times do you envision it being called? once. +static int run_umh(struct file *file) +{ + struct subprocess_info *sub_info

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/9/18 11:38 AM, Linus Torvalds wrote: On Fri, Mar 9, 2018 at 11:12 AM, Linus Torvalds wrote: How are you going to handle five processes doing the same setup concurrently? Side note: it's not just serialization. It's also "is it actually up and running".

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/9/18 11:37 AM, Andy Lutomirski wrote: On Fri, Mar 9, 2018 at 6:55 PM, David Miller <da...@davemloft.net> wrote: From: Alexei Starovoitov <a...@fb.com> Date: Fri, 9 Mar 2018 10:50:49 -0800 On 3/9/18 10:23 AM, Andy Lutomirski wrote: It might not be totally crazy to back

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/8/18 7:54 PM, Andy Lutomirski wrote: On Mar 8, 2018, at 7:06 PM, Linus Torvalds wrote: Honestly, that "read twice" thing may be what scuttles this. Initially, I thought it was a non-issue, because anybody who controls the module subdirectory enough to

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 09, 2018 at 12:59:36AM +, Andy Lutomirski wrote: > > Alexei, can you give an example use case? I'm sure it's upthread > somewhere, but I'm having trouble finding it. at the time of iptable's setsockopt() the kernel will do err = request_module("bpfilter"); once. The rough POC

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 09, 2018 at 02:12:24AM +, Andy Lutomirski wrote: > On Fri, Mar 9, 2018 at 1:20 AM, Alexei Starovoitov > <alexei.starovoi...@gmail.com> wrote: > > On Fri, Mar 09, 2018 at 12:59:36AM +, Andy Lutomirski wrote: > >> > >> Alexei, can you give

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/8/18 4:24 PM, Kees Cook wrote: How is this not marked [RFC]? :) On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov <a...@kernel.org> wrote: As the first step in development of bpfilter project [1] the request_module() code is extended to allow user mode helpers to be invoked

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On Fri, Mar 09, 2018 at 01:04:39AM +, Andy Lutomirski wrote: > On Fri, Mar 9, 2018 at 12:57 AM, Alexei Starovoitov <a...@fb.com> wrote: > > On 3/8/18 4:24 PM, Kees Cook wrote: > >> > >> As Andy asked earlier, why not DYN too to catch PIE executables? Seem

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/9/18 7:16 AM, Andy Lutomirski wrote: On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov <a...@fb.com> wrote: On 3/8/18 7:54 PM, Andy Lutomirski wrote: On Mar 8, 2018, at 7:06 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: Honestly, that "read twice" thin

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 3/9/18 8:24 AM, Andy Lutomirski wrote: On Fri, Mar 9, 2018 at 3:39 PM, Alexei Starovoitov <a...@fb.com> wrote: On 3/9/18 7:16 AM, Andy Lutomirski wrote: On Mar 8, 2018, at 9:08 PM, Alexei Starovoitov <a...@fb.com> wrote: On 3/8/18 7:54 PM, Andy Lutomirski wrote: On Mar 8

Re: [PATCH] x86/cpufeature: guard asm_volatile_goto usage with CC_HAVE_ASM_GOTO

On 4/10/18 2:07 PM, Peter Zijlstra wrote: On Tue, Apr 10, 2018 at 01:42:59PM -0700, Yonghong Song wrote: Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always use __always_inline function _static_cpu_has() funciton. The

Re: [PATCH] x86/cpufeature: guard asm_volatile_goto usage with CC_HAVE_ASM_GOTO

On 4/13/18 11:19 AM, Peter Zijlstra wrote: On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote: Instead of #ifdef CC_HAVE_ASM_GOTO we can replace it with #ifndef __BPF__ or some other name, I would prefer the BPF specific hack; otherwise we might be encouraging people to build

Re: [PATCH bpf-next v8 05/11] seccomp,landlock: Enforce Landlock programs per process hierarchy

;> > >>> On 27/02/2018 17:39, Andy Lutomirski wrote: > >>>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov > >>>> <alexei.starovoi...@gmail.com> wrote: > >>>>> On Tue, Feb 27, 2018 at 05:20:55AM +, Andy Lutomirski

Re: [PATCH v5 0/6] enable creating [k,u]probe with perf_event_open

On 4/9/18 9:45 PM, Ravi Bangoria wrote: Hi Song, On 12/07/2017 04:15 AM, Song Liu wrote: With current kernel, user space tools can only create/destroy [k,u]probes with a text-based API (kprobe_events and uprobe_events in tracefs). This approach relies on user space to clean up the [k,u]probe

Re: [GIT PULL] Kernel lockdown for secure boot

On Sun, Apr 08, 2018 at 04:07:42PM +0800, joeyli wrote: > > > If the only thing that folks are paranoid about is reading > > arbitrary kernel memory with bpf_probe_read() helper > > then preferred patch would be to disable it during verification > > when in lockdown mode > > Sorry for I didn't

Re: [RFC 0/9] bpf: Add buildid check support

On Thu, Apr 05, 2018 at 05:16:36PM +0200, Jiri Olsa wrote: > hi, > eBPF programs loaded for kprobes are allowed to read kernel > internal structures. We check the provided kernel version > to ensure that the program is loaded for the proper kernel. > > The problem is that the version check is

Re: Build error for samples/bpf/ due to commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")

On Fri, Apr 13, 2018 at 03:22:37PM +0200, Jesper Dangaard Brouer wrote: > Hi Peter, > > Your commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS") broke build > for several samples/bpf programs. I'm unsure what the best way forward > is to unbreak these... > > The issue is that these samples

Re: [PATCH bpf-next 4/5] samples/bpf: Refine printing symbol for sampleip

On Thu, Apr 19, 2018 at 01:12:49PM +0800, Leo Yan wrote: > On Wed, Apr 18, 2018 at 09:47:45PM -0700, Alexei Starovoitov wrote: > > On Thu, Apr 19, 2018 at 09:34:05AM +0800, Leo Yan wrote: > > > The code defines macro 'PAGE_OFFSET' and uses it to decide if the > > >

<    13   14   15   16   17   18   19   20   21   22   >