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

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

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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.