linux-ext4 - Re: Detecting default signedness of char in ext4 (despite -funsigned-char)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y8ju/CuPWA2lTR3W@sol.localdomain>
Date:   Wed, 18 Jan 2023 23:19:24 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     Theodore Ts'o <tytso@....edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Eric Whitney <enwlinux@...il.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Masahiro Yamada <masahiroy@...nel.org>
Subject: Re: Detecting default signedness of char in ext4 (despite
 -funsigned-char)

On Wed, Jan 18, 2023 at 03:20:03PM -0700, Andreas Dilger wrote:
> > In terms of what should we do for next steps, if we only pick signed,
> > then it's possible if there are some edge case users who actually did
> > use non-ASCII characters in the xattr name on PowerPC, ARM, or S/390,
> > they would be broken.  That's simpler, and if we think there are
> > darned few of them, I guess we could do that.
> > 
> > That being said, it's not that much more work to use a flag in the
> > superblock to indicate whether or not we should be explicitly casting
> > *name to either a signed or unsigned char, and then setting that flag
> > automagically to avoid problems on people who started the file system
> > on say, x86 before the signed to unsigned char transition, and who
> > started natively on a PowerPC, ARM, or S/390.
> > 
> > The one bit which makes this a bit more complex is either way, we need
> > to change both the kernel and e2fsprogs, which is why if we do the
> > signed/unsigned xattr hash flag, it's important to set the flag value
> > to be whatever the "default" signeded would be on that architecture
> > pre 6.2-rc1.
> 
> It makes sense to use the existing UNSIGNED/SIGNED flag in the superblock
> for the dir hash also for the xattr hash.  That would give the historical
> value for the xattr hashes prior to the 6.2 unsigned char change, and is
> correct for all filesystems and xattrs *except* non-ASCII xattr names
> created on 6.2+ kernels (which should indeed be relatively few cases).
> 
> e2fsck could do the same, and would again be correct for all xattrs names
> except those created with kernel 6.2+.  It could check both the signed
> and unsigned forms and correct those few that are reversed compared to
> the superblock flag, which should be rare, but isn't much work and avoids
> incorrectly clearing the "corrupted" xattrs.

Reusing the existing SIGNED/UNSIGNED dirhash superblock flag wouldn't work in
the case where a filesystem is created on x86, then flashed to an ARM device.
That's exactly how Android works.  The dirhash is then explicitly SIGNED,
whereas the xattr hash is implicitly unsigned.

Yes, that case has always been broken if there were non-ASCII xattr names in the
filesystem to begin with, before it was flashed to the device.  That doesn't
really happen though.  What *is* plausible is that some random application
running on the device uses non-ASCII xattr names.

So to be safe, a new pair of SIGNED/UNSIGNED superblock flags for the xattr hash
would be needed.  The existing pair would be for the dirhash only.

- Eric