Re: bin/52609 (npf generates bad bytecode for port ranges)

[maxv%NetBSD.org@localhost]

Synopsis: npf generates bad bytecode for port ranges

State-Changed-From-To: open->analyzed
State-Changed-By: maxv%NetBSD.org@localhost
State-Changed-When: Fri, 13 Apr 2018 17:41:35 +0000
State-Changed-Why:
After some investigation, it turns out that basically NPF's BPF generator
does not support the syntax { 4-5, 7 }.

This syntax generates:

(004) ldx      M[1]
(005) ldh      [x + 2]
(006) jge      #0x4             jt 11   jf 7
(007) jgt      #0x5             jt 8    jf 11
(008) ldh      [x + 2]
(009) jeq      #0x7             jt 11   jf 10
(010) ret      #0
(011) ret      #-1

Instruction 006 has inverted fields, because of fixup_jumps(). It is
rather clear that this one is a bug.

But even if you swap the fields back to their correct form, the
instruction will still be:

(006) jge      #0x4             jt 7    jf 11

which is incorrect, it should logically be 'jf 8' (as you said).

But NPF doesn't handle that logic. NPF creates a group, from instruction
005 to instruction 010 (included on both sides), and can either continue
in that group or skip the group entirely.

So in instruction 006, it can only do two things, continue in 007, or
leave the group in 011. You can't ask to jump to 008, in the middle of
the group.

Obviously, it would be nice to fix it, but I don't really know how to
achieve that. We can't replace the instruction by

	BPF_JUMP(BPF_JMP+BPF_JGE+BPF_K, from, 0, 1)

because if there is no other port in the syntax, then there's a fall-
through in the "success" path, and we don't want that to happen.