Messages in this thread | | | Date | Wed, 1 May 2002 18:24:38 -0400 (EDT) | From | "Calin A. Culianu" <> | Subject | Re: Dirty memory? (WAS Re: remote memory reading using arp?) |
| |
Actually nevermind. It looks like memory allocated for userspace is always zeroed out... hehe don't I feel dumb..
-Calin
On Wed, 1 May 2002, Calin A. Culianu wrote:
> On Mon, 29 Apr 2002, Andi Kleen wrote: > > > 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) > > Well, that sounds pretty elegant. After all, it makes sense for the > caller to ensure the data field in his skbuff is at least as big as the > (MTU? is this the field we want in struct net_device?) for his dev... > > > > > But should be done. > > I am glad you think so. More generally, once can make the argument that > to be 100% secure, one needs to revisit a lot of the kernel memory > allocations (not just in the networking code) and see if the following two > criteria are met: any of the memory allocated could potentially be/remain > 'dirty' for a while && there is a possibility that the contents of that > memory could make their way into 'untrusted' hands. Things like giving > the dirty memory to userspace or sending portions of it down the network > wire are examples of placing it in untrusted hands. > > I am not sure if this is a can of worms worth opening. While it would be > nice for the kernel to reliably provide guarantees about memory and its > 'cleanliness' and privateness (after all this is one third the reason for > memory protection in the first place!), it may be a lot of trouble > performancewise.... however it still is an interesting problem to look > at... > > I wonder if any other operating systems have addressed the issue of memory > allocators and the possibility that the memory they return may contain > sensitive data? > > -Calin > > > > > -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/ > > > > - > 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/ >
- 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/
| |