linux-kernel - Re: Question : ext2 compatibility feature mechanism

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]

Message-ID: <20080825144132.GO1408@mit.edu>
Date:	Mon, 25 Aug 2008 10:41:32 -0400
From:	Theodore Tso <tytso@....edu>
To:	ohyama_sec@...el-networks.com
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Question : ext2 compatibility feature mechanism

On Mon, Aug 25, 2008 at 09:04:48PM +0900, ohyama_sec@...el-networks.com wrote:
> 
> Could you please give me the documents that is written about ext2
> filesystem at length, especially compatibility feature mechanism.

Please check out the Articles and Publiciations page on the ext4 wiki:

       http://ext4.wiki.kernel.org/index.php/Publications

The short version for how the compatibility feature mechanism works is
that there are three bitmasks, compat, rocompat, and incompat.  The
ext2/ext3/ext4 filesystem code in the kernel uses the these feature
bitmasks to test for the presence of features it understands, and will
read and write to the filesystem appropriately depending on which
features are enabled.

For bits in the feature bitmasks that the filesystem does not
recognize, bits in the "compat" bitmask are assumed to be changes that
are fully forwards compatible, so an implementation which sees a bit
in the "compat" bitmask which it doesn't understand should still feel
free to mount the filesystem and modify it as necessary.  If an
implementation sees a bit in the "rocompat" bitmask that it does not
understand, it is safe to mount the filesystem read/only, but
modifying the filesystem may likely damage the filesystem.  And if an
implementation sees a bit in the "incompat" bitmask that it does not
understand, it should reject mounting the filesystem entirely,
read/only or read/write.

E2fsck uses a much more stringent standard, in that if there are any
bits in the bitmask that it does not undersatnd, it will refuse to
touch the filesystem altogether, lest it damage the filesystem and
lose data as it tries to repair it.

Regards,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/