On May 2, 2013, at 3:20 PM, Damien Miller <d...@mindrot.org> wrote: > On Thu, 2 May 2013, Franco Fichtner wrote: > >> OK, the implementation only pulls a couple of bytes from the packet's >> payload. It will never pull bytes that are not verified. It will never >> allocate anything. It will never test against something that's neither >> hard-coded nor available in the range of the approved payload. It will >> never return more than "unsigned int" with a number describing the >> actual application. It will never manipulate any input value, lest of >> all the packet itself. It will never run into endless loops. And I'll >> gladly zap everything that could still considered be a potential risk. > > You've just described bpf, right down to "no endless loops" and the amount > of data it returns. > > For a little more code that it takes to write one packet parser > (basically: loading bpf rules from pf and making the bpf_filter()'s > return value available to it) you get everything you described above and > more.
I yield. I'm working on making DPI more human-readable and maintainable, and struct bpf_insn is not an option for me, personally. Worse still, searching for bpf+dpi in google already brings up this mail thread as a top ten hit, which may be a good indicator of how successful this approach has been the last couple of years. ;) Franco
