aboutsummaryrefslogtreecommitdiff
path: root/lib/libcrc32c.c
AgeCommit message (Collapse)Author
2018-03-26libcrc32c: Add crc32c_impl functionNikolay Borisov
This function returns a string with the currently in-use implementation of the crc32c algorithm, i.e crc32c-generic (for unoptimised, generic implementation) or crc32c-intel for the sse optimised version. This will be used by btrfs. Signed-off-by: Nikolay Borisov <nborisov@suse.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> [ use crypto_shash_driver_name as suggested by Herbert ] Signed-off-by: David Sterba <dsterba@suse.com>
2017-06-08crypto: Work around deallocated stack frame reference gcc bug on sparc.David Miller
On sparc, if we have an alloca() like situation, as is the case with SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack memory. The result can be that the value is clobbered if a trap or interrupt arrives at just the right instruction. It only occurs if the function ends returning a value from that alloca() area and that value can be placed into the return value register using a single instruction. For example, in lib/libcrc32c.c:crc32c() we end up with a return sequence like: return %i7+8 lduw [%o5+16], %o0 ! MEM[(u32 *)__shash_desc.1_10 + 16B], %o5 holds the base of the on-stack area allocated for the shash descriptor. But the return released the stack frame and the register window. So if an intererupt arrives between 'return' and 'lduw', then the value read at %o5+16 can be corrupted. Add a data compiler barrier to work around this problem. This is exactly what the gcc fix will end up doing as well, and it absolutely should not change the code generated for other cpus (unless gcc on them has the same bug :-) With crucial insight from Eric Sandeen. Cc: <stable@vger.kernel.org> Reported-by: Anatoly Pugachev <matorola@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-01-22Merge branch 'linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes the following issues: API: - A large number of bug fixes for the af_alg interface, credit goes to Dmitry Vyukov for discovering and reporting these issues. Algorithms: - sw842 needs to select crc32. - The soft dependency on crc32c is now in the correct spot. Drivers: - The atmel AES driver needs HAS_DMA. - The atmel AES driver was a missing break statement, fortunately it's only a debug function. - A number of bug fixes for the Intel qat driver" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (24 commits) crypto: algif_skcipher - sendmsg SG marking is off by one crypto: crc32c - Fix crc32c soft dependency crypto: algif_skcipher - Load TX SG list after waiting crypto: atmel-aes - Add missing break to atmel_aes_reg_name crypto: algif_skcipher - Fix race condition in skcipher_check_key crypto: algif_hash - Fix race condition in hash_check_key crypto: CRYPTO_DEV_ATMEL_AES should depend on HAS_DMA lib: sw842: select crc32 crypto: af_alg - Forbid bind(2) when nokey child sockets are present crypto: algif_skcipher - Remove custom release parent function crypto: algif_hash - Remove custom release parent function crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path crypto: qat - update init_esram for C3xxx dev type crypto: qat - fix timeout issues crypto: qat - remove to call get_sram_bar_id for qat_c3xxx crypto: algif_skcipher - Add key check exception for cipher_null crypto: skcipher - Add crypto_skcipher_has_setkey crypto: algif_hash - Require setkey before accept(2) crypto: hash - Add crypto_ahash_has_setkey crypto: algif_skcipher - Add nokey compatibility path ...
2016-01-20lib/libcrc32c.c: fix build warningJean Delvare
Fix the following build warning: lib/libcrc32c.c:42:5: warning: no previous prototype for "crc32c" [-Wmissing-prototypes] u32 crc32c(u32 crc, const void *address, unsigned int length) ^ Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-01-19crypto: crc32c - Fix crc32c soft dependencyJean Delvare
I don't think it makes sense for a module to have a soft dependency on itself. This seems quite cyclic by nature and I can't see what purpose it could serve. OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty much assumes that some incarnation of the "crc32c" hash algorithm has been loaded. Therefore it makes sense to have the soft dependency there (as crc-t10dif does.) Cc: stable@vger.kernel.org Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-10-14crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.cJan-Simon Möller
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de> Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: pageexec@freemail.hu Cc: "David S. Miller" <davem@davemloft.net>
2014-06-04lib/libcrc32c.c: use PTR_ERR_OR_ZEROFabian Frederick
replace IS_ERR/PTR_ERR Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-12-25libcrc32c: Fix "crc32c undefined" compilation errorAdrian-Ken Rueegsegger
The latest shash changes leave crc32c undefined: [...] Building modules, stage 2. MODPOST 1381 modules ERROR: "crc32c" [net/sctp/sctp.ko] undefined! ERROR: "crc32c" [net/ipv4/netfilter/nf_nat_proto_sctp.ko] undefined! Adding EXPORT_SYMBOL(crc32c) to lib/libcrc32c.c fixes the compile error. This patch has been compile-tested only. Signed-off-by: Adrian-Ken Rueegsegger <rueegsegger@swiss-it.ch> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25libcrc32c: Move implementation to crypto crc32cHerbert Xu
This patch swaps the role of libcrc32c and crc32c. Previously the implementation was in libcrc32c and crc32c was a wrapper. Now the code is in crc32c and libcrc32c just calls the crypto layer. The reason for the change is to tap into the algorithm selection capability of the crypto API so that optimised implementations such as the one utilising Intel's CRC32C instruction can be used where available. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-11-08[LIB] crc32c: Keep intermediate crc state in cpu orderBenny Halevy
crypto/crc32.c:chksum_final() is computing the digest as *(__le32 *)out = ~cpu_to_le32(mctx->crc); so the low-level crc32c_le routines should just keep the crc in cpu order, otherwise it is getting swabbed one too many times on big-endian machines. Signed-off-by: Benny Halevy <bhalevy@fs1.bhalevy.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2007-10-18Replace __attribute_pure__ with __pureRalf Baechle
To be consistent with the use of attributes in the rest of the kernel replace all use of __attribute_pure__ with __pure and delete the definition of __attribute_pure__. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Cc: Russell King <rmk@arm.linux.org.uk> Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Bryan Wu <bryan.wu@analog.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-06-25[PATCH] constify libcrc32c tableAndreas Mohr
constify a medium-large CRC code table. Signed-off-by: Andreas Mohr <andi@lisas.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!