summaryrefslogtreecommitdiff
path: root/drivers/crypto/marvell
AgeCommit message (Collapse)AuthorFilesLines
2015-10-14crypto: marvell/cesa - initialise struct mv_cesa_ahash_reqRussell King1-0/+12
When a AF_ALG fd is accepted a second time (hence hash_accept() is used), hash_accept_parent() allocates a new private context using sock_kmalloc(). This context is uninitialised. After use of the new fd, we eventually end up with the kernel complaining: marvell-cesa f1090000.crypto: dma_pool_free cesa_padding, c0627770/0 (bad dma) where c0627770 is a random address. Poisoning the memory allocated by the above sock_kmalloc() produces kernel oopses within the marvell hash code, particularly the interrupt handling. The following simplfied call sequence occurs: hash_accept() crypto_ahash_export() marvell hash export function af_alg_accept() hash_accept_parent() <== allocates uninitialised struct hash_ctx crypto_ahash_import() marvell hash import function hash_ctx contains the struct mv_cesa_ahash_req in its req.__ctx member, and, as the marvell hash import function only partially initialises this structure, we end up with a lot of members which are left with whatever data was in memory prior to sock_kmalloc(). Add zero-initialisation of this structure. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Boris Brezillon <boris.brezillon@free-electronc.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-10-14crypto: marvell/cesa - fix stack smashing in marvell/hash.cRussell King1-0/+3
Several of the algorithms in marvell/hash.c have a statesize of zero. When an AF_ALG accept() on an already-accepted file descriptor to calls into hash_accept(), this causes: char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))]; to be zero-sized, but we still pass this to: err = crypto_ahash_export(req, state); which proceeds to write to 'state' as if it was a "struct md5_state", "struct sha1_state" etc. Add the necessary initialisers for the .statesize member. Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-07-14crypto: marvell/cesa - Drop owner assignment from platform_driverKrzysztof Kozlowski1-1/+0
platform_driver does not need to set an owner because platform_driver_register() will set it. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-07-01genalloc: rename of_get_named_gen_pool() to of_gen_pool_get()Vladimir Zapolskiy1-3/+2
To be consistent with other kernel interface namings, rename of_get_named_gen_pool() to of_gen_pool_get(). In the original function name "_named" suffix references to a device tree property, which contains a phandle to a device and the corresponding device driver is assumed to register a gen_pool object. Due to a weak relation and to avoid any confusion (e.g. in future possible scenario if gen_pool objects are named) the suffix is removed. [sfr@canb.auug.org.au: crypto/marvell/cesa - fix up for of_get_named_gen_pool() rename] Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Boris BREZILLON <boris.brezillon@free-electrons.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-06-19crypto: marvell/cesa - add support for Kirkwood and Dove SoCsArnaud Ebalard1-1/+12
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport module parameter to avoid probing the CESA IP when the old CESA driver is enabled (unless it is explicitly requested to do so). Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add support for Orion SoCsBoris BREZILLON1-7/+35
Add the Orion SoC description, and select this implementation by default to support non-DT probing: Orion is the only platform where non-DT boards are declaring the CESA block. Control the allhwsupport module parameter to avoid probing the CESA IP when the old CESA driver is enabled (unless it is explicitly requested to do so). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add allhwsupport module parameterBoris BREZILLON1-0/+4
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs. Add a module parameter to choose whether these SoCs should be attached to the new or the old driver. The default policy is to keep attaching those IPs to the old driver if it is enabled, until we decide the new CESA driver is stable/secure enough. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add support for all armada SoCsBoris BREZILLON1-0/+12
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add SHA256 supportArnaud Ebalard3-0/+163
Add support for SHA256 operations. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add MD5 supportArnaud Ebalard3-2/+174
Add support for MD5 operations. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add Triple-DES supportArnaud Ebalard3-0/+151
Add support for Triple-DES operations. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add DES supportBoris BREZILLON3-0/+154
Add support for DES operations. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add TDMA supportBoris BREZILLON6-16/+1100
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA) which can control the crypto block. When you use this mode, all the required data (operation metadata and payload data) are transferred using DMA, and the results are retrieved through DMA when possible (hash results are not retrieved through DMA yet), thus reducing the involvement of the CPU and providing better performances in most cases (for small requests, the cost of DMA preparation might exceed the performance gain). Note that some CESA IPs do not embed this dedicated DMA, hence the activation of this feature on a per platform basis. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add a new driver for Marvell's CESABoris BREZILLON5-0/+2024
The existing mv_cesa driver supports some features of the CESA IP but is quite limited, and reworking it to support new features (like involving the TDMA engine to offload the CPU) is almost impossible. This driver has been rewritten from scratch to take those new features into account. This commit introduce the base infrastructure allowing us to add support for DMA optimization. It also includes support for one hash (SHA1) and one cipher (AES) algorithm, and enable those features on the Armada 370 SoC. Other algorithms and platforms will be added later on. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>