On 28/06/19 10:44 AM, Eric Biggers wrote:
On Fri, Jun 28, 2019 at 09:57:42AM +0530, Keerthy wrote:
+static int sa_sham_update(struct ahash_request *req)
+{
+ return -ENOTSUPP;
+}
+
+static int sa_sham_final(struct ahash_request *req)
+{
+ return sa_sham_digest(req);
+}
+
+static i
On 28/06/19 10:55 AM, Eric Biggers wrote:
On Fri, Jun 28, 2019 at 10:44:26AM +0530, keerthy wrote:
On 6/28/2019 10:23 AM, Eric Biggers wrote:
Hi Keerthy,
On Fri, Jun 28, 2019 at 09:57:35AM +0530, Keerthy wrote:
The series adds Crypto hardware accelerator support for SA2UL.
SA2UL stands f
On 28/06/19 10:39 AM, Eric Biggers wrote:
On Fri, Jun 28, 2019 at 09:57:40AM +0530, Keerthy wrote:
The transform function can be used as is by other crypto
drivers that need to transform the 256 bit key using cpu.
Hence export it.
What is this supposed to mean? SHA-256 is an unkeyed hash f
On Fri, Jun 28, 2019 at 10:44:26AM +0530, keerthy wrote:
>
>
> On 6/28/2019 10:23 AM, Eric Biggers wrote:
> > Hi Keerthy,
> >
> > On Fri, Jun 28, 2019 at 09:57:35AM +0530, Keerthy wrote:
> > > The series adds Crypto hardware accelerator support for SA2UL.
> > > SA2UL stands for security accelera
On 28/06/19 10:37 AM, Eric Biggers wrote:
On Fri, Jun 28, 2019 at 09:57:37AM +0530, Keerthy wrote:
The Security Accelerator (SA2_UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
• Encryption and authentication for secure boot
• Encryption and authenticat
On 6/28/2019 10:23 AM, Eric Biggers wrote:
Hi Keerthy,
On Fri, Jun 28, 2019 at 09:57:35AM +0530, Keerthy wrote:
The series adds Crypto hardware accelerator support for SA2UL.
SA2UL stands for security accelerator ultra lite.
The Security Accelerator (SA2_UL) subsystem provides hardware
cryp
On Fri, Jun 28, 2019 at 09:57:42AM +0530, Keerthy wrote:
> +static int sa_sham_update(struct ahash_request *req)
> +{
> + return -ENOTSUPP;
> +}
> +
> +static int sa_sham_final(struct ahash_request *req)
> +{
> + return sa_sham_digest(req);
> +}
> +
> +static int sa_sham_finup(struct ahash_
On Fri, Jun 28, 2019 at 09:57:41AM +0530, Keerthy wrote:
> Add aead support for hmac(sha256)cbc(aes) algorithm. Authenticated
> encryption (AE) and authenticated encryption with associated data
> (AEAD) is a form of encryption which simultaneously provides
> confidentiality, integrity, and authenti
On Fri, Jun 28, 2019 at 09:57:40AM +0530, Keerthy wrote:
> The transform function can be used as is by other crypto
> drivers that need to transform the 256 bit key using cpu.
> Hence export it.
What is this supposed to mean? SHA-256 is an unkeyed hash function.
Also, you need to actually explai
On Fri, Jun 28, 2019 at 09:57:37AM +0530, Keerthy wrote:
> The Security Accelerator (SA2_UL) subsystem provides hardware
> cryptographic acceleration for the following use cases:
> • Encryption and authentication for secure boot
> • Encryption and authentication of content in applications
> requi
Hi Keerthy,
On Fri, Jun 28, 2019 at 09:57:35AM +0530, Keerthy wrote:
> The series adds Crypto hardware accelerator support for SA2UL.
> SA2UL stands for security accelerator ultra lite.
>
> The Security Accelerator (SA2_UL) subsystem provides hardware
> cryptographic acceleration for the followin
Add crypto accelarator node. Define the psil specific config
node as well. This can be used in Packet Mode alone.
Signed-off-by: Keerthy
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 33
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.
Add aead support for hmac(sha1)cbc(aes) algorithm. Authenticated
encryption (AE) and authenticated encryption with associated data
(AEAD) is a form of encryption which simultaneously provides
confidentiality, integrity, and authenticity assurances on the data.
hmac(sha1) has a digest size of 20 by
HMAC hash-based message authentication code) is a specific type of
message authentication code (MAC) involving a cryptographic hash
function and a secret cryptographic key. It may be used to
simultaneously verify both the data integrity and the authentication
of a message, as with any MAC. Add hmac
Add aead support for hmac(sha256)cbc(aes) algorithm. Authenticated
encryption (AE) and authenticated encryption with associated data
(AEAD) is a form of encryption which simultaneously provides
confidentiality, integrity, and authenticity assurances on the data.
hmac(sha256) has a digest size of 3
The Security Accelerator (SA2_UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
• Encryption and authentication for secure boot
• Encryption and authentication of content in applications
requiring DRM (digital rights management) and
content/asset protection
Triple DES (3DES), officially the Triple Data Encryption Algorithm
(TDEA or Triple DEA), is a symmetric-key block cipher, which applies
the DES cipher algorithm three times to each data block
Add 3DES ECB(Electronic code book) & CBC(Cipher Block Chaining)
Mode support.
Signed-off-by: Keerthy
---
HMAC hash-based message authentication code) is a specific type of
message authentication code (MAC) involving a cryptographic hash
function and a secret cryptographic key. It may be used to
simultaneously verify both the data integrity and the authentication
of a message, as with any MAC. Add hmac
The series adds Crypto hardware accelerator support for SA2UL.
SA2UL stands for security accelerator ultra lite.
The Security Accelerator (SA2_UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
• Encryption and authentication for secure boot
• Encryption and au
The transform function can be used as is by other crypto
drivers that need to transform the 256 bit key using cpu.
Hence export it.
Signed-off-by: Keerthy
---
crypto/sha256_generic.c | 3 ++-
include/crypto/sha.h| 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/crypto/sha2
The series adds Crypto hardware accelerator support for SA2UL.
SA2UL stands for security accelerator ultra lite.
The Security Accelerator (SA2_UL) subsystem provides hardware
cryptographic acceleration for the following use cases:
• Encryption and authentication for secure boot
• Encryption and au
Add support for AES algorithm in ECB Mode. Data encryption modes
are supported via MCE engine (programmable mode control engine).
ECB (Electronic code book) is a mode of operation for a block cipher,
with the characteristic that each possible block of plaintext has a
defined corresponding ciphertex
On Tue, Jun 18, 2019 at 02:13:47PM +0200, Arnd Bergmann wrote:
> Build testing with some core crypto options disabled revealed
> a few modules that are missing CRYPTO_HASH:
>
> crypto/asymmetric_keys/x509_public_key.o: In function `x509_get_sig_params':
> x509_public_key.c:(.text+0x4c7): undefined
On Tue, Jun 18, 2019 at 12:09:22PM -0700, Haren Myneni wrote:
>
> System gets checkstop if RxFIFO overruns with more requests than the
> maximum possible number of CRBs in FIFO at the same time. The max number
> of requests per window is controlled by window credits. So find max
> CRBs from FI
On Tue, Jun 18, 2019 at 11:21:52AM +0200, Arnd Bergmann wrote:
> On arm32, we get warnings about high stack usage in some of the functions:
>
> crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function
> 'alg_test_aead' [-Werror,-Wframe-larger-than=]
> static int alg_test_aead(c
On Tue, Jun 18, 2019 at 01:19:42PM +0200, Arnd Bergmann wrote:
> The same bug that gcc hit in the past is apparently now showing
> up with clang, which decides to inline __serpent_setkey_sbox:
>
> crypto/serpent_generic.c:268:5: error: stack frame size of 2112 bytes in
> function '__serpent_setke
On Mon, Jun 17, 2019 at 03:25:17PM +0200, Arnd Bergmann wrote:
> After the latest addition, the stack usage of sun4i_ss_cipher_poll
> grew beyond the warning limit when KASAN is enabled:
>
> drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:118:12: error: stack frame size of
> 1152 bytes in function 'sun
On Mon, Jun 17, 2019 at 09:14:45PM +, Christophe Leroy wrote:
> When building for SEC1 only, talitos2_done functions are unneeded
> and should go away.
>
> For this, use has_ftr_sec1() which will always return true when only
> SEC1 support is being built, allowing GCC to drop TALITOS2 function
On Mon, Jun 17, 2019 at 11:46:26AM +0300, Gilad Ben-Yossef wrote:
> A bunch of minor fixes and sanity checks
>
> Gilad Ben-Yossef (1):
> crypto: ccree: add HW engine config check
>
> Ofir Drang (3):
> crypto: ccree: Relocate driver irq registration after clk init
> crypto: ccree: check that
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/crypto/amcc/crypto4xx_core.c | 1 -
1 file changed, 1 deletion(-)
diff --
Define new "d-modsig" template field which holds the digest that is
expected to match the one contained in the modsig, and also new "modsig"
template field which holds the appended file signature.
Add a new "ima-modsig" defined template descriptor with the new fields as
well as the ones from the "
Verify xattr signature in a separate function so that the logic in
ima_appraise_measurement() remains clear when it gains the ability to also
verify an appended module signature.
The code in the switch statement is unchanged except for having to
dereference the status and cause variables (since th
Implement the appraise_type=imasig|modsig option, allowing IMA to read and
verify modsig signatures.
In case a file has both an xattr signature and an appended modsig, IMA will
only use the appended signature if the key used by the xattr signature
isn't present in the IMA or platform keyring.
Bec
It's useful being able to specify a different IMA template on appraise
policy rules, so allow it.
Signed-off-by: Thiago Jung Bauermann
Suggested-by: Mimi Zohar
---
security/integrity/ima/ima_policy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/integrity/ima/im
Introduce the modsig keyword to the IMA policy syntax to specify that
a given hook should expect the file to have the IMA signature appended
to it. Here is how it can be used in a rule:
appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig
With this rule, IMA will accept either a signature
If the IMA template contains the "modsig" or "d-modsig" field, then the
modsig should be added to the measurement list when the file is appraised.
And that is what normally happens, but if a measurement rule caused a file
containing a modsig to be measured before a different rule causes it to be
a
IMA will need to verify a PKCS#7 signature which has already been parsed.
For this reason, factor out the code which does that from
verify_pkcs7_signature() into a new function which takes a struct
pkcs7_message instead of a data buffer.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Mimi Zoha
IMA will use the module_signature format for append signatures, so export
the relevant definitions and factor out the code which verifies that the
appended signature trailer is valid.
Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
and be able to use mod_check_sig() withou
Obtain the modsig and calculate its corresponding hash in
ima_collect_measurement().
Signed-off-by: Thiago Jung Bauermann
---
security/integrity/ima/ima.h | 8 -
security/integrity/ima/ima_api.c | 5 ++-
security/integrity/ima/ima_appraise.c | 2 +-
security/integrity/ima/im
IMA will need to access the digest of the PKCS7 message (as calculated by
the kernel) before the signature is verified, so introduce
pkcs7_get_digest() for that purpose.
Also, modify pkcs7_digest() to detect when the digest was already
calculated so that it doesn't have to do redundant work. Verif
Hello,
This version is essentially identical to the last one.
It is only a rebase on top of today's linux-integrity/next-queued-testing,
prompted by conflicts with Prakhar Srivastava's patches to measure the
kernel command line. It also drops two patches that are already present in
that branch.
This avoids a dependency cycle in soon-to-be-introduced
CONFIG_IMA_APPRAISE_MODSIG: it will select CONFIG_MODULE_SIG_FORMAT
which in turn selects CONFIG_KEYS. Kconfig then complains that
CONFIG_INTEGRITY_SIGNATURE depends on CONFIG_KEYS.
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Mimi Zo
On Fri, Jun 28, 2019 at 11:43:16AM +1000, Michael Ellerman wrote:
>
> No. I assumed you'd take it because it's in drivers/crypto.
>
> If you want me to take it that's fine, just let me know.
No that's fine Michael. I'll pick it up.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.o
Herbert Xu writes:
> Haren Myneni wrote:
>>
>> System gets checkstop if RxFIFO overruns with more requests than the
>> maximum possible number of CRBs in FIFO at the same time. The max number
>> of requests per window is controlled by window credits. So find max
>> CRBs from FIFO size and set
On Thu, Jun 27, 2019 at 11:19:51AM -0700, John Fastabend wrote:
> Eric Biggers wrote:
> > [+TLS maintainers]
> >
> > Very likely a net/tls bug, not a crypto bug.
> >
> > Possibly a duplicate of other reports such as "KMSAN: uninit-value in
> > gf128mul_4k_lle (3)"
> >
> > See https://lore.kerne
Eric Biggers wrote:
> [+TLS maintainers]
>
> Very likely a net/tls bug, not a crypto bug.
>
> Possibly a duplicate of other reports such as "KMSAN: uninit-value in
> gf128mul_4k_lle (3)"
>
> See https://lore.kernel.org/netdev/20190625055019.GD17703@sol.localdomain/ for
> the list of 17 other op
On Thu, Jun 27, 2019 at 12:26:43PM +0200, Ard Biesheuvel wrote:
> There are a few copies of the AES S-boxes floating around, so export
> the ones from the AES library so that we can reuse them in other
> modules.
>
> Signed-off-by: Ard Biesheuvel
> ---
> include/crypto/aes.h | 3 +++
> lib/crypt
On Thu, Jun 20, 2019 at 11:15:05AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> fscrypt only uses SHA-256 for AES-128-CBC-ESSIV, which isn't the default
> and is only recommended on platforms that have hardware accelerated
> AES-CBC but not AES-XTS. There's no link-time dependency, since
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/crypto/amcc/crypto4xx_core.c | 1 -
1 file changed, 1 deletion
On Thu, Jun 20, 2019 at 11:15:05AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> fscrypt only uses SHA-256 for AES-128-CBC-ESSIV, which isn't the default
> and is only recommended on platforms that have hardware accelerated
> AES-CBC but not AES-XTS. There's no link-time dependency, since
syzbot has found a reproducer for the following crash on:
HEAD commit:41550654 [UPSTREAM] KVM: x86: degrade WARN to pr_warn_rate..
git tree: kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=11302ccba0
kernel config: https://syzkaller.appspot.com/x/.config?x=40511ad0c
[+TLS maintainers]
Very likely a net/tls bug, not a crypto bug.
Possibly a duplicate of other reports such as "KMSAN: uninit-value in
gf128mul_4k_lle (3)"
See https://lore.kernel.org/netdev/20190625055019.GD17703@sol.localdomain/ for
the list of 17 other open syzbot bugs I've assigned to the TL
Hello,
syzbot found the following crash on:
HEAD commit:3351e2b9 usb-fuzzer: main usb gadget fuzzer driver
git tree: kmsan
console output: https://syzkaller.appspot.com/x/log.txt?x=135d0c06a0
kernel config: https://syzkaller.appspot.com/x/.config?x=40511ad0c5945201
dashboard link:
On Thu, 27 Jun 2019 at 18:19, Eric Biggers wrote:
>
> On Thu, Jun 27, 2019 at 02:02:55PM +0200, Ard Biesheuvel wrote:
> > Signed-off-by: Ard Biesheuvel
> > ---
> > drivers/crypto/hifn_795x.c | 30 +---
> > 1 file changed, 7 insertions(+), 23 deletions(-)
> >
> > diff --git a/driv
Add an SPDX identifier and remove any specific statements.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-crypto-aes-cmac.c |5 +
drivers/crypto/ccp/ccp-crypto-aes-galois.c |5 +
drivers/crypto/ccp/ccp-crypto-aes-xts.c|5 +
drivers/crypto/ccp/ccp-crypto-aes.c
On Thu, Jun 27, 2019 at 02:02:55PM +0200, Ard Biesheuvel wrote:
> Signed-off-by: Ard Biesheuvel
> ---
> drivers/crypto/hifn_795x.c | 30 +---
> 1 file changed, 7 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
> index d656be
The error code read from the queue status register is only 6 bits wide,
but we need to verify its value is within range before indexing the error
messages.
Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable")
Reported-by: Cfir Cohen
Signed-off-by: Gary R Hook
---
Changes si
On Thu, Jun 27, 2019 at 02:03:06PM +0200, Ard Biesheuvel wrote:
> Signed-off-by: Ard Biesheuvel
> ---
> drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 22
> drivers/crypto/sunxi-ss/sun4i-ss.h| 2 +-
> 2 files changed, 5 insertions(+), 19 deletions(-)
>
> diff --git a/d
On 6/27/2019 5:54 PM, Ard Biesheuvel wrote:
> On Thu, 27 Jun 2019 at 16:50, Ard Biesheuvel
> wrote:
>>
>> On Thu, 27 Jun 2019 at 16:44, Horia Geanta wrote:
>>>
>>> On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
n my effort to remove crypto_alloc_cipher() invocations from non-crypto
code,
On Thu, 27 Jun 2019 at 16:50, Ard Biesheuvel wrote:
>
> On Thu, 27 Jun 2019 at 16:44, Horia Geanta wrote:
> >
> > On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
> > > n my effort to remove crypto_alloc_cipher() invocations from non-crypto
> > > code, i ran into a DES call in the CIFS driver. This is
On Thu, 27 Jun 2019 at 16:44, Horia Geanta wrote:
>
> On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
> > n my effort to remove crypto_alloc_cipher() invocations from non-crypto
> > code, i ran into a DES call in the CIFS driver. This is addressed in
> > patch #30.
> >
> > The other patches are cleanu
On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
> n my effort to remove crypto_alloc_cipher() invocations from non-crypto
> code, i ran into a DES call in the CIFS driver. This is addressed in
> patch #30.
>
> The other patches are cleanups for the quirky DES interface, and lots
> of duplication of th
On Thu, 27 Jun 2019 at 15:26, Horia Geanta wrote:
>
> On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
> > @@ -785,20 +781,23 @@ static int skcipher_setkey(struct crypto_skcipher
> > *skcipher, const u8 *key,
> > static int des_skcipher_setkey(struct crypto_skcipher *skcipher,
> >
On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
> @@ -785,20 +781,23 @@ static int skcipher_setkey(struct crypto_skcipher
> *skcipher, const u8 *key,
> static int des_skcipher_setkey(struct crypto_skcipher *skcipher,
> const u8 *key, unsigned int keylen)
> {
> - u32
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/talitos.c | 28 +++-
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c865f5d5eaba..022292aed9f9 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/tali
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/cavium/nitrox/nitrox_skcipher.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/cavium/nitrox/nitrox_skcipher.c
b/drivers/crypto/cavium/nitrox/nitrox_skcipher.c
index 7e4a5e69085e..ab8ac05f00a1 100644
Some legacy code in the CIFS driver uses single DES to calculate
some password hash, and uses the crypto cipher API to do so. Given
that there is no point in invoking an accelerated cipher for doing
56-bit symmetric encryption on a single 8-byte block of input, the
flexibility of the crypto cipher
Another one for the cipher museum: split off DES core processing into
a separate module so other drivers (mostly for crypto accelerators)
can reuse the code without pulling in the generic DES cipher itself.
This will also permit the cipher interface to be made private to the
crypto API itself once
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/des3_ede_glue.c | 42 +++-
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/arch/x86/crypto/des3_ede_glue.c b/arch/x86/crypto/des3_ede_glue.c
index ff6cca8d69eb..cce329b188d1 100644
--- a/arch/x86/crypto/des3_ede_glu
Signed-off-by: Ard Biesheuvel
---
crypto/des_generic.c | 13 -
include/crypto/des.h | 3 ---
2 files changed, 16 deletions(-)
diff --git a/crypto/des_generic.c b/crypto/des_generic.c
index 8669423886aa..201caf22b881 100644
--- a/crypto/des_generic.c
+++ b/crypto/des_generic.c
@@ -56
Remove the old DES3 verification functions that are no longer used.
Signed-off-by: Ard Biesheuvel
---
include/crypto/des.h | 41
1 file changed, 41 deletions(-)
diff --git a/include/crypto/des.h b/include/crypto/des.h
index 72c7c8e5a5a7..31b04ba835b1 100644
--- a/include/cr
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/rockchip/rk3288_crypto.h| 2 +-
drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 21 +++-
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/rockchip/rk3288_crypto.h
b/drivers/crypto/roc
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/ccree/cc_aead.c | 10 +++---
drivers/crypto/ccree/cc_cipher.c | 15 ---
2 files changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/ccree/cc_aead.c b/drivers/crypto/ccree/cc_aead.c
index 7aa4cbe19a86..44c621030a
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/caam/caamalg.c | 39 ++--
drivers/crypto/caam/caamalg_qi.c | 17 +
drivers/crypto/caam/caamalg_qi2.c | 17 +
drivers/crypto/caam/compat.h | 2 +-
4 files changed, 38 insertions(+), 37 deletions(-)
diff --
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/stm32/stm32-cryp.c | 24 ++--
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-cryp.c
b/drivers/crypto/stm32/stm32-cryp.c
index cddcc97875b2..c1c7124c44aa 100644
--- a/drivers/crypto/stm32/s
In preparation of moving the shared key expansion routine into the
DES library, move the verification done by __des3_ede_setkey() into
its callers.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/des3_ede_glue.c | 4
crypto/des_generic.c| 10 +-
2 files changed, 9 ins
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 22
drivers/crypto/sunxi-ss/sun4i-ss.h| 2 +-
2 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
b/drivers/crypto/sunxi-ss/sun4i-ss-c
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/ux500/cryp/cryp_core.c | 31 +---
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c
b/drivers/crypto/ux500/cryp/cryp_core.c
index 7a93cba0877f..447bddd72fe7 100644
--- a/drivers/cr
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/cavium/cpt/cptvf_algs.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index f6b0c9df12ed..f9b0ac792d6d 100644
--- a/drivers/cry
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/inside-secure/safexcel_cipher.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/inside-secure/safexcel_cipher.c
b/drivers/crypto/inside-secure/safexcel_cipher.c
index 8cdbdbe35681..e6f00b56f063
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/omap-des.c | 25 ++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 3d82d18ff810..103b3293c113 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/picoxcell_crypto.c | 21 +++-
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/picoxcell_crypto.c
b/drivers/crypto/picoxcell_crypto.c
index 05b89e703903..31bc23665400 100644
--- a/drivers/crypto/picoxce
Acked-by: Harald Freudenberger
Signed-off-by: Ard Biesheuvel
---
arch/s390/crypto/des_s390.c | 23 +---
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/s390/crypto/des_s390.c b/arch/s390/crypto/des_s390.c
index 1f9ab24dc048..99edfb4907b5 100644
--- a/arch/s39
The recently added helper routines to perform key strength validation
of 3ede_keys is slightly inadequate, since it doesn't check the key
length, and it comes in two versions, neither of which are highly
useful for anything other than skciphers (and many users still use the
older blkcipher interfac
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 26 ++--
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index 0d5d3d8eb680..d313958d09a9 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_c
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/hifn_795x.c | 30 +---
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index d656be0a142b..000477e4a429 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/cry
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/ixp4xx_crypto.c | 21
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 3f40be34ac95..f7642e3848b8 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/ccp/ccp-crypto-des3.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-des3.c
b/drivers/crypto/ccp/ccp-crypto-des3.c
index 91482ffcac59..0ca0469d7a1e 100644
--- a/drivers/crypto/ccp/ccp-crypto-
n my effort to remove crypto_alloc_cipher() invocations from non-crypto
code, i ran into a DES call in the CIFS driver. This is addressed in
patch #30.
The other patches are cleanups for the quirky DES interface, and lots
of duplication of the weak key checks etc.
Changes since v1/RFC:
- fix buil
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/hisilicon/sec/sec_algs.c | 34 ++--
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hisilicon/sec/sec_algs.c
b/drivers/crypto/hisilicon/sec/sec_algs.c
index 02768af0dccd..0dc828b9c4a1 100644
--- a/driv
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 82 +---
1 file changed, 20 insertions(+), 62 deletions(-)
diff --git a/drivers/crypto/bcm/cipher.c b/drivers/crypto/bcm/cipher.c
index d972ffac779d..02006781528a 100644
--- a/drivers/crypto/bcm/cipher.c
+++ b/driver
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/atmel-tdes.c | 28 +---
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/crypto/atmel-tdes.c b/drivers/crypto/atmel-tdes.c
index fa76620281e8..3df8b3bb12a5 100644
--- a/drivers/crypto/atmel-tdes.c
+++ b/drivers
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/qce/ablkcipher.c | 55 ++--
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/crypto/qce/ablkcipher.c b/drivers/crypto/qce/ablkcipher.c
index 8d3493855a70..3003603f1872 100644
--- a/drivers/crypto/qce/ablkciphe
Signed-off-by: Ard Biesheuvel
---
arch/sparc/crypto/des_glue.c | 35 +---
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/arch/sparc/crypto/des_glue.c b/arch/sparc/crypto/des_glue.c
index 453a4cf5492a..8a35491d6656 100644
--- a/arch/sparc/crypto/des_glue.c
+++ b/ar
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/marvell/cipher.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index 2fd936b19c6d..718b51675638 100644
--- a/drivers/crypto/marvell/cipher
On Thu, 27 Jun 2019 at 11:58, Horia Geanta wrote:
>
> On 6/22/2019 3:32 AM, Ard Biesheuvel wrote:
> > Signed-off-by: Ard Biesheuvel
> > ---
> > drivers/crypto/caam/caamalg.c | 13 +++
> > drivers/crypto/caam/caamalg_qi.c | 23 ++--
> > drivers/crypto/caam/caamalg_qi2
On Thu, 27 Jun 2019 at 11:14, Horia Geanta wrote:
>
> On 6/22/2019 3:31 AM, Ard Biesheuvel wrote:
> > Signed-off-by: Ard Biesheuvel
> > ---
> > drivers/crypto/bcm/cipher.c | 82 +---
> > drivers/crypto/caam/caamalg.c | 31
> > 2 files changed, 37 insertions(+), 76 dele
On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> Exactly the same code to figure out DMA mask is repeated twice in the
> driver code. To avoid repetition, move that logic into a standalone
> subroutine in intern.h. While at it re-shuffle the code to make it
> more readable with early returns.
>
> Sig
The bluetooth code uses a bare AES cipher for the encryption operations.
Given that it carries out a set_key() operation right before every
encryption operation, this is clearly not a hot path, and so the use of
the cipher interface (which provides the best implementation available
on the system) i
GHASH is used by the GCM mode, which is often used in contexts where
only synchronous ciphers are permitted. So provide a synchronous version
of GHASH based on the existing code. This requires a non-SIMD fallback
to deal with invocations occurring from a context where SIMD instructions
may not be u
1 - 100 of 139 matches
Mail list logo
