On Mon, Sep 10, 2018 at 11:33:59PM -0400, Jerome Glisse wrote:
> Date: Mon, 10 Sep 2018 23:33:59 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Kenneth Lee , Zaibo Xu ,
> Herbert Xu , k...@vger.kernel.org, Jonathan
> Corbet , Greg Kroah-Hartman ,
> Joerg Roedel , linux-...@vger.kernel.org
On Fri, Sep 07, 2018 at 09:02:45AM -0700, Kees Cook wrote:
>
> I'll continue to investigate alternatives, but I wanted to point out
> that the struct change actually fills an existing padding byte (so no
> change in memory usage) and marking this as an unlikely() test means
> it wouldn't even be me
On Fri, Sep 07, 2018 at 08:56:23AM +0200, Ard Biesheuvel wrote:
>
> OK, so given that all SKCIPHER_REQUEST_ON_STACK occurrences are
> updated in this series anyway, perhaps we should add
> skcipher_[en|de]crypt_onstack() flavors that encapsulate the
> additional check? Only question is how to enfor
Hi Horia,
I love your patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on v4.19-rc3 next-20180910]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Fixes: 10c08052347f ("crypto: caam/qi2 - add DPAA2-CAAM driver")
Signed-off-by: kbuild test robot
---
caamalg_qi2.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/caam/caamalg_qi2.c
b/drivers/crypto/caam/caamalg_qi2.c
index e883386..af8d890 100644
---
On Tue, Sep 11, 2018 at 10:42:09AM +0800, Kenneth Lee wrote:
> On Mon, Sep 10, 2018 at 10:54:23AM -0400, Jerome Glisse wrote:
> > On Mon, Sep 10, 2018 at 11:28:09AM +0800, Kenneth Lee wrote:
> > > On Fri, Sep 07, 2018 at 12:53:06PM -0400, Jerome Glisse wrote:
> > > > On Fri, Sep 07, 2018 at 12:01:3
On Mon, Sep 10, 2018 at 10:54:23AM -0400, Jerome Glisse wrote:
> Date: Mon, 10 Sep 2018 10:54:23 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Kenneth Lee , Alex Williamson
> , Herbert Xu ,
> k...@vger.kernel.org, Jonathan Corbet , Greg Kroah-Hartman
> , Joerg Roedel ,
> linux-...@vger.
Sorry, this 07/17 is old cruft that was erroneously sitting around in
my v3 directory. Please look only at the real 07/17 instead:
https://patchwork.ozlabs.org/patch/968359/
My scripts have been adjusted so that this kind of clash doesn't happen again.
This implements the ChaCha20 permutation as a single C statement, by way
of the comma operator, which the compiler is able to simplify
terrifically.
Information: https://cr.yp.to/chacha.html
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe A
Zinc stands for "Zinc Is Neat Crypto" or "Zinc as IN Crypto" or maybe
just "Zx2c4's INsane Cryptolib." It's also short, easy to type, and
plays nicely with the recent trend of naming crypto libraries after
elements. The guiding principle is "don't overdo it". It's less of a
library and more of a di
These NEON and non-NEON implementations come from Andy Polyakov's
implementation, with several modifications for being friendly to kernel
space.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell King
C
This provides SSSE3, AVX-2, AVX-512F, and AVX-512VL implementations for
ChaCha20. The AVX-512F implementation is disabled on Skylake, due to
throttling, and the VL ymm implementation is used instead. These come
from Andy Polyakov's implementation, with some heavy modifications from
Samuel Neves and
This MIPS32r2 implementation comes from René van Dorst and me and
results in a nice speedup on the usual OpenWRT targets.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: René van Dorst
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Ja
The C implementation is based on Andy Polyakov's implementation, heavily
modified by Samuel Neves.
Information: https://cr.yp.to/mac.html
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: linux-crypto@vger.kernel.org
---
includ
These NEON and non-NEON implementations come from Andy Polyakov's
implementation, with several modifications for being friendly to kernel
space.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: Jean-Philippe Aumasson
Cc: Andy Polyakov
Cc: Russell King
C
The C implementation was originally based on Samuel Neves' public
domain reference implementation but has since been heavily modified
for the kernel. We're able to do compile-time optimizations by moving
some scaffolding around the final function into the header file.
Information: https://blake2.n
These two C implementations -- a 32x32 one and a 64x64 one, depending on
the platform -- come from Andrew Moon's public domain poly1305-donna
portable code, modified for usage in the kernel and for usage with
accelerated primitives.
Information: https://cr.yp.to/mac.html
Signed-off-by: Jason A. D
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and has been modified to be friendly for kernel space, as well as
removing some qhasm strangeness to be more idiomatic.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc: D. J. Bernst
This implementation is the fastest available x86_64 implementation, and
unlike Sandy2x, it doesn't requie use of the floating point registers at
all. Instead it makes use of BMI2 and ADX, available on recent
microarchitectures. The implementation was written by Armando
Faz-Hernández with contributi
These implementations from Samuel Neves support AVX and AVX-512VL.
Originally this used AVX-512F, but Skylake thermal throttling made
AVX-512VL more attractive and possible to do with negligable difference.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Samuel Neves
Cc:
This contains two formally verified C implementations of the Curve25519
scalar multiplication function, one for 32-bit systems, and one for
64-bit systems whose compiler supports efficient 128-bit integer types.
Not only are these implementations formally verified, but they are also
the fastest ava
This MIPS32r2 implementation comes from René van Dorst and me and
results in a nice speedup on the usual OpenWRT targets. The MIPS64
implementation comes from Andy Polyakov with some kernel-friendly
modifications from me and results in a nice speedup on commodity Octeon
hardware.
Signed-off-by: Ja
This provides AVX, AVX-2, and AVX-512F implementations for Poly1305.
The AVX-512F implementation is disabled on Skylake, due to throttling.
These come from Andy Polyakov's implementation, with some heavy
modifications from Samuel Neves and me.
Signed-off-by: Jason A. Donenfeld
Cc: Andy Lutomirski
On Mon, Sep 10, 2018 at 10:02:38PM +0200, Ard Biesheuvel wrote:
> >> [146535.257274] tpm tpm0: A TPM error (379) occurred attempting get random
> >> [146535.257304] usercopy: Kernel memory exposure attempt detected from
> >> SLUB object 'kmalloc-64' (offset 0, size 379)!
>
> The TPM return code '
On Mon, Sep 10, 2018 at 12:19 PM Horia Geantă wrote:
>
> Add support for Congestion State Change Notifications (CSCN), which
> allow DPIO users to be notified when a congestion group changes its
> state (due to hitting the entrance / exit threshold).
>
> Signed-off-by: Horia Geantă
Acked-by: Li
On Mon, Sep 10, 2018 at 12:19 PM Horia Geantă wrote:
>
> This reverts commit a211c8170b3c348353decb6e175c58a7814f218c.
> (+ updated to account for driver being moved out of staging)
So this is not a straightforward revert, as the original files have
been moved. Probably it will be better not to
n
On 10 September 2018 at 21:53, Theodore Y. Ts'o wrote:
> On Mon, Sep 10, 2018 at 08:08:51PM +0300, Meelis Roos wrote:
>> This is weekend's 4.19.0-rc2-00246-gd7b686ebf704 on a Thinkad T460s.
>> There seems to be a usercopy warning from rng_dev read (full dmesg
>> below).
>
> Looking at rng_dev_h
> > This is weekend's 4.19.0-rc2-00246-gd7b686ebf704 on a Thinkad T460s.
> > There seems to be a usercopy warning from rng_dev read (full dmesg
> > below).
>
> Looking at rng_dev_head(), which is in drivers/char/hw_random.c, it
> looks like this was probably caused by a problem in the specific
>
On Mon, Sep 10, 2018 at 08:08:51PM +0300, Meelis Roos wrote:
> This is weekend's 4.19.0-rc2-00246-gd7b686ebf704 on a Thinkad T460s.
> There seems to be a usercopy warning from rng_dev read (full dmesg
> below).
Looking at rng_dev_head(), which is in drivers/char/hw_random.c, it
looks like this w
Hi Boris,
On 09/04/2018 03:11 AM, Borislav Petkov wrote:
...
+
+static int psp_probe_timeout = 5;
+module_param(psp_probe_timeout, int, 0644);
+MODULE_PARM_DESC(psp_probe_timeout, " default timeout value, in seconds, during PSP
device probe");
Just a question: what prevents the user from su
Hi,
This patch set adds the CAAM crypto engine driver for DPAA2
(Data Path Acceleration Architecture v2) found on ARMv8-based SoCs
like LS1088A, LS2088A, LX2160A.
Previously sent RFC can be found here:
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg27290.html
Driver consists of:
-D
Add support for Congestion State Change Notifications (CSCN), which
allow DPIO users to be notified when a congestion group changes its
state (due to hitting the entrance / exit threshold).
Signed-off-by: Horia Geantă
---
include/soc/fsl/dpaa2-global.h | 15 +++
1 file changed, 15 in
caam/qi2 driver will support ahash algorithms,
thus move ahash descriptors generation in a shared location.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Kconfig | 3 ++
drivers/crypto/caam/Makefile| 1 +
drivers/crypto/caam/caamhash.c | 79 +-
Add support for dpaa2_fd_list format, i.e. dpaa2_fl_entry structure
and accessors.
Frame list entries (FLEs) are similar, but not identical to FDs:
+ "F" (final) bit
- FMT[b'01] is reserved
- DD, SC, DROPP bits (covered by "FD compatibility" field in FLE case)
- FLC[5:0] not used for stashing
Sig
Add support to translate error codes returned by QI v2, i.e.
Queue Interface present on DataPath Acceleration Architecture
v2 (DPAA2).
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/error.c | 75 +++--
drivers/crypto/caam/error.h | 6 +++-
drivers/cr
This reverts commit a211c8170b3c348353decb6e175c58a7814f218c.
(+ updated to account for driver being moved out of staging)
dpseci object will make use of these functions, thus it's time to add
them back.
Signed-off-by: Horia Geantă
---
drivers/soc/fsl/dpio/dpio-service.c | 58 ++
Enable CAAM (Cryptographic Accelerator and Assurance Module) driver
for QorIQ Data Path Acceleration Architecture (DPAA) v2.
It handles DPSECI (Data Path SEC Interface) DPAA2 objects that sit
on the Management Complex (MC) fsl-mc bus.
Signed-off-by: Horia Geantă
---
arch/arm64/configs/defconfig
Add support for unkeyed and keyed (hmac) md5, sha algorithms.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Kconfig |4 +-
drivers/crypto/caam/caamalg_qi2.c | 1712 +
drivers/crypto/caam/caamalg_qi2.h | 16 +
3 files changed, 1731 insertions(
Add CAAM driver that works using the DPSECI backend, i.e. manages
DPSECI DPAA2 objects sitting on the Management Complex (MC) fsl-mc bus.
Data transfers (crypto requests) are sent/received to/from CAAM crypto
engine via Queue Interface (v2), this being similar to existing caam/qi.
OTOH, configurat
Add the low-level API that allows to manage DPSECI DPAA2 objects
that sit on the Management Complex (MC) fsl-mc bus.
The API is compatible with MC firmware 10.2.0+.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/dpseci.c | 426 +++
drivers/crypto/caa
Signed-off-by: Horia Geantă
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +
include/linux/fsl/mc.h | 6 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c6571f..4552b06fe601 100644
--- a/drivers/bus/fsl-mc
Add support to submit the following skcipher algorithms
via the DPSECI backend:
cbc({aes,des,des3_ede})
ctr(aes), rfc3686(ctr(aes))
xts(aes)
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Kconfig | 1 +
drivers/crypto/caam/caamalg_qi2.c | 562 ++
Hi Ondrej,
On Mon, Sep 10, 2018 at 01:28:41PM +0200, Ondrej Mosnacek wrote:
>
> -static int init_crypt(struct skcipher_request *req, crypto_completion_t done)
> +static int xor_tweak_pre(struct skcipher_request *req)
> {
> - struct priv *ctx = crypto_skcipher_ctx(crypto_skcipher_reqtfm(req)
On Tue, Sep 04, 2018 at 11:18:55AM +0800, Herbert Xu wrote:
> On Tue, Aug 28, 2018 at 08:43:35PM +0200, Ard Biesheuvel wrote:
> > On 28 August 2018 at 19:01, Will Deacon wrote:
> > > On Mon, Aug 27, 2018 at 01:02:43PM +0200, Ard Biesheuvel wrote:
> > >> Add a CRC32 feature bit and wire it up to th
On Mon, Sep 10, 2018 at 11:28:09AM +0800, Kenneth Lee wrote:
> On Fri, Sep 07, 2018 at 12:53:06PM -0400, Jerome Glisse wrote:
> > On Fri, Sep 07, 2018 at 12:01:38PM +0800, Kenneth Lee wrote:
> > > On Thu, Sep 06, 2018 at 09:31:33AM -0400, Jerome Glisse wrote:
> > > > On Thu, Sep 06, 2018 at 05:45:3
For some reason, the asmlinkage prototypes of the NEON routines take
u8[] arguments for the round key arrays, while the actual round keys
are arrays of u32, and so passing them into those routines requires
u8* casts at each occurrence. Fix that.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypt
The reasoning of commit f10dc56c64bb ("crypto: arm64 - revert NEON yield
for fast AEAD implementations") applies equally to skciphers: the walk
API already guarantees that the input size of each call into the NEON
code is bounded to the size of a page, and so there is no need for an
additional TIF_
The Crypto Extension instantiation of the aes-modes.S collection of
skciphers uses only 15 NEON registers for the round key array, whereas
the pure NEON flavor uses 16 NEON registers for the AES S-box.
This means we have a spare register available that we can use to hold
the XTS mask vector, remov
Some cleanups and optimizations for the arm64 AES skcipher routines.
Patch #1 fixes the peculiar use of u8 arrays to refer to AES round keys,
which are natively arrays of u32.
Patch #2 partially reverts the use of NEON yield calls, which is not
needed for skciphers.
Patch #3 adds support for ct
Currently, we rely on the generic CTS chaining mode wrapper to
instantiate the cts(cbc(aes)) skcipher. Due to the high performance
of the ARMv8 Crypto Extensions AES instructions (~1 cycles per byte),
any overhead in the chaining mode layers is amplified, and so it pays
off considerably to fold the
This patch rewrites the tweak computation to a slightly simpler method
that performs less bswaps. Based on performance measurements the new
code seems to provide slightly better performance than the old one.
PERFORMANCE MEASUREMENTS (x86_64)
Performed using: https://gitlab.com/omos/linux-crypto-be
This patch simplifies the LRW template to recompute the LRW tweaks from
scratch in the second pass and thus also removes the need to allocate a
dynamic buffer using kmalloc().
As discussed at [1], the use of kmalloc causes deadlocks with dm-crypt.
PERFORMANCE MEASUREMENTS (x86_64)
Performed using
This patchset is a follow-up to a similar patch for XTS:
https://patchwork.kernel.org/patch/10588775/
The first patch applies a small optimization to the tweak computation
and the second simplifes away the use of auxiliary buffer to cache
computed tweaks.
Changes in v2:
- small cleanup suggeste
Since commit acb9b159c784 ("crypto: gf128mul - define gf128mul_x_* in
gf128mul.h"), the gf128mul_x_*() functions are very fast and therefore
caching the computed XTS tweaks has only negligible advantage over
computing them twice.
In fact, since the current caching implementation limits the size of
use dma_pool_zalloc() instead of dma_pool_alloc with __GFP_ZERO flag.
crypto dma pool renamed to "nitrox-context".
Signed-off-by: Srikanth Jampala
---
drivers/crypto/cavium/nitrox/nitrox_lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/cavium/nitrox/ni
On Mon, Sep 10, 2018 at 9:42 AM Ondrej Mosnacek wrote:
> commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream.
>
> Conflicts:
> drivers/crypto/vmx/
> aes_cbc.c - adapted enable/disable calls to v4.4 state
> aes_xts.c - did not exist yet in v4.4
>
> This patch fixes sleep-in-atomic bu
commit 0522236d4f9c5ab2e79889cb020d1acbe5da416e upstream.
Conflicts:
drivers/crypto/vmx/
aes_cbc.c - adapted enable/disable calls to v4.4 state
aes_xts.c - did not exist yet in v4.4
This patch fixes sleep-in-atomic bugs in AES-CBC and AES-XTS VMX
implementations. The problem is that the
On 10 September 2018 at 08:21, Stefan Agner wrote:
> Hi Ard,
>
> On 21.05.2017 03:23, Ard Biesheuvel wrote:
>> Make the module autoloadable by tying it to the CPU feature bit that
>> describes whether the optional instructions it relies on are implemented
>> by the current CPU.
>>
>
> This leads t
58 matches
Mail list logo
