linux-ext4 - Re: simplify ext4_sb_read

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]

Date:   Sun, 05 Jun 2022 02:23:26 -0400
From:   Gabriel Krisman Bertazi <krisman@...labora.com>
To:     "Stephen E. Baker" <baker.stephen.e@...il.com>
Cc:     amstan@...omium.org, "Theodore Ts'o" <tytso@....edu>,
        linux-ext4@...r.kernel.org
Subject: Re: simplify ext4_sb_read_encoding regression

"Stephen E. Baker" <baker.stephen.e@...il.com> writes:

> On Sat, Jun 4, 2022 at 8:11 PM Stephen E. Baker
> <baker.stephen.e@...il.com> wrote:
>>
>> I reached out on the archlinuxarm IRC room and amstan offered the use
>> of his device.
>>
>> When he boots my image he sees:
>> "EXT4-fs (sda2): can't mount with superblock charset: utf8-12.1.0 not
>> supported by the kernel. flags: 0x0."
>
> At amstan's request I created a new root filesystem without casefold,
> and created a loop device with casefold enabled. I am able to boot
> with that filesystem.
>
> zgrep UNICODE /proc/config
> CONFIG_UNICODE=y
> CONFIG_UNICODE_UTF8_DATA=y
> CONFIG_UNICODE_NORMALIZATION_SELFTEST=m
>
> mount /dev/loop0p1 /mnt
> [ 679.358591] EXT-fs (loop0p1): can't mount with superblock charset:
> utf8-12.1.0 not supported by the kernel. flags: 0x0

That is great news.  It should allow us to do more investigation.  This
message can unfortunately come from a few error cases, but, most likely,
it is from a failure to get the utf8_data_table symbol.

Since you don't need the module to boot this kernel anymore now that
your rootfs is no longer casefolded, can you try building with
CONFIG_UNICODE=m, modprobe the module, and see if you can mount
/dev/loop0p1 successfully?  If it works, we should be able to discard
the steps being done to generate the bootable uimg and the flashing from
the equation being done at [1].

I've built a vanilla aarch64 kernel and ran over qemu, but I haven't
been able to reproduce it, or notice anything out of the ordinary in the
symbols.  It makes this bug quite puzzling at the moment.

[1] https://github.com/archlinuxarm/PKGBUILDs/blob/30c181baea493effe3bea7b3a2c3ec6ee62b41ae/core/linux-aarch64/PKGBUILD#L201-L228.

-- 
Gabriel Krisman Bertazi