Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Tue, Feb 6, 2024 at 8:42 AM <dthaler1968@xxxxxxxxxxxxxx> wrote: > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi > > > <jose.marchesi@xxxxxxxxxx> wrote: > > > > > clang generates BPF code with opcode 0x8d (BPF_CALL | BPF_X, > > > > > which it calls "callx"), when compiling with -O0 or -O1. Of > > > > > course -O2 is recommended, but if anyone later defines opcode > > > > > 0x8d for anything other than what clang means by it, it could cause > problems. > > > > > > > > GCC also generates BPF_CALL|BPF_X also named callx, but only if > > > > the experimental -mxbpf option is passed to the compiler. > > > > > > > > I recommend this particular encoding to be specifically reserved > > > > for a future `call REG' for when/if a time comes when the BPF > > > > verifier supports some form of indirect calls. > > > > > > +1. > > > Same thinking from llvm pov. > > > CALL|X is what we will use when the kernel supports indirect calls. > > > I think it means we need to add a 'reserved' category to the spec. > > > > My reading of this thread is that there seems to be consensus that: > > 1) CALL|X should have an entry in the IANA registry with its own > > conformance group, > > 2) The intended meaning is understood, > > 3) clang and gcc both implement it already with the intended meaning, > > 4) The Linux kernel might support it someday. > > > > I'd propose we make it its own conformance group called "callx", which > > of course the Linux kernel does not yet support, but clang and gcc do. > > > > Rationale: > > * There may be other instructions reserved over time in the future so > > using a more specific name than just "reserved" is good since later > > additions require new groups with different names. This also now makes me think we should probably rename the "legacy" conformance group to "packet" for similar reasons. It's the status (Historical) of the group rather than the name that actually makes it legacy. > > * Defining it now with the meaning already implemented by clang & gcc > > means that no changes are needed later once Linux supports it. > > * ebpf-for-windows is likely to start supporting it in the very near future > > as a result of this thread. There is already a github pull request under > > review to add support for it in the PREVAIL verifier. > > All makes sense to me. > Could you share a prevail pull link? > I'm curious what it means to support it in that verifier? https://github.com/vbpf/ebpf-verifier/pull/584 I don't know yet whether it will be accepted in the current form, but the proposed approach is basically: * Fail verification unless the register is known to always hold a single integer value at the time of the instruction. This covers the common case. * Using the single integer, do the same verifier checks as would have been done with the normal BPF_CALL instruction. * It's only implemented for src = 0x0 so far since PREVAIL doesn't yet support src = 0x1 or 0x2 (there's separate github issues tracking those), but the mechanism for callx would be the same for those once they're implemented. Dave
