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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ