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: <CAG_fn=VSEw2NvrE=GE4f4H6CAD-6BjUQvz3W06nLmF8tg7CfBA@mail.gmail.com>
Date:   Thu, 13 Dec 2018 13:24:36 +0100
From:   Alexander Potapenko <glider@...gle.com>
To:     mkubecek@...e.cz
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 1:20 PM Michal Kubecek <mkubecek@...e.cz> wrote:
>
> 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?
Yes. Sorry for being unclear.
By default regs[] is uninitialized, so we need to initialize it before
using the register values.
I am also wondering if it's possible to simply copy the uninitialized
register values from regs[] to the userspace via maps.
> Michal Kubecek



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg