-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Please keep the list CC'ed at all times] On Tue, Apr 03, 2007 at 11:38:05AM -0400, Ryan MacArthur wrote: > The reason I am asking this stemmed from reading this paper: > > J. Chow et al. Shredding your garbage: Reducing data lifetime. USENIX Sec, > 2005. > > > Pages are never reassigned with old data still present. The kernel is > >lazy and won't zero any page unless it's really necessary. At exit the > >pages are unmapped and returned to the free pool (when there are no > >other users, of course). > > > > > >Erik > > > > I guess I am stil confused as to "pages are never reassigned with old > data still present. The kernel is lazy and won't zero any page unless > its really necessary" So how > does the kernel ensure that clean pages wont have any old data present? Because uses a copy-on-write mechanism. For memory backed files, the data from the file is copied into the new page, for anonymous pages, the contents of the zero page (which happen to be all zeroes) are copied into the new page. In effect the kernel only zeroes anonymous pages (aka the heap), but not when a page is freed, but when it is reassigned. > A couple of exerpts from the paper that are causing most of my confusion: > > > "We wrote Windows and Linux versions of software de- > signed to measure long-term data lifetime and installed > it on several systems we and our colleagues use for ev- > eryday work. At installation time, the Linux version > allocates 64 MB of memory and fills it with 20-byte > "stamps," each of which contains a magic number, a se- > rial number, and a checksum. Then, it returns the mem- > ory to the system and terminates. > ... > In the best case, the Linux server, only 23 KB of stamps remained after 14 > days. > ... > A closer look found most data retained over the > long term to lie in holes in pages owned by the Linux > slab allocator, which divides pages into smaller blocks > of equal size for piecemeal use. Most block sizes do > not fit evenly into the page size, so leftover space (up > to hundreds of bytes worth) follows the final block in a > slab, and some blocks also contain data members that are > rarely used. This unused space retains data as long as the > slab page itself persists?at least as long as any block in > the page is in use and ordinarily longer?and slab pages > tend to be deallocated in large numbers only under mem- > ory pressure. Thus, we expect data that falls into a hole > in a slab to persist for a long time on an ordinarily loaded > system, explaining our observations. > ... This is about the kernel memory allocator, this has nothing to do with userland pages! > To augment kernel allocators to provide secure deallo- > cation, we began with large, page-granular allocations, > handled by the Linux page allocator. We added a bit > to the page structure to allow pages to be individually > marked polluted, that is, containing (possibly) sensitive > data. This bit has an effect only when a page is freed, not > while it is still in use. > Whereas an unmodified Linux 2.4 kernel maintains > only one set of free pages, our modified kernel divides > free pages into three pools. The not-zeroed pool holds > pages whose contents are not sensitive but not (known to > be) zeroed. The zeroed pool holds pages that have been > cleared to zeros. The polluted pool holds free pages with > sensitive contents. > > ... > > With an unmodified kernel, we found many tainted > regions in kernel and user space following the experi- > ments. > ... > All of these buffers contained the full password in cleartext That shouldn't happen, and any occurence of such a bug should be taken up with the Linux kernel security officers (security@xxxxxxxxxxxxxxx). > I am reading up more on how the page and slab allocators work, but this is > scaring me. I don't think it has much relevance anymore, the paper already says that there are already bugs fixed. Just be sure to run the latest stable kernel (2.6.20.4 right now). The data leaks the paper talks about are from kernel space to swap (fix permissions on swap device), network packets, and the ext2 filesystem. It doesn't say anything about direct leaks to userspace pages. (oh, and when you're root you can read the swap device, but once you're root you can also read every process memory space, so all bets are off anyway). Erik - -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGEoIN/PlVHJtIto0RAkFjAJ4kh18C5pVkcsLT1i2Sg3gQCduMRwCeI+5T oA+nrHWxrgYa32rYP/AMwlE= =nRmM -----END PGP SIGNATURE----- -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
