- 05 9月, 2019 7 次提交
-
-
由 Pascal van Leeuwen 提交于
This patch adds support for the basic AES-CCM AEAD cipher suite. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch adds support for AES in output feedback mode (AES-OFB). Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch adds support for AES in 128 bit cipher feedback mode (AES-CFB). Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch adds support for the basic AES-GCM AEAD cipher suite. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
Instead of having a fixed value (of 300) all over the place, the value for for .cra_priority is now made into a define (SAFEXCEL_CRA_PRIORITY). This makes it easier to play with, e.g. during development. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch probes the supported algorithms from the hardware and only registers the ones that the hardware actually supports. This is necessary because this is a generic driver supposed to run on a wide variety of engines, which may or may not implement certain algorithms. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch adds support for the AES-XTS skcipher algorithm. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 30 8月, 2019 3 次提交
-
-
由 Pascal van Leeuwen 提交于
Until now, the inside-secure driver required a set of firmware images supplied by the silicon vendor, typically under NDA, to be present in /lib/firmware/inside-secure in order to be able to function. This patch removes the dependence on this official vendor firmware by falling back to generic "mini" FW - developed specifically for this driver - that can be provided under GPL 2.0 through linux-firmwares. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Acked-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch adds support for a PCIE development board with FPGA from Xilinx, to facilitate pre-silicon driver development by both Inside Secure and its IP customers. Since Inside Secure neither produces nor has access to actual silicon, this is required functionality to allow us to contribute. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Acked-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This removes some code determine which engine has which algorithms which was effectively redundant (may have been forward-looking?) due to always enabling all algorithms for all currently supported engines. A future patch will use a different, more scalable approach to achieve this. This is removed now because otherwise the next patch will add new hardware which would otherwise have to be added to all algorithms, so now is a convenient time to just get rid of this. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Acked-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 26 7月, 2019 6 次提交
-
-
由 Pascal van Leeuwen 提交于
This patch recognises the fact that the hardware cannot ever process more than 2,199,023,386,111 bytes of hash or HMAC payload, so there is no point in maintaining 128 bit wide byte counters, 64 bits is more than sufficient Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch adds support for the following AEAD ciphersuites: - authenc(hmac(sha1),rfc3686(ctr(aes))) - authenc(hmac(sha224),rfc3686(ctr(aes))) - authenc(hmac(sha256),rfc3686(ctr(aes))) - authenc(hmac(sha384),rfc3686(ctr(aes))) - authenc(hmac(sha512),rfc3686(ctr(aes))) Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch fixes an issue with hash and HMAC operations that perform "large" intermediate updates (i.e. combined size > 2 hash blocks) by actually making use of the hardware's hash continue capabilities. The original implementation would cache these updates in a buffer that was 2 hash blocks in size and fail if all update calls combined would overflow that buffer. Which caused the cryptomgr extra tests to fail. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Pascal van Leeuwen 提交于
This patch fixes a buffer overflow error returning -EINVAL for AEAD decrypt operations by NOT appending the (already verified) ICV to the output packet (which is not expected by the API anyway). With this fix, all testmgr AEAD (extra) tests now pass. Signed-off-by: NPascal van Leeuwen <pvanleeuwen@verimatrix.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 06 6月, 2019 3 次提交
-
-
由 Antoine Tenart 提交于
This patch adds support for HMAC updates in the Inside Secure SafeXcel crypto engine driver. Updates were supported for hash algorithms, but were never enabled for HMAC ones. This fixes boot time test issues. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch adds support for retrieving intermediate IV from the crypto engine when using the CBC block mode with AES and (3)DES. The retrieved IV is copied to the request IV buffer, as requested by the kernel crypto API. This fix boot tests added by commit 8efd972e ("crypto: testmgr - support checking skcipher output IV"). Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
The context given to the crypto engine can be reused over time. While the driver was designed to allow this, the feature wasn't enabled in the hardware engine. This patch enables it. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 20 7月, 2018 1 次提交
-
-
由 Antoine Tenart 提交于
Use the appropriate SPDX license identifiers and drop the license text. This patch is only cosmetic. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 09 7月, 2018 13 次提交
-
-
由 Ofer Heifetz 提交于
This patch main goal is to improve driver performance by moving the crypto request from a list to a RDR ring shadow. This is possible since there is one producer and one consume for this RDR request shadow and one ring descriptor is left unused. Doing this change eliminates the use of spinlock when accessing the descriptor ring and the need to dynamicaly allocate memory per crypto request. The crypto request is placed in the first RDR shadow descriptor only if there are enough descriptors, when the result handler is invoked, it fetches the first result descriptor from RDR shadow. Signed-off-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
This patch adds support for two new algorithms in the Inside Secure SafeXcel cryptographic engine driver: ecb(des3_ede) and cbc(des3_ede). Signed-off-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
This patch adds support for two algorithms in the Inside Secure SafeXcel cryptographic engine driver: ecb(des) and cbc(des). Signed-off-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
This patch adds support for the hmac(md5) algorithm in the Inside Secure SafeXcel cryptographic engine driver. Signed-off-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
This patch adds the MD5 algorithm support to the Inside Secure SafeXcel cryptographic engine driver. Signed-off-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
The ORO bridge (connected to the EIP197 write channel) does not generate back pressure towards the EIP197 when its internal FIFO is full. It assumes that the EIP will not drive more write transactions than the maximal supported outstanding (32). Hence tx_max_cmd_queue must be configured to 5 (or less). Signed-off-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
This patch updates the TRC configuration so that the version of the EIP197 engine being used is taken into account, as the configuration differs between the EIP197B and the EIP197D. Signed-off-by: NOfer Heifetz <oferh@marvell.com> [Antoine: commit message] Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch adds support for the eip197d engine to the Inside Secure SafeXcel cryptographic driver. This new engine is similar to the eip197b and reuse most of its code. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
So far a single processing engine (PE) was configured and used in the Inside Secure SafeXcel cryptographic engine driver. Some versions have more than a single PE. This patch rework the driver's initialization to take this into account and to allow configuring more than one PE. Signed-off-by: NOfer Heifetz <oferh@marvell.com> [Antoine: some reworks and commit message.] Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
The Inside Secure SafeXcel driver currently uses 4 rings, but the eip197d engines has 8 of them. This patch updates the driver so that rings are allocated dynamically based on the number of available rings supported by a given engine. Signed-off-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
Add a flags field in the private structure, and a first flag for engines needing context invalidation (currently only the eip197b). The invalidation is needed when the engine includes a TRC cache, which will also be true for the upcoming addition of the eip197d engine. Suggested-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
EIP engines do not support the same set of algorithms. So far the supported engines in the Inside Secure SafeXcel driver support the same set of algorithms, but that won't be true for all engines. This patch adds an 'engines' field in the algorithm definitions so that they only are registered when using a compatible cryptographic engine. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
At first we used two compatibles in the SafeXcel driver, named after the engine revision: eip97 and eip197. However this family of engines has more precise versions and in fact we're supporting the eip97ies and eip197b. More versions will be supported in the future, such as the eip197d, and we'll need to differentiate them. This patch fixes the compatibles used in the driver, to now use precise ones. The two historical compatibles are kept for backward compatibility. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 22 6月, 2018 7 次提交
-
-
由 Antoine Tenart 提交于
This patch adds the authenc(hmac(sha384),cbc(aes)) algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch adds the hmac(sha384) algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch adds the sha384 algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch adds the authenc(hmac(sha512),cbc(aes)) algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch adds the hmac(sha512) algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch adds the sha512 algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
A counter is given to the engine when finishing hash computation. It currently uses the blocksize while it counts the number of 64 bytes blocks given to the engine. This works well for all algorithms so far, as SHA1, SHA224 and SHA256 all have a blocksize of 64 bytes, but others algorithms such as SHA512 wouldn't work. Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-