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