lkml.org 
[lkml]   [2013]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH tip 3/5] Extended BPF (64-bit BPF) design document
From
Date

Alexei Starovoitov <ast@plumgrid.com> writes:

> [...]
>> Having EBPF code manipulating pointers - or kernel memory - directly
>> seems like a nonstarter. However, per your subsequent paragraph it
>> sounds like pointers are a special type at which point it shouldn't
>> matter at the EBPF level how many bytes it takes to represent it?
>
> bpf_check() will track every register through every insn.
> If pointer is stored in the register, it will know what type
> of pointer it is and will allow '*reg' operation only if pointer is valid.
> [...]
> BPF program actually can manipulate kernel memory directly
> when checker guarantees that it is safe to do so :)

It sounds like this sort of static analysis would have difficulty with
situations such as:

- multiple levels of indirection

- conditionals (where it can't trace a unique data/type flow for all pointers)

- aliasing (same reason)

- the possibility of bad (or userspace?) pointers arriving as
parameters from the underlying trace events


> For example in tracing filters bpf_context access is restricted to:
> static const struct bpf_context_access ctx_access[MAX_CTX_OFF] = {
> [offsetof(struct bpf_context, regs.di)] = {
> FIELD_SIZEOF(struct bpf_context, regs.di),
> BPF_READ
> },

Are such constraints to be hard-coded in the kernel?


> Over course of development bpf_check() found several compiler bugs.
> I also tried all of sorts of ways to break bpf jail from inside of a
> bpf program, but so far checker catches everything I was able to throw
> at it.

(One can be sure that attackers will chew hard on this interface,
should it become reasonably accessible to userspace, so good job
starting to check carefully!)


- FChE


\
 
 \ /
  Last update: 2013-12-03 22:01    [W:0.146 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site