Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <3A9E6D2E-F98F-461C-834D-D4E269CC737F@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_F5CEB163-EA7D-4B9A-ABEA-18C72CE99631";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Detecting default signedness of char in ext4 (despite
 -funsigned-char)
Date:   Wed, 18 Jan 2023 15:20:03 -0700
In-Reply-To: <Y8hpZRmHJwdutRr2@mit.edu>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Eric Biggers <ebiggers@kernel.org>,
        Ext4 Developers List <linux-ext4@vger.kernel.org>,
        Eric Whitney <enwlinux@gmail.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Masahiro Yamada <masahiroy@kernel.org>
To:     Theodore Ts'o <tytso@mit.edu>
References: <Y8bpkm3jA3bDm3eL@debian-BULLSEYE-live-builder-AMD64>
 <7DE6598D-B60D-466F-8771-5FEC0FDEC57F@dilger.ca>
 <Y8dtze3ZLGaUi8pi@sol.localdomain>
 <CAHk-=whUNjwqZXa-MH9KMmc_CpQpoFKFjAB9ZKHuu=TbsouT4A@mail.gmail.com>
 <Y8eAJIKikCTJrlcr@sol.localdomain> <Y8hUCIVImjqCmEWv@mit.edu>
 <CAHk-=wiGdxWtHRZftcqyPf8WbenyjniesKyZ=o73UyxfK9BL-A@mail.gmail.com>
 <Y8hpZRmHJwdutRr2@mit.edu>
Precedence: bulk


--Apple-Mail=_F5CEB163-EA7D-4B9A-ABEA-18C72CE99631
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Jan 18, 2023, at 12:39 PM, Linus Torvalds =
<torvalds@linux-foundation.org> wrote:
>> Note that the reason I'm so laissez-faire about it is that "broken
>> test case" is something very different from "actually broken user
>> space".
>>=20
>> I haven't actually seen anybody _report_ this as a problem, I've only
>> seen the generic/454 xfstest failures.

That is likely because the number of 6.2+ kernel users who are using
Unicode xattr names is small, but they would likely come out of the
woodwork once Ubuntu/RHEL start using those kernels, and by then it
would be too late to fix this in a compatible manner.

> On Wed, Jan 18, 2023 at 03:14:04PM -0600, Linus Torvalds wrote:
>> You're missing the fact that 'char' gets expanded to 'int', and in =
the
>> process but #7 gets copied to bits 8-31 if it is signed.
>>=20
>> Then the xor and the later shifting will move those bits around..
>=20
> I agree with your analysis that in actual practice, almost no one
> actually uses non-ASCII characters for xattr names.  (Filenames, yes,
> but in general xattr names are set by programs, not by users.)  So
> besides xfstests generic/454, how likely is it that people would be
> using things like Octopus emoji's or Unicode characters such as <GREEK
> UPSILON WITH ACUTE AND HOOK SYMBOL>?  Very unlikely, I'd argue.  I
> might be a bit more worried about userspace applications written for,
> say, Red Flag Linux in China using chinese characters in xattrs, but
> I'd argue even there it's much more likely that this would be in the
> xattr values as opposed to the name.
>=20
> 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.
>=20
> 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.
>=20
> 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.

Cheers, Andreas


--Apple-Mail=_F5CEB163-EA7D-4B9A-ABEA-18C72CE99631
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmPIcJQACgkQcqXauRfM
H+DgYBAAioolu1HjArjRqCPToB/HV1wErzLCZXbd0rGyA99KJABUXqxOv9UXJ6L6
BgoPb2xFM4OE+8Z5gMMD644AKL0WS2Wl67v/OKsS71f0dZ5v6F51ywEQVafx4GaC
LBodsJsyb+6aTPFUK8v6EMh/3fM7Com5sPJge10Wdy8+k8y58cE8QWUD2/NgOdyw
8GA2n2UYKpcRGYAoaJbhn8QVe1aUXVHJ3xHkja3IPdBENokUAmaaK1+uSfZxj5FR
OQpW03mjdVbzAqssZjcRHFBcbvRwdq0WP+WEjieY84Q0pcOrWMio4UIzd4JAmUT5
A1q9730Epc0noWrxjs7kvOweDw3MzDWuUiSHbvnmq91RK1ruA0OMrLqlSJIv3807
zHvb2gmD+IOmXCIIGTPYS/XLIMnFh/eNGHzhwC37DdIA7nXFUt2BAUTYJC/8sw/w
2aOgt7DTcUpMiGJBayh0WAsZv/TMDB/Tqy53I3GtingF50HXmvrRZFiq6lJgqIzx
txaXMiDvwQL/JL+MD/dtKTVryN43WeLpboTIH2Xsz2LJ9azXUKDuel1ptFU6vPLP
UZ5iemJrKzOF4RJd9tGYR2MFocmho08a8R3/USMdSnYVKuDkQ7RpMuOjGYiKoPxH
i5lOAwb3sORs8CwFnWEQmsZdPvKSk40DcpskX1dEgYsVAVjqlss=
=uEc0
-----END PGP SIGNATURE-----

--Apple-Mail=_F5CEB163-EA7D-4B9A-ABEA-18C72CE99631--