Alexei Starovoitov <a...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
