user/sven/linux.git/lib/libcrc32c.c, branch v4.19.204

libcrc32c: Add crc32c_impl function

2018-03-26T13:09:38Z

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 Acked-by: Herbert Xu [ use crypto_shash_driver_name as suggested by Herbert ] Signed-off-by: David Sterba

crypto: Work around deallocated stack frame reference gcc bug on sparc.

2017-06-08T09:36:03Z

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: Reported-by: Anatoly Pugachev Signed-off-by: David S. Miller Signed-off-by: Herbert Xu

Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2016-01-22T19:58:43Z

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

lib/libcrc32c.c: fix build warning

2016-01-21T01:09:18Z

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 Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

crypto: crc32c - Fix crc32c soft dependency

2016-01-19T07:52:10Z

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 Cc: "David S. Miller" Signed-off-by: Jean Delvare Signed-off-by: Herbert Xu

crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.c

2014-10-14T08:51:23Z

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 Signed-off-by: Behan Webster Reviewed-by: Mark Charlebois Acked-by: Herbert Xu Cc: pageexec@freemail.hu Cc: "David S. Miller"

lib/libcrc32c.c: use PTR_ERR_OR_ZERO

2014-06-04T23:54:18Z

replace IS_ERR/PTR_ERR Signed-off-by: Fabian Frederick Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

libcrc32c: Fix "crc32c undefined" compilation error

2008-12-25T00:01:42Z

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 Signed-off-by: Herbert Xu

libcrc32c: Move implementation to crypto crc32c

2008-12-25T00:01:40Z

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

[LIB] crc32c: Keep intermediate crc state in cpu order

2007-11-08T13:34:09Z

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 Signed-off-by: Herbert Xu