Re: bpf: undefined shift in __bpf_prog_run

On Fri, Dec 04, 2015 at 12:44:09PM -0800, Kostya Serebryany wrote:

On Fri, Dec 4, 2015 at 12:35 PM, Alexei Starovoitov <
alexei.starovoitov@gmail.com> wrote:

quoted

On Fri, Dec 04, 2015 at 08:48:57PM +0100, Dmitry Vyukov wrote:

quoted

For example, a compiler can assume that result of left shift is larger
or equal to first operand, which in turn can allow it to elide some
bounds check in code, which in turn can lead to an exploit. I am not
saying that this particular pattern is present in the code, what I
want to say is that such undefined behaviors can lead to very
unpredictable and unexpected consequences.

Within bpf it cannot.
shift is not used in any memory or bounds operations.
so reg <<= 1234 cannot be exploited.

I afraid this is not that simple.
In C, undefined behavior applies to the entire program, not just to a
single instruction.
My favorite example:
http://stackoverflow.com/questions/7682477/why-does-integer-overflow-on-x86-with-gcc-cause-an-infinite-loop
Here an undefined behavior in one instruction causes *other* instructions
to misbehave.

that's actually not related example. There compiler takes advantage of undefined
behavior which is very typical for compiler to do.
for(int i = 0; i < 100; i++)
and
for(unsigned int i = 0; i < 100; i++)
are very different loops from compiler point of view.

but that is not applicable in bpf world.
there are no loops in bpf in the first place.