[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181213115936.GG21324@unicorn.suse.cz>
Date: Thu, 13 Dec 2018 12:59:36 +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: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.
>
> Do you think it's feasible to explicitly initialize the register
> values like it's done here:
> https://github.com/google/kmsan/commit/813c0f3d45ebfa321d70b4b06cc054518dd1d90d
> ?
Wouldn't that mean we still end up with undefined behavior whenever
a cBPF program explicitly uses the xor with itself to zero a register?
Michal Kubecek
Powered by blists - more mailing lists