summaryrefslogtreecommitdiff
path: root/drivers/crypto/atmel-ecc.c
AgeCommit message (Collapse)Author
2020-08-07mm, treewide: rename kzfree() to kfree_sensitive()Waiman Long
As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or something. The "zero" part of the interface isn't even _relevant_. The main reason that kzfree() exists is to clear sensitive information that should not be leaked to other future users of the same memory objects. Rename kzfree() to kfree_sensitive() to follow the example of the recently added kvfree_sensitive() and make the intention of the API more explicit. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: git grep -w --name-only kzfree |\ xargs sed -i 's/kzfree/kfree_sensitive/' followed by some editing of the kfree_sensitive() kerneldoc and adding a kzfree backward compatibility macro in slab.h. [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h] [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more] Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: David Howells <dhowells@redhat.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Joe Perches <joe@perches.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: David Rientjes <rientjes@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: "Jason A . Donenfeld" <Jason@zx2c4.com> Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-05-30crypto: atmel-ecc - factor out code that can be sharedArd Biesheuvel
In preparation of adding support for the random number generator in Atmel atsha204a devices, refactor the existing atmel-ecc driver (which drives hardware that is closely related) so we can share the basic I2C and command queuing routines. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-30crypto: atmel-ecc - add support for ACPI probing on non-AT91 platformsArd Biesheuvel
The Atmel/Microchip EC508A is a I2C device that could be wired into any platform, and is being used on the Linaro/96boards Secure96 mezzanine adapter. This means it could be found on any platform, even on ones that use ACPI enumeration (via PRP0001 devices). So update the code to enable this use case. This involves tweaking the bus rate discovery code to take ACPI probing into account, which records the maximum bus rate as a property of the slave device. For the atmel-ecc code, this means that the effective bus rate should never exceed the maximum rate, unless we are dealing with buggy firmware. Nonetheless, let's just use the existing plumbing to discover the bus rate and keep the existing logic intact. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-09-04crypto: atmel - switch to SPDX license identifiersTudor Ambarus
Adopt the SPDX license identifiers to ease license compliance management. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-06-22crypto: atmel-ecc - remove overly verbose dev_infoTudor-Dan Ambarus
Remove it because when using a slow console, it can affect the speed of crypto operations. Similar to 'commit 730f23b66095 ("crypto: vmx - Remove overly verbose printk from AES XTS init")'. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-06-22crypto: atmel-ecc - fix to allow multi segment scatterlistsTudor-Dan Ambarus
Remove the limitation of single element scatterlists. ECDH with multi-element scatterlists is needed by TPM. Similar to 'commit 95ec01ba1ef0 ("crypto: ecdh - fix to allow multi segment scatterlists")'. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-08-03crypto: atmel-ecc - fix signed integer to u8 assignmentTudor-Dan Ambarus
static checker warning: drivers/crypto/atmel-ecc.c:281 atmel_ecdh_done() warn: assigning (-22) to unsigned variable 'status' Similar warning can be raised in atmel_ecc_work_handler() when atmel_ecc_send_receive() returns an error. Fix this too. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-08-03Crypto: atmel-ecc: Make a couple of local functions staticColin Ian King
Functions atmel_ecc_i2c_client_alloc and atmel_ecc_i2c_client_free are local to the source and no not need to be in the global scope. Make them static. Cleans up sparse warnings: symbol 'atmel_ecc_i2c_client_alloc' was not declared. Should it be static? symbol 'atmel_ecc_i2c_client_free' was not declared. Should it be static? Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-18crypto: atmel-ecc - introduce Microchip / Atmel ECC driverTudor-Dan Ambarus
Add ECDH support for ATECC508A (I2C) device. The device features hardware acceleration for the NIST standard P256 prime curve and supports the complete key life cycle from private key generation to ECDH key agreement. Random private key generation is supported internally within the device to ensure that the private key can never be known outside of the device. If the user wants to use its own private keys, the driver will fallback to the ecdh software implementation. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>