milos-linux/crypto/crc32.c

129 lines
2.8 KiB
C
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright 2012 Xyratex Technology Limited
*/
/*
* This is crypto api shash wrappers to crc32_le.
*/
#include <linux/unaligned.h>
#include <linux/crc32.h>
#include <crypto/internal/hash.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/string.h>
#include <linux/kernel.h>
#define CHKSUM_BLOCK_SIZE 1
#define CHKSUM_DIGEST_SIZE 4
/** No default init with ~0 */
static int crc32_cra_init(struct crypto_tfm *tfm)
{
u32 *key = crypto_tfm_ctx(tfm);
*key = 0;
return 0;
}
/*
* Setting the seed allows arbitrary accumulators and flexible XOR policy
* If your algorithm starts with ~0, then XOR with ~0 before you set
* the seed.
*/
static int crc32_setkey(struct crypto_shash *hash, const u8 *key,
unsigned int keylen)
{
u32 *mctx = crypto_shash_ctx(hash);
crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. Also, many algorithms fail to set this flag when given a bad length key. Reviewing just the generic implementations, this is the case for aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably many more in arch/*/crypto/ and drivers/crypto/. Some algorithms can even set this flag when the key is the correct length. For example, authenc and authencesn set it when the key payload is malformed in any way (not just a bad length), the atmel-sha and ccree drivers can set it if a memory allocation fails, and the chelsio driver sets it for bad auth tag lengths, not just bad key lengths. So even if someone actually wanted to start checking this flag (which seems unlikely, since it's been unused for a long time), there would be a lot of work needed to get it working correctly. But it would probably be much better to go back to the drawing board and just define different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-30 21:19:36 -06:00
if (keylen != sizeof(u32))
return -EINVAL;
*mctx = get_unaligned_le32(key);
return 0;
}
static int crc32_init(struct shash_desc *desc)
{
u32 *mctx = crypto_shash_ctx(desc->tfm);
u32 *crcp = shash_desc_ctx(desc);
*crcp = *mctx;
return 0;
}
static int crc32_update(struct shash_desc *desc, const u8 *data,
unsigned int len)
{
u32 *crcp = shash_desc_ctx(desc);
*crcp = crc32_le(*crcp, data, len);
return 0;
}
/* No final XOR 0xFFFFFFFF, like crc32_le */
crypto/crc32[c]: register only "-lib" drivers For the "crc32" and "crc32c" shash algorithms, instead of registering "*-generic" drivers as well as conditionally registering "*-$(ARCH)" drivers, instead just register "*-lib" drivers. These just use the regular library functions crc32_le() and crc32c(), so they just do the right thing and are fully accelerated when supported by the CPU. This eliminates the need for the CRC library to export crc32_le_base() and crc32c_base(). Separate commits make those static functions. Since this commit removes the "crc32-generic" and "crc32c-generic" driver names which crypto/testmgr.c expects to exist, update testmgr.c accordingly. This does mean that testmgr.c will no longer fuzz-test the "generic" implementation against the "arch" implementation for crc32 and crc32c, but this was redundant with crc_kunit anyway. Besides the above, and btrfs_init_csum_hash() which the previous commit fixed, no code appears to have been relying on the "crc32-generic" or "crc32c-generic" driver names specifically. btrfs does export the checksum name and checksum driver name in /sys/fs/btrfs/$uuid/checksum. This commit makes the driver name portion of that file contain "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)". This should be fine, since in practice the purpose of the driver name portion of this file seems to have been just to allow users to manually check whether they needed to enable the optimized CRC32C code. This was needed only because of the bug in old kernels where the optimized CRC32C code defaulted to off and even needed to be explicitly added to the ramdisk to be used. Now that it just works in Linux 6.14 and later, there's no need for users to take any action and the driver name portion of this is basically obsolete. (Also, note that the crc32c driver name already changed in 6.14.) Acked-by: David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20250613183753.31864-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-13 11:37:53 -07:00
static int __crc32_finup(u32 *crcp, const u8 *data, unsigned int len, u8 *out)
{
put_unaligned_le32(crc32_le(*crcp, data, len), out);
return 0;
}
static int crc32_finup(struct shash_desc *desc, const u8 *data,
unsigned int len, u8 *out)
{
return __crc32_finup(shash_desc_ctx(desc), data, len, out);
}
static int crc32_final(struct shash_desc *desc, u8 *out)
{
u32 *crcp = shash_desc_ctx(desc);
put_unaligned_le32(*crcp, out);
return 0;
}
static int crc32_digest(struct shash_desc *desc, const u8 *data,
unsigned int len, u8 *out)
{
return __crc32_finup(crypto_shash_ctx(desc->tfm), data, len, out);
}
crypto/crc32[c]: register only "-lib" drivers For the "crc32" and "crc32c" shash algorithms, instead of registering "*-generic" drivers as well as conditionally registering "*-$(ARCH)" drivers, instead just register "*-lib" drivers. These just use the regular library functions crc32_le() and crc32c(), so they just do the right thing and are fully accelerated when supported by the CPU. This eliminates the need for the CRC library to export crc32_le_base() and crc32c_base(). Separate commits make those static functions. Since this commit removes the "crc32-generic" and "crc32c-generic" driver names which crypto/testmgr.c expects to exist, update testmgr.c accordingly. This does mean that testmgr.c will no longer fuzz-test the "generic" implementation against the "arch" implementation for crc32 and crc32c, but this was redundant with crc_kunit anyway. Besides the above, and btrfs_init_csum_hash() which the previous commit fixed, no code appears to have been relying on the "crc32-generic" or "crc32c-generic" driver names specifically. btrfs does export the checksum name and checksum driver name in /sys/fs/btrfs/$uuid/checksum. This commit makes the driver name portion of that file contain "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)". This should be fine, since in practice the purpose of the driver name portion of this file seems to have been just to allow users to manually check whether they needed to enable the optimized CRC32C code. This was needed only because of the bug in old kernels where the optimized CRC32C code defaulted to off and even needed to be explicitly added to the ramdisk to be used. Now that it just works in Linux 6.14 and later, there's no need for users to take any action and the driver name portion of this is basically obsolete. (Also, note that the crc32c driver name already changed in 6.14.) Acked-by: David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20250613183753.31864-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-13 11:37:53 -07:00
static struct shash_alg alg = {
.setkey = crc32_setkey,
.init = crc32_init,
.update = crc32_update,
.final = crc32_final,
.finup = crc32_finup,
.digest = crc32_digest,
.descsize = sizeof(u32),
.digestsize = CHKSUM_DIGEST_SIZE,
.base.cra_name = "crc32",
crypto/crc32[c]: register only "-lib" drivers For the "crc32" and "crc32c" shash algorithms, instead of registering "*-generic" drivers as well as conditionally registering "*-$(ARCH)" drivers, instead just register "*-lib" drivers. These just use the regular library functions crc32_le() and crc32c(), so they just do the right thing and are fully accelerated when supported by the CPU. This eliminates the need for the CRC library to export crc32_le_base() and crc32c_base(). Separate commits make those static functions. Since this commit removes the "crc32-generic" and "crc32c-generic" driver names which crypto/testmgr.c expects to exist, update testmgr.c accordingly. This does mean that testmgr.c will no longer fuzz-test the "generic" implementation against the "arch" implementation for crc32 and crc32c, but this was redundant with crc_kunit anyway. Besides the above, and btrfs_init_csum_hash() which the previous commit fixed, no code appears to have been relying on the "crc32-generic" or "crc32c-generic" driver names specifically. btrfs does export the checksum name and checksum driver name in /sys/fs/btrfs/$uuid/checksum. This commit makes the driver name portion of that file contain "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)". This should be fine, since in practice the purpose of the driver name portion of this file seems to have been just to allow users to manually check whether they needed to enable the optimized CRC32C code. This was needed only because of the bug in old kernels where the optimized CRC32C code defaulted to off and even needed to be explicitly added to the ramdisk to be used. Now that it just works in Linux 6.14 and later, there's no need for users to take any action and the driver name portion of this is basically obsolete. (Also, note that the crc32c driver name already changed in 6.14.) Acked-by: David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20250613183753.31864-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-13 11:37:53 -07:00
.base.cra_driver_name = "crc32-lib",
.base.cra_priority = 100,
.base.cra_flags = CRYPTO_ALG_OPTIONAL_KEY,
.base.cra_blocksize = CHKSUM_BLOCK_SIZE,
.base.cra_ctxsize = sizeof(u32),
.base.cra_module = THIS_MODULE,
.base.cra_init = crc32_cra_init,
crypto/crc32[c]: register only "-lib" drivers For the "crc32" and "crc32c" shash algorithms, instead of registering "*-generic" drivers as well as conditionally registering "*-$(ARCH)" drivers, instead just register "*-lib" drivers. These just use the regular library functions crc32_le() and crc32c(), so they just do the right thing and are fully accelerated when supported by the CPU. This eliminates the need for the CRC library to export crc32_le_base() and crc32c_base(). Separate commits make those static functions. Since this commit removes the "crc32-generic" and "crc32c-generic" driver names which crypto/testmgr.c expects to exist, update testmgr.c accordingly. This does mean that testmgr.c will no longer fuzz-test the "generic" implementation against the "arch" implementation for crc32 and crc32c, but this was redundant with crc_kunit anyway. Besides the above, and btrfs_init_csum_hash() which the previous commit fixed, no code appears to have been relying on the "crc32-generic" or "crc32c-generic" driver names specifically. btrfs does export the checksum name and checksum driver name in /sys/fs/btrfs/$uuid/checksum. This commit makes the driver name portion of that file contain "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)". This should be fine, since in practice the purpose of the driver name portion of this file seems to have been just to allow users to manually check whether they needed to enable the optimized CRC32C code. This was needed only because of the bug in old kernels where the optimized CRC32C code defaulted to off and even needed to be explicitly added to the ramdisk to be used. Now that it just works in Linux 6.14 and later, there's no need for users to take any action and the driver name portion of this is basically obsolete. (Also, note that the crc32c driver name already changed in 6.14.) Acked-by: David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20250613183753.31864-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-13 11:37:53 -07:00
};
static int __init crc32_mod_init(void)
{
crypto/crc32[c]: register only "-lib" drivers For the "crc32" and "crc32c" shash algorithms, instead of registering "*-generic" drivers as well as conditionally registering "*-$(ARCH)" drivers, instead just register "*-lib" drivers. These just use the regular library functions crc32_le() and crc32c(), so they just do the right thing and are fully accelerated when supported by the CPU. This eliminates the need for the CRC library to export crc32_le_base() and crc32c_base(). Separate commits make those static functions. Since this commit removes the "crc32-generic" and "crc32c-generic" driver names which crypto/testmgr.c expects to exist, update testmgr.c accordingly. This does mean that testmgr.c will no longer fuzz-test the "generic" implementation against the "arch" implementation for crc32 and crc32c, but this was redundant with crc_kunit anyway. Besides the above, and btrfs_init_csum_hash() which the previous commit fixed, no code appears to have been relying on the "crc32-generic" or "crc32c-generic" driver names specifically. btrfs does export the checksum name and checksum driver name in /sys/fs/btrfs/$uuid/checksum. This commit makes the driver name portion of that file contain "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)". This should be fine, since in practice the purpose of the driver name portion of this file seems to have been just to allow users to manually check whether they needed to enable the optimized CRC32C code. This was needed only because of the bug in old kernels where the optimized CRC32C code defaulted to off and even needed to be explicitly added to the ramdisk to be used. Now that it just works in Linux 6.14 and later, there's no need for users to take any action and the driver name portion of this is basically obsolete. (Also, note that the crc32c driver name already changed in 6.14.) Acked-by: David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20250613183753.31864-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-13 11:37:53 -07:00
return crypto_register_shash(&alg);
}
static void __exit crc32_mod_fini(void)
{
crypto/crc32[c]: register only "-lib" drivers For the "crc32" and "crc32c" shash algorithms, instead of registering "*-generic" drivers as well as conditionally registering "*-$(ARCH)" drivers, instead just register "*-lib" drivers. These just use the regular library functions crc32_le() and crc32c(), so they just do the right thing and are fully accelerated when supported by the CPU. This eliminates the need for the CRC library to export crc32_le_base() and crc32c_base(). Separate commits make those static functions. Since this commit removes the "crc32-generic" and "crc32c-generic" driver names which crypto/testmgr.c expects to exist, update testmgr.c accordingly. This does mean that testmgr.c will no longer fuzz-test the "generic" implementation against the "arch" implementation for crc32 and crc32c, but this was redundant with crc_kunit anyway. Besides the above, and btrfs_init_csum_hash() which the previous commit fixed, no code appears to have been relying on the "crc32-generic" or "crc32c-generic" driver names specifically. btrfs does export the checksum name and checksum driver name in /sys/fs/btrfs/$uuid/checksum. This commit makes the driver name portion of that file contain "crc32c-lib" instead of "crc32c-generic" or "crc32c-$(ARCH)". This should be fine, since in practice the purpose of the driver name portion of this file seems to have been just to allow users to manually check whether they needed to enable the optimized CRC32C code. This was needed only because of the bug in old kernels where the optimized CRC32C code defaulted to off and even needed to be explicitly added to the ramdisk to be used. Now that it just works in Linux 6.14 and later, there's no need for users to take any action and the driver name portion of this is basically obsolete. (Also, note that the crc32c driver name already changed in 6.14.) Acked-by: David Sterba <dsterba@suse.com> Link: https://lore.kernel.org/r/20250613183753.31864-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-13 11:37:53 -07:00
crypto_unregister_shash(&alg);
}
module_init(crc32_mod_init);
module_exit(crc32_mod_fini);
MODULE_AUTHOR("Alexander Boyko <alexander_boyko@xyratex.com>");
MODULE_DESCRIPTION("CRC32 calculations wrapper for lib/crc32");
MODULE_LICENSE("GPL");
MODULE_ALIAS_CRYPTO("crc32");