netdev - Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework value tracking

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 linux-hardening linux-cve-announce 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]

Message-Id: <E65DE75F-FC5F-41BC-9F7B-C03D324D8C6F@gmail.com>
Date:   Thu, 6 Jul 2017 14:21:46 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     davem@...emloft.net,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        iovisor-dev <iovisor-dev@...ts.iovisor.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [iovisor-dev] [PATCH v3 net-next 02/12] bpf/verifier: rework
 value tracking

Edward Cree via iovisor-dev <iovisor-dev@...ts.iovisor.org> wrote:

> Tracks value alignment by means of tracking known & unknown bits.
> Tightens some min/max value checks and fixes a couple of bugs therein.
> If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES,
> treat the pointer as an unknown scalar and try again, because we might be
> able to conclude something about the result (e.g. pointer & 0x40 is either
> 0 or 0x40).
> 
> Signed-off-by: Edward Cree <ecree@...arflare.com>
> ---
> include/linux/bpf.h          |   34 +-
> include/linux/bpf_verifier.h |   40 +-
> include/linux/tnum.h         |   79 ++
> kernel/bpf/Makefile          |    2 +-
> kernel/bpf/tnum.c            |  163 ++++
> kernel/bpf/verifier.c        | 1692 ++++++++++++++++++++++++------------------
> 6 files changed, 1235 insertions(+), 775 deletions(-)

(RESEND)

I find it a bit surprising that such huge changes that can affect security
and robustness are performed in one patch. Personally, I cannot comprehend
all of these changes. In addition, I think that it is valuable to describe
in detail the bugs that the patch solves and when they were introduced.

I can bring up some concerns regarding inconsistencies in offset checks and
size, not spilling SCALAR and my wish not to limit packet size. However,
when the patch is that big, I think it is useless.

Nadav