[Bpf] Re: Undefined behavior in eBPF RFC

[Tristan Itschner <[e-mail]>]

Hi there again,

first of all, I would like to apologize for the unprofessional tune in 
my initial message. Sorry for realizing that only in retrospect.

My concern was as follows: In pipelined RTL CPU implementations, it 
makes a significant difference, whether unaligned or only aligned loads 
and stores are allowed. Implementing unaligned loads requires quite a 
bit more logic, especially when optimizing certain fast cases. Knowing 
from my background that cBPF requires unaligned loads, I assumed that 
eBPF does the same in principle. My concern was that someone only 
implements aligned loads and stores in an eBPF hardware implementation, 
because it is not explicitly stated. In fact, the word alignment does 
not appear at all in the RFC. This would break jitting cBPF programs to 
eBPF programs, because then the behavior of unaligned loads is 
undefined. But you would not notice it in practice if you were only 
using C programs, because the compiler only generates aligned loads and 
store (unless you tell it to do otherwise). This is only an issue in the 
context of processing packets with variable header length, such as is 
done with cBPF. But cBPF is enough for that of course.

However, I have realized now by re-reading the spec, that eBPF allows 
only aligned loads at all (I misread the C-like syntax), which of course 
makes a lot more sense for the actual use-cases of eBPF.

I hope you do understand now where I was initial coming from. I'm a big 
fan of both BPF implementations, so please don't get me wrong. But my 
concern is unfounded besides being understood as a suggestion to clarify 
that behavior in the RFC.

Best regards, Tristan Itschner

On 12/18/25 21:47, Tristan Itschner wrote:
> Hi there,
>
> hardware developer here!
>
> I have some comments for your request for comments Nr. 9669:
>
> The ratified RFC does not define alignment restrictions for load and 
> store instructions (including atomics).
>
> This is really quite a bummer (undefined behavior) and it may lead to 
> incompatible hardware implementations.
>
> You might want to get that sorted out rather soon. It should be rather 
> obvious what the requirements are, especially considering cBPF support.
>
> Best regards, Tristan Itschner
>