netdev - Re: [RFC PATCH 2/4] bpf: verifier, do explicit u32 bounds 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: <3f80b587-c5b0-0446-8cbc-eff1758496e9@solarflare.com>
Date:   Tue, 10 Mar 2020 17:12:31 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        John Fastabend <john.fastabend@...il.com>
CC:     <yhs@...com>, <daniel@...earbox.net>, <netdev@...r.kernel.org>,
        <bpf@...r.kernel.org>
Subject: Re: [RFC PATCH 2/4] bpf: verifier, do explicit u32 bounds tracking

On 09/03/2020 23:58, Alexei Starovoitov wrote:> Thinking about it differently... var_off is a bit representation of
> 64-bit register. So that bit representation doesn't really have
> 32 or 16-bit chunks. It's a full 64-bit register. I think all alu32
> and jmp32 ops can update var_off without losing information.
Agreed; AFAICT the 32-bit var_off should always just be the bottom
 32 bits of the full var_off.
In fact, it seems like the only situations where 32-bit bounds are
 needed are (a) the high and low halves of a 64-bit register are
 being used separately, so e.g. r0 = (x << 32) | y with small known
 bounds on y you want to track, or (b) 32-bit signed arithmetic.
(a) doesn't seem like it's in scope to be supported, and (b) should
 (I'm naïvely imagining) only need the s32 bounds, not the u32 or
 var32.

John Fastabend wrote:
> For example, BPF_ADD will do a tnum_add() this is a different
> operation when overflows happen compared to tnum32_add(). Simply
> truncating tnum_add result to 32-bits is not the same operation.
I don't see why.  Overflows from the low (tracked) 32 bits can only
 affect the high 32.  Truncation should be a homomorphism from
 Z_2^n to Z_2^m wrt. both addition and multiplication, and tnums
 are just (a particular class of) subsets of those rings.
Can you construct an example of a tnum addition that breaks the
 homomorphism?

-ed