[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180213225147.vdpwnv7rjxsw4tj5@ast-mbp.dhcp.thefacebook.com>
Date: Tue, 13 Feb 2018 14:51:49 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Edward Cree <ecree@...arflare.com>
Cc: John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH bpf-next 0/2] bpf/verifier: simplify subprog tracking
On Tue, Feb 13, 2018 at 06:14:53PM +0000, Edward Cree wrote:
>
> Anyway, that's my design, I hope it wasn't _too_ horrifying, and I hope to
> have some RFC patches in the next week or so.
I prefer John's approach since it fits into my thinking how verifier should evolve
and follows the outline compilers have been developed for generations.
imo "divide and conquer" should be a center piece of verifier design.
Unfortunately we didn't follow this thinking everywhere and ended up with mess
in few places, but we need to move into that direction.
In practice it means splitting verifier into distinct passes that do one job
and do it well.
In John's proposal it's:
- function call boundaries
- basic block detection
- control flow build
- dom tree build
- existing do_check pass
- etc
I'm working on splitting do_check() further, since reserved fields check
should have been done as separate pass instead of imbedded into do_check().
Also since you're refusing to cleanup [su]minmax I'd have to find
time to do it myself and to revive the work I've started here:
https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?h=verif_simplif_v1
_before_ any significant amount of code will land in the verifier,
so please bare with me.
At this point all new verifier code will be deferred until [su]minmax
issues are resolved.
Powered by blists - more mailing lists