linux-ext4 - Re: [RESEND PATCH 2/2] ext4: ext4_inode_is_fast

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:	Mon, 6 Jan 2014 14:45:35 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Yongqiang Yang <xiaoqiangnk@...il.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [RESEND PATCH 2/2] ext4: ext4_inode_is_fast_symlink should use
 cluster size

On Mon, Jan 06, 2014 at 10:47:03AM -0700, Andreas Dilger wrote:
> What about the idea to stop using the blocks count for doing the
> fast/slow symlink check, and instead use i_size?  IMHO this is far
> more robust than using the blocks count, since we've repeatedly seen
> bugs when the number of blocks allocated to an inode changes for
> done reason (e.g. xattrs, bigalloc, multi-block xattrs in the
> future).

I did see your earlier proposal on this front, but I didn't want to
this change without thinking about it a bit more closely.  In
particular, we probably would want to enforce this change in e2fsck
for a while first.

Currently, if we have a slow symlink where i_size is less than 60
bytes, both e2fsprogs and the kernel handles this case.  See the
attached file system image.

Yes, I created it synthetically, but keep in mind that that there are
other implementations of ext2/3/4 other than just in the Linux kernel.
In particular, the GNU Hurd and *BSD have their own independent
implementation of ext2.  So even if the Linux kernel has never created
a slow symlink with i_size <= 60 bytes, but that doesn't mean that
it's for certain that there are no such implementations out there in the wild.

That doesn't mean that we should never make such a change, but it does
mean that it's not something I want to do lightly.

							- Ted
--
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