Re: remote memory reading using arp?
Andi Kleen (firstname.lastname@example.org)
Mon, 29 Apr 2002 17:31:44 +0200
On Mon, Apr 29, 2002 at 11:24:04AM -0400, Calin A. Culianu wrote:
> On 28 Apr 2002, Andi Kleen wrote:
> > Bryan Rittmeyer <email@example.com> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/