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]

Date:   Thu, 13 Dec 2018 13:20:04 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     ast@...nel.org, daniel@...earbox.net,
        Dmitriy Vyukov <dvyukov@...gle.com>,
        Networking <netdev@...r.kernel.org>
Subject: Re: Self-XORing BPF registers is undefined behavior

On Thu, Dec 13, 2018 at 12:59:36PM +0100, Michal Kubecek wrote:
> On Thu, Dec 13, 2018 at 12:00:59PM +0100, Alexander Potapenko wrote:
> > Hi BPF maintainers,
> > 
> > some time ago KMSAN found an issue in BPF code which we decided to
> > suppress at that point, but now I'd like to bring it to your
> > attention.
> > Namely, some BPF programs may contain instructions that XOR a register
> > with itself.
> > This effectively results in the following C code:
> >   regs[BPF_REG_A] = regs[BPF_REG_A] ^ regs[BPF_REG_A];
> > or
> >   regs[BPF_REG_X] = regs[BPF_REG_X] ^ regs[BPF_REG_X];
> > being executed.
> > 
> > According to the C11 standard this is undefined behavior, so KMSAN
> > reports an error in this case.
> 
> Can you quote the part of the standard saying this is undefined
> behavior? I couldn't find anything else than
> 
>   If the value being stored in an object is read from another object
>   that overlaps in any way the storage of the first object, then the
>   overlap shall be exact and the two objects shall have qualified or
>   unqualified versions of a compatible type; otherwise, the behavior
>   is undefined.
> 
> (but I only have a draft for obvious reasons). I'm not sure what exactly
> they mean by "exact overlap" and the standard doesn't seem to define
> the term but if the two objects are actually the same, they certainly
> have compatible types.


I think I understand now. You didn't want to say that the statement

  regs[BPF_REG_A] = regs[BPF_REG_A] ^ regs[BPF_REG_A];

as such is undefined behavior but that it's UB when regs[BPF_REG_A] is
uninitialized. Right?

Michal Kubecek