Expand description
Functionality for parsing and serializing INET_DIAG bytecode programs.
SOCK_DIAG_BY_FAMILY requests with NLM_F_DUMP can accept a bytecode program. The program is run against all of the sockets matching the standard part of the request (though some fields, like socket_id, are not examined at all). If the program accepts a socket, it is returned to the caller. Acceptance is signalled by the program reaching the length of the buffer exactly. Rejection is signalled by the program jumping to somewhere past this.
Each instruction is composed of the following basic structure, where yes
and no are how many bytes jump forward if the instruction matches or not.
Note that this means there are no loops and all programs trivially must
terminate:
opcode: u8,
yes: u8,
no: u16,
// Followed (optionally) by parameters for the instruction.Instructions are variable-length, which is unwieldy to deal with in Rust, so instead we represent a program as a series of fixed-length instructions, which requires mapping back and forth to byte offsets during parsing and serialization.
There is a small loss of fidelity in this Rust representation. The types
here encode acception and rejection explicitly, which means there’s only a
single rejection target. It also encodes NOPs and jumps more simply,
forgoing the yes and no fields entirely. While this shouldn’t make a
semantic difference, it does mean round-tripping a program might result in a
different representation.
Structs§
- Bytecode
- A bytecode program used by Linux to match AF_INET sockets.
- Cgroup
Condition Buffer - Device
Condition Buffer - Ipv4
Addr Buffer - Ipv6
Addr Buffer - Mark
Condition Buffer - Parse
Error - An error encountered when parsing a program from a raw byte buffer.
- Port
Condition Buffer - RawInstruction
Buffer - Tuple
Condition - Tuple
Condition Buffer