ISA: BPF_MSH and deprecated packet access instructions

ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968]

Under "Load and store instructions", various mode modifiers are documented.
I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in 
various projects, including Linux, BSD, seccomp, etc. and is even documented
in various books such as
https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover

Should we document it as deprecated and add it to the set of deprecated
instructions (the legacy conformance group) like BPF_ABS and BPF_IND
already are?

Also, for purposes of the IANA registry of instructions where we list which
opcodes are "(deprecated, implementation-specific)", I currently list all
possible BPF_ABS and BPF_IND opcodes regardless of whether they were
ever used (I didn't check which were used and which might not have been),
so I could just list all possible BPF_MSH opcodes similarly.  But if we know
that some were never used then I don't need to do so, so I guess I should
ask:
do we have a list of which combinations were actually used or should we
continue to just deprecate all combinations?

As an example,
https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
Other sources like the book page referenced above, and the BSD man page,
list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368

So, should we list the DW variants as deprecated, or never assigned?
Should we list the H, W, and LD variants as deprecated, or never assigned?

What about DW and LDX variants of BPF_IND and BPF_ABS?

Dave

[Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968=40googlemail.com]

Under "Load and store instructions", various mode modifiers are documented.
I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in 
various projects, including Linux, BSD, seccomp, etc. and is even documented
in various books such as
https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover

Should we document it as deprecated and add it to the set of deprecated
instructions (the legacy conformance group) like BPF_ABS and BPF_IND
already are?

Also, for purposes of the IANA registry of instructions where we list which
opcodes are "(deprecated, implementation-specific)", I currently list all
possible BPF_ABS and BPF_IND opcodes regardless of whether they were
ever used (I didn't check which were used and which might not have been),
so I could just list all possible BPF_MSH opcodes similarly.  But if we know
that some were never used then I don't need to do so, so I guess I should
ask:
do we have a list of which combinations were actually used or should we
continue to just deprecate all combinations?

As an example,
https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
Other sources like the book page referenced above, and the BSD man page,
list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368

So, should we list the DW variants as deprecated, or never assigned?
Should we list the H, W, and LD variants as deprecated, or never assigned?

What about DW and LDX variants of BPF_IND and BPF_ABS?

Dave


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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

We do not support any load/sotre instruction with mode BPF_MSH in
binutils.  Should we do so?  What are these?

> Under "Load and store instructions", various mode modifiers are documented.
> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in 
> various projects, including Linux, BSD, seccomp, etc. and is even documented
> in various books such as
> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover
>
> Should we document it as deprecated and add it to the set of deprecated
> instructions (the legacy conformance group) like BPF_ABS and BPF_IND
> already are?
>
> Also, for purposes of the IANA registry of instructions where we list which
> opcodes are "(deprecated, implementation-specific)", I currently list all
> possible BPF_ABS and BPF_IND opcodes regardless of whether they were
> ever used (I didn't check which were used and which might not have been),
> so I could just list all possible BPF_MSH opcodes similarly.  But if we know
> that some were never used then I don't need to do so, so I guess I should
> ask:
> do we have a list of which combinations were actually used or should we
> continue to just deprecate all combinations?
>
> As an example,
> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
> Other sources like the book page referenced above, and the BSD man page,
> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
>
> So, should we list the DW variants as deprecated, or never assigned?
> Should we list the H, W, and LD variants as deprecated, or never assigned?
>
> What about DW and LDX variants of BPF_IND and BPF_ABS?
>
> Dave

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

We do not support any load/sotre instruction with mode BPF_MSH in
binutils.  Should we do so?  What are these?

> Under "Load and store instructions", various mode modifiers are documented.
> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in 
> various projects, including Linux, BSD, seccomp, etc. and is even documented
> in various books such as
> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover
>
> Should we document it as deprecated and add it to the set of deprecated
> instructions (the legacy conformance group) like BPF_ABS and BPF_IND
> already are?
>
> Also, for purposes of the IANA registry of instructions where we list which
> opcodes are "(deprecated, implementation-specific)", I currently list all
> possible BPF_ABS and BPF_IND opcodes regardless of whether they were
> ever used (I didn't check which were used and which might not have been),
> so I could just list all possible BPF_MSH opcodes similarly.  But if we know
> that some were never used then I don't need to do so, so I guess I should
> ask:
> do we have a list of which combinations were actually used or should we
> continue to just deprecate all combinations?
>
> As an example,
> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
> Other sources like the book page referenced above, and the BSD man page,
> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
>
> So, should we list the DW variants as deprecated, or never assigned?
> Should we list the H, W, and LD variants as deprecated, or never assigned?
>
> What about DW and LDX variants of BPF_IND and BPF_ABS?
>
> Dave

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

> We do not support any load/sotre instruction with mode BPF_MSH in
> binutils.  Should we do so?  What are these?
>
>> Under "Load and store instructions", various mode modifiers are documented.
>> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in 
>> various projects, including Linux, BSD, seccomp, etc. and is even documented
>> in various books such as
>> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
>> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover
>>
>> Should we document it as deprecated and add it to the set of deprecated
>> instructions (the legacy conformance group) like BPF_ABS and BPF_IND
>> already are?
>>
>> Also, for purposes of the IANA registry of instructions where we list which
>> opcodes are "(deprecated, implementation-specific)", I currently list all
>> possible BPF_ABS and BPF_IND opcodes regardless of whether they were
>> ever used (I didn't check which were used and which might not have been),
>> so I could just list all possible BPF_MSH opcodes similarly.  But if we know
>> that some were never used then I don't need to do so, so I guess I should
>> ask:
>> do we have a list of which combinations were actually used or should we
>> continue to just deprecate all combinations?
>>
>> As an example,
>> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
>> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
>> Other sources like the book page referenced above, and the BSD man page,
>> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
>> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
>>
>> So, should we list the DW variants as deprecated, or never assigned?
>> Should we list the H, W, and LD variants as deprecated, or never assigned?
>>
>> What about DW and LDX variants of BPF_IND and BPF_ABS?

These we support:

  /* Absolute load instructions, designed to be used in socket filters.  */
  {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
  {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
  {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
  {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},

  /* Generic load instructions (to register.)  */
  {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
  {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
  {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
  {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},


>> Dave

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

> We do not support any load/sotre instruction with mode BPF_MSH in
> binutils.  Should we do so?  What are these?
>
>> Under "Load and store instructions", various mode modifiers are documented.
>> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in 
>> various projects, including Linux, BSD, seccomp, etc. and is even documented
>> in various books such as
>> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
>> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover
>>
>> Should we document it as deprecated and add it to the set of deprecated
>> instructions (the legacy conformance group) like BPF_ABS and BPF_IND
>> already are?
>>
>> Also, for purposes of the IANA registry of instructions where we list which
>> opcodes are "(deprecated, implementation-specific)", I currently list all
>> possible BPF_ABS and BPF_IND opcodes regardless of whether they were
>> ever used (I didn't check which were used and which might not have been),
>> so I could just list all possible BPF_MSH opcodes similarly.  But if we know
>> that some were never used then I don't need to do so, so I guess I should
>> ask:
>> do we have a list of which combinations were actually used or should we
>> continue to just deprecate all combinations?
>>
>> As an example,
>> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
>> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
>> Other sources like the book page referenced above, and the BSD man page,
>> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
>> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
>>
>> So, should we list the DW variants as deprecated, or never assigned?
>> Should we list the H, W, and LD variants as deprecated, or never assigned?
>>
>> What about DW and LDX variants of BPF_IND and BPF_ABS?

These we support:

  /* Absolute load instructions, designed to be used in socket filters.  */
  {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
  {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
  {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
  {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
   BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},

  /* Generic load instructions (to register.)  */
  {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
  {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
  {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
  {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr %o16 )",
   BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},


>> Dave

Re: ISA: BPF_MSH and deprecated packet access instructions

[Yonghong Song]

On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote:
> Under "Load and store instructions", various mode modifiers are documented.
> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in
> various projects, including Linux, BSD, seccomp, etc. and is even documented
> in various books such as
> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover
>
> Should we document it as deprecated and add it to the set of deprecated
> instructions (the legacy conformance group) like BPF_ABS and BPF_IND
> already are?
>
> Also, for purposes of the IANA registry of instructions where we list which
> opcodes are "(deprecated, implementation-specific)", I currently list all
> possible BPF_ABS and BPF_IND opcodes regardless of whether they were
> ever used (I didn't check which were used and which might not have been),
> so I could just list all possible BPF_MSH opcodes similarly.  But if we know
> that some were never used then I don't need to do so, so I guess I should
> ask:
> do we have a list of which combinations were actually used or should we
> continue to just deprecate all combinations?
>
> As an example,
> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
> Other sources like the book page referenced above, and the BSD man page,
> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368

 From kernel source code (net/core/filter.c), the only supported format is
    BPF_LDX | BPF_MSH | BPF_B

The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF)
is converted to BPF insn set. If the current BPF program has this insn,
verifier will reject it and bpf kernel interpreter does not support this
insn either. So technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported
by BPF program.

>
> So, should we list the DW variants as deprecated, or never assigned?
> Should we list the H, W, and LD variants as deprecated, or never assigned?
>
> What about DW and LDX variants of BPF_IND and BPF_ABS?
>
>
>

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Yonghong Song]

On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote:
> Under "Load and store instructions", various mode modifiers are documented.
> I notice that BPF_MSH (0xa0) is not documented, but appears to be in use in
> various projects, including Linux, BSD, seccomp, etc. and is even documented
> in various books such as
> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Uncovere
> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec=frontcover
>
> Should we document it as deprecated and add it to the set of deprecated
> instructions (the legacy conformance group) like BPF_ABS and BPF_IND
> already are?
>
> Also, for purposes of the IANA registry of instructions where we list which
> opcodes are "(deprecated, implementation-specific)", I currently list all
> possible BPF_ABS and BPF_IND opcodes regardless of whether they were
> ever used (I didn't check which were used and which might not have been),
> so I could just list all possible BPF_MSH opcodes similarly.  But if we know
> that some were never used then I don't need to do so, so I guess I should
> ask:
> do we have a list of which combinations were actually used or should we
> continue to just deprecate all combinations?
>
> As an example,
> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.c#L68
> lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but not DW).
> Other sources like the book page referenced above, and the BSD man page,
> list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources such as
> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368

 From kernel source code (net/core/filter.c), the only supported format is
    BPF_LDX | BPF_MSH | BPF_B

The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF)
is converted to BPF insn set. If the current BPF program has this insn,
verifier will reject it and bpf kernel interpreter does not support this
insn either. So technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported
by BPF program.

>
> So, should we list the DW variants as deprecated, or never assigned?
> Should we list the H, W, and LD variants as deprecated, or never assigned?
>
> What about DW and LDX variants of BPF_IND and BPF_ABS?
>
>
>

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

RE: ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968]

> -----Original Message-----
> From: Yonghong Song <yonghong.song@linux.dev>
> Sent: Saturday, January 27, 2024 4:27 PM
> To: dthaler1968@googlemail.com
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: Re: ISA: BPF_MSH and deprecated packet access instructions
> 
> 
> On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote:
> > Under "Load and store instructions", various mode modifiers are
> documented.
> > I notice that BPF_MSH (0xa0) is not documented, but appears to be in
> > use in various projects, including Linux, BSD, seccomp, etc. and is
> > even documented in various books such as
> >
> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un
> > covere
> >
> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec
> =frontco
> > ver
> >
> > Should we document it as deprecated and add it to the set of
> > deprecated instructions (the legacy conformance group) like BPF_ABS
> > and BPF_IND already are?
> >
> > Also, for purposes of the IANA registry of instructions where we list
> > which opcodes are "(deprecated, implementation-specific)", I currently
> > list all possible BPF_ABS and BPF_IND opcodes regardless of whether
> > they were ever used (I didn't check which were used and which might
> > not have been), so I could just list all possible BPF_MSH opcodes
> > similarly.  But if we know that some were never used then I don't need
> > to do so, so I guess I should
> > ask:
> > do we have a list of which combinations were actually used or should
> > we continue to just deprecate all combinations?
> >
> > As an example,
> > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.
> > c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but
> > not DW).
> > Other sources like the book page referenced above, and the BSD man
> > page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources
> > such as
> > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
> 
>  From kernel source code (net/core/filter.c), the only supported format is
>     BPF_LDX | BPF_MSH | BPF_B
> 
> The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is
> converted to BPF insn set. If the current BPF program has this insn, verifier will
> reject it and bpf kernel interpreter does not support this insn either. So
> technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program.
>
> > So, should we list the DW variants as deprecated, or never assigned?
> > Should we list the H, W, and LD variants as deprecated, or never assigned?

Thanks for confirming.  I think the doc is ok as is for this part.

> > What about DW and LDX variants of BPF_IND and BPF_ABS?

What about this question?

Dave

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968=40googlemail.com]

> -----Original Message-----
> From: Yonghong Song <yonghong.song@linux.dev>
> Sent: Saturday, January 27, 2024 4:27 PM
> To: dthaler1968@googlemail.com
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: Re: ISA: BPF_MSH and deprecated packet access instructions
> 
> 
> On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote:
> > Under "Load and store instructions", various mode modifiers are
> documented.
> > I notice that BPF_MSH (0xa0) is not documented, but appears to be in
> > use in various projects, including Linux, BSD, seccomp, etc. and is
> > even documented in various books such as
> >
> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un
> > covere
> >
> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec
> =frontco
> > ver
> >
> > Should we document it as deprecated and add it to the set of
> > deprecated instructions (the legacy conformance group) like BPF_ABS
> > and BPF_IND already are?
> >
> > Also, for purposes of the IANA registry of instructions where we list
> > which opcodes are "(deprecated, implementation-specific)", I currently
> > list all possible BPF_ABS and BPF_IND opcodes regardless of whether
> > they were ever used (I didn't check which were used and which might
> > not have been), so I could just list all possible BPF_MSH opcodes
> > similarly.  But if we know that some were never used then I don't need
> > to do so, so I guess I should
> > ask:
> > do we have a list of which combinations were actually used or should
> > we continue to just deprecate all combinations?
> >
> > As an example,
> > https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.
> > c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but
> > not DW).
> > Other sources like the book page referenced above, and the BSD man
> > page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources
> > such as
> > https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
> 
>  From kernel source code (net/core/filter.c), the only supported format is
>     BPF_LDX | BPF_MSH | BPF_B
> 
> The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is
> converted to BPF insn set. If the current BPF program has this insn, verifier will
> reject it and bpf kernel interpreter does not support this insn either. So
> technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program.
>
> > So, should we list the DW variants as deprecated, or never assigned?
> > Should we list the H, W, and LD variants as deprecated, or never assigned?

Thanks for confirming.  I think the doc is ok as is for this part.

> > What about DW and LDX variants of BPF_IND and BPF_ABS?

What about this question?

Dave

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

Re: ISA: BPF_MSH and deprecated packet access instructions

[Yonghong Song]

On 1/27/24 4:53 PM, dthaler1968@googlemail.com wrote:
>> -----Original Message-----
>> From: Yonghong Song <yonghong.song@linux.dev>
>> Sent: Saturday, January 27, 2024 4:27 PM
>> To: dthaler1968@googlemail.com
>> Cc: bpf@ietf.org; bpf@vger.kernel.org
>> Subject: Re: ISA: BPF_MSH and deprecated packet access instructions
>>
>>
>> On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote:
>>> Under "Load and store instructions", various mode modifiers are
>> documented.
>>> I notice that BPF_MSH (0xa0) is not documented, but appears to be in
>>> use in various projects, including Linux, BSD, seccomp, etc. and is
>>> even documented in various books such as
>>>
>> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un
>>> covere
>>>
>> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec
>> =frontco
>>> ver
>>>
>>> Should we document it as deprecated and add it to the set of
>>> deprecated instructions (the legacy conformance group) like BPF_ABS
>>> and BPF_IND already are?
>>>
>>> Also, for purposes of the IANA registry of instructions where we list
>>> which opcodes are "(deprecated, implementation-specific)", I currently
>>> list all possible BPF_ABS and BPF_IND opcodes regardless of whether
>>> they were ever used (I didn't check which were used and which might
>>> not have been), so I could just list all possible BPF_MSH opcodes
>>> similarly.  But if we know that some were never used then I don't need
>>> to do so, so I guess I should
>>> ask:
>>> do we have a list of which combinations were actually used or should
>>> we continue to just deprecate all combinations?
>>>
>>> As an example,
>>> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.
>>> c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but
>>> not DW).
>>> Other sources like the book page referenced above, and the BSD man
>>> page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources
>>> such as
>>> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
>>   From kernel source code (net/core/filter.c), the only supported format is
>>      BPF_LDX | BPF_MSH | BPF_B
>>
>> The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is
>> converted to BPF insn set. If the current BPF program has this insn, verifier will
>> reject it and bpf kernel interpreter does not support this insn either. So
>> technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program.
>>
>>> So, should we list the DW variants as deprecated, or never assigned?
>>> Should we list the H, W, and LD variants as deprecated, or never assigned?
> Thanks for confirming.  I think the doc is ok as is for this part.
>
>>> What about DW and LDX variants of BPF_IND and BPF_ABS?
> What about this question?

I don't know how to do proper wording in the standard. But
DW and LDX variants of BPF_IND/BPF_ABS are not supported
by verifier for now and they are considered illegal insns.

>
> Dave
>

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Yonghong Song]

On 1/27/24 4:53 PM, dthaler1968@googlemail.com wrote:
>> -----Original Message-----
>> From: Yonghong Song <yonghong.song@linux.dev>
>> Sent: Saturday, January 27, 2024 4:27 PM
>> To: dthaler1968@googlemail.com
>> Cc: bpf@ietf.org; bpf@vger.kernel.org
>> Subject: Re: ISA: BPF_MSH and deprecated packet access instructions
>>
>>
>> On 1/27/24 10:50 AM, dthaler1968@googlemail.com wrote:
>>> Under "Load and store instructions", various mode modifiers are
>> documented.
>>> I notice that BPF_MSH (0xa0) is not documented, but appears to be in
>>> use in various projects, including Linux, BSD, seccomp, etc. and is
>>> even documented in various books such as
>>>
>> https://www.google.com/books/edition/Programming_Linux_Hacker_Tools_Un
>>> covere
>>>
>> d/yqHVAwAAQBAJ?hl=en&gbpv=1&dq=%22BPF_MSH%22&pg=PA129&printsec
>> =frontco
>>> ver
>>>
>>> Should we document it as deprecated and add it to the set of
>>> deprecated instructions (the legacy conformance group) like BPF_ABS
>>> and BPF_IND already are?
>>>
>>> Also, for purposes of the IANA registry of instructions where we list
>>> which opcodes are "(deprecated, implementation-specific)", I currently
>>> list all possible BPF_ABS and BPF_IND opcodes regardless of whether
>>> they were ever used (I didn't check which were used and which might
>>> not have been), so I could just list all possible BPF_MSH opcodes
>>> similarly.  But if we know that some were never used then I don't need
>>> to do so, so I guess I should
>>> ask:
>>> do we have a list of which combinations were actually used or should
>>> we continue to just deprecate all combinations?
>>>
>>> As an example,
>>> https://github.com/seccomp/libseccomp/blob/main/tools/scmp_bpf_disasm.
>>> c#L68 lists 6 variants of BPF_MSH: LD and LDX, for B, H, and W (but
>>> not DW).
>>> Other sources like the book page referenced above, and the BSD man
>>> page, list only BPF_LDX | BPF_B | BPF_MSH, which is in Linux sources
>>> such as
>>> https://elixir.bootlin.com/linux/v6.8-rc1/source/lib/test_bpf.c#L368
>>   From kernel source code (net/core/filter.c), the only supported format is
>>      BPF_LDX | BPF_MSH | BPF_B
>>
>> The insn (BPF_LDX | BPF_MSH | BPF_B) is only used when cBPF (classic BPF) is
>> converted to BPF insn set. If the current BPF program has this insn, verifier will
>> reject it and bpf kernel interpreter does not support this insn either. So
>> technically, (BPF_LDX | BPF_MSH | BPF_B) is not supported by BPF program.
>>
>>> So, should we list the DW variants as deprecated, or never assigned?
>>> Should we list the H, W, and LD variants as deprecated, or never assigned?
> Thanks for confirming.  I think the doc is ok as is for this part.
>
>>> What about DW and LDX variants of BPF_IND and BPF_ABS?
> What about this question?

I don't know how to do proper wording in the standard. But
DW and LDX variants of BPF_IND/BPF_ABS are not supported
by verifier for now and they are considered illegal insns.

>
> Dave
>

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

RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968]

I asked:
> >> What about DW and LDX variants of BPF_IND and BPF_ABS?

Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
> These we support:
> 
>   /* Absolute load instructions, designed to be used in socket filters.
*/
>   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
>   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
>   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
>   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
> 
>   /* Generic load instructions (to register.)  */
>   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
)",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
>   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
%o16
> )",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
>   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
%o16
> )",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
>   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
> %o16 )",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},

Yonghong Song <yonghong.song@linux.dev> wrote:
> I don't know how to do proper wording in the standard. But DW and LDX
> variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
> are considered illegal insns.

Although the Linux verifier doesn't support them, the fact that gcc does
support
them tells me that it's probably safest to list the DW and LDX variants as
deprecated as well, which is what the draft already did in the appendix so
that's good (nothing to change there, I think).

Dave

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968=40googlemail.com]

I asked:
> >> What about DW and LDX variants of BPF_IND and BPF_ABS?

Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
> These we support:
> 
>   /* Absolute load instructions, designed to be used in socket filters.
*/
>   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
>   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
>   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
>   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
>    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
> 
>   /* Generic load instructions (to register.)  */
>   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
)",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
>   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
%o16
> )",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
>   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
%o16
> )",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
>   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
> %o16 )",
>    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},

Yonghong Song <yonghong.song@linux.dev> wrote:
> I don't know how to do proper wording in the standard. But DW and LDX
> variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
> are considered illegal insns.

Although the Linux verifier doesn't support them, the fact that gcc does
support
them tells me that it's probably safest to list the DW and LDX variants as
deprecated as well, which is what the draft already did in the appendix so
that's good (nothing to change there, I think).

Dave

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Alexei Starovoitov]

On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote:
>
> I asked:
> > >> What about DW and LDX variants of BPF_IND and BPF_ABS?
>
> Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
> > These we support:
> >
> >   /* Absolute load instructions, designed to be used in socket filters.
> */
> >   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
> >   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
> >   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
> >   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
> >
> >   /* Generic load instructions (to register.)  */
> >   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
> )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
> >   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
> %o16
> > )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
> >   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
> %o16
> > )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
> >   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
> > %o16 )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},
>
> Yonghong Song <yonghong.song@linux.dev> wrote:
> > I don't know how to do proper wording in the standard. But DW and LDX
> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
> > are considered illegal insns.
>
> Although the Linux verifier doesn't support them, the fact that gcc does
> support
> them tells me that it's probably safest to list the DW and LDX variants as
> deprecated as well, which is what the draft already did in the appendix so
> that's good (nothing to change there, I think).

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. So nothing is deprecated.
Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
It's a legacy insn. Just like abs/ind.

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Alexei Starovoitov]

On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote:
>
> I asked:
> > >> What about DW and LDX variants of BPF_IND and BPF_ABS?
>
> Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
> > These we support:
> >
> >   /* Absolute load instructions, designed to be used in socket filters.
> */
> >   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
> >   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
> >   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
> >   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
> >
> >   /* Generic load instructions (to register.)  */
> >   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
> )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
> >   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
> %o16
> > )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
> >   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
> %o16
> > )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
> >   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
> > %o16 )",
> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},
>
> Yonghong Song <yonghong.song@linux.dev> wrote:
> > I don't know how to do proper wording in the standard. But DW and LDX
> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
> > are considered illegal insns.
>
> Although the Linux verifier doesn't support them, the fact that gcc does
> support
> them tells me that it's probably safest to list the DW and LDX variants as
> deprecated as well, which is what the draft already did in the appendix so
> that's good (nothing to change there, I think).

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. So nothing is deprecated.
Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
It's a legacy insn. Just like abs/ind.

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

> On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote:
>>
>> I asked:
>> > >> What about DW and LDX variants of BPF_IND and BPF_ABS?
>>
>> Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
>> > These we support:
>> >
>> >   /* Absolute load instructions, designed to be used in socket filters.
>> */
>> >   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
>> >   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
>> >   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
>> >   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
>> >
>> >   /* Generic load instructions (to register.)  */
>> >   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
>> )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
>> >   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
>> %o16
>> > )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
>> >   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
>> %o16
>> > )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
>> >   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
>> > %o16 )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},
>>
>> Yonghong Song <yonghong.song@linux.dev> wrote:
>> > I don't know how to do proper wording in the standard. But DW and LDX
>> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
>> > are considered illegal insns.
>>
>> Although the Linux verifier doesn't support them, the fact that gcc does
>> support
>> them tells me that it's probably safest to list the DW and LDX variants as
>> deprecated as well, which is what the draft already did in the appendix so
>> that's good (nothing to change there, I think).
>
> 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. So nothing is deprecated.

We have no reason to support these instructions in the assembler, and
GCC certainly never generates these.  So I will remove the ABS/IND DW
instructions from the assembler today.

> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> It's a legacy insn. Just like abs/ind.

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

> On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote:
>>
>> I asked:
>> > >> What about DW and LDX variants of BPF_IND and BPF_ABS?
>>
>> Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
>> > These we support:
>> >
>> >   /* Absolute load instructions, designed to be used in socket filters.
>> */
>> >   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
>> >   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
>> >   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
>> >   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
>> >
>> >   /* Generic load instructions (to register.)  */
>> >   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
>> )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
>> >   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
>> %o16
>> > )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
>> >   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
>> %o16
>> > )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
>> >   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
>> > %o16 )",
>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},
>>
>> Yonghong Song <yonghong.song@linux.dev> wrote:
>> > I don't know how to do proper wording in the standard. But DW and LDX
>> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
>> > are considered illegal insns.
>>
>> Although the Linux verifier doesn't support them, the fact that gcc does
>> support
>> them tells me that it's probably safest to list the DW and LDX variants as
>> deprecated as well, which is what the draft already did in the appendix so
>> that's good (nothing to change there, I think).
>
> 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. So nothing is deprecated.

We have no reason to support these instructions in the assembler, and
GCC certainly never generates these.  So I will remove the ABS/IND DW
instructions from the assembler today.

> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> It's a legacy insn. Just like abs/ind.

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

>> On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote:
>>>
>>> I asked:
>>> > >> What about DW and LDX variants of BPF_IND and BPF_ABS?
>>>
>>> Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
>>> > These we support:
>>> >
>>> >   /* Absolute load instructions, designed to be used in socket filters.
>>> */
>>> >   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
>>> >   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
>>> >   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
>>> >   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
>>> >
>>> >   /* Generic load instructions (to register.)  */
>>> >   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
>>> )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
>>> >   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
>>> %o16
>>> > )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
>>> >   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
>>> %o16
>>> > )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
>>> >   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
>>> > %o16 )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},
>>>
>>> Yonghong Song <yonghong.song@linux.dev> wrote:
>>> > I don't know how to do proper wording in the standard. But DW and LDX
>>> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
>>> > are considered illegal insns.
>>>
>>> Although the Linux verifier doesn't support them, the fact that gcc does
>>> support
>>> them tells me that it's probably safest to list the DW and LDX variants as
>>> deprecated as well, which is what the draft already did in the appendix so
>>> that's good (nothing to change there, I think).
>>
>> 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. So nothing is deprecated.
>
> We have no reason to support these instructions in the assembler, and
> GCC certainly never generates these.  So I will remove the ABS/IND DW
> instructions from the assembler today.

This has been done now in upstream binutils.

>> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
>> It's a legacy insn. Just like abs/ind.

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Jose E. Marchesi]

>> On Sat, Jan 27, 2024 at 10:59 PM <dthaler1968@googlemail.com> wrote:
>>>
>>> I asked:
>>> > >> What about DW and LDX variants of BPF_IND and BPF_ABS?
>>>
>>> Jose E. Marchesi <jose.marchesi@oracle.com> wrote:
>>> > These we support:
>>> >
>>> >   /* Absolute load instructions, designed to be used in socket filters.
>>> */
>>> >   {BPF_INSN_LDABSB, "ldabsb%W%i32", "r0 = * ( u8 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_B|BPF_MODE_ABS},
>>> >   {BPF_INSN_LDABSH, "ldabsh%W%i32", "r0 = * ( u16 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_H|BPF_MODE_ABS},
>>> >   {BPF_INSN_LDABSW, "ldabsw%W%i32", "r0 = * ( u32 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_W|BPF_MODE_ABS},
>>> >   {BPF_INSN_LDABSDW, "ldabsdw%W%i32", "r0 = * ( u64 * ) skb [ %i32 ]",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LD|BPF_SIZE_DW|BPF_MODE_ABS},
>>> >
>>> >   /* Generic load instructions (to register.)  */
>>> >   {BPF_INSN_LDXB, "ldxb%W%dr , [ %sr %o16 ]", "%dr = * ( u8 * ) ( %sr %o16
>>> )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_B|BPF_MODE_MEM},
>>> >   {BPF_INSN_LDXH, "ldxh%W%dr , [ %sr %o16 ]", "%dr = * ( u16 * ) ( %sr
>>> %o16
>>> > )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_H|BPF_MODE_MEM},
>>> >   {BPF_INSN_LDXW, "ldxw%W%dr , [ %sr %o16 ]", "%dr = * ( u32 * ) ( %sr
>>> %o16
>>> > )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_W|BPF_MODE_MEM},
>>> >   {BPF_INSN_LDXDW, "ldxdw%W%dr , [ %sr %o16 ]","%dr = * ( u64 * ) ( %sr
>>> > %o16 )",
>>> >    BPF_V1, BPF_CODE, BPF_CLASS_LDX|BPF_SIZE_DW|BPF_MODE_MEM},
>>>
>>> Yonghong Song <yonghong.song@linux.dev> wrote:
>>> > I don't know how to do proper wording in the standard. But DW and LDX
>>> > variants of BPF_IND/BPF_ABS are not supported by verifier for now and they
>>> > are considered illegal insns.
>>>
>>> Although the Linux verifier doesn't support them, the fact that gcc does
>>> support
>>> them tells me that it's probably safest to list the DW and LDX variants as
>>> deprecated as well, which is what the draft already did in the appendix so
>>> that's good (nothing to change there, I think).
>>
>> 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. So nothing is deprecated.
>
> We have no reason to support these instructions in the assembler, and
> GCC certainly never generates these.  So I will remove the ABS/IND DW
> instructions from the assembler today.

This has been done now in upstream binutils.

>> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
>> It's a legacy insn. Just like abs/ind.

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

RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
[...]
> > Although the Linux verifier doesn't support them, the fact that gcc
> > does support them tells me that it's probably safest to list the DW
> > and LDX variants as deprecated as well, which is what the draft
> > already did in the appendix so that's good (nothing to change there, I
> > think).
> 
> 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. So
> nothing is deprecated.

Ack, I will remove the ABS/IND + DW lines from the appendix.

> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> It's a legacy insn. Just like abs/ind.

Should it be listed in the legacy conformance group then?

Currently it's not mentioned in instruction-set.rst at all, so the opcode
is available to use by any new instruction.  If we do list it in instruction-set.rst
then, like abs/ind, it will be avoided by anyone proposing new instructions.

Dave

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968=40googlemail.com]

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
[...]
> > Although the Linux verifier doesn't support them, the fact that gcc
> > does support them tells me that it's probably safest to list the DW
> > and LDX variants as deprecated as well, which is what the draft
> > already did in the appendix so that's good (nothing to change there, I
> > think).
> 
> 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. So
> nothing is deprecated.

Ack, I will remove the ABS/IND + DW lines from the appendix.

> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> It's a legacy insn. Just like abs/ind.

Should it be listed in the legacy conformance group then?

Currently it's not mentioned in instruction-set.rst at all, so the opcode
is available to use by any new instruction.  If we do list it in instruction-set.rst
then, like abs/ind, it will be avoided by anyone proposing new instructions.

Dave

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Alexei Starovoitov]

On Tue, Jan 30, 2024 at 7:51 AM <dthaler1968@googlemail.com> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> [...]
> > > Although the Linux verifier doesn't support them, the fact that gcc
> > > does support them tells me that it's probably safest to list the DW
> > > and LDX variants as deprecated as well, which is what the draft
> > > already did in the appendix so that's good (nothing to change there, I
> > > think).
> >
> > 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. So
> > nothing is deprecated.
>
> Ack, I will remove the ABS/IND + DW lines from the appendix.
>
> > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > It's a legacy insn. Just like abs/ind.
>
> Should it be listed in the legacy conformance group then?
>
> Currently it's not mentioned in instruction-set.rst at all, so the opcode
> is available to use by any new instruction.  If we do list it in instruction-set.rst
> then, like abs/ind, it will be avoided by anyone proposing new instructions.

Yeah. The standard needs to mention it as legacy insn.
It's such a weird ultra specialized insn introduced for one specific
purpose parsing IP header. tcpdump only. Effectively.

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Alexei Starovoitov]

On Tue, Jan 30, 2024 at 7:51 AM <dthaler1968@googlemail.com> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> [...]
> > > Although the Linux verifier doesn't support them, the fact that gcc
> > > does support them tells me that it's probably safest to list the DW
> > > and LDX variants as deprecated as well, which is what the draft
> > > already did in the appendix so that's good (nothing to change there, I
> > > think).
> >
> > 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. So
> > nothing is deprecated.
>
> Ack, I will remove the ABS/IND + DW lines from the appendix.
>
> > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > It's a legacy insn. Just like abs/ind.
>
> Should it be listed in the legacy conformance group then?
>
> Currently it's not mentioned in instruction-set.rst at all, so the opcode
> is available to use by any new instruction.  If we do list it in instruction-set.rst
> then, like abs/ind, it will be avoided by anyone proposing new instructions.

Yeah. The standard needs to mention it as legacy insn.
It's such a weird ultra specialized insn introduced for one specific
purpose parsing IP header. tcpdump only. Effectively.

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

RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968]

> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> [...]
> > > Although the Linux verifier doesn't support them, the fact that gcc
> > > does support them tells me that it's probably safest to list the DW
> > > and LDX variants as deprecated as well, which is what the draft
> > > already did in the appendix so that's good (nothing to change there,
> > > I think).
> >
> > 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. So nothing is deprecated.
> 
> Ack, I will remove the ABS/IND + DW lines from the appendix.
> 
> > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > It's a legacy insn. Just like abs/ind.
> 
> Should it be listed in the legacy conformance group then?
> 
> Currently it's not mentioned in instruction-set.rst at all, so the opcode is
> available to use by any new instruction.  If we do list it in instruction-set.rst
> then, like abs/ind, it will be avoided by anyone proposing new instructions.

Here's my understanding of this thread so far:

* (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
   by clang and gcc.  They should be in the legacy conformance group of deprecated
   instructions.

* (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
   never used.  Clang doesn't generate them but gcc did which is now removed
   based on this discussion.  They should NOT be in the legacy conformance group of
   deprecated instructions because they were never defined in the first place, and
   instruction-set.rst should be updated to clarify this.

* (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were 
   never used.  Clang doesn't generate them but gcc does. They should NOT 
   be in the legacy conformance group of deprecated instructions because they were
   never defined in the first place, and instruction-set.rst should be updated to clarify this.

* (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were 
   never used.  I don't know whether clang or gcc generates them.  They should NOT 
   be in the legacy conformance group of deprecated instructions because they were
   never defined in the first place, and instruction-set.rst should be updated to clarify this.

* MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
   by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.
   The "Legacy BPF Packet access instructions" section of instruction-set.rst says
   > BPF previously introduced special instructions for access to packet data that were carried
   > over from classic BPF. However, these instructions are deprecated and should no longer be used.
   I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
   should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
   But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

* MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were 
   never used.  They should NOT be in the legacy conformance group of deprecated instructions
   because they were never defined in the first place.

Let me know if any of the above is incorrect and I can submit a doc patch.

Dave

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968=40googlemail.com]

> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> [...]
> > > Although the Linux verifier doesn't support them, the fact that gcc
> > > does support them tells me that it's probably safest to list the DW
> > > and LDX variants as deprecated as well, which is what the draft
> > > already did in the appendix so that's good (nothing to change there,
> > > I think).
> >
> > 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. So nothing is deprecated.
> 
> Ack, I will remove the ABS/IND + DW lines from the appendix.
> 
> > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > It's a legacy insn. Just like abs/ind.
> 
> Should it be listed in the legacy conformance group then?
> 
> Currently it's not mentioned in instruction-set.rst at all, so the opcode is
> available to use by any new instruction.  If we do list it in instruction-set.rst
> then, like abs/ind, it will be avoided by anyone proposing new instructions.

Here's my understanding of this thread so far:

* (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
   by clang and gcc.  They should be in the legacy conformance group of deprecated
   instructions.

* (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
   never used.  Clang doesn't generate them but gcc did which is now removed
   based on this discussion.  They should NOT be in the legacy conformance group of
   deprecated instructions because they were never defined in the first place, and
   instruction-set.rst should be updated to clarify this.

* (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were 
   never used.  Clang doesn't generate them but gcc does. They should NOT 
   be in the legacy conformance group of deprecated instructions because they were
   never defined in the first place, and instruction-set.rst should be updated to clarify this.

* (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were 
   never used.  I don't know whether clang or gcc generates them.  They should NOT 
   be in the legacy conformance group of deprecated instructions because they were
   never defined in the first place, and instruction-set.rst should be updated to clarify this.

* MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
   by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.
   The "Legacy BPF Packet access instructions" section of instruction-set.rst says
   > BPF previously introduced special instructions for access to packet data that were carried
   > over from classic BPF. However, these instructions are deprecated and should no longer be used.
   I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
   should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
   But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

* MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were 
   never used.  They should NOT be in the legacy conformance group of deprecated instructions
   because they were never defined in the first place.

Let me know if any of the above is incorrect and I can submit a doc patch.

Dave

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

RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968]

[...]
> > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > > It's a legacy insn. Just like abs/ind.
> >
> > Should it be listed in the legacy conformance group then?
> >
> > Currently it's not mentioned in instruction-set.rst at all, so the
> > opcode is available to use by any new instruction.  If we do list it
> > in instruction-set.rst then, like abs/ind, it will be avoided by anyone proposing
> new instructions.
> 
> Yeah. The standard needs to mention it as legacy insn.
> It's such a weird ultra specialized insn introduced for one specific purpose
> parsing IP header. tcpdump only. Effectively.

Thanks for the quick answer on this one.  Will do.

Dave

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[dthaler1968=40googlemail.com]

[...]
> > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > > It's a legacy insn. Just like abs/ind.
> >
> > Should it be listed in the legacy conformance group then?
> >
> > Currently it's not mentioned in instruction-set.rst at all, so the
> > opcode is available to use by any new instruction.  If we do list it
> > in instruction-set.rst then, like abs/ind, it will be avoided by anyone proposing
> new instructions.
> 
> Yeah. The standard needs to mention it as legacy insn.
> It's such a weird ultra specialized insn introduced for one specific purpose
> parsing IP header. tcpdump only. Effectively.

Thanks for the quick answer on this one.  Will do.

Dave

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Yonghong Song]

On 1/30/24 8:39 AM, dthaler1968@googlemail.com wrote:
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>> [...]
>>>> Although the Linux verifier doesn't support them, the fact that gcc
>>>> does support them tells me that it's probably safest to list the DW
>>>> and LDX variants as deprecated as well, which is what the draft
>>>> already did in the appendix so that's good (nothing to change there,
>>>> I think).
>>> 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. So nothing is deprecated.
>> Ack, I will remove the ABS/IND + DW lines from the appendix.
>>
>>> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
>>> It's a legacy insn. Just like abs/ind.
>> Should it be listed in the legacy conformance group then?
>>
>> Currently it's not mentioned in instruction-set.rst at all, so the opcode is
>> available to use by any new instruction.  If we do list it in instruction-set.rst
>> then, like abs/ind, it will be avoided by anyone proposing new instructions.
> Here's my understanding of this thread so far:
>
> * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
>     by clang and gcc.  They should be in the legacy conformance group of deprecated
>     instructions.
>
> * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc did which is now removed
>     based on this discussion.  They should NOT be in the legacy conformance group of
>     deprecated instructions because they were never defined in the first place, and
>     instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc does. They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were
>     never used.  I don't know whether clang or gcc generates them.  They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
>     by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.

clang never generated this insn either.

>     The "Legacy BPF Packet access instructions" section of instruction-set.rst says
>     > BPF previously introduced special instructions for access to packet data that were carried
>     > over from classic BPF. However, these instructions are deprecated and should no longer be used.
>     I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
>     should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
>     But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

It is just my opinion. Standardization is complicated. I guess adding it to the legacy insn
is okay to prevent anybody using the same opcode.

>
> * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were
>     never used.  They should NOT be in the legacy conformance group of deprecated instructions
>     because they were never defined in the first place.
>
> Let me know if any of the above is incorrect and I can submit a doc patch.
>
> Dave
>

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Yonghong Song]

On 1/30/24 8:39 AM, dthaler1968@googlemail.com wrote:
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>> [...]
>>>> Although the Linux verifier doesn't support them, the fact that gcc
>>>> does support them tells me that it's probably safest to list the DW
>>>> and LDX variants as deprecated as well, which is what the draft
>>>> already did in the appendix so that's good (nothing to change there,
>>>> I think).
>>> 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. So nothing is deprecated.
>> Ack, I will remove the ABS/IND + DW lines from the appendix.
>>
>>> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
>>> It's a legacy insn. Just like abs/ind.
>> Should it be listed in the legacy conformance group then?
>>
>> Currently it's not mentioned in instruction-set.rst at all, so the opcode is
>> available to use by any new instruction.  If we do list it in instruction-set.rst
>> then, like abs/ind, it will be avoided by anyone proposing new instructions.
> Here's my understanding of this thread so far:
>
> * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
>     by clang and gcc.  They should be in the legacy conformance group of deprecated
>     instructions.
>
> * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc did which is now removed
>     based on this discussion.  They should NOT be in the legacy conformance group of
>     deprecated instructions because they were never defined in the first place, and
>     instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc does. They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were
>     never used.  I don't know whether clang or gcc generates them.  They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
>     by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.

clang never generated this insn either.

>     The "Legacy BPF Packet access instructions" section of instruction-set.rst says
>     > BPF previously introduced special instructions for access to packet data that were carried
>     > over from classic BPF. However, these instructions are deprecated and should no longer be used.
>     I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
>     should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
>     But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

It is just my opinion. Standardization is complicated. I guess adding it to the legacy insn
is okay to prevent anybody using the same opcode.

>
> * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were
>     never used.  They should NOT be in the legacy conformance group of deprecated instructions
>     because they were never defined in the first place.
>
> Let me know if any of the above is incorrect and I can submit a doc patch.
>
> Dave
>

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

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Alexei Starovoitov]

On Tue, Jan 30, 2024 at 8:39 AM <dthaler1968@googlemail.com> wrote:
>
> > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > [...]
> > > > Although the Linux verifier doesn't support them, the fact that gcc
> > > > does support them tells me that it's probably safest to list the DW
> > > > and LDX variants as deprecated as well, which is what the draft
> > > > already did in the appendix so that's good (nothing to change there,
> > > > I think).
> > >
> > > 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. So nothing is deprecated.
> >
> > Ack, I will remove the ABS/IND + DW lines from the appendix.
> >
> > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > > It's a legacy insn. Just like abs/ind.
> >
> > Should it be listed in the legacy conformance group then?
> >
> > Currently it's not mentioned in instruction-set.rst at all, so the opcode is
> > available to use by any new instruction.  If we do list it in instruction-set.rst
> > then, like abs/ind, it will be avoided by anyone proposing new instructions.
>
> Here's my understanding of this thread so far:
>
> * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
>    by clang and gcc.  They should be in the legacy conformance group of deprecated
>    instructions.

yes

> * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
>    never used.  Clang doesn't generate them but gcc did which is now removed
>    based on this discussion.  They should NOT be in the legacy conformance group of
>    deprecated instructions because they were never defined in the first place, and
>    instruction-set.rst should be updated to clarify this.

yes

> * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were
>    never used.  Clang doesn't generate them but gcc does. They should NOT
>    be in the legacy conformance group of deprecated instructions because they were
>    never defined in the first place, and instruction-set.rst should be updated to clarify this.

yes.

> * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were
>    never used.  I don't know whether clang or gcc generates them.  They should NOT
>    be in the legacy conformance group of deprecated instructions because they were
>    never defined in the first place, and instruction-set.rst should be updated to clarify this.

yes

> * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
>    by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.
>    The "Legacy BPF Packet access instructions" section of instruction-set.rst says
>    > BPF previously introduced special instructions for access to packet data that were carried
>    > over from classic BPF. However, these instructions are deprecated and should no longer be used.
>    I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
>    should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
>    But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

Yonghong is actually more correct here.

MSH | B | LDX is only accepted by _classic_ BPF.

It was never accepted by eBPF verifier,
so I have to back track my earlier suggestion.
I think it's undefined opcode from 'eBPF standardization' pov.
The standard doesn't talk about 'classic BPF' at all.
So it's fine to use MSH | B | LDX for something in the future.

> * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were
>    never used.  They should NOT be in the legacy conformance group of deprecated instructions
>    because they were never defined in the first place.

yes.

Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions

[Alexei Starovoitov]

On Tue, Jan 30, 2024 at 8:39 AM <dthaler1968@googlemail.com> wrote:
>
> > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > [...]
> > > > Although the Linux verifier doesn't support them, the fact that gcc
> > > > does support them tells me that it's probably safest to list the DW
> > > > and LDX variants as deprecated as well, which is what the draft
> > > > already did in the appendix so that's good (nothing to change there,
> > > > I think).
> > >
> > > 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. So nothing is deprecated.
> >
> > Ack, I will remove the ABS/IND + DW lines from the appendix.
> >
> > > Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> > > It's a legacy insn. Just like abs/ind.
> >
> > Should it be listed in the legacy conformance group then?
> >
> > Currently it's not mentioned in instruction-set.rst at all, so the opcode is
> > available to use by any new instruction.  If we do list it in instruction-set.rst
> > then, like abs/ind, it will be avoided by anyone proposing new instructions.
>
> Here's my understanding of this thread so far:
>
> * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
>    by clang and gcc.  They should be in the legacy conformance group of deprecated
>    instructions.

yes

> * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
>    never used.  Clang doesn't generate them but gcc did which is now removed
>    based on this discussion.  They should NOT be in the legacy conformance group of
>    deprecated instructions because they were never defined in the first place, and
>    instruction-set.rst should be updated to clarify this.

yes

> * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were
>    never used.  Clang doesn't generate them but gcc does. They should NOT
>    be in the legacy conformance group of deprecated instructions because they were
>    never defined in the first place, and instruction-set.rst should be updated to clarify this.

yes.

> * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were
>    never used.  I don't know whether clang or gcc generates them.  They should NOT
>    be in the legacy conformance group of deprecated instructions because they were
>    never defined in the first place, and instruction-set.rst should be updated to clarify this.

yes

> * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
>    by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.
>    The "Legacy BPF Packet access instructions" section of instruction-set.rst says
>    > BPF previously introduced special instructions for access to packet data that were carried
>    > over from classic BPF. However, these instructions are deprecated and should no longer be used.
>    I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
>    should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
>    But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

Yonghong is actually more correct here.

MSH | B | LDX is only accepted by _classic_ BPF.

It was never accepted by eBPF verifier,
so I have to back track my earlier suggestion.
I think it's undefined opcode from 'eBPF standardization' pov.
The standard doesn't talk about 'classic BPF' at all.
So it's fine to use MSH | B | LDX for something in the future.

> * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were
>    never used.  They should NOT be in the legacy conformance group of deprecated instructions
>    because they were never defined in the first place.

yes.

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