This fixes a typo in the CRYPTO_KPP dependency of CRYPTO_ECDH.

Fixes: 3c4b2390 ("crypto: ecdh - Add ECDH software support")
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When a cipher fails to register in aes_init(), the error path goes thought
aes_exit() then crypto_unregister_skciphers().
Since aes_exit calls also crypto_unregister_skcipher, this triggers a
refcount_t: underflow; use-after-free.
Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When chacha20_block() outputs the keystream block, it uses 'u32' stores
directly.  However, the callers (crypto/chacha20_generic.c and
drivers/char/random.c) declare the keystream buffer as a 'u8' array,
which is not guaranteed to have the needed alignment.

Fix it by having both callers declare the keystream as a 'u32' array.
For now this is preferable to switching over to the unaligned access
macros because chacha20_block() is only being used in cases where we can
easily control the alignment (stack buffers).
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that the generic ChaCha20 implementation no longer needs a
cra_alignmask, the x86 one doesn't either -- given that the x86
implementation doesn't need the alignment itself.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that crypto_chacha20_setkey() and crypto_chacha20_init() use the
unaligned access macros and crypto_xor() also accepts unaligned buffers,
there is no need to have a cra_alignmask set for chacha20-generic.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The generic ChaCha20 implementation has a cra_alignmask of 3, which
ensures that the key passed into crypto_chacha20_setkey() and the IV
passed into crypto_chacha20_init() are 4-byte aligned.  However, these
functions are also called from the ARM and ARM64 implementations of
ChaCha20, which intentionally do not have a cra_alignmask set.  This is
broken because 32-bit words are being loaded from potentially-unaligned
buffers without the unaligned access macros.

Fix it by using the unaligned access macros when loading the key and IV.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The four 32-bit constants for the initial state of ChaCha20 were loaded
from a char array which is not guaranteed to have the needed alignment.

Fix it by just assigning the constants directly instead.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Make the cryptd queue length configurable. We recently had customer where this
needed to be tuned to accommodate the aesni_intel module and prevent packet
drop.
Signed-off-by: NJon Maxwell <jmaxwell37@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Most crypto drivers involving kernel mode NEON take care to put the code
that actually touches the NEON register file in a separate compilation
unit, to prevent the compiler from reordering code that preserves or
restores the NEON context with code that may corrupt it. This is
necessary because we currently have no way to express the restrictions
imposed upon use of the NEON in kernel mode in a way that the compiler
understands.

However, in the case of aes-ce-cipher, it did not seem unreasonable to
deviate from this rule, given how it does not seem possible for the
compiler to reorder cross object function calls with asm blocks whose
in- and output constraints reflect that it reads from and writes to
memory.

Now that LTO is being proposed for the arm64 kernel, it is time to
revisit this. The link time optimization may replace the function
calls to kernel_neon_begin() and kernel_neon_end() with instantiations
of the IR that make up its implementation, allowing further reordering
with the asm block.

So let's clean this up, and move the asm() blocks into a separate .S
file.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-By: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

'dev' is leaking in the error handling path of 'hifn_probe()'.

Add a 'kfree(dev)' to match the code in 'hifn_remove()'
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: NPrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Preempt counter APIs have been split out, currently, hardirq.h just
includes irq_enter/exit APIs which are not used by crypto at all.

So, remove the unused hardirq.h.
Signed-off-by: NYang Shi <yang.s@alibaba-inc.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

register xfrmdev_ops callbacks, Send IPsec tunneled data
to HW for inline processing.
The driver use hardware crypto accelerator to encrypt and
generate ICV for the transmitted packet in Inline mode.
Signed-off-by: NAtul Gupta <atul.gupta@chelsio.com>
Signed-off-by: NHarsh Jain <harsh@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Added Tx routine for ULD
- define interface for ULD Tx.

Export routines used for Tx data
- Routines common for data transmit are used by cxgb4 and chcr
  drivers.
- EXPORT routines enable transmit from chcr driver.
Signed-off-by: NAtul Gupta <atul.gupta@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The Arm TrustZone CryptoCell is a hardware security engine. This patch
adds DT bindings for its Rich Execution Environment crypto engine.

A driver supporting this device is already present in the staging tree.
Signed-off-by: NGilad Ben-Yossef <gilad@benyossef.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The object info is being leaked on an error return path, fix this
by setting ret to -ENOMEM and exiting via the request_cleanup path
that will free info.

Detected by CoverityScan, CID#1408439 ("Resource Leak")

Fixes: c694b233 ("crypto: cavium - Add the Virtual Function driver for CPT")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):

    crypto/keywrap.c: In function ‘crypto_kw_decrypt’:
    crypto/keywrap.c:191: warning: integer constant is too large for ‘long’ type
    crypto/keywrap.c: In function ‘crypto_kw_encrypt’:
    crypto/keywrap.c:224: warning: integer constant is too large for ‘long’ type

Fixes: 9e49451d ("crypto: keywrap - simplify code")
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Results better code readability.
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Trivial fix to spelling mistake in pr_err error message text. Also
fix spelling mistake in proceeding comment.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NHaren Myneni <haren@us.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>".
Signed-off-by: NMartin Kepplinger <martink@posteo.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If crypto_get_default_rng returns an error, the
function ecc_gen_privkey should return an error.
Instead, it currently tries to use the default_rng
nevertheless, thus creating a kernel panic with a
NULL pointer dereference.
Returning the error directly, as was supposedly
intended when looking at the code, fixes this.
Signed-off-by: NPierre Ducroquet <pinaraf@pinaraf.info>
Reviewed-by: NPrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This code seems correct, but the goto was indented too far.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The dma_map_sg() function returns zero on error and positive values on
success.  We want to return -ENOMEM on failure here and zero on success.

Fixes: 2f47d580 ("crypto: chelsio - Move DMA un/mapping to chcr from lld cxgb4 driver")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Pointer reqctx is assigned the same value twice, once on initialization
and again a few statements later, remove the second redundant assignment.
Variable dst_size is assigned but it is never read, so the variable is
redundant and can be removed. Cleans up clang warnings:

drivers/crypto/chelsio/chcr_algo.c:156:29: warning: Value stored to
'reqctx' during its initialization is never read
drivers/crypto/chelsio/chcr_algo.c:2020:2: warning: Value stored to
'dst_size' is never read
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

bcm2835-rng is now capable of supporting the BCM63xx hardware, so remove
the driver which duplicates the same functionality.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We have now incorporated all necessary functionality for the BCM63xx
platforms to successfully migrate over bcm2835-rng, so add the final
bits: Kconfig selection and proper platform_device device type matching
to keep the same platform device name for registration to work.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Since the same block is used on BCM2835 and BCM6368, merge the bindings
and remove the brcm,bcm6368.txt binding document.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Broadcom MIPS HW is always strapped to match the system-wide endian such
that all I/O access to this RNG block is done with the native CPU
endian, account for that.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In preparation for allowing BCM63xx to use this driver, we abstract I/O
accessors such that we can easily change those later on.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

One of the last steps before bcm63xx-rng can be eliminated is to manage
a clock during hwrng::init and hwrng::cleanup, so fetch it in the probe
function, and manage it during these two steps when valid.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The interrupt masking done for Northstart Plus and Northstar (BCM5301X)
is moved from being a function pointer mapped to of_device_id::data into
a proper part of the hwrng::init callback. While at it, we also make the
of_data be a proper structure indicating the platform specifics, since
the day we need to add a second type of platform information, we would
have to do that anyway.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that we have moved the RNG disabling into a hwrng::cleanup callback,
we can use the device managed registration operation and remove our
remove callback since it won't do anything necessary.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We should be disabling the RNG in a hwrng::cleanup callback if we are
not longer the system selected RNG, not wait until the device driver is
removed.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We should be moving the enabling of the HWRNG into a hwrng::init
callback since we can be disabled and enabled every time a different
hwrng is selected in the system.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Instead of making hwrng::priv host the base register address, define a
driver private context, make it per platform device instance and pass it
down the different functions.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In preparation for consolidating bcm63xx-rng into bcm2835-rng, make sure
that we obtain the base register via platform_get_resource() since we
need to support the non-DT enabled MIPS-based BCM63xx DSL SoCs.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This module registers block cipher algorithms that make use of the
STMicroelectronics STM32 crypto "CRYP1" hardware.
The following algorithms are supported:
- aes: ecb, cbc, ctr
- des: ecb, cbc
- tdes: ecb, cbc
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Document device tree bindings for the STM32 CRYP.
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In case buffer length is a multiple of PAGE_SIZE,
the S/G table is incorrectly generated.
Fix this by handling buflen = k * PAGE_SIZE separately.
Signed-off-by: NRobert Baronescu <robert.baronescu@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When asked to encrypt or decrypt 0 bytes, both the generic and x86
implementations of Salsa20 crash in blkcipher_walk_done(), either when
doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
because walk->buffer and walk->page have not been initialized.

The bug is that Salsa20 is calling blkcipher_walk_done() even when
nothing is in 'walk.nbytes'.  But blkcipher_walk_done() is only meant to
be called when a nonzero number of bytes have been provided.

The broken code is part of an optimization that tries to make only one
call to salsa20_encrypt_bytes() to process inputs that are not evenly
divisible by 64 bytes.  To fix the bug, just remove this "optimization"
and use the blkcipher_walk API the same way all the other users do.

Reproducer:

    #include <linux/if_alg.h>
    #include <sys/socket.h>
    #include <unistd.h>

    int main()
    {
            int algfd, reqfd;
            struct sockaddr_alg addr = {
                    .salg_type = "skcipher",
                    .salg_name = "salsa20",
            };
            char key[16] = { 0 };

            algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
            bind(algfd, (void *)&addr, sizeof(addr));
            reqfd = accept(algfd, 0, 0);
            setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
            read(reqfd, key, sizeof(key));
    }
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Fixes: eb6f13eb ("[CRYPTO] salsa20_generic: Fix multi-page processing")
Cc: <stable@vger.kernel.org> # v2.6.25+
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Because the HMAC template didn't check that its underlying hash
algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
being used without having been keyed, resulting in sha3_update() being
called without sha3_init(), causing a stack buffer overflow.

This is a very old bug, but it seems to have only started causing real
problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
because the innermost hash's state is ->import()ed from a zeroed buffer,
and it just so happens that other hash algorithms are fine with that,
but SHA-3 is not.  However, there could be arch or hardware-dependent
hash algorithms also affected; I couldn't test everything.

Fix the bug by introducing a function crypto_shash_alg_has_setkey()
which tests whether a shash algorithm is keyed.  Then update the HMAC
template to require that its underlying hash algorithm is unkeyed.

Here is a reproducer:

    #include <linux/if_alg.h>
    #include <sys/socket.h>

    int main()
    {
        int algfd;
        struct sockaddr_alg addr = {
            .salg_type = "hash",
            .salg_name = "hmac(hmac(sha3-512-generic))",
        };
        char key[4096] = { 0 };

        algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
        bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
        setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
    }

Here was the KASAN report from syzbot:

    BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341  [inline]
    BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0  crypto/sha3_generic.c:161
    Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044

    CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:17 [inline]
      dump_stack+0x194/0x257 lib/dump_stack.c:53
      print_address_description+0x73/0x250 mm/kasan/report.c:252
      kasan_report_error mm/kasan/report.c:351 [inline]
      kasan_report+0x25b/0x340 mm/kasan/report.c:409
      check_memory_region_inline mm/kasan/kasan.c:260 [inline]
      check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
      memcpy+0x37/0x50 mm/kasan/kasan.c:303
      memcpy include/linux/string.h:341 [inline]
      sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
      crypto_shash_update+0xcb/0x220 crypto/shash.c:109
      shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
      crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
      hmac_finup+0x182/0x330 crypto/hmac.c:152
      crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
      shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
      crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
      hmac_setkey+0x36a/0x690 crypto/hmac.c:66
      crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
      shash_async_setkey+0x47/0x60 crypto/shash.c:207
      crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
      hash_setkey+0x40/0x90 crypto/algif_hash.c:446
      alg_setkey crypto/af_alg.c:221 [inline]
      alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
      SYSC_setsockopt net/socket.c:1851 [inline]
      SyS_setsockopt+0x189/0x360 net/socket.c:1830
      entry_SYSCALL_64_fastpath+0x1f/0x96
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>