linux-ext4 - ext4's dependency on crc32c

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

Message-ID: <73fc221b-400b-a749-4bca-e6854d361a9a@suse.com>
Date:   Tue, 1 Feb 2022 15:19:54 +0100
From:   Jan Beulich <jbeulich@...e.com>
To:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: ext4's dependency on crc32c

Hello,

in 5.16, due to (afaict) adad556efcdd ("crypto: api - Fix built-in
testing dependency failures") booting a system with cryptmgr.ko not
(perhaps manually) put in the initrd doesn't work when ext4.ko is
responsible for / . I've contacted Herbert already after finding
this issue with btrfs, but in the case of ext4 another aspect plays
into it: I've observed the problem on a system where ext4.ko is used
solely to service ext3 partitions (including / ), but aiui crc32c
isn't used at all in this case. Yet it's the attempt of loading it
which actually causes the mount (and hence booting) to fail.

If my understanding is correct, wouldn't it make sense to skip the
call to crypto_alloc_shash() unless an ext4 superblock is being
processed?

Thanks, Jan