Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via pointer conversion)

[Dave Kleikamp <shaggy@linux.vnet.ibm.com>]

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