Re: remote memory reading using arp?

[Andi Kleen]

On Mon, Apr 29, 2002 at 11:24:04AM -0400, Calin A. Culianu wrote:
> On 28 Apr 2002, Andi Kleen wrote:
> 
> > Bryan Rittmeyer <[e-mail]> writes:
> >
> > > It's not the ARP layer that's causing the padding... Ethernet has a
> > > minimum transmit size of 64 bytes (everything below that is disgarded
> > > by hardware as a fragment), so the network device driver or
> > > the hardware itself will pad any Linux skb smaller than 60 bytes up to
> > > that size (so that it's 64 bytes after appending CRC32). Apparently, in
> > > some cases that's done by just transmitting whatever uninitialized
> > > memory follows skb->data, which, after the system has been running
> > > for a while, may be inside a page previously used by userspace.
> >
> > The driver should be fixed in that case. I would consider it a driver
> > bug. The cost of clearing the tail should be minimal, it is at most
> 
> Yes, I wholeheartedly agree.  Also, the notion that it's userspace's
> responsibility to clear memory before exiting is preposterous.  That would
> involve just about every piece of software ever made to be rewritten (you
> could change glibc to clear memory on free()s but what about the stack?).

It actually requires more changes. The skbuff allocator needs to 
be fixed too to ensure a 64 bytes minimum length of the skb. 
(or alternatively if you don't want to penalize non ethernet protocols
read minlen from a dev-> field similar to hard_header_len and compute it 
in the caller, but that's likely overkill) 

But should be done. 

-Andi