Re: BPF in hardware

[Guy Harris <guy () alum mit edu>]

On Nov 22, 2004, at 1:26 PM, Livio Ricciulli wrote:

> The idea is to automatically translate the BPF expressions passed to
> libpcap into MTP macrocode and load it into the card on the fly
> ___in_addition_to___ the normal BPF software matching.

By "BPF expressions" do you mean "BPF programs" or do you mean "filter 
expressions"?

I.e., do you mean translating

        port 2049 and host nfs.foobar.com

into MTP macrocode or do you mean translating

(000) ldh      [12]
(001) jeq      #0x86dd          jt 19   jf 2
(002) jeq      #0x800           jt 3    jf 19
(003) ldb      [23]
(004) jeq      #0x84            jt 7    jf 5
(005) jeq      #0x6             jt 7    jf 6
(006) jeq      #0x11            jt 7    jf 19
(007) ldh      [20]
(008) jset     #0x1fff          jt 19   jf 9
(009) ldxb     4*([14]&0xf)
(010) ldh      [x + 14]
(011) jeq      #0x801           jt 14   jf 12
(012) ldh      [x + 16]
(013) jeq      #0x801           jt 14   jf 19
(014) ld       [26]
(015) jeq      #0x7f000001      jt 18   jf 16
(016) ld       [30]
(017) jeq      #0x7f000001      jt 18   jf 19
(018) ret      #96
(019) ret      #0

into MTP macrocode?

If the latter, then, if the card's driver plugs into the OS networking 
stack largely the same way a regular network adapter does (i.e., you 
could use the native OS's pcap-*.c code) - I infer this is the case 
from

>  Also, no changes are
> necessary from the OS side of things since the matched packets are
> received as if they were coming from a regular NIC in promiscuous
> mode..

you'd have the setfilter routine for that platform (e.g., 
pcap_setfilter_linux())...

> The presence
> of the MTP interface can be easily detected at runtime making this
> possibly completely transparent to the user.

...do that check and, if it's setting a filter on an MTP interface, 
translate the BPF code it was given into MTP macrocode and install that 
filter.

If, however, you mean the former, then:

> 1) What's the best way to do this from a coding architecture point of
> view? Any suggestions where to put the code? Add the entry of the
> MTP-specific code in pcap_compile?

...what should ultimately be done is to have a new API for setting 
filters:

	a routine that takes a filter string and generates a parse tree, with 
*no* code generation;

	a routine that takes a parse tree and a pcap_t pointer, and translates 
that parse tree into filter code and installs the filter on the pcap_t 
in question.

The latter routine doesn't supply any BPF code to its caller - it just 
installs the filter.  It might generate BPF code and install that, it 
might generate CMU/Stanford packet filter code and install that (e.g., 
on Solaris), it might generate BPF code and run that in userland, or it 
might generate MTP code and install that.

We'd also want a routine to take a pcap_t pointer - or, perhaps, a 
link-layer type and snapshot length, instead - and a parse tree and 
generate BPF code, for the benefit of code that is going to use 
"bpf_filter()" itself, for example.

> 2) The cards can do unanchored string search in the payloads; it would
> be possible to add new primitives for content (ala Snort) in a BPF
> expression. Would people use it?

There are probably users of libpcap-based applications that would; 
there have been requests on the Ethereal mailing list for string-based 
capture filters, although at least some of those might be anchored 
matches, which can be done, albeit a bit painfully, with the existing 
filter language.

> Why don't you do it already in software?

Because there hasn't be a *lot* of demand for it, and because doing it 
as part of the kernel packet matching would require that the BPF 
engines in several OSes be updated to support it, and we don't really 
have direct control over them - only, at best, influence over some of 
them.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.