Subject: Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory

From: Ben Greear <[email-masked]>
Date: Sat, 24 Jul 2010 06:18:07 -0700

On 07/23/2010 10:23 PM, Eric Dumazet wrote:
> Le vendredi 23 juillet 2010 à 16:14 -0700, Ben Greear a écrit :
>> Some time back, someone added some memset() calls to pktgen to
>> keep from leaking memory contents to the network.
>>
>
> Well, someone might be me ;)
>
>> At least in our modified version of pktgen, this caused about 25%
>> performance degradation when sending 1514 byte pkts (multi-pkt == 0)
>> on a pair of 10G ports.  It was easy enough to comment these memset
>> calls out of course.
>>
>> I don't mind if this patch stays in,
>> but thought I'd post my findings in case anyone else wonders why
>> their pktgen slowed down...
>>
>
> Thanks Ben
>
> Here is a patch adding a new pktgen flag, so that admins can choose
> speed if they want to, if they dont use clone_skb to reduce skb setup
> costs.

It looks fine to me, though I have not actually tested it.

> +Very fast mode
> +==============
> +One knob to get very fast pktgen is the UNSAFE flag :
> +
> +flag UNSAFE
> +
> +This ask to pktgen to not clear content of packets before sending them.
> +Note this is a security problem, and should be used only if really needed.
> +If packets are cloned (clone_skb 1000), clearing data cost is amortized so
> +this UNSAFE mode is less interesting.

I think most users of pktgen wouldn't be too concerned about leaking
memory content to the network.  It's a root-only test tool that can easily
saturate most networks and do horrible things like overflow switch CAM tables
by randomizing source/dest macs etc.  So, this warning might could be a bit
more descriptive of how it is a security problem "arbitrary contents of memory can be
sent across the network and may be sniffed by devices on the network, potentially
revealing private information such as passwords and application data for applications
running on the machine running pktgen" instead of telling folks not to use it unless it's
really needed.

Thanks,
Ben

-- 
Ben Greear <[email-masked]>
Candela Technologies Inc  http://www.candelatech.com