Add new ISAv4 instructions

[dylandreimerink]

The proposal for a new version of the eBPF instruction set has been accepted and merged in both LLVM 18 and linux kernel v6.6. So we might be seeing these new instructions in the near future.

This PR adds support for these new instructions. Before this PR we could still parse the instructions but did not recognize the variations added:

myfunc:
         0: SwapLE dst: r1 imm: 16
         1: SwapLE dst: r2 imm: 32
         2: SwapLE dst: r3 imm: 64
         3: LdXMode(128)B 
         4: LdXMode(128)H 
         5: LdXMode(128)W 
         6: LdXMode(128)B 
         7: LdXMode(128)H 
         8: MovReg dst: r1 src: r4
         9: MovReg dst: r2 src: r5
        10: MovReg dst: r3 src: r6
        11: Mov32Reg dst: r1 src: r3
        12: Mov32Reg dst: r2 src: r4
        13: InvalidJumpOp32Imm dst: r0 off: 0 imm: 4
        14: DivReg dst: r1 src: r3
        15: ModReg dst: r2 src: r4
        16: Div32Reg dst: r1 src: r3
        17: Mod32Reg dst: r2 src: r4

After this PR we correctly understand the new instructions:

myfunc:
        0: BSwap16 dst: r1 
        1: BSwap32 dst: r2 
        2: BSwap64 dst: r3 
        3: LdXMemSXB dst: r1 src: r4 off: 0 imm: 0
        4: LdXMemSXH dst: r2 src: r5 off: 4 imm: 0
        5: LdXMemSXW dst: r3 src: r6 off: 8 imm: 0
        6: LdXMemSXB dst: r1 src: r4 off: 0 imm: 0
        7: LdXMemSXH dst: r2 src: r5 off: 4 imm: 0
        8: SMov8Reg dst: r1 src: r4
        9: SMov16Reg dst: r2 src: r5
        10: SMov32Reg dst: r3 src: r6
        11: SMov8Reg32 dst: r1 src: r3
        12: SMov16Reg32 dst: r2 src: r4
        13: Ja32 imm: 4
        14: SDivReg dst: r1 src: r3
        15: SModReg dst: r2 src: r4
        16: SDivReg32 dst: r1 src: r3
        17: SModReg32 dst: r2 src: r4

Fixes: #1188

[lmb]

Thanks for putting this together. I think that my main concern with this approach is that it introduces so many special cases. A lot of the getters on OpCode actually don't work correctly for extended opcodes, something we've not tackled with this at all (documentation or code wise).

So far OpCode is a 1:1 representation of the BPF wire format. This made sense since not all of the space was allocated. This is important for InvalidOpCode to function correctly. Now that pretty much all space is gone there is another option we can try: divorce the representation of OpCode from the wire format. I'm thinking something along these lines:

diff --git a/asm/opcode.go b/asm/opcode.go
index 845c5521..04d1d6cf 100644
--- a/asm/opcode.go
+++ b/asm/opcode.go
@@ -66,18 +66,33 @@ func (cls Class) isJumpOrALU() bool {
 	return cls.IsJump() || cls.IsALU()
 }
 
-// OpCode is a packed eBPF opcode.
+// OpCode represents a single operation.
 //
-// Its encoding is defined by a Class value:
+// It is not a 1:1 mapping to real eBPF opcodes.
 //
-//	msb      lsb
-//	+----+-+---+
-//	| ???? |CLS|
-//	+----+-+---+
-type OpCode uint8
+// The encoding varies based on a 3-bit Class:
+//
+//	7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+//	           ???           | CLS
+//
+// For ALUClass and ALUCLass32:
+//
+//	7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+//	          OPC          |S| CLS
+//
+// For LdClass, LdXclass, StClass and StXClass:
+//
+//	7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+//	       0       | MDE |SIZ| CLS
+//
+// For JumpClass, Jump32Class:
+//
+//	7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+//	       0       |  OPC  |S| CLS
+type OpCode uint16
 
 // InvalidOpCode is returned by setters on OpCode
-const InvalidOpCode OpCode = 0xff
+const InvalidOpCode OpCode = 0xffff
 
 // rawInstructions returns the number of BPF instructions required
 // to encode this opcode.

Basically, make OpCode wider so that we can represent all the logical opcodes. For simplicity we'd also change the various *Op to be uint16. We'd then handle converting to and from OpCode in Instruction.Marshal and Unmarshal, similar to what we do for dword loads. This way ExtendedALUOp is not required anymore and SMod / SDiv can be ALUOp. Finally we can also guarantee that InvalidOpCode really is invalid.

This is basically free at runtime since we don't increase the size of Instruction. I even think that we can arrange it so that existing users won't break (besides having to throw in a uint16 cast maybe).

What do you think?

[dylandreimerink]

Basically, make OpCode wider so that we can represent all the logical opcodes. For simplicity we'd also change the various *Op to be uint16. We'd then handle converting to and from OpCode in Instruction.Marshal and Unmarshal, similar to what we do for dword loads. This way ExtendedALUOp is not required anymore and SMod / SDiv can be ALUOp. Finally we can also guarantee that InvalidOpCode really is invalid.

This is basically free at runtime since we don't increase the size of Instruction. I even think that we can arrange it so that existing users won't break (besides having to throw in a uint16 cast maybe).

What do you think?

Yes, that feels less hacky than what I have so far 👍

[lmb]

Two questions, otherwise LGTM.

[lmb]

Renamed LoadSXMemOp to LoadMemSXOp

[lmb]

Thanks!

[lmb]

I managed to force push an old version i think x( Fixes incoming.