lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ