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

[Matthew Wilcox <matthew@wil.cx>]

On Fri, Nov 17, 2006 at 08:43:00AM -0500, Jeff Layton wrote:
> 2) this scheme would effectively leak inode addresses into userspace.
> I'm not sure if that would be exploitable, but it's probably best not to
> do it. The patch adds a static unsigned int that is initialized to a
> random value at boot time. We'll xor the inode offset with this value.
> That should allow for a unique i_ino value, but since the xor mask would
> be secret, it shouldn't be possible to turn it back into an address.
> There may be a more secure way to do this. I'm definitely open to
> suggestions here.

I *think* the xor mask is mere obfuscation.  It looks likely that you can
recover it with a little bit of trial and error.  If you can force the
filesystem to hand you back new inodes quickly such that there is a high
probability you get consecutive allocations, you'll get a sequence which
would be spaced 700-odd bytes apart, except that it's been xored.  Since
you know it's incrementing, if you see the sequence decrease, you'll
know that was a 1 in that bit.

It'd be a bit more complex than that, and cryptanalysis was never my
forte, but I suspect we should either use a folded hash like md5, or
give up and just divide the address by sizeof(struct inode).  Sure,
divides are slow, but this is a divide by a constant, so it shouldn't be
that bad.