- Apr 10, 2017
-
-
Herbert Xu authored
This patch hard-codes CRYPTO_MAX_NAME in the user-space API to 64, which is the current value of CRYPTO_MAX_ALG_NAME. This patch also replaces all remaining occurences of CRYPTO_MAX_ALG_NAME in the user-space API with CRYPTO_MAX_NAME. This way the user-space API will not be modified when we raise the value of CRYPTO_MAX_ALG_NAME. Furthermore, the code has been updated to handle names longer than the user-space API. They will be truncated. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Tested-by:
-
Rick Altherr authored
Some hardware RNGs provide a single register for obtaining random data. Instead of signaling when new data is available, the reader must wait a fixed amount of time between reads for new data to be generated. timeriomem_rng implements this scheme with the period specified in platform data or device tree. While the period is specified in microseconds, the implementation used a standard timer which has a minimum delay of 1 jiffie and caused a significant bottleneck for devices that can update at 1us. By switching to an hrtimer, 1us periods now only delay at most 2us per read. Signed-off-by:
Rick Altherr <raltherr@google.com> Signed-off-by:
-
Rick Altherr authored
No functional changes. Signed-off-by:
-
Rick Altherr authored
Preserves the existing behavior of only returning 32-bits per call. Signed-off-by:
-
Matthias Kaehlcke authored
The operand is an integer constant, make the constness explicit by adding the modifier. This is needed for clang to generate valid code and also works with gcc. Also change the constraint of the operand from 'I' ("Integer constant that is valid as an immediate operand in an ADD instruction", AArch64) to 'i' ("An immediate integer operand"). Based-on-patch-from: Greg Hackmann <ghackmann@google.com> Signed-off-by:Greg Hackmann <ghackmann@google.com> Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
- Apr 05, 2017
-
-
Ondrej Mosnáček authored
Since the gf128mul_x_ble function used by xts.c is now defined inline in the header file, the XTS module no longer depends on gf128mul. Therefore, the 'select CRYPTO_GF128MUL' line can be safely removed. Signed-off-by:
Ondrej Mosnacek <omosnacek@gmail.com> Reviewd-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Ondrej Mosnáček authored
The le128_gf128mul_x_ble function in glue_helper.h is now obsolete and can be replaced with the gf128mul_x_ble function from gf128mul.h. Signed-off-by:
-
Ondrej Mosnáček authored
Currently, gf128mul_x_ble works with pointers to be128, even though it actually interprets the words as little-endian. Consequently, it uses cpu_to_le64/le64_to_cpu on fields of type __be64, which is incorrect. This patch fixes that by changing the function to accept pointers to le128 and updating all users accordingly. Signed-off-by:
-
Ondrej Mosnáček authored
The gf128mul_x_ble function is currently defined in gf128mul.c, because it depends on the gf128mul_table_be multiplication table. However, since the function is very small and only uses two values from the table, it is better for it to be defined as inline function in gf128mul.h. That way, the function can be inlined by the compiler for better performance. For consistency, the other gf128mul_x_* functions are also moved to the header file. In addition, the code is rewritten to be constant-time. After this change, the speed of the generic 'xts(aes)' implementation increased from ~225 MiB/s to ~235 MiB/s (measured using 'cryptsetup benchmark -c aes-xts-plain64' on an Intel system with CRYPTO_AES_X86_64 and CRYPTO_AES_NI_INTEL disabled). Signed-off-by:
-
Haren Myneni authored
Signed-off-by:
Haren Myneni <haren@us.ibm.com> Acked-by:
Dan Streetman <ddstreet@ieee.org> Signed-off-by:
-
Gary R Hook authored
The AES GCM function (in ccp-ops) requires a fair amount of stack space, which elicits a complaint when KASAN is enabled. Rearranging and packing a few structures eliminates the warning. Signed-off-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
-
Gary R Hook authored
Endianness is dealt with when the command descriptor is copied into the command queue. Remove any occurrences of cpu_to_le32() found elsewhere. Signed-off-by:
-
Fabien DESSENNE authored
Add STM32 crypto support in stm32_defconfig file. Signed-off-by:
Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by:
-
Fabien DESSENNE authored
Enable the CRC (CRC32 crypto) on stm32746g-eval board Signed-off-by:
-
Fabien DESSENNE authored
Add CRC (CRC32 crypto) support to stm32f746. Signed-off-by:
-
Fabien DESSENNE authored
This module registers a CRC32 ("Ethernet") and a CRC32C (Castagnoli) algorithm that make use of the STMicroelectronics STM32 crypto hardware. Theses algorithms are compatible with the little-endian generic ones. Both algorithms use ~0 as default seed (key). With CRC32C the output is xored with ~0. Using TCRYPT CRC32C speed test, this shows up to 900% speedup compared to the crc32c-generic algorithm. Signed-off-by: -
Fabien DESSENNE authored
Document device tree bindings for the STM32 CRC (crypto CRC32) Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Herbert Xu authored
Merge the crypto tree to resolve conflict between caam changes.
-
Horia Geantă authored
RNG instantiation was previously fixed by commit 62743a41 ("crypto: caam - fix RNG init descriptor ret. code checking") while deinstantiation was not addressed. Since the descriptors used are similar, in the sense that they both end with a JUMP HALT command, checking for errors should be similar too, i.e. status code 7000_0000h should be considered successful. Cc: <stable@vger.kernel.org> # 3.13+ Fixes: 1005bccd ("crypto: caam - enable instantiation of all RNG4 state handles") Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Horia Geantă authored
In case caam_jr_alloc() fails, ctx->dev carries the error code, thus accessing it with dev_err() is incorrect. Cc: <stable@vger.kernel.org> # 4.8+ Fixes: 8c419778 ("crypto: caam - add support for RSA algorithm") Signed-off-by:
-
Horia Geantă authored
The way Job Ring platform devices are created and released does not allow for multiple create-release cycles. JR0 Platform device creation error JR0 Platform device creation error caam 2100000.caam: no queues configured, terminating caam: probe of 2100000.caam failed with error -12 The reason is that platform devices are created for each job ring: for_each_available_child_of_node(nprop, np) if (of_device_is_compatible(np, "fsl,sec-v4.0-job-ring") || of_device_is_compatible(np, "fsl,sec4.0-job-ring")) { ctrlpriv->jrpdev[ring] = of_platform_device_create(np, NULL, dev); which sets OF_POPULATED on the device node, but then it cleans these up: /* Remove platform devices for JobRs */ for (ring = 0; ring < ctrlpriv->total_jobrs; ring++) { if (ctrlpriv->jrpdev[ring]) of_device_unregister(ctrlpriv->jrpdev[ring]); } which leaves OF_POPULATED set. Use of_platform_populate / of_platform_depopulate instead. This allows for a bit of driver clean-up, jrpdev is no longer needed. Logic changes a bit too: -exit in case of_platform_populate fails, since currently even QI backend depends on JR; true, we no longer support the case when "some" of the JR DT nodes are incorrect -when cleaning up, caam_remove() would also depopulate RTIC in case it would have been populated somewhere else - not the case for now Cc: <stable@vger.kernel.org> Fixes: 313ea293 ("crypto: caam - Add Platform driver for Job Ring") Reported-by:Russell King <rmk+kernel@armlinux.org.uk> Suggested-by:
Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
- Mar 24, 2017
-
-
Geliang Tang authored
Use sg_virt() instead of open-coding it. Signed-off-by:
Geliang Tang <geliangtang@gmail.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Stephan Mueller authored
An SGL to be initialized only once even when its buffers are written to several times. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Marcelo Cerri authored
3DES is missing the fips_allowed flag for CTR mode. Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Arnd Bergmann authored
kernelci.org reports a build-time regression on linux-next, with a harmless warning in x86 allmodconfig: drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=] drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=] drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=] The return type for atomic64_read() unfortunately differs between architectures, with some defining it as atomic_long_read() and others returning a 64-bit type explicitly. Fixing this in general would be nice, but also require changing other users of these functions, so the simpler workaround is to add a cast here that avoids the warnings on the default build. Fixes: 09ae5d37 ("crypto: zip - Add Compression/Decompression statistics") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Dan Carpenter authored
There is a typo here. It should be "stats" instead of "state". The impact is that we clear 224 bytes instead of 80 and we zero out memory that we shouldn't. Fixes: 09ae5d37 ("crypto: zip - Add Compression/Decompression statistics") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Add kernel-doc to s5p_aes_dev structure. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The driver uses type of device (variant) only during probe so there is no need to store it for later. Signed-off-by:
-
Krzysztof Kozlowski authored
Driver is capable of handling only one request at a time and it stores it in its state container struct s5p_aes_dev. This stored request must be protected between concurrent invocations (e.g. completing current request and scheduling new one). Combination of lock and "busy" field is used for that purpose. When "busy" field is true, the driver will not accept new request thus it will not overwrite currently handled data. However commit 28b62b14 ("crypto: s5p-sss - Fix spinlock recursion on LRW(AES)") moved some of the write to "busy" field out of a lock protected critical section. This might lead to potential race between completing current request and scheduling a new one. Effectively the request completion might try to operate on new crypto request. Cc: <stable@vger.kernel.org> # v4.10.x Fixes: 28b62b14 ("crypto: s5p-sss - Fix spinlock recursion on LRW(AES)") Signed-off-by:
-
Horia Geantă authored
Add support to submit ablkcipher and authenc algorithms via the QI backend: -ablkcipher: cbc({aes,des,des3_ede}) ctr(aes), rfc3686(ctr(aes)) xts(aes) -authenc: authenc(hmac(md5),cbc({aes,des,des3_ede})) authenc(hmac(sha*),cbc({aes,des,des3_ede})) caam/qi being a new driver, let's wait some time to settle down without interfering with existing caam/jr driver. Accordingly, for now all caam/qi algorithms (caamalg_qi module) are marked to be of lower priority than caam/jr ones (caamalg module). Signed-off-by:Vakul Garg <vakul.garg@nxp.com> Signed-off-by:
Alex Porosanu <alexandru.porosanu@nxp.com> Signed-off-by:
-
Horia Geantă authored
CAAM engine supports two interfaces for crypto job submission: -job ring interface - already existing caam/jr driver -Queue Interface (QI) - caam/qi driver added in current patch QI is present in CAAM engines found on DPAA platforms. QI gets its I/O (frame descriptors) from QMan (Queue Manager) queues. This patch adds a platform device for accessing CAAM's queue interface. The requests are submitted to CAAM using one frame queue per cryptographic context. Each crypto context has one shared descriptor. This shared descriptor is attached to frame queue associated with corresponding driver context using context_a. The driver hides the mechanics of FQ creation, initialisation from its applications. Each cryptographic context needs to be associated with driver context which houses the FQ to be used to transport the job to CAAM. The driver provides API for: (a) Context creation (b) Job submission (c) Context deletion (d) Congestion indication - whether path to/from CAAM is congested The driver supports affining its context to a particular CPU. This means that any responses from CAAM for the context in question would arrive at the given CPU. This helps in implementing one CPU per packet round trip in IPsec application. The driver processes CAAM responses under NAPI contexts. NAPI contexts are instantiated only on cores with affined portals since only cores having their own portal can receive responses from DQRR. The responses from CAAM for all cryptographic contexts ride on a fixed set of FQs. We use one response FQ per portal owning core. The response FQ is configured in each core's and thus portal's dedicated channel. This gives the flexibility to direct CAAM's responses for a crypto context on a given core. Signed-off-by:
-
Horia Geantă authored
Signed-off-by:
-
Horia Geantă authored
A few other things need to be added in soc/qman, such that caam/qi won't open-code them. Signed-off-by:
-
Horia Geantă authored
Export qman_query_fq_np() function and related structures. This will be needed in the caam/qi driver, where "queue empty" condition will be decided based on the frm_cnt. Signed-off-by:
-
Horia Geantă authored
Add and export the ID of the channel serviced by the CAAM (Cryptographic Acceleration and Assurance Module) DCP. Signed-off-by:
-
Horia Geantă authored
Since qman_volatile_dequeue() is already exported, move the related structures into the public header too. Signed-off-by:
-
Jason A. Donenfeld authored
The md5_transform function is no longer used any where in the tree, except for the crypto api's actual implementation of md5, so we can drop the function from lib and put it as a static function of the crypto file, where it belongs. There should be no new users of md5_transform, anyway, since there are more modern ways of doing what it once achieved. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by:
-
Michael Davidson authored
aes_ctrby8_avx-x86_64.S uses the C preprocessor for token pasting of character sequences that are not valid preprocessor tokens. While this is allowed when preprocessing assembler files it exposes an incompatibilty between the clang and gcc preprocessors where clang does not strip leading white space from macro parameters, leading to the CONCAT(%xmm, i) macro expansion on line 96 resulting in a token with a space character embedded in it. While this could be resolved by deleting the offending space character, the assembler is perfectly capable of doing the token pasting correctly for itself so we can just get rid of the preprocessor macros. Signed-off-by:
Michael Davidson <md@google.com> Signed-off-by:
-
Gary R Hook authored
A version 5 device provides the primitive commands required for AES GCM. This patch adds support for en/decryption. Signed-off-by:
-
Gary R Hook authored
Wire up support for Triple DES in ECB mode. Signed-off-by:
-
