netdev - Re: Self-XORing BPF registers is undefined behavior

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: <CACT4Y+bs-eiJQQjofAAo0oLNPzosOmhMuJOLHP0sShQScGKX7A@mail.gmail.com>
Date:   Fri, 29 May 2020 10:53:20 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Michal Kubecek <mkubecek@...e.cz>,
        Alexei Starovoitov <ast@...nel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: Self-XORing BPF registers is undefined behavior

On Fri, May 29, 2020 at 10:46 AM Edward Cree <ecree@...arflare.com> wrote:
>
> On 29/05/2020 07:14, Dmitry Vyukov wrote:
> >> (In C99 it gets subtler because an 'indeterminate value' is
> >>  defined to be 'either a valid value or a trap representation',
> >>  so arguably the compiler can only do this stuff if it _has_
> >>  trap representations for the type in question.)
> > Interesting. Are you sure that's the meaning of 'indeterminate value'?
> > My latest copy of the standard says:
> >
> > 3.19.2
> > 1 indeterminate value
> > either an unspecified value or a trap representation
> Yes, but (from N1256):
> | 3.17.3
> | unspecified value
> | valid value of the relevant type where this International Standard
> | imposes no requirements on which value is chosen in any instance
> | NOTE An unspecified value cannot be a trap representation
>
> > My reading of this would be that this only prevents things from
> > exploding in all possible random ways (like formatting drive). The
> > effects are only reduced to either getting a random value, or a trap
> > on access to the value. Both of these do not seem to be acceptable for
> > a bpf program.
> A random value, XORed with itself, produces 0, which is what we want.
> (XORing a trap representation with itself, of course, produces a trap.)
>
> So it'd be fine *unless* the 'in any instance' language can be read as
>  allowing the uninitialised object to have *different* random values on
>  separate accesses.

Ah, I see. I thought the result of such XOR is redefined to be an
indeterminate value rather than UB.
Thanks