lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 9 Sep 2010 13:23:38 -0600
From:	Andreas Dilger <adilger.kernel@...ger.ca>
To:	Jan Kara <jack@...e.cz>
Cc:	Masayoshi MIZUMA <m.mizuma@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] [RESEND] ext3: set i_extra_isize of 11th inode

On 2010-09-09, at 10:38, Jan Kara wrote:
>  Sigh, sorry to bring this up again... I wanted to use the original patch
> with the workaround you suggested but realized there's still a hole. The
> new patched kernel will happily use extra inode space for xattrs for inode
> 11 but if you mount the filesystem with older kernel it will reset
> i_extra_size to zero and thus you'll lose the stored xattrs.
>  So to get out of this compatibility trap we'd have to accept xattrs in
> the extended inode space but never store it there and after a sufficiently
> long time, we could remove the workaround. But this seems not worth the
> effort to me given we speak about a single inode and rather trivial
> workaround in ext3_iget and ext3_new_inode.

The old saying goes "Be strict in what you send, but generous in what you receive", so I think it makes sense that we allow reading xattrs from inode #11 (and also the root inode #2 is affected), and as you suggest we should only store these xattrs in external blocks.

The unfortunate thing is that xatts on the root inode will probably be the most heavily used, but it will also most likely be in cache so it probably won't be a serious performance issue (it can't be any worse than it is today).

While I think it would be slightly less complex to deny in-inode xattrs entirely, that doesn't give us any path toward actually removing this problem.

Of course, I think in the next 6 months or so (once ext4 is the default on RHEL6, widely in use at Google, and available on SLES11 SP1) we should probably consider ext4 stable enough that we should consider removing ext3 entirely from the tree and just have the "ext3" filesystem type be handled by ext4 as well.

Cheers, Andreas.--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists