From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via pointer conversion) Date: Fri, 17 Nov 2006 07:24:35 -0700 Message-ID: <20061117142435.GC18567@parisc-linux.org> References: <1163770980.13410.39.camel@dantu.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:11751 "EHLO mail.parisc-linux.org") by vger.kernel.org with ESMTP id S933617AbWKQOYg (ORCPT ); Fri, 17 Nov 2006 09:24:36 -0500 To: Jeff Layton Content-Disposition: inline In-Reply-To: <1163770980.13410.39.camel@dantu.rdu.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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.