Re: Memory-mapped capture and thinking the packet's

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

On Sep 26, 2009, at 5:55 PM, Guy Harris wrote:

> On Sep 26, 2009, at 3:09 PM, Eloy Paris wrote:
>
> > So it seems like the only option I have to fix the regression is to  
> > convert the pcap_next() call to pcap_dispatch()/pcap_loop()  
> > semantics. I don't think that copying the packet to a safe place as  
> > soon as pcap_next() returns is good enough since, while the  
> > exposure window is narrower, there's still a chance to have packet  
> > data overwritten by the kernel.
>
> How?
>
> If the kernel can overwrite the packet data before the userland code  
> (libpcap or whatever) sets the packet status to TP_STATUS_KERNEL,  
> that's an *extremely severe* kernel bug, and would break memory- 
> mapped capture regardless of whether you're using pcap_next()/ 
> pcap_next_ex() - or even whether you're using libpcap at all!
>
> If the kernel cannot overwrite the packet data before the userland  
> code sets the packet status to TP_STATUS_KERNEL, then, as long as  
> the copy is done before the packet status is set to  
> TP_STATUS_KERNEL, the packet data will not be overwritten before the  
> copy is made - and, once the copy is made, the kernel can't  
> overwrite the copy, so, if pcap_next()/pcap_next_ex() returns a  
> pointer to the copy, rather than to the data in the memory-mapped  
> ring buffer, that's safe.

...although if you mean that *you* can't safely copy the packet to  
another location in your application after pcap_next() or  
pcap_next_ex() returns, that's correct.

> > Under these conditions pcap_next() and pcap_next_ex() are  
> > completely unusable. Perhaps we should document that pcap_next()  
> > and pcap_next_ex() should not be used when libpcap uses mmap()?

The change I mentioned is in the current top-of-tree version of  
libpcap, so pcap_next()/pcap_next_ex() *are* safe in that version, so  
there's no need to change the documentation in that version, or to add  
a "disable memory-mapping" API in that version.

> > Along the same lines, is there a way to disable libpcap's use of  
> > mmap() at run-time even if it's available?

Unfortunately, no.

> > That would be a better workaround than to re-write my application...

The rewrite needn't be too painful - you could copy pcap_next() or  
pcap_next_ex() from the current top-of-tree libpcap, rename it, change  
it so that the callback copies the packet data to a separate location  
and returns a pointer to that, and call the modified routine rather  
than pcap_next() or pcap_next_ex().
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.