llvm dev - Sep 2017 - [iovisor-dev] [PATCH RFC 0/4] Initial 32-bit eBPF encoding support

On Sat, Sep 23, 2017 at 10:41:25AM +0200, Jakub Kicinski
wrote:
> > > Thinking about next steps - do we expect the 32b operations to
clear the
> > > upper halves of the registers?  The interpreter does it, and so
does
> > > x86.  I don't think we can load 32bit-only programs on 64bit
hosts, so
> > > we would need some form of data flow analysis in the kernel to
prune
> > > the zeroing for 32bit offload targets.  Is that correct?  
> > 
> > Could you contrive an example to show the problem? If I understand 
> > correctly, you most worried that some natural sign extension is gone
> > with "clearing the upper 32-bit register" and such clearing
may make
> > some operation, esp. memory operation not correct in 64-bit machine?
> 
> Hm.  Perhaps it's a blunder on my side, but let's take:
> 
>   r1 = ~0ULL
>   w1 = 0
>   # use r1
> 
> on x86 and the interpreter, the w1 = 0 will clear upper 32bits, so r1
> ends up as 0.  32b arches may translate this to something like:
> 
>   # r1 = ~0ULL
>   r1.lo = ~0
>   r1.hi = ~0
>   # w1 = 0
>   r1.lo = 0
>   # r1.hi not touched
> 
> which will obviously result in r1 == 0xffffffff00000000.  LLVM should
> not assume r1.hi is cleared, but I'm not sure this is a strong enough
> argument.
llvm will assume that r1.hi is cleared. 32-bit subregisters were
defined on the day one. See Documentation/networking/filter.txt
"All eBPF registers are 64-bit with 32-bit lower
 subregisters that zero-extend into 64-bit if they are being written to."
If some JIT is not clearing upper bits, it's a bug or it's being too
smart :)
We can add analysis pass to the verifier to help JITs in such case.