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  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:   Fri, 29 May 2020 10:53:20 +0200
From:   Dmitry Vyukov <>
To:     Edward Cree <>
Cc:     Alexei Starovoitov <>,
        Alexander Potapenko <>,
        Daniel Borkmann <>,
        Michal Kubecek <>,
        Alexei Starovoitov <>,
        Networking <>
Subject: Re: Self-XORing BPF registers is undefined behavior

On Fri, May 29, 2020 at 10:46 AM Edward Cree <> 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.

Powered by blists - more mailing lists