On Fri, 2006-11-17 at 10:06 -0500, Jeff Layton wrote: > On Fri, 2006-11-17 at 09:01 -0600, Dave Kleikamp wrote: > > > Wouldn't you only be able to only crack a few of the low-order bits due > > to a cluster of inodes being sequential? I don't think you'd be able > > crack enough of it to be useful. You may be able to determine where > > some inodes are relative to others, but I don't think you'd be able to > > point the their location in memory. I don't know anything about crypto, > > so I could be wrong. > > > > On a 64-bit kernel, that would be the case. On a 32-bit kernel, there > are no high order bits to chop off, so this would effectively give you > the address.
By a few of the low-order bits, I mean very few, not 32. The slab allocator generally allocates one page at a time, so you typically don't get more than about 6 inodes in a slab page. Even if you consider that you may be able allocate several slab pages together, it would be hard to get very many contiguous pages of inode slab cache. Even if it were possible to force the system to allocate around 256 contiguous inodes, you would still only be able to determine 8 bits out of 32. At most one or two more if you could determine a pattern of inode numbers that would be skipped due to the inclusion of struct inode within the fs-dependent inode structure. I may be wrong, but I doubt that someone could determine the entire mask from the observed i_ino's. Shaggy -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
