linux-ext4 - Re: uninit_bg compatibility?

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:	Tue, 21 Sep 2010 13:59:12 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Bo Brantén <bosse@....umu.se>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: uninit_bg compatibility?

On Tue, Sep 21, 2010 at 03:28:51PM +0200, Bo Brantén wrote:
> 
> when writing new files to an ext4 file system using the Windows
> driver fsck will later complain "Group descriptor nn checksum is
> invalid" and I think that is because it used an yet unused block
> group without knowing that they can be marked as uninitialized. So I
> thought a simple patch would be to mount the file system read-only
> if that feature is in use untill the driver is updated with full
> write support but I can't find the flag to use, there is no
> EXT4_FEATURE_RO_COMPAT_UNINIT_BG so I thought I ask here if anyone
> could clear this out.

Yeah, this is one where we decided to change the feature to uninit_bg
(since that describes the net benefit to the end-user), but we never
ended up changing the name of the flag in the source code.  The
feature flag in question is:

#define EXT4_FEATURE_RO_COMPAT_GDT_CSUM		0x0010

I'll note that the Windows driver must not be checking the feature
flags, since the whole point of RO_COMPAT flags is that if a file
system implementation (such as the Windows drivers) sees an RO_COMPAT
flag it doesn't understand, it's supposed to treat the file system as
read-only.

						- 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