2019-05-27 08:55:01 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2010-02-16 20:31:19 +08:00
|
|
|
/*
|
2005-04-16 15:20:36 -07:00
|
|
|
* Cryptographic API.
|
|
|
|
|
*
|
|
|
|
|
* CRC32C chksum
|
|
|
|
|
*
|
2008-11-07 15:11:47 +08:00
|
|
|
*@Article{castagnoli-crc,
|
|
|
|
|
* author = { Guy Castagnoli and Stefan Braeuer and Martin Herrman},
|
|
|
|
|
* title = {{Optimization of Cyclic Redundancy-Check Codes with 24
|
|
|
|
|
* and 32 Parity Bits}},
|
|
|
|
|
* journal = IEEE Transactions on Communication,
|
|
|
|
|
* year = {1993},
|
|
|
|
|
* volume = {41},
|
|
|
|
|
* number = {6},
|
|
|
|
|
* pages = {},
|
|
|
|
|
* month = {June},
|
|
|
|
|
*}
|
2020-07-30 19:39:21 -07:00
|
|
|
* Used by the iSCSI driver, possibly others, and derived from
|
2008-11-07 15:11:47 +08:00
|
|
|
* the iscsi-crc.c module of the linux-iscsi driver at
|
|
|
|
|
* http://linux-iscsi.sourceforge.net.
|
2005-04-16 15:20:36 -07:00
|
|
|
*
|
2008-11-07 15:11:47 +08:00
|
|
|
* Following the example of lib/crc32, this function is intended to be
|
|
|
|
|
* flexible and useful for all users. Modules that currently have their
|
|
|
|
|
* own crc32c, but hopefully may be able to use this one are:
|
|
|
|
|
* net/sctp (please add all your doco to here if you change to
|
|
|
|
|
* use this one!)
|
|
|
|
|
* <endoflist>
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2004 Cisco Systems, Inc.
|
2008-07-08 20:54:28 +08:00
|
|
|
* Copyright (c) 2008 Herbert Xu <herbert@gondor.apana.org.au>
|
2005-04-16 15:20:36 -07:00
|
|
|
*/
|
2008-07-08 20:54:28 +08:00
|
|
|
|
2024-10-01 15:35:57 -04:00
|
|
|
#include <linux/unaligned.h>
|
2008-07-08 20:54:28 +08:00
|
|
|
#include <crypto/internal/hash.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/string.h>
|
2006-08-06 23:03:08 +10:00
|
|
|
#include <linux/kernel.h>
|
2012-03-23 15:02:25 -07:00
|
|
|
#include <linux/crc32.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-07-08 20:54:28 +08:00
|
|
|
#define CHKSUM_BLOCK_SIZE 1
|
2005-04-16 15:20:36 -07:00
|
|
|
#define CHKSUM_DIGEST_SIZE 4
|
|
|
|
|
|
|
|
|
|
struct chksum_ctx {
|
2006-08-06 23:03:08 +10:00
|
|
|
u32 key;
|
2005-04-16 15:20:36 -07:00
|
|
|
};
|
|
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_desc_ctx {
|
|
|
|
|
u32 crc;
|
|
|
|
|
};
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
2020-07-30 19:39:21 -07:00
|
|
|
* Steps through buffer one byte at a time, calculates reflected
|
2005-04-16 15:20:36 -07:00
|
|
|
* crc using table.
|
|
|
|
|
*/
|
|
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
static int chksum_init(struct shash_desc *desc)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_ctx *mctx = crypto_shash_ctx(desc->tfm);
|
|
|
|
|
struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
|
|
|
|
|
|
|
|
|
|
ctx->crc = mctx->key;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
return 0;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
2008-09-09 17:23:07 +10:00
|
|
|
static int chksum_setkey(struct crypto_shash *tfm, const u8 *key,
|
2006-08-13 14:16:39 +10:00
|
|
|
unsigned int keylen)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_ctx *mctx = crypto_shash_ctx(tfm);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
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(mctx->key))
|
2005-04-16 15:20:36 -07:00
|
|
|
return -EINVAL;
|
2018-05-19 22:07:38 -07:00
|
|
|
mctx->key = get_unaligned_le32(key);
|
2005-04-16 15:20:36 -07:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
static int chksum_update(struct shash_desc *desc, const u8 *data,
|
|
|
|
|
unsigned int length)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
lib/crc32: standardize on crc32c() name for Castagnoli CRC32
For historical reasons, the Castagnoli CRC32 is available under 3 names:
crc32c(), crc32c_le(), and __crc32c_le(). Most callers use crc32c().
The more verbose versions are not really warranted; there is no "_be"
version that the "_le" version needs to be differentiated from, and the
leading underscores are pointless.
Therefore, let's standardize on just crc32c(). Remove the other two
names, and update callers accordingly.
Specifically, the new crc32c() comes from what was previously
__crc32c_le(), so compared to the old crc32c() it now takes a size_t
length rather than unsigned int, and it's now in linux/crc32.h instead
of just linux/crc32c.h (which includes linux/crc32.h).
Later patches will also rename __crc32c_le_combine(), crc32c_le_base(),
and crc32c_le_arch().
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20250208024911.14936-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2025-02-07 18:49:09 -08:00
|
|
|
ctx->crc = crc32c(ctx->crc, data, length);
|
2006-08-06 23:03:08 +10:00
|
|
|
return 0;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
static int chksum_final(struct shash_desc *desc, u8 *out)
|
2008-07-08 20:54:28 +08:00
|
|
|
{
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
|
2008-07-08 20:54:28 +08:00
|
|
|
|
2018-05-19 22:07:38 -07:00
|
|
|
put_unaligned_le32(~ctx->crc, out);
|
2008-07-08 20:54:28 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
static int __chksum_finup(u32 *crcp, const u8 *data, unsigned int len, u8 *out)
|
2008-07-08 20:54:28 +08:00
|
|
|
{
|
lib/crc32: standardize on crc32c() name for Castagnoli CRC32
For historical reasons, the Castagnoli CRC32 is available under 3 names:
crc32c(), crc32c_le(), and __crc32c_le(). Most callers use crc32c().
The more verbose versions are not really warranted; there is no "_be"
version that the "_le" version needs to be differentiated from, and the
leading underscores are pointless.
Therefore, let's standardize on just crc32c(). Remove the other two
names, and update callers accordingly.
Specifically, the new crc32c() comes from what was previously
__crc32c_le(), so compared to the old crc32c() it now takes a size_t
length rather than unsigned int, and it's now in linux/crc32.h instead
of just linux/crc32c.h (which includes linux/crc32.h).
Later patches will also rename __crc32c_le_combine(), crc32c_le_base(),
and crc32c_le_arch().
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20250208024911.14936-5-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
2025-02-07 18:49:09 -08:00
|
|
|
put_unaligned_le32(~crc32c(*crcp, data, len), out);
|
2008-07-08 20:54:28 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
static int chksum_finup(struct shash_desc *desc, const u8 *data,
|
|
|
|
|
unsigned int len, u8 *out)
|
2008-07-08 20:54:28 +08:00
|
|
|
{
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
|
2008-07-08 20:54:28 +08:00
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
return __chksum_finup(&ctx->crc, data, len, out);
|
2008-07-08 20:54:28 +08:00
|
|
|
}
|
|
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
static int chksum_digest(struct shash_desc *desc, const u8 *data,
|
|
|
|
|
unsigned int length, u8 *out)
|
2008-07-08 20:54:28 +08:00
|
|
|
{
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_ctx *mctx = crypto_shash_ctx(desc->tfm);
|
2008-07-08 20:54:28 +08:00
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
return __chksum_finup(&mctx->key, data, length, out);
|
2008-07-08 20:54:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int crc32c_cra_init(struct crypto_tfm *tfm)
|
|
|
|
|
{
|
2008-09-09 17:23:07 +10:00
|
|
|
struct chksum_ctx *mctx = crypto_tfm_ctx(tfm);
|
2008-07-08 20:54:28 +08:00
|
|
|
|
2008-09-09 17:23:07 +10:00
|
|
|
mctx->key = ~0;
|
2008-07-08 20:54:28 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
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 = {
|
2024-10-16 20:57:25 +02:00
|
|
|
.digestsize = CHKSUM_DIGEST_SIZE,
|
|
|
|
|
.setkey = chksum_setkey,
|
|
|
|
|
.init = chksum_init,
|
|
|
|
|
.update = chksum_update,
|
|
|
|
|
.final = chksum_final,
|
|
|
|
|
.finup = chksum_finup,
|
|
|
|
|
.digest = chksum_digest,
|
|
|
|
|
.descsize = sizeof(struct chksum_desc_ctx),
|
|
|
|
|
|
|
|
|
|
.base.cra_name = "crc32c",
|
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 = "crc32c-lib",
|
2024-10-16 20:57:25 +02:00
|
|
|
.base.cra_priority = 100,
|
|
|
|
|
.base.cra_flags = CRYPTO_ALG_OPTIONAL_KEY,
|
|
|
|
|
.base.cra_blocksize = CHKSUM_BLOCK_SIZE,
|
|
|
|
|
.base.cra_ctxsize = sizeof(struct chksum_ctx),
|
|
|
|
|
.base.cra_module = THIS_MODULE,
|
|
|
|
|
.base.cra_init = crc32c_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
|
|
|
};
|
2024-12-01 17:08:29 -08:00
|
|
|
|
2008-04-05 21:00:57 +08:00
|
|
|
static int __init crc32c_mod_init(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
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);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
2008-04-05 21:00:57 +08:00
|
|
|
static void __exit crc32c_mod_fini(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
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);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
2025-04-30 16:17:02 +08:00
|
|
|
module_init(crc32c_mod_init);
|
2008-04-05 21:00:57 +08:00
|
|
|
module_exit(crc32c_mod_fini);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Clay Haapala <chaapala@cisco.com>");
|
|
|
|
|
MODULE_DESCRIPTION("CRC32c (Castagnoli) calculations wrapper for lib/crc32c");
|
|
|
|
|
MODULE_LICENSE("GPL");
|
2014-11-20 17:05:53 -08:00
|
|
|
MODULE_ALIAS_CRYPTO("crc32c");
|