Messages in this thread | | | Subject | Re: [RFC PATCH tip 3/5] Extended BPF (64-bit BPF) design document | From | (Frank Ch. Eigler) | Date | Tue, 03 Dec 2013 15:41:28 -0500 |
| |
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
| |