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 `bpf_patch_ca
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 change
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.
>
On Tue, Jan 09, 2018 at 04:48:24PM -0800, Dan Williams wrote:
>
> #define __nospec_array_ptr(base, idx, sz) \
> ({ \
> union { typeof(&base[0]) _ptr; unsigned long _bit; } __u; \
>
l variable from all JITs, 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 |
ne extra hunk.
It will 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 remo
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 com
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
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 a
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 the
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 w
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 a
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
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 s
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 proposal
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 c
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 ke
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:
> >
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:
> >>
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
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 specul
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 n
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 add
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?
>
>
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 o
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 ou
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,
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_kpr
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 mco
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
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
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
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
On Wed, Dec 27, 2017 at 07:02:29PM +0100, Eric Leblond wrote:
> Signed-off-by: Eric Leblond
thank you.
Acked-by: Alexei Starovoitov
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 5fe8aaa2123e.
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
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
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")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux
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
> >
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 ..962de14f74e3
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
> ---
> Documentation/fault-injection
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
(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
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 i
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 sloppi
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.
>
> Currentl
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 befor
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
&
On 12/20/17 3:00 AM, Masami Hiramatsu wrote:
On Fri, 15 Dec 2017 14:12:52 -0500
Josef Bacik wrote:
From: Josef Bacik
Using BPF we can override kprob'ed functions and return arbitrary
values. Obviously this can be a bit unsafe, so make this feature opt-in
for functions. Simply tag a functio
On 12/19/17 11:13 PM, Masami Hiramatsu wrote:
On Tue, 19 Dec 2017 18:14:17 -0800
Alexei Starovoitov wrote:
On 12/18/17 10:29 PM, Masami Hiramatsu wrote:
+#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+#ifdef CONFIG_BPF_KPROBE_OVERRIDE
BTW, CONFIG_BPF_KPROBE_OVERRIDE is also co
On 12/18/17 10:29 PM, Masami Hiramatsu wrote:
+#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+#ifdef CONFIG_BPF_KPROBE_OVERRIDE
BTW, CONFIG_BPF_KPROBE_OVERRIDE is also confusable name.
Since this feature override a function to just return with
some return value (as far as I understand, or
On Tue, Dec 19, 2017 at 11:12:04AM +0100, Arnd Bergmann wrote:
> CONFIG_BPF_KPROBE_OVERRIDE causes a link failure when CONFIG_KPROBE_EVENTS
> is disabled:
>
> kernel/trace/bpf_trace.o: In function `bpf_override_return':
> (.text+0x172): undefined reference to `bpf_kprobe_override'
>
> This adds i
On Tue, Dec 19, 2017 at 05:56:55PM +0900, Masami Hiramatsu wrote:
> include/trace/events/sctp.h | 98 ++
> include/trace/events/tcp.h | 80 +++
> net/Kconfig | 17 --
> net/dccp/Kconfig| 17 --
> net/dccp/Makefile |2
> net/dc
On 12/15/17 11:12 AM, Josef Bacik wrote:
+#ifdef CONFIG_BPF_KPROBE_OVERRIDE
+BPF_CALL_2(bpf_override_return, struct pt_regs *, regs, unsigned long, rc)
+{
+ __this_cpu_write(bpf_kprobe_override, 1);
+ regs_set_return_value(regs, rc);
+ arch_ftrace_kprobe_override_function(regs);
On 12/14/17 11:39 PM, Peter Zijlstra wrote:
On Thu, Dec 14, 2017 at 07:16:00PM -0800, Alexei Starovoitov wrote:
On 12/14/17 12:49 PM, Peter Zijlstra wrote:
On Thu, Dec 14, 2017 at 12:20:41PM -0800, Teng Qin wrote:
This set of commits attempts to improve three scheduler related
Tracepoints
On 12/14/17 12:49 PM, Peter Zijlstra wrote:
On Thu, Dec 14, 2017 at 12:20:41PM -0800, Teng Qin wrote:
This set of commits attempts to improve three scheduler related
Tracepoints: sched_switch, sched_process_fork, sched_process_exit.
Firstly, these commit add additional flag values, namely preem
On Wed, Dec 13, 2017 at 12:32:45PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/events/core.o: In function `perf_ioctl':
> core.c:(.text+0x98c4): undefined reference to `bpf_event_que
On 12/11/17 8:36 AM, Josef Bacik wrote:
This is the same as v8, just rebased onto the bpf tree.
v8->v9:
- rebased onto the bpf tree.
v7->v8:
- removed the _ASM_KPROBE_ERROR_INJECT since it was not needed.
v6->v7:
- moved the opt-in macro to bpf.h out of kprobes.h.
v5->v6:
- add BPF_ALLOW_ERRO
On Sat, Dec 09, 2017 at 09:34:46AM -0700, David Ahern wrote:
> On 12/9/17 7:43 AM, Eric Leblond wrote:
> > + /* started nested attribute for XDP */
> > + nla = (struct nlattr *)(((char *)&req)
> > + + NLMSG_ALIGN(req.nh.nlmsg_len));
> > + nla->nla_type = NLA_F_NESTED
On 12/4/17 10:24 AM, Song Liu wrote:
On Dec 3, 2017, at 9:03 AM, Alexei Starovoitov
wrote:
On Thu, Nov 30, 2017 at 03:50:18PM -0800, Song Liu wrote:
Two new perf types, perf_kprobe and perf_uprobe, will be added to allow
creating [k,u]probe with perf_event_open. These [k,u]probe are
Brueckner
> Reviewed-and-tested-by: Thomas Richter
> Cc: Arnaldo Carvalho de Melo
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Arnd Bergmann
> Cc: Alexei Starovoitov
> Cc: Daniel B
is NULL), or [k,u]probe offset.
>
> Signed-off-by: Song Liu
> Reviewed-by: Yonghong Song
> Reviewed-by: Josef Bacik
> Acked-by: Alexei Starovoitov
> ---
> include/uapi/linux/perf_event.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/uapi/linux/pe
On Thu, Nov 09, 2017 at 12:16:45PM +0530, Sandipan Das wrote:
> The GCC randomize layout plugin can randomize the member
> offsets of sensitive kernel data structures. To use this
> feature, certain annotations and members are added to the
> structures which affect the member offsets even if this
>
On 12/1/17 9:51 AM, Arnaldo Carvalho de Melo wrote:
But this is not just testcase expectations, the usecase is someone
wanting to use a newer tool, with perhaps some new features of interest
that don't depend on changes in the kernel, in an older kernel on a
system where updating it is not possi
On 11/30/17 11:00 AM, Arnaldo Carvalho de Melo wrote:
Instead of sinking all future bpf_attr's backward compatibility
requirements to sys_bpf, I would push it up to its own BPF_* command
helper which has a better sense of its bpf_attr, i.e. push it up
to bpf_create_map_node() and bpf_load_progra
On 11/24/17 12:28 AM, Peter Zijlstra wrote:
On Thu, Nov 23, 2017 at 10:31:29PM -0800, Alexei Starovoitov wrote:
unfortunately 32-bit is more screwed than it seems:
$ cat align.c
#include
struct S {
unsigned long long a;
} s;
struct U {
unsigned long long a;
} u;
int main
On 11/23/17 2:02 AM, Peter Zijlstra wrote:
On Wed, Nov 15, 2017 at 09:23:33AM -0800, Song Liu wrote:
Note: We use type __u64 for pointer probe_desc instead of __aligned_u64.
The reason here is to avoid changing the size of struct perf_event_attr,
and breaking new-kernel-old-utility scenario. To
On Wed, Nov 22, 2017 at 04:23:29PM -0500, Josef Bacik wrote:
> This is hopefully the final version, I've addressed the comment by Igno and
> added his Acks.
>
> v6->v7:
> - moved the opt-in macro to bpf.h out of kprobes.h.
Thanks Josef!
All patches look great to me.
We'll probably take them all i
On Wed, Nov 15, 2017 at 09:23:31AM -0800, Song Liu wrote:
> Changes RFC v2 to PATCH v1:
> Check type PERF_TYPE_PROBE in perf_event_set_filter().
> Rebase on to tip perf/core.
>
> Changes RFC v1 to RFC v2:
> Fix build issue reported by kbuild test bot by adding ifdef of
> CONFIG_KPROBE_EVEN
On Mon, Nov 13, 2017 at 12:06:17AM -0800, peng yu wrote:
> > 1. anything bpf related has to go via net-next tree.
> I found there is a net-next git repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> I will use this repo for the further bpf-ftrace patch set.
>
> > 2.
> > t
On Sun, Nov 12, 2017 at 07:28:24AM +, yupeng0...@gmail.com wrote:
> Add a new type BPF_PROG_TYPE_FTRACE to bpf, let bpf can be attached to
> ftrace. Ftrace pass the function parameters to bpf prog, bpf prog
> return 1 or 0 to indicate whether ftrace can trace this function. The
> major propose
On 11/11/17 4:14 PM, Ingo Molnar wrote:
* Josef Bacik wrote:
On Fri, Nov 10, 2017 at 10:34:59AM +0100, Ingo Molnar wrote:
* Josef Bacik wrote:
@@ -551,6 +578,10 @@ static const struct bpf_func_proto
*kprobe_prog_func_proto(enum bpf_func_id func
return &bpf_get_stackid_pr
On Thu, Nov 09, 2017 at 02:01:38PM +0800, Yafang Shao wrote:
> With this newly introduced TRACE_EVENT, it will be very easy to minotor
> TCP/IPv4 state transition.
>
> A new TRACE_SYSTEM named tcp is added, in which we can trace other TCP
> event as well.
>
> Two helpers are added,
> static inlin
On 11/8/17 6:47 AM, Y Song wrote:
On Tue, Nov 7, 2017 at 1:39 PM, Alexei Starovoitov wrote:
On 11/8/17 6:14 AM, Y Song wrote:
On Tue, Nov 7, 2017 at 12:37 AM, Naveen N. Rao
wrote:
Alexei Starovoitov wrote:
On 11/7/17 12:55 AM, Naveen N. Rao wrote:
I thought such struct shouldn&#
On 11/8/17 5:28 AM, Josef Bacik wrote:
I'm sending this through Dave since it'll conflict with other BPF changes in his
tree, but since it touches tracing as well Dave would like a review from
somebody on the tracing side.
v4->v5:
- disallow kprobe_override programs from being put in the prog ma
On 11/8/17 6:14 AM, Y Song wrote:
On Tue, Nov 7, 2017 at 12:37 AM, Naveen N. Rao
wrote:
Alexei Starovoitov wrote:
On 11/7/17 12:55 AM, Naveen N. Rao wrote:
I thought such struct shouldn't change layout.
If it is we need to fix include/linux/compiler-clang.h to do that
anon struct as
On 11/7/17 12:55 AM, Naveen N. Rao wrote:
I thought such struct shouldn't change layout.
If it is we need to fix include/linux/compiler-clang.h to do that
anon struct as well.
We considered that, but it looked to be very dependent on the version of
gcc used to build the kernel. But, this may be
On 11/5/17 2:31 AM, Naveen N. Rao wrote:
Hi Alexei,
Alexei Starovoitov wrote:
On 11/3/17 3:58 PM, Sandipan Das wrote:
For added security, the layout of some structures can be
randomized by enabling CONFIG_GCC_PLUGIN_RANDSTRUCT. One
such structure is task_struct. To build BPF programs, we
use
On 11/3/17 3:58 PM, Sandipan Das wrote:
For added security, the layout of some structures can be
randomized by enabling CONFIG_GCC_PLUGIN_RANDSTRUCT. One
such structure is task_struct. To build BPF programs, we
use Clang which does not support this feature. So, if we
attempt to read a field of a
On Fri, Nov 03, 2017 at 05:52:22PM +0100, Daniel Borkmann wrote:
> On 11/03/2017 03:31 PM, Josef Bacik wrote:
> > On Fri, Nov 03, 2017 at 12:12:13AM +0100, Daniel Borkmann wrote:
> > > Hi Josef,
> > >
> > > one more issue I just noticed, see comment below:
> > >
> > > On 11/02/2017 03:37 PM, Jose
18aaf8a4 ("bpf: move knowledge about post-translation offsets
> > out of verifier")
> > Signed-off-by: Arnd Bergmann
>
> Thanks Arnd! I was hoping to nuke this code before build bots catch up
> to me, didn't work out :)
yeah. Jakub's patches may not make it in time for net-next closing.
so let's use this fix for now.
Acked-by: Alexei Starovoitov
On Thu, Nov 02, 2017 at 05:14:00PM +0100, Arnd Bergmann wrote:
> On Thu, Nov 2, 2017 at 4:59 PM, Alexei Starovoitov
> wrote:
> > On Thu, Nov 02, 2017 at 12:05:52PM +0100, Arnd Bergmann wrote:
> >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> >> in
On Thu, Nov 02, 2017 at 12:05:52PM +0100, Arnd Bergmann wrote:
> The bpf_verifer_ops array is generated dynamically and may be
> empty depending on configuration, which then causes an out
> of bounds access:
>
> kernel/bpf/verifier.c: In function 'bpf_check':
> kernel/bpf/verifier.c:4320:29: error
On 11/2/17 7:54 AM, Roman Gushchin wrote:
+#define DEV_BPF_ACC_MKNOD (1ULL << 0)
+#define DEV_BPF_ACC_READ (1ULL << 1)
+#define DEV_BPF_ACC_WRITE (1ULL << 2)
+
+#define DEV_BPF_DEV_BLOCK (1ULL << 0)
+#define DEV_BPF_DEV_CHAR (1ULL << 1)
+
all macros in bpf.h start wit
On Wed, Nov 01, 2017 at 03:59:48PM +0200, Michael S. Tsirkin wrote:
> On Wed, Nov 01, 2017 at 09:02:03PM +0800, Jason Wang wrote:
> >
> >
> > On 2017年11月01日 00:45, Michael S. Tsirkin wrote:
> > > > +static void __tun_set_steering_ebpf(struct tun_struct *tun,
> > > > +
Bacik
Acked-by: Alexei Starovoitov
+++ b/samples/bpf/test_override_return.sh
@@ -0,0 +1,15 @@
+#!/bin/bash
+
+rm -f testfile.img
+dd if=/dev/zero of=testfile.img bs=1M seek=1000 count=1
+DEVICE=$(losetup --show -f testfile.img)
+mkfs.btrfs -f $DEVICE
+mkdir tmpmnt
+./tracex7 $DEVICE
+if [ $?
injection for all of our code
paths.
Signed-off-by: Josef Bacik
Both bpf and tracing bits look great to me.
Acked-by: Alexei Starovoitov
On Wed, Nov 01, 2017 at 09:55:24AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 01, 2017 at 09:27:43AM +0100, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Wed, Nov 01, 2017 at 06:15:54PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of
On 10/31/17 8:45 AM, Josef Bacik wrote:
From: Josef Bacik
Error injection is sloppy and very ad-hoc. BPF could fill this niche
perfectly with it's kprobe functionality. We could make sure errors are
only triggered in specific call chains that we care about with very
specific situations. Acco
On 10/31/17 6:55 PM, David Miller wrote:
From: Josef Bacik
Date: Tue, 31 Oct 2017 11:45:55 -0400
v1->v2:
- moved things around to make sure that bpf_override_return could really only be
used for an ftrace kprobe.
- killed the special return values from trace_call_bpf.
- renamed pc_modified t
On 10/30/17 2:19 PM, Josef Bacik wrote:
+
+rm -f testfile.img
+dd if=/dev/zero of=testfile.img bs=1M seek=1000 count=1
+DEVICE=$(losetup --show -f testfile.img)
+mkfs.btrfs -f $DEVICE
+mkdir tmpmnt
+./tracex7 $DEVICE
+if [ $? -eq 0 ]
+then
+ echo "SUCCESS!"
+else
+ echo "FAILED!"
+fi
On 10/30/17 2:19 PM, Josef Bacik wrote:
From: Josef Bacik
Error injection is sloppy and very ad-hoc. BPF could fill this niche
perfectly with it's kprobe functionality. We could make sure errors are
only triggered in specific call chains that we care about with very
specific situations. Acco
On Tue, Oct 24, 2017 at 11:53:20AM +0800, Herbert Xu wrote:
> On Mon, Oct 23, 2017 at 10:50:43PM -0500, Gustavo A. R. Silva wrote:
> >
> > Quoting Herbert Xu :
> >
> > >On Mon, Oct 23, 2017 at 01:18:57PM -0500, Gustavo A. R. Silva wrote:
> > >>Use BUG_ON instead of if condition followed by BUG.
>
On Fri, Oct 20, 2017 at 11:57:48PM +0800, j...@suse.com wrote:
> On Fri, Oct 20, 2017 at 09:08:48AM +0100, David Howells wrote:
> > Hi Joey,
> >
> > Should I just lock down sys_bpf() entirely for now? We can always free it
> > up
> > somewhat later.
> >
> > David
>
> OK~~ Please just remove my
On Thu, Oct 19, 2017 at 11:48:34PM +0100, David Howells wrote:
> Alexei Starovoitov wrote:
>
> > > @@ -65,6 +65,11 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size,
> > > const void *, unsafe_ptr)
> > > {
> > > int ret;
>
On Thu, Oct 19, 2017 at 03:52:49PM +0100, David Howells wrote:
> From: Chun-Yi Lee
>
> There are some bpf functions can be used to read kernel memory:
> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
> private keys in kernel memory (e.g. the hibernation image signing key)
On Wed, Oct 18, 2017 at 7:22 AM, Daniel Borkmann wrote:
>
> Higher prio imo would be to make the allocation itself faster
> though, I remember we talked about this back in May wrt hashtable,
> but I kind of lost track whether there was an update on this in
> the mean time. ;-)
new percpu allocato
enly assumed __GFP_NOWARN would work, so
> no changes needed to their actual __alloc_percpu_gfp() calls
> which use the flag already.
>
> Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
ed-by: Mark Rutland
> Reported-by: Shankara Pailoor
> Reported-by: Richard Weinberger
> Signed-off-by: Daniel Borkmann
> Cc: John Fastabend
Acked-by: Alexei Starovoitov
for __GFP_NOWARN and using it in bpf is much cleaner
fix that avoids layering violations.
Acked-by: Alexei Starovoitov
601 - 700 of 2283 matches
Mail list logo
