ISA: BPF_CALL | BPF_X

ISA: BPF_CALL | BPF_X

[dthaler1968]

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.

On the BPF_MSH thread at
https://mailarchive.ietf.org/arch/msg/bpf/ogmS9qFhdBCxC4VrOWL7nzjSiXU/
Alexei wrote regarding BPF_ABS and BPF_IND:
> DW never existed in classic bpf, so abs/ind never had DW flavor.
> If some assembler/compiler decided to "support" them it's on them.
> The standard must not list such things as deprecated. They never existed.

Technically BPF_CALL | BPF_X never existed either, so can be omitted from
the IANA registry.  But given the widespread deployment of clang's
use, and the WG charter statement:
> The BPF working group is initially tasked with documenting the existing
> state of the BPF ecosystem
I could see a potential argument to list it as reserved or something.

Today, the document doesn't reserve it, so it's open for future use for any
purpose.  I just wanted to verify that the WG is ok with not listing it
in the IANA registry, given the above information.

Dave

[Bpf] ISA: BPF_CALL | BPF_X

[dthaler1968=40googlemail.com]

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.

On the BPF_MSH thread at
https://mailarchive.ietf.org/arch/msg/bpf/ogmS9qFhdBCxC4VrOWL7nzjSiXU/
Alexei wrote regarding BPF_ABS and BPF_IND:
> DW never existed in classic bpf, so abs/ind never had DW flavor.
> If some assembler/compiler decided to "support" them it's on them.
> The standard must not list such things as deprecated. They never existed.

Technically BPF_CALL | BPF_X never existed either, so can be omitted from
the IANA registry.  But given the widespread deployment of clang's
use, and the WG charter statement:
> The BPF working group is initially tasked with documenting the existing
> state of the BPF ecosystem
I could see a potential argument to list it as reserved or something.

Today, the document doesn't reserve it, so it's open for future use for any
purpose.  I just wanted to verify that the WG is ok with not listing it
in the IANA registry, given the above information.

Dave


-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] ISA: BPF_CALL | BPF_X

[Jose E. Marchesi]

> 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.

>
> On the BPF_MSH thread at
> https://mailarchive.ietf.org/arch/msg/bpf/ogmS9qFhdBCxC4VrOWL7nzjSiXU/
> Alexei wrote regarding BPF_ABS and BPF_IND:
>> DW never existed in classic bpf, so abs/ind never had DW flavor.
>> If some assembler/compiler decided to "support" them it's on them.
>> The standard must not list such things as deprecated. They never existed.
>
> Technically BPF_CALL | BPF_X never existed either, so can be omitted from
> the IANA registry.  But given the widespread deployment of clang's
> use, and the WG charter statement:
>> The BPF working group is initially tasked with documenting the existing
>> state of the BPF ecosystem
> I could see a potential argument to list it as reserved or something.
>
> Today, the document doesn't reserve it, so it's open for future use for any
> purpose.  I just wanted to verify that the WG is ok with not listing it
> in the IANA registry, given the above information.
>
> Dave

Re: [Bpf] ISA: BPF_CALL | BPF_X

[Jose E. Marchesi]

> 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.

>
> On the BPF_MSH thread at
> https://mailarchive.ietf.org/arch/msg/bpf/ogmS9qFhdBCxC4VrOWL7nzjSiXU/
> Alexei wrote regarding BPF_ABS and BPF_IND:
>> DW never existed in classic bpf, so abs/ind never had DW flavor.
>> If some assembler/compiler decided to "support" them it's on them.
>> The standard must not list such things as deprecated. They never existed.
>
> Technically BPF_CALL | BPF_X never existed either, so can be omitted from
> the IANA registry.  But given the widespread deployment of clang's
> use, and the WG charter statement:
>> The BPF working group is initially tasked with documenting the existing
>> state of the BPF ecosystem
> I could see a potential argument to list it as reserved or something.
>
> Today, the document doesn't reserve it, so it's open for future use for any
> purpose.  I just wanted to verify that the WG is ok with not listing it
> in the IANA registry, given the above information.
>
> Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] ISA: BPF_CALL | BPF_X

[Alexei Starovoitov]

On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
<jose.marchesi@oracle.com> 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.

Re: [Bpf] ISA: BPF_CALL | BPF_X

[Alexei Starovoitov]

On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
<jose.marchesi@oracle.com> 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.

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: [Bpf] ISA: BPF_CALL | BPF_X

[dthaler1968]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: 
> On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
> <jose.marchesi@oracle.com> 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.
* 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.

Dave
 

Re: [Bpf] ISA: BPF_CALL | BPF_X

[dthaler1968=40googlemail.com]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: 
> On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
> <jose.marchesi@oracle.com> 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.
* 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.

Dave
 

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] ISA: BPF_CALL | BPF_X

[Alexei Starovoitov]

On Tue, Feb 6, 2024 at 8:42 AM <dthaler1968@googlemail.com> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
> > <jose.marchesi@oracle.com> 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.
> * 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?

Re: [Bpf] ISA: BPF_CALL | BPF_X

[Alexei Starovoitov]

On Tue, Feb 6, 2024 at 8:42 AM <dthaler1968@googlemail.com> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
> > <jose.marchesi@oracle.com> 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.
> * 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?

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: [Bpf] ISA: BPF_CALL | BPF_X

[dthaler1968]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: 
> On Tue, Feb 6, 2024 at 8:42 AM <dthaler1968@googlemail.com> wrote:
> > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
> > > <jose.marchesi@oracle.com> 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

Re: [Bpf] ISA: BPF_CALL | BPF_X

[dthaler1968=40googlemail.com]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: 
> On Tue, Feb 6, 2024 at 8:42 AM <dthaler1968@googlemail.com> wrote:
> > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > On Tue, Jan 30, 2024 at 11:49 AM Jose E. Marchesi
> > > <jose.marchesi@oracle.com> 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

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf