linux-2.6-microblaze.git
3 years agocrypto: sa2ul - Fix inconsistent IS_ERR and PTR_ERR
Gustavo A. R. Silva [Fri, 24 Jul 2020 16:50:27 +0000 (11:50 -0500)]
crypto: sa2ul - Fix inconsistent IS_ERR and PTR_ERR

Fix inconsistent IS_ERR and PTR_ERR in sa_dma_init(). The proper pointer
to be passed as argument to PTR_ERR() is dd->dma_tx.

This bug was detected with the help of Coccinelle.

Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agohwrng: core - remove redundant initialization of variable ret
Colin Ian King [Fri, 24 Jul 2020 10:10:01 +0000 (11:10 +0100)]
hwrng: core - remove redundant initialization of variable ret

The variable ret is being initialized with a value that is never read
and it is being updated later with a new value.  The initialization is
redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: x86/curve25519 - Remove unused carry variables
Herbert Xu [Thu, 23 Jul 2020 07:50:48 +0000 (17:50 +1000)]
crypto: x86/curve25519 - Remove unused carry variables

The carry variables are assigned but never used, which upsets
the compiler.  This patch removes them.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: ingenic - Add hardware RNG for Ingenic JZ4780 and X1000
周琰杰 (Zhou Yanjie) [Thu, 23 Jul 2020 06:24:46 +0000 (14:24 +0800)]
crypto: ingenic - Add hardware RNG for Ingenic JZ4780 and X1000

Add JZ4780 SoC and X1000 SoC random number generator driver,
based on PrasannaKumar Muralidharan's JZ4780 RNG driver.

Tested-by: 周正 (Zhou Zheng) <sernia.zhou@foxmail.com>
Tested-by: Mathieu Malaterre <malat@debian.org>
Suggested-by: Jeffrey Walton <noloader@gmail.com>
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agodt-bindings: RNG: Add Ingenic RNG bindings.
周琰杰 (Zhou Yanjie) [Thu, 23 Jul 2020 06:24:45 +0000 (14:24 +0800)]
dt-bindings: RNG: Add Ingenic RNG bindings.

Add the RNG bindings for the JZ4780 SoC and
the X1000 SoC from Ingenic.

Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam/qi2 - add module alias
Horia Geantă [Wed, 22 Jul 2020 12:14:58 +0000 (15:14 +0300)]
crypto: caam/qi2 - add module alias

Add a module alias, to enable udev-based module autoloading:

$ modinfo -F alias drivers/crypto/caam/dpaa2_caam.ko
fsl-mc:v00001957ddpseci

Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam - add more RNG hw error codes
Horia Geantă [Wed, 22 Jul 2020 12:14:57 +0000 (15:14 +0300)]
crypto: caam - add more RNG hw error codes

In some cases, e.g. when TRNG is not properly configured,
the RNG module could issue a "Hardware error" at runtime.

"Continuos check" error is emitted when some of the BISTs fail.

Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam/jr - remove incorrect reference to caam_jr_register()
Dan Douglass [Wed, 22 Jul 2020 12:14:56 +0000 (15:14 +0300)]
crypto: caam/jr - remove incorrect reference to caam_jr_register()

caam_jr_register() function is no longer part of the driver since
commit 6dad41158db6 ("crypto: caam - Remove unused functions from Job Ring")

This patch removes a comment referencing the function.

Signed-off-by: Dan Douglass <dan.douglass@nxp.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam - silence .setkey in case of bad key length
Horia Geantă [Wed, 22 Jul 2020 12:14:55 +0000 (15:14 +0300)]
crypto: caam - silence .setkey in case of bad key length

In case of bad key length, driver emits "key size mismatch" messages,
but only for xts(aes) algorithms.

Reduce verbosity by making them visible only when debugging.
This way crypto fuzz testing log cleans up a bit.

Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam/qi2 - create ahash shared descriptors only once
Horia Geantă [Wed, 22 Jul 2020 12:14:54 +0000 (15:14 +0300)]
crypto: caam/qi2 - create ahash shared descriptors only once

For keyed hash algorithms, shared descriptors are currently generated
twice:
-at tfm initialization time, in cra_init() callback
-in setkey() callback

Since it's mandatory to call setkey() for keyed algorithms, drop the
generation in cra_init().

This is similar to the change in caamhash (caam/jr top-level library)
commit 9a2537d0ebc9 ("crypto: caam - create ahash shared descriptors only once")

Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam/qi2 - fix error reporting for caam_hash_alloc
Horia Geantă [Wed, 22 Jul 2020 12:14:53 +0000 (15:14 +0300)]
crypto: caam/qi2 - fix error reporting for caam_hash_alloc

Fix error reporting when preparation of an hmac algorithm
for registration fails: print the hmac algorithm name, not the unkeyed
hash algorithm name.

Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam - remove deadcode on 32-bit platforms
Franck LENORMAND [Wed, 22 Jul 2020 12:14:52 +0000 (15:14 +0300)]
crypto: caam - remove deadcode on 32-bit platforms

When building on a platform with a 32bit DMA address, taking the
upper 32 bits makes no sense.

Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: ccp - use generic power management
Vaibhav Gupta [Wed, 22 Jul 2020 09:30:58 +0000 (15:00 +0530)]
crypto: ccp - use generic power management

Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.

Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the unnecessary load from the driver.
This also avoids the need for the driver to directly call most of the PCI
helper functions and device power state control functions as through
the generic framework, PCI Core takes care of the necessary operations,
and drivers are required to do only device-specific jobs.

Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: xts - Replace memcpy() invocation with simple assignment
Ard Biesheuvel [Tue, 21 Jul 2020 06:05:54 +0000 (09:05 +0300)]
crypto: xts - Replace memcpy() invocation with simple assignment

Colin reports that the memcpy() call in xts_cts_final() trigggers a
"Overlapping buffer in memory copy" warning in Coverity, which is a
false postive, given that tail is guaranteed to be smaller than or
equal to the distance between source and destination.

However, given that any additional bytes that we copy will be ignored
anyway, we can simply copy XTS_BLOCK_SIZE unconditionally, which means
we can use struct assignment of the array members instead, which is
likely to be more efficient as well.

Addresses-Coverity: ("Overlapping buffer in memory copy")
Fixes: 8083b1bf8163 ("crypto: xts - add support for ciphertext stealing")
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: marvell/cesa - irq balance
Sven Auhagen [Tue, 21 Jul 2020 04:40:27 +0000 (06:40 +0200)]
crypto: marvell/cesa - irq balance

Balance the irqs of the marvell cesa driver over all
available cpus.
Currently all interrupts are handled by the first CPU.

From my testing with IPSec AES 256 SHA256
on my clearfog base with 2 Cores I get a 2x speed increase:

Before the patch: 26.74 Kpps
With the patch: 56.11 Kpps

Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: inside-secure - irq balance
Sven Auhagen [Tue, 21 Jul 2020 04:37:59 +0000 (06:37 +0200)]
crypto: inside-secure - irq balance

Balance the irqs of the inside secure driver over all
available cpus.
Currently all interrupts are handled by the first CPU.

From my testing with IPSec AES-GCM 256
on my MCbin with 4 Cores I get a 50% speed increase:

Before the patch: 99.73 Kpps
With the patch: 151.25 Kpps

Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: ecc - SP800-56A rev 3 local public key validation
Stephan Müller [Mon, 20 Jul 2020 17:09:23 +0000 (19:09 +0200)]
crypto: ecc - SP800-56A rev 3 local public key validation

After the generation of a local public key, SP800-56A rev 3 section
5.6.2.1.3 mandates a validation of that key with a full validation
compliant to section 5.6.2.3.3.

Only if the full validation passes, the key is allowed to be used.

The patch adds the full key validation compliant to 5.6.2.3.3 and
performs the required check on the generated public key.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: dh - SP800-56A rev 3 local public key validation
Stephan Müller [Mon, 20 Jul 2020 17:08:52 +0000 (19:08 +0200)]
crypto: dh - SP800-56A rev 3 local public key validation

After the generation of a local public key, SP800-56A rev 3 section
5.6.2.1.3 mandates a validation of that key with a full validation
compliant to section 5.6.2.3.1.

Only if the full validation passes, the key is allowed to be used.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: dh - check validity of Z before export
Stephan Müller [Mon, 20 Jul 2020 17:08:32 +0000 (19:08 +0200)]
crypto: dh - check validity of Z before export

SP800-56A rev3 section 5.7.1.1 step 2 mandates that the validity of the
calculated shared secret is verified before the data is returned to the
caller. This patch adds the validation check.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
Acked-by: Neil Horman <nhorman@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agolib/mpi: Add mpi_sub_ui()
Marcelo Henrique Cerri [Mon, 20 Jul 2020 17:08:09 +0000 (19:08 +0200)]
lib/mpi: Add mpi_sub_ui()

Add mpi_sub_ui() based on Gnu MP mpz_sub_ui() function from file
mpz/aors_ui.h[1] from change id 510b83519d1c adapting the code to the
kernel's data structures, helper functions and coding style and also
removing the defines used to produce mpz_sub_ui() and mpz_add_ui()
from the same code.

[1] https://gmplib.org/repo/gmp-6.2/file/510b83519d1c/mpz/aors.h

Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: ecdh - check validity of Z before export
Stephan Müller [Mon, 20 Jul 2020 17:07:48 +0000 (19:07 +0200)]
crypto: ecdh - check validity of Z before export

SP800-56A rev3 section 5.7.1.2 step 2 mandates that the validity of the
calculated shared secret is verified before the data is returned to the
caller. Thus, the export function and the validity check functions are
reversed. In addition, the sensitive variables of priv and rand_z are
zeroized.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Acked-by: Neil Horman <nhorman@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: x86 - Put back integer parts of include/asm/inst.h
Uros Bizjak [Mon, 20 Jul 2020 13:51:57 +0000 (15:51 +0200)]
crypto: x86 - Put back integer parts of include/asm/inst.h

Resolves conflict with the tip tree.

Fixes: d7866e503bdc ("crypto: x86 - Remove include/asm/inst.h")
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: Borislav Petkov <bp@alien8.de>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: Stephen Rothwell <sfr@canb.auug.org.au>,
CC: "Chang S. Bae" <chang.seok.bae@intel.com>,
CC: Peter Zijlstra <peterz@infradead.org>,
CC: Sasha Levin <sashal@kernel.org>
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: testmgr - delete duplicated words
Randy Dunlap [Sun, 19 Jul 2020 18:07:50 +0000 (11:07 -0700)]
crypto: testmgr - delete duplicated words

Delete the doubled word "from" in multiple places.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: Replace HTTP links with HTTPS ones
Alexander A. Klimov [Sun, 19 Jul 2020 16:49:59 +0000 (18:49 +0200)]
crypto: Replace HTTP links with HTTPS ones

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: skcipher - drop duplicated word in kernel-doc
Randy Dunlap [Fri, 17 Jul 2020 23:35:49 +0000 (16:35 -0700)]
crypto: skcipher - drop duplicated word in kernel-doc

Drop the doubled word "request" in a kernel-doc comment.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hash - drop duplicated word in a comment
Randy Dunlap [Fri, 17 Jul 2020 23:35:33 +0000 (16:35 -0700)]
crypto: hash - drop duplicated word in a comment

Drop the doubled word "in" in a comment.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: omap-aes - Fix sparse and compiler warnings
Herbert Xu [Thu, 16 Jul 2020 08:06:56 +0000 (18:06 +1000)]
crypto: omap-aes - Fix sparse and compiler warnings

This patch fixes all the sparse and W=1 compiler warnings in the
driver.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agohwrng: imx-rngc - enable driver for i.MX6
Horia Geantă [Wed, 15 Jul 2020 15:26:04 +0000 (18:26 +0300)]
hwrng: imx-rngc - enable driver for i.MX6

i.MX6 SL, SLL, ULL, ULZ SoCs have an RNGB block.

Since imx-rngc driver supports also rngb,
let's enable it for these SoCs too.

Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agodt-bindings: rng: add RNGB compatibles for i.MX6 SoCs
Horia Geantă [Wed, 15 Jul 2020 15:26:00 +0000 (18:26 +0300)]
dt-bindings: rng: add RNGB compatibles for i.MX6 SoCs

RNGB block is found in some i.MX6 SoCs - 6SL, 6SLL, 6ULL, 6ULZ.
Add corresponding compatible strings.

Note:

Several NXP SoC from QorIQ family (P1010, P1023, P4080, P3041, P5020)
also have a RNGB, however it's part of the CAAM
(Cryptograhic Accelerator and Assurance Module) crypto accelerator.
In this case, RNGB is managed in the caam driver
(drivers/crypto/caam/), since it's tightly related to
the caam "job ring" interface, not to mention CAAM internally relying on
RNGB as source of randomness.

On the other hand, the i.MX6 SoCs with RNGB have a DCP
(Data Co-Processor) crypto accelerator and this block and RNGB
are independent.

Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agopadata: remove padata_parallel_queue
Daniel Jordan [Tue, 14 Jul 2020 20:13:56 +0000 (16:13 -0400)]
padata: remove padata_parallel_queue

Only its reorder field is actually used now, so remove the struct and
embed @reorder directly in parallel_data.

No functional change, just a cleanup.

Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agopadata: fold padata_alloc_possible() into padata_alloc()
Daniel Jordan [Tue, 14 Jul 2020 20:13:55 +0000 (16:13 -0400)]
padata: fold padata_alloc_possible() into padata_alloc()

There's no reason to have two interfaces when there's only one caller.
Removing _possible saves text and simplifies future changes.

Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agopadata: remove effective cpumasks from the instance
Daniel Jordan [Tue, 14 Jul 2020 20:13:54 +0000 (16:13 -0400)]
padata: remove effective cpumasks from the instance

A padata instance has effective cpumasks that store the user-supplied
masks ANDed with the online mask, but this middleman is unnecessary.
parallel_data keeps the same information around.  Removing this saves
text and code churn in future changes.

Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agopadata: inline single call of pd_setup_cpumasks()
Daniel Jordan [Tue, 14 Jul 2020 20:13:53 +0000 (16:13 -0400)]
padata: inline single call of pd_setup_cpumasks()

pd_setup_cpumasks() has only one caller.  Move its contents inline to
prepare for the next cleanup.

Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agopadata: remove stop function
Daniel Jordan [Tue, 14 Jul 2020 20:13:52 +0000 (16:13 -0400)]
padata: remove stop function

padata_stop() has two callers and is unnecessary in both cases.  When
pcrypt calls it before padata_free(), it's being unloaded so there are
no outstanding padata jobs[0].  When __padata_free() calls it, it's
either along the same path or else pcrypt initialization failed, which
of course means there are also no outstanding jobs.

Removing it simplifies padata and saves text.

[0] https://lore.kernel.org/linux-crypto/20191119225017.mjrak2fwa5vccazl@gondor.apana.org.au/

Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agopadata: remove start function
Daniel Jordan [Tue, 14 Jul 2020 20:13:51 +0000 (16:13 -0400)]
padata: remove start function

padata_start() is only used right after pcrypt allocates an instance
with all possible CPUs, when PADATA_INVALID can't happen, so there's no
need for a separate "start" step.  It can be done during allocation to
save text, make using padata easier, and avoid unneeded calls in the
future.

Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: qat - fix double free in qat_uclo_create_batch_init_list
Tom Rix [Mon, 13 Jul 2020 14:06:34 +0000 (07:06 -0700)]
crypto: qat - fix double free in qat_uclo_create_batch_init_list

clang static analysis flags this error

qat_uclo.c:297:3: warning: Attempt to free released memory
  [unix.Malloc]
                kfree(*init_tab_base);
                ^~~~~~~~~~~~~~~~~~~~~

When input *init_tab_base is null, the function allocates memory for
the head of the list.  When there is problem allocating other list
elements the list is unwound and freed.  Then a check is made if the
list head was allocated and is also freed.

Keeping track of the what may need to be freed is the variable 'tail_old'.
The unwinding/freeing block is

while (tail_old) {
mem_init = tail_old->next;
kfree(tail_old);
tail_old = mem_init;
}

The problem is that the first element of tail_old is also what was
allocated for the list head

init_header = kzalloc(sizeof(*init_header), GFP_KERNEL);
...
*init_tab_base = init_header;
flag = 1;
}
tail_old = init_header;

So *init_tab_base/init_header are freed twice.

There is another problem.
When the input *init_tab_base is non null the tail_old is calculated by
traveling down the list to first non null entry.

tail_old = init_header;
while (tail_old->next)
tail_old = tail_old->next;

When the unwinding free happens, the last entry of the input list will
be freed.

So the freeing needs a general changed.
If locally allocated the first element of tail_old is freed, else it
is skipped.  As a bit of cleanup, reset *init_tab_base if it came in
as null.

Fixes: b4b7e67c917f ("crypto: qat - Intel(R) QAT ucode part of fw loader")
Cc: <stable@vger.kernel.org>
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sa2ul - add device links to child devices
Tero Kristo [Mon, 13 Jul 2020 08:34:25 +0000 (11:34 +0300)]
crypto: sa2ul - add device links to child devices

The child devices for sa2ul (like the RNG) have hard dependency towards
the parent, they can't function without the parent enabled. Add device
link for this purpose so that the dependencies are taken care of properly.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sa2ul - Add AEAD algorithm support
Keerthy [Mon, 13 Jul 2020 08:34:24 +0000 (11:34 +0300)]
crypto: sa2ul - Add AEAD algorithm support

Add support for sa2ul hardware AEAD for hmac(sha256),cbc(aes) and
hmac(sha1),cbc(aes) algorithms.

Signed-off-by: Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: number of bug fixes, major refactoring and cleanup of
 code]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sa2ul - add sha1/sha256/sha512 support
Keerthy [Mon, 13 Jul 2020 08:34:23 +0000 (11:34 +0300)]
crypto: sa2ul - add sha1/sha256/sha512 support

Add support for sha1/sha256/sha512 sa2ul based hardware authentication.
With the hash update mechanism, we always use software fallback
mechanism for now, as there is no way to fetch the partial hash state
from the HW accelerator. HW accelerator is only used when digest is
called for a data chunk of known size.

Signed-off-by: Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: various bug fixes, major cleanups and refactoring of code]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sa2ul - Add crypto driver
Keerthy [Mon, 13 Jul 2020 08:34:22 +0000 (11:34 +0300)]
crypto: sa2ul - Add crypto driver

Adds a basic crypto driver and currently supports AES/3DES
in cbc mode for both encryption and decryption.

Signed-off-by: Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: major re-work to fix various bugs in the driver and to
 cleanup the code]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agodt-bindings: crypto: Add TI SA2UL crypto accelerator documentation
Keerthy [Mon, 13 Jul 2020 08:34:21 +0000 (11:34 +0300)]
dt-bindings: crypto: Add TI SA2UL crypto accelerator documentation

The Security Accelerator Ultra Lite (SA2UL) 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

SA2UL provides support for number of different cryptographic algorithms
including SHA1, SHA256, SHA512, AES, 3DES, and various combinations of
the previous for AEAD use.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Keerthy <j-keerthy@ti.com>
[t-kristo@ti.com: converted documentation to yaml]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: x86/crc32c - fix building with clang ias
Arnd Bergmann [Wed, 27 May 2020 14:17:40 +0000 (16:17 +0200)]
crypto: x86/crc32c - fix building with clang ias

The clang integrated assembler complains about movzxw:

arch/x86/crypto/crc32c-pcl-intel-asm_64.S:173:2: error: invalid instruction mnemonic 'movzxw'

It seems that movzwq is the mnemonic that it expects instead,
and this is what objdump prints when disassembling the file.

Fixes: 6a8ce1ef3940 ("crypto: crc32c - Optimize CRC32C calculation with PCLMULQDQ instruction")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: chelsio - Fix some pr_xxx messages
Christophe JAILLET [Sun, 12 Jul 2020 21:14:24 +0000 (23:14 +0200)]
crypto: chelsio - Fix some pr_xxx messages

At the top this file, we have:
   #define pr_fmt(fmt) "chcr:" fmt

So there is no need to repeat "chcr : " in some error message when the
pr_xxx macro is used.
This would lead to log "chcr:chcr : blabla"

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: chelsio - Avoid some code duplication
Christophe JAILLET [Sun, 12 Jul 2020 21:14:04 +0000 (23:14 +0200)]
crypto: chelsio - Avoid some code duplication

The error handling path of 'chcr_authenc_setkey()' is the same as this
error handling code.

So just 'goto out' as done everywhere in the function to simplify the code.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: lrw - prefix function and struct names with "lrw"
Eric Biggers [Sat, 11 Jul 2020 03:36:49 +0000 (20:36 -0700)]
crypto: lrw - prefix function and struct names with "lrw"

Overly-generic names can cause problems like naming collisions,
confusing crash reports, and reduced grep-ability.  E.g. see
commit d099ea6e6fde ("crypto - Avoid free() namespace collision").

Clean this up for the lrw template by prefixing the names with "lrw_".

(I didn't use "crypto_lrw_" instead because that seems overkill.)

Also constify the tfm context in a couple places.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: xts - prefix function and struct names with "xts"
Eric Biggers [Sat, 11 Jul 2020 03:34:28 +0000 (20:34 -0700)]
crypto: xts - prefix function and struct names with "xts"

Overly-generic names can cause problems like naming collisions,
confusing crash reports, and reduced grep-ability.  E.g. see
commit d099ea6e6fde ("crypto - Avoid free() namespace collision").

Clean this up for the xts template by prefixing the names with "xts_".

(I didn't use "crypto_xts_" instead because that seems overkill.)

Also constify the tfm context in a couple places, and make
xts_free_instance() use the instance context structure so that it
doesn't just assume the crypto_skcipher_spawn is at the beginning.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/hpre - disable FLR triggered by hardware
Hui Tang [Fri, 10 Jul 2020 07:40:46 +0000 (15:40 +0800)]
crypto: hisilicon/hpre - disable FLR triggered by hardware

for Hi1620 hardware, we should disable these hardware flr:
1. BME_FLR - bit 7,
2. PM_FLR - bit 11,
3. SRIOV_FLR - bit 12,
Or HPRE may goto D3 state, when we bind and unbind HPRE quickly,
as it does FLR triggered by BME/PM/SRIOV.

Fixes: c8b4b477079d("crypto: hisilicon - add HiSilicon HPRE accelerator")
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Signed-off-by: Meng Yu <yumeng18@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/hpre - update debugfs interface parameters
Meng Yu [Fri, 10 Jul 2020 07:40:45 +0000 (15:40 +0800)]
crypto: hisilicon/hpre - update debugfs interface parameters

Update debugfs interface parameters, and adjust the
processing logic inside the corresponding function.

Fixes: 848974151618("crypto: hisilicon - Add debugfs for HPRE")
Signed-off-by: Meng Yu <yumeng18@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/hpre - Add a switch in sriov_configure
Meng Yu [Fri, 10 Jul 2020 07:40:44 +0000 (15:40 +0800)]
crypto: hisilicon/hpre - Add a switch in sriov_configure

If CONFIG_PCI_IOV is not enabled, we can not use "sriov_configure".

Fixes: 5ec302a364bf("crypto: hisilicon - add SRIOV support for HPRE")
Signed-off-by: Meng Yu <yumeng18@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Reviewed-by: Shukun Tan <tanshukun1@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/hpre - Modify the Macro definition and format
Meng Yu [Fri, 10 Jul 2020 07:40:43 +0000 (15:40 +0800)]
crypto: hisilicon/hpre - Modify the Macro definition and format

1. Bit 1 to bit 5 are NFE, not CE.
2. Macro 'HPRE_VF_NUM' is defined in 'qm.h', so delete it here.
3. Delete multiple blank lines.
4. Adjust format alignment.

Signed-off-by: Meng Yu <yumeng18@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Reviewed-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/hpre - HPRE_OVERTIME_THRHLD can be written by debugfs
Hui Tang [Fri, 10 Jul 2020 07:40:42 +0000 (15:40 +0800)]
crypto: hisilicon/hpre - HPRE_OVERTIME_THRHLD can be written by debugfs

Registers in "hpre_dfx_files" can only be cleaned to zero but
HPRE_OVERTIME_THRHLD, which can be written as any number.

Fixes: 64a6301ebee7("crypto: hisilicon/hpre - add debugfs for ...")
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Signed-off-by: Meng Yu <yumeng18@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/hpre - Init the value of current_q of debugfs
Meng Yu [Fri, 10 Jul 2020 07:40:41 +0000 (15:40 +0800)]
crypto: hisilicon/hpre - Init the value of current_q of debugfs

Initialize current queue number as HPRE_PF_DEF_Q_NUM, or it is zero
and we can't set its value by "current_q_write".

Signed-off-by: Meng Yu <yumeng18@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Reviewed-by: Hui Tang <tanghui20@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY
Mikulas Patocka [Fri, 10 Jul 2020 06:20:41 +0000 (23:20 -0700)]
crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY

Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
allocate memory.

drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c: sun8i_ce_cipher
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c: sun8i_ss_cipher
drivers/crypto/amlogic/amlogic-gxl-core.c: meson_cipher
drivers/crypto/axis/artpec6_crypto.c: artpec6_crypto_common_init
drivers/crypto/bcm/cipher.c: spu_skcipher_rx_sg_create
drivers/crypto/caam/caamalg.c: aead_edesc_alloc
drivers/crypto/caam/caamalg_qi.c: aead_edesc_alloc
drivers/crypto/caam/caamalg_qi2.c: aead_edesc_alloc
drivers/crypto/caam/caamhash.c: hash_digest_key
drivers/crypto/cavium/cpt/cptvf_algs.c: process_request
drivers/crypto/cavium/nitrox/nitrox_aead.c: nitrox_process_se_request
drivers/crypto/cavium/nitrox/nitrox_skcipher.c: nitrox_process_se_request
drivers/crypto/ccp/ccp-crypto-aes-cmac.c: ccp_do_cmac_update
drivers/crypto/ccp/ccp-crypto-aes-galois.c: ccp_crypto_enqueue_request
drivers/crypto/ccp/ccp-crypto-aes-xts.c: ccp_crypto_enqueue_request
drivers/crypto/ccp/ccp-crypto-aes.c: ccp_crypto_enqueue_request
drivers/crypto/ccp/ccp-crypto-des3.c: ccp_crypto_enqueue_request
drivers/crypto/ccp/ccp-crypto-sha.c: ccp_crypto_enqueue_request
drivers/crypto/chelsio/chcr_algo.c: create_cipher_wr
drivers/crypto/hisilicon/sec/sec_algs.c: sec_alloc_and_fill_hw_sgl
drivers/crypto/hisilicon/sec2/sec_crypto.c: sec_alloc_req_id
drivers/crypto/inside-secure/safexcel_cipher.c: safexcel_queue_req
drivers/crypto/inside-secure/safexcel_hash.c: safexcel_ahash_enqueue
drivers/crypto/ixp4xx_crypto.c: ablk_perform
drivers/crypto/marvell/cesa/cipher.c: mv_cesa_skcipher_dma_req_init
drivers/crypto/marvell/cesa/hash.c: mv_cesa_ahash_dma_req_init
drivers/crypto/marvell/octeontx/otx_cptvf_algs.c: create_ctx_hdr
drivers/crypto/n2_core.c: n2_compute_chunks
drivers/crypto/picoxcell_crypto.c: spacc_sg_to_ddt
drivers/crypto/qat/qat_common/qat_algs.c: qat_alg_skcipher_encrypt
drivers/crypto/qce/skcipher.c: qce_skcipher_async_req_handle
drivers/crypto/talitos.c : talitos_edesc_alloc
drivers/crypto/virtio/virtio_crypto_algs.c: __virtio_crypto_skcipher_do_req
drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
[EB: avoid overly-long lines]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: algapi - introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY
Eric Biggers [Fri, 10 Jul 2020 06:20:40 +0000 (23:20 -0700)]
crypto: algapi - introduce the flag CRYPTO_ALG_ALLOCATES_MEMORY

Introduce a new algorithm flag CRYPTO_ALG_ALLOCATES_MEMORY.  If this
flag is set, then the driver allocates memory in its request routine.
Such drivers are not suitable for disk encryption because GFP_ATOMIC
allocation can fail anytime (causing random I/O errors) and GFP_KERNEL
allocation can recurse into the block layer, causing a deadlock.

For now, this flag is only implemented for some algorithm types.  We
also assume some usage constraints for it to be meaningful, since there
are lots of edge cases the crypto API allows (e.g., misaligned or
fragmented scatterlists) that mean that nearly any crypto algorithm can
allocate memory in some case.  See the comment for details.

Also add this flag to CRYPTO_ALG_INHERITED_FLAGS so that when a template
is instantiated, this flag is set on the template instance if it is set
on any algorithm the instance uses.

Based on a patch by Mikulas Patocka <mpatocka@redhat.com>
(https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: algapi - add NEED_FALLBACK to INHERITED_FLAGS
Eric Biggers [Fri, 10 Jul 2020 06:20:39 +0000 (23:20 -0700)]
crypto: algapi - add NEED_FALLBACK to INHERITED_FLAGS

CRYPTO_ALG_NEED_FALLBACK is handled inconsistently.  When it's requested
to be clear, some templates propagate that request to child algorithms,
while others don't.

It's apparently desired for NEED_FALLBACK to be propagated, to avoid
deadlocks where a module tries to load itself while it's being
initialized, and to avoid unnecessarily complex fallback chains where we
have e.g. cbc-aes-$driver falling back to cbc(aes-$driver) where
aes-$driver itself falls back to aes-generic, instead of cbc-aes-$driver
simply falling back to cbc(aes-generic).  There have been a number of
fixes to this effect:

commit 89027579bc6c ("crypto: xts - Propagate NEED_FALLBACK bit")
commit d2c2a85cfe82 ("crypto: ctr - Propagate NEED_FALLBACK bit")
commit e6c2e65c70a6 ("crypto: cbc - Propagate NEED_FALLBACK bit")

But it seems that other templates can have the same problems too.

To avoid this whack-a-mole, just add NEED_FALLBACK to INHERITED_FLAGS so
that it's always inherited.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: algapi - use common mechanism for inheriting flags
Eric Biggers [Fri, 10 Jul 2020 06:20:38 +0000 (23:20 -0700)]
crypto: algapi - use common mechanism for inheriting flags

The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a
template is instantiated, the template will have CRYPTO_ALG_ASYNC set if
any of the algorithms it uses has CRYPTO_ALG_ASYNC set.

We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets
"inherited" in the same way.  This is difficult because the handling of
CRYPTO_ALG_ASYNC is hardcoded everywhere.  Address this by:

  - Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that
    have these inheritance semantics.

  - Add crypto_algt_inherited_mask(), for use by template ->create()
    methods.  It returns any of these flags that the user asked to be
    unset and thus must be passed in the 'mask' to crypto_grab_*().

  - Also modify crypto_check_attr_type() to handle computing the 'mask'
    so that most templates can just use this.

  - Make crypto_grab_*() propagate these flags to the template instance
    being created so that templates don't have to do this themselves.

Make crypto/simd.c propagate these flags too, since it "wraps" another
algorithm, similar to a template.

Based on a patch by Mikulas Patocka <mpatocka@redhat.com>
(https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: seqiv - remove seqiv_create()
Eric Biggers [Fri, 10 Jul 2020 06:20:37 +0000 (23:20 -0700)]
crypto: seqiv - remove seqiv_create()

seqiv_create() is pointless because it just checks that the template is
being instantiated as an AEAD, then calls seqiv_aead_create().  But
seqiv_aead_create() does the exact same check, via aead_geniv_alloc().

Just remove seqiv_create() and use seqiv_aead_create() directly.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: geniv - remove unneeded arguments from aead_geniv_alloc()
Eric Biggers [Fri, 10 Jul 2020 06:20:36 +0000 (23:20 -0700)]
crypto: geniv - remove unneeded arguments from aead_geniv_alloc()

The type and mask arguments to aead_geniv_alloc() are always 0, so
remove them.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: x86 - Remove include/asm/inst.h
Uros Bizjak [Thu, 9 Jul 2020 15:08:57 +0000 (17:08 +0200)]
crypto: x86 - Remove include/asm/inst.h

Current minimum required version of binutils is 2.23,
which supports PSHUFB, PCLMULQDQ, PEXTRD, AESKEYGENASSIST,
AESIMC, AESENC, AESENCLAST, AESDEC, AESDECLAST and MOVQ
instruction mnemonics.

Substitute macros from include/asm/inst.h with a proper
instruction mnemonics in various assmbly files from
x86/crypto directory, and remove now unneeded file.

The patch was tested by calculating and comparing sha256sum
hashes of stripped object files before and after the patch,
to be sure that executable code didn't change.

Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: "David S. Miller" <davem@davemloft.net>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: Borislav Petkov <bp@alien8.de>
CC: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: ccp - Silence strncpy warning
Herbert Xu [Thu, 9 Jul 2020 12:44:04 +0000 (22:44 +1000)]
crypto: ccp - Silence strncpy warning

This patch kills an strncpy by using strscpy instead.  The name
would be silently truncated if it is too long.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agohwrng: ks-sa - Replace HTTP links with HTTPS ones
Alexander A. Klimov [Thu, 9 Jul 2020 10:35:39 +0000 (12:35 +0200)]
hwrng: ks-sa - Replace HTTP links with HTTPS ones

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agoASoC: cros_ec_codec: use sha256() instead of open coding
Eric Biggers [Wed, 8 Jul 2020 16:39:43 +0000 (09:39 -0700)]
ASoC: cros_ec_codec: use sha256() instead of open coding

Now that there's a function that calculates the SHA-256 digest of a
buffer in one step, use it instead of sha256_init() + sha256_update() +
sha256_final().

Also simplify the code by inlining calculate_sha256() into its caller
and switching a debug log statement to use %*phN instead of bin2hex().

Acked-by: Tzung-Bi Shih <tzungbi@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Cc: alsa-devel@alsa-project.org
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Cheng-Yi Chiang <cychiang@chromium.org>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Tzung-Bi Shih <tzungbi@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agomptcp: use sha256() instead of open coding
Eric Biggers [Wed, 8 Jul 2020 16:39:42 +0000 (09:39 -0700)]
mptcp: use sha256() instead of open coding

Now that there's a function that calculates the SHA-256 digest of a
buffer in one step, use it instead of sha256_init() + sha256_update() +
sha256_final().

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Cc: mptcp@lists.01.org
Cc: Mat Martineau <mathew.j.martineau@linux.intel.com>
Cc: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agoefi: use sha256() instead of open coding
Eric Biggers [Wed, 8 Jul 2020 16:39:41 +0000 (09:39 -0700)]
efi: use sha256() instead of open coding

Now that there's a function that calculates the SHA-256 digest of a
buffer in one step, use it instead of sha256_init() + sha256_update() +
sha256_final().

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Cc: linux-efi@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: lib/sha256 - add sha256() function
Eric Biggers [Wed, 8 Jul 2020 16:39:40 +0000 (09:39 -0700)]
crypto: lib/sha256 - add sha256() function

Add a function sha256() which computes a SHA-256 digest in one step,
combining sha256_init() + sha256_update() + sha256_final().

This is similar to how we also have blake2s().

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sparc - rename sha256 to sha256_alg
Eric Biggers [Wed, 8 Jul 2020 16:39:39 +0000 (09:39 -0700)]
crypto: sparc - rename sha256 to sha256_alg

To avoid a naming collision when we add a sha256() library function,
rename the "sha256" static variable in sha256_glue.c to "sha256_alg".
For consistency, also rename "sha224" to "sha224_alg".

Reported-by: kernel test robot <lkp@intel.com>
Cc: sparclinux@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: x86/chacha-sse3 - use unaligned loads for state array
Ard Biesheuvel [Wed, 8 Jul 2020 09:11:18 +0000 (12:11 +0300)]
crypto: x86/chacha-sse3 - use unaligned loads for state array

Due to the fact that the x86 port does not support allocating objects
on the stack with an alignment that exceeds 8 bytes, we have a rather
ugly hack in the x86 code for ChaCha to ensure that the state array is
aligned to 16 bytes, allowing the SSE3 implementation of the algorithm
to use aligned loads.

Given that the performance benefit of using of aligned loads appears to
be limited (~0.25% for 1k blocks using tcrypt on a Corei7-8650U), and
the fact that this hack has leaked into generic ChaCha code, let's just
remove it.

Cc: Martin Willi <martin@strongswan.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Martin Willi <martin@strongswan.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: lib/chacha20poly1305 - Add missing function declaration
Herbert Xu [Wed, 8 Jul 2020 02:41:13 +0000 (12:41 +1000)]
crypto: lib/chacha20poly1305 - Add missing function declaration

This patch adds a declaration for chacha20poly1305_selftest to
silence a sparse warning.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: mediatek - use AES library for GCM key derivation
Ard Biesheuvel [Tue, 7 Jul 2020 06:32:03 +0000 (09:32 +0300)]
crypto: mediatek - use AES library for GCM key derivation

The Mediatek accelerator driver calls into a dynamically allocated
skcipher of the ctr(aes) variety to perform GCM key derivation, which
involves AES encryption of a single block consisting of NUL bytes.

There is no point in using the skcipher API for this, so use the AES
library interface instead.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sahara - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:32:02 +0000 (09:32 +0300)]
crypto: sahara - permit asynchronous skcipher as fallback

Even though the sahara driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: qce - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:32:01 +0000 (09:32 +0300)]
crypto: qce - permit asynchronous skcipher as fallback

Even though the qce driver implements asynchronous versions of ecb(aes),
cbc(aes)and xts(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

While at it, remove the pointless memset() from qce_skcipher_init(), and
remove the call to it qce_skcipher_init_fallback().

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: picoxcell - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:32:00 +0000 (09:32 +0300)]
crypto: picoxcell - permit asynchronous skcipher as fallback

Even though the picoxcell driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: mxs-dcp - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:59 +0000 (09:31 +0300)]
crypto: mxs-dcp - permit asynchronous skcipher as fallback

Even though the mxs-dcp driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: chelsio - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:58 +0000 (09:31 +0300)]
crypto: chelsio - permit asynchronous skcipher as fallback

Even though the chelsio driver implements asynchronous versions of
cbc(aes) and xts(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: ccp - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:57 +0000 (09:31 +0300)]
crypto: ccp - permit asynchronous skcipher as fallback

Even though the ccp driver implements an asynchronous version of xts(aes),
the fallback it allocates is required to be synchronous. Given that SIMD
based software implementations are usually asynchronous as well, even
though they rarely complete asynchronously (this typically only happens
in cases where the request was made from softirq context, while SIMD was
already in use in the task context that it interrupted), these
implementations are disregarded, and either the generic C version or
another table based version implemented in assembler is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sun8i-ss - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:56 +0000 (09:31 +0300)]
crypto: sun8i-ss - permit asynchronous skcipher as fallback

Even though the sun8i-ss driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sun8i-ce - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:55 +0000 (09:31 +0300)]
crypto: sun8i-ce - permit asynchronous skcipher as fallback

Even though the sun8i-ce driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: sun4i - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:54 +0000 (09:31 +0300)]
crypto: sun4i - permit asynchronous skcipher as fallback

Even though the sun4i driver implements asynchronous versions of ecb(aes)
and cbc(aes), the fallbacks it allocates are required to be synchronous.
Given that SIMD based software implementations are usually asynchronous
as well, even though they rarely complete asynchronously (this typically
only happens in cases where the request was made from softirq context,
while SIMD was already in use in the task context that it interrupted),
these implementations are disregarded, and either the generic C version
or another table based version implemented in assembler is selected
instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: omap-aes - permit asynchronous skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:53 +0000 (09:31 +0300)]
crypto: omap-aes - permit asynchronous skcipher as fallback

Even though the omap-aes driver implements asynchronous versions of
ecb(aes), cbc(aes) and ctr(aes), the fallbacks it allocates are required
to be synchronous. Given that SIMD based software implementations are
usually asynchronous as well, even though they rarely complete
asynchronously (this typically only happens in cases where the request was
made from softirq context, while SIMD was already in use in the task
context that it interrupted), these implementations are disregarded, and
either the generic C version or another table based version implemented in
assembler is selected instead.

Since falling back to synchronous AES is not only a performance issue, but
potentially a security issue as well (due to the fact that table based AES
is not time invariant), let's fix this, by allocating an ordinary skcipher
as the fallback, and invoke it with the completion routine that was given
to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: amlogic-gxl - permit async skcipher as fallback
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:52 +0000 (09:31 +0300)]
crypto: amlogic-gxl - permit async skcipher as fallback

Even though the amlogic-gxl driver implements asynchronous versions of
ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
synchronous. Given that SIMD based software implementations are usually
asynchronous as well, even though they rarely complete asynchronously
(this typically only happens in cases where the request was made from
softirq context, while SIMD was already in use in the task context that
it interrupted), these implementations are disregarded, and either the
generic C version or another table based version implemented in assembler
is selected instead.

Since falling back to synchronous AES is not only a performance issue,
but potentially a security issue as well (due to the fact that table
based AES is not time invariant), let's fix this, by allocating an
ordinary skcipher as the fallback, and invoke it with the completion
routine that was given to the outer request.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: amlogic-gxl - default to build as module
Ard Biesheuvel [Tue, 7 Jul 2020 06:31:51 +0000 (09:31 +0300)]
crypto: amlogic-gxl - default to build as module

The AmLogic GXL crypto accelerator driver is built into the kernel if
ARCH_MESON is set. However, given the single image policy of arm64, its
defconfig enables all platforms by default, and so ARCH_MESON is usually
enabled.

This means that the AmLogic driver causes the arm64 defconfig build to
pull in a huge chunk of the crypto stack as a builtin as well, which is
undesirable, so let's make the amlogic GXL driver default to 'm' instead.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agohwrng: ba431 - Include kernel.h
Herbert Xu [Tue, 7 Jul 2020 03:47:13 +0000 (13:47 +1000)]
hwrng: ba431 - Include kernel.h

There are multiple things in this file that requires kernel.h but
it's only included through other header files indirectly.  This
patch adds a direct inclusion as those indirect inclusions may go
away at any point.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/sec2 - fix some coding styles
Longfang Liu [Tue, 7 Jul 2020 01:15:41 +0000 (09:15 +0800)]
crypto: hisilicon/sec2 - fix some coding styles

Modify some log output interfaces and
update author information

Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/sec2 - update debugfs interface parameters
Longfang Liu [Tue, 7 Jul 2020 01:15:40 +0000 (09:15 +0800)]
crypto: hisilicon/sec2 - update debugfs interface parameters

Update debugfs interface parameters, and adjust the
processing logic inside the corresponding function

Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/sec2 - update SEC initialization and reset
Longfang Liu [Tue, 7 Jul 2020 01:15:39 +0000 (09:15 +0800)]
crypto: hisilicon/sec2 - update SEC initialization and reset

Updates the initialization and reset of SEC driver's
register operation.

Signed-off-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto:hisilicon/sec2 - update busy processing logic
Kai Ye [Tue, 7 Jul 2020 01:15:38 +0000 (09:15 +0800)]
crypto:hisilicon/sec2 - update busy processing logic

As before, if a SEC queue is at the 'fake busy' status,
the request with a 'fake busy' flag will be sent into hardware
and the sending function returns busy. After the request is
finished, SEC driver's call back will identify the 'fake busy' flag,
and notifies the user that hardware is not busy now by calling
user's call back function.

Now, a request sent into busy hardware will be cached in the
SEC queue's backlog, return '-EBUSY' to user.
After the request being finished, the cached requests will
be processed in the call back function. to notify the
corresponding user that SEC queue can process more requests.

Signed-off-by: Kai Ye <yekai13@huawei.com>
Reviewed-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/sec2 - clear SEC debug regs
Kai Ye [Tue, 7 Jul 2020 01:15:37 +0000 (09:15 +0800)]
crypto: hisilicon/sec2 - clear SEC debug regs

SEC debug registers aren't cleared even if its driver is removed,
so add a clearing operation in driver removing.

Signed-off-by: Kai Ye <yekai13@huawei.com>
Reviewed-by: Longfang Liu <liulongfang@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: caam - Remove broken arc4 support
Herbert Xu [Thu, 16 Jul 2020 11:45:03 +0000 (21:45 +1000)]
crypto: caam - Remove broken arc4 support

The arc4 algorithm requires storing state in the request context
in order to allow more than one encrypt/decrypt operation.  As this
driver does not seem to do that, it means that using it for more
than one operation is broken.

Fixes: eaed71a44ad9 ("crypto: caam - add ecb(*) support")
Link: https://lore.kernel.org/linux-crypto/CAMj1kXGvMe_A_iQ43Pmygg9xaAM-RLy=_M=v+eg--8xNmv9P+w@mail.gmail.com
Link: https://lore.kernel.org/linux-crypto/20200702101947.682-1-ardb@kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: arm/ghash - use variably sized key struct
Ard Biesheuvel [Mon, 29 Jun 2020 07:39:25 +0000 (09:39 +0200)]
crypto: arm/ghash - use variably sized key struct

Of the two versions of GHASH that the ARM driver implements, only one
performs aggregation, and so the other one has no use for the powers
of H to be precomputed, or space to be allocated for them in the key
struct. So make the context size dependent on which version is being
selected, and while at it, use a static key to carry this decision,
and get rid of the function pointer.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: arm64/gcm - use inline helper to suppress indirect calls
Ard Biesheuvel [Mon, 29 Jun 2020 07:39:24 +0000 (09:39 +0200)]
crypto: arm64/gcm - use inline helper to suppress indirect calls

Introduce an inline wrapper for ghash_do_update() that incorporates
the indirect call to the asm routine that is passed as an argument,
and keep the non-SIMD fallback code out of line. This ensures that
all references to the function pointer are inlined where the address
is taken, removing the need for any indirect calls to begin with.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: arm64/gcm - use variably sized key struct
Ard Biesheuvel [Mon, 29 Jun 2020 07:39:23 +0000 (09:39 +0200)]
crypto: arm64/gcm - use variably sized key struct

Now that the ghash and gcm drivers are split, we no longer need to allocate
a key struct for the former that carries powers of H that are only used by
the latter. Also, take this opportunity to clean up the code a little bit.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: arm64/gcm - disentangle ghash and gcm setkey() routines
Ard Biesheuvel [Mon, 29 Jun 2020 07:39:22 +0000 (09:39 +0200)]
crypto: arm64/gcm - disentangle ghash and gcm setkey() routines

The remaining ghash implementation does not support aggregation, and so
there is no point in including the precomputed powers of H in the key
struct. So move that into the GCM setkey routine, and get rid of the
shared sub-routine entirely.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: arm64/ghash - drop PMULL based shash
Ard Biesheuvel [Mon, 29 Jun 2020 07:39:21 +0000 (09:39 +0200)]
crypto: arm64/ghash - drop PMULL based shash

There are two ways to implement SIMD accelerated GCM on arm64:
- using the PMULL instructions for carryless 64x64->128 multiplication,
  in which case the architecture guarantees that the AES instructions are
  available as well, and so we can use the AEAD implementation that combines
  both,
- using the PMULL instructions for carryless 8x8->16 bit multiplication,
  which is implemented as a shash, and can be combined with any ctr(aes)
  implementation by the generic GCM AEAD template driver.

So let's drop the 64x64->128 shash driver, which is never needed for GCM,
and not suitable for use anywhere else.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: hisilicon/zip - permit users to specify NUMA node
Barry Song [Sun, 5 Jul 2020 09:18:59 +0000 (21:18 +1200)]
crypto: hisilicon/zip - permit users to specify NUMA node

If users don't specify NUMA node, the driver will use the ZIP module near
the CPU allocating acomp. Otherwise, it uses the ZIP module according to
the requirement of users.

Cc: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: api - permit users to specify numa node of acomp hardware
Barry Song [Sun, 5 Jul 2020 09:18:58 +0000 (21:18 +1200)]
crypto: api - permit users to specify numa node of acomp hardware

For a Linux server with NUMA, there are possibly multiple (de)compressors
which are either local or remote to some NUMA node. Some drivers will
automatically use the (de)compressor near the CPU calling acomp_alloc().
However, it is not necessarily correct because users who send acomp_req
could be from different NUMA node with the CPU which allocates acomp.

Just like kernel has kmalloc() and kmalloc_node(), here crypto can have
same support.

Cc: Seth Jennings <sjenning@redhat.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Vitaly Wool <vitaly.wool@konsulko.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: aesni - Fix build with LLVM_IAS=1
Sedat Dilek [Fri, 3 Jul 2020 14:32:06 +0000 (16:32 +0200)]
crypto: aesni - Fix build with LLVM_IAS=1

When building with LLVM_IAS=1 means using Clang's Integrated Assembly (IAS)
from LLVM/Clang >= v10.0.1-rc1+ instead of GNU/as from GNU/binutils
I see the following breakage in Debian/testing AMD64:

<instantiation>:15:74: error: too many positional arguments
 PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
                                                                         ^
 arch/x86/crypto/aesni-intel_asm.S:1598:2: note: while in macro instantiation
 GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp)
 ^
<instantiation>:47:2: error: unknown use of instruction mnemonic without a size suffix
 GHASH_4_ENCRYPT_4_PARALLEL_dec %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc
 ^
arch/x86/crypto/aesni-intel_asm.S:1599:2: note: while in macro instantiation
 GCM_ENC_DEC dec
 ^
<instantiation>:15:74: error: too many positional arguments
 PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
                                                                         ^
arch/x86/crypto/aesni-intel_asm.S:1686:2: note: while in macro instantiation
 GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp)
 ^
<instantiation>:47:2: error: unknown use of instruction mnemonic without a size suffix
 GHASH_4_ENCRYPT_4_PARALLEL_enc %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc
 ^
arch/x86/crypto/aesni-intel_asm.S:1687:2: note: while in macro instantiation
 GCM_ENC_DEC enc

Craig Topper suggested me in ClangBuiltLinux issue #1050:

> I think the "too many positional arguments" is because the parser isn't able
> to handle the trailing commas.
>
> The "unknown use of instruction mnemonic" is because the macro was named
> GHASH_4_ENCRYPT_4_PARALLEL_DEC but its being instantiated with
> GHASH_4_ENCRYPT_4_PARALLEL_dec I guess gas ignores case on the
> macro instantiation, but llvm doesn't.

First, I removed the trailing comma in the PRECOMPUTE line.

Second, I substituted:
1. GHASH_4_ENCRYPT_4_PARALLEL_DEC -> GHASH_4_ENCRYPT_4_PARALLEL_dec
2. GHASH_4_ENCRYPT_4_PARALLEL_ENC -> GHASH_4_ENCRYPT_4_PARALLEL_enc

With these changes I was able to build with LLVM_IAS=1 and boot on bare metal.

I confirmed that this works with Linux-kernel v5.7.5 final.

NOTE: This patch is on top of Linux v5.7 final.

Thanks to Craig and especially Nick for double-checking and his comments.

Suggested-by: Craig Topper <craig.topper@intel.com>
Suggested-by: Craig Topper <craig.topper@gmail.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: "ClangBuiltLinux" <clang-built-linux@googlegroups.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1050
Link: https://bugs.llvm.org/show_bug.cgi?id=24494
Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: ccp - Fix sparse warnings
Herbert Xu [Fri, 3 Jul 2020 04:46:52 +0000 (14:46 +1000)]
crypto: ccp - Fix sparse warnings

This patch fixes a number of endianness marking issues in the ccp
driver.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: John Allen <john.allen@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: af_alg - Fix regression on empty requests
Herbert Xu [Thu, 2 Jul 2020 03:32:21 +0000 (13:32 +1000)]
crypto: af_alg - Fix regression on empty requests

Some user-space programs rely on crypto requests that have no
control metadata.  This broke when a check was added to require
the presence of control metadata with the ctx->init flag.

This patch fixes the regression by setting ctx->init as long as
one sendmsg(2) has been made, with or without a control message.

Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agocrypto: virtio - constify features[] and id_table[]
Rikard Falkeborn [Wed, 1 Jul 2020 20:29:36 +0000 (22:29 +0200)]
crypto: virtio - constify features[] and id_table[]

features[] and id_table[] are not modified and can be made const to
allow the compiler to put them in read-only memory.

Before:
   text    data     bss     dec     hex filename
  11534    2056     160   13750    35b6 drivers/crypto/virtio/virtio_crypto_core.o

After:
   text    data     bss     dec     hex filename
  11630    1992     128   13750    35b6 drivers/crypto/virtio/virtio_crypto_core.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 years agohwrng: virtio - Constify id_table[]
Rikard Falkeborn [Wed, 1 Jul 2020 20:09:48 +0000 (22:09 +0200)]
hwrng: virtio - Constify id_table[]

id_table[] is not modified and an be made const to allow the compiler to
put it in read-only memory.

Before:
   text    data     bss     dec     hex filename
   1746     192       8    1946     79a drivers/char/hw_random/virtio-rng.o

After:
   text    data     bss     dec     hex filename
   1762     176       8    1946     79a drivers/char/hw_random/virtio-rng.o

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>