On Tue, Nov 20, 2018 at 05:24:41PM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu
> wrote:
> > Yes. In fact it's used for FIPS certification testing.
> > Sure, nobody sane should be doing it. But when it comes to
> > government certification... :)
>
> The kernel
nitrox_skcipher_crypt() will do the necessary formatting/ordering of
input and output sglists based on the algorithm requirements.
It will also accommodate the mandatory output buffers required for
NITROX hardware like Output request headers (ORH) and Completion headers.
Signed-off-by: Nagadheeraj
On Mon, Nov 19, 2018 at 08:29:39PM -0700, Jason Gunthorpe wrote:
> Date: Mon, 19 Nov 2018 20:29:39 -0700
> From: Jason Gunthorpe
> To: Kenneth Lee
> CC: Leon Romanovsky , Kenneth Lee ,
> Tim Sell , linux-...@vger.kernel.org, Alexander
> Shishkin , Zaibo Xu
> , zhangfei@foxmail.com, linux..
On Tue, Nov 20, 2018 at 05:18:24PM +0100, Jason A. Donenfeld wrote:
>
> N'ack. As I mentioned in the last email, this really isn't okay, and
> mostly defeats the purpose of Zinc in the first place, adding
> complexity in a discombobulated half-baked way. Your proposal seems to
> be the worst of all
On Tue, Nov 20, 2018 at 07:17:44AM +0200, Leon Romanovsky wrote:
> Date: Tue, 20 Nov 2018 07:17:44 +0200
> From: Leon Romanovsky
> To: Kenneth Lee
> CC: Jason Gunthorpe , Kenneth Lee , Tim
> Sell , linux-...@vger.kernel.org, Alexander
> Shishkin , Zaibo Xu
> , zhangfei@foxmail.com, linux..
On Tue, Nov 20, 2018 at 05:24:41PM +0100, Jason A. Donenfeld wrote:
> On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu
> wrote:
> > Yes. In fact it's used for FIPS certification testing.
> > Sure, nobody sane should be doing it. But when it comes to
> > government certification... :)
>
> The kernel
Hi Martin,
On Tue, Nov 20, 2018 at 5:29 PM Martin Willi wrote:
> Thanks for the offer, no need at this time. But I certainly would
> welcome if you could do some (Wireguard) benching with that code to see
> if it works for you.
I certainly will test it in a few different network circumstances,
e
This version uses the same principle as the AVX2 version by scheduling the
operations for two block pairs in parallel. It benefits from the AVX-512VL
rotate instructions and the more efficient partial block handling using
"vmovdqu8", resulting in a speedup of the raw block function of ~20%.
Signed
In the quest for pushing the limits of chacha20 encryption for both IPsec
and Wireguard, this small series adds AVX-512VL block functions. The VL
variant works on 256-bit ymm registers, but compared to AVX2 can benefit
from the new instructions.
Compared to the AVX2 version, these block functions
This version uses the same principle as the AVX2 version. It benefits
from the AVX-512VL rotate instructions and the more efficient partial
block handling using "vmovdqu8", resulting in a speedup of ~20%.
Unlike the AVX2 version, it is faster than the single block SSSE3 version
to process a single
This variant is similar to the AVX2 version, but benefits from the AVX-512
rotate instructions and the additional registers, so it can operate without
any data on the stack. It uses ymm registers only to avoid the massive core
throttling on Skylake-X platforms. Nontheless does it bring a ~30% speed
Hi Jason,
> [...] I have a massive Xeon Gold 5120 machine that I can give you
> access to if you'd like to do some testing and benching.
Thanks for the offer, no need at this time. But I certainly would
welcome if you could do some (Wireguard) benching with that code to see
if it works for you.
On Tue, Nov 20, 2018 at 3:19 PM Herbert Xu wrote:
> Yes. In fact it's used for FIPS certification testing.
> Sure, nobody sane should be doing it. But when it comes to
> government certification... :)
The kernel does not aim toward any FIPS certification, and we're not
going to start bloating o
Hi Herbert,
On Tue, Nov 20, 2018 at 7:02 AM Herbert Xu wrote:
> Here is an updated version demonstrating how we could access the
> accelerated versions of chacha20. It also includes a final patch
> to deposit the new zinc version of x86-64 chacha20 into
> arch/x86/crypto where it can be used by
Hi Ard:
On Tue, Nov 20, 2018 at 11:32:05AM +0100, Ard Biesheuvel wrote:
>
> > 1. The crypto API algorithms remain individually accessible, this
> > is crucial as these algorithm names are exported to user-space so
> > changing the names to foo-zinc is not going to work.
>
> Are you saying user sp
On Tue, Nov 20, 2018 at 12:32:17PM +, Corentin Labbe wrote:
> Even if CRYPTO_STATS is set to n, some part of CRYPTO_STATS are
> compiled.
> This patch made all part of crypto_user_stat uncompiled in that case.
>
> Signed-off-by: Corentin Labbe
> ---
> crypto/Makefile |
All the 32-bit fields need to be 64-bit. In some cases, UINT32_MAX crypto
operations can be done in seconds.
Reported-by: Eric Biggers
Signed-off-by: Corentin Labbe
---
crypto/algapi.c | 10 +--
crypto/crypto_user_stat.c | 114 +++-
include/cr
CRYPTO_STATS is using CRYPTO_USER stuff, so it should depends on it.
Signed-off-by: Corentin Labbe
---
crypto/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 62dbd1a99fa3..a2f1b4a86b92 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1829,6 +1
Even if CRYPTO_STATS is set to n, some part of CRYPTO_STATS are
compiled.
This patch made all part of crypto_user_stat uncompiled in that case.
Signed-off-by: Corentin Labbe
---
crypto/Makefile | 3 ++-
crypto/algapi.c | 2 ++
include/crypto/internal/c
It is cleaner to have each stat in their own structures.
Signed-off-by: Corentin Labbe
---
crypto/crypto_user_stat.c | 20 +++
include/uapi/linux/cryptouser.h | 100
2 files changed, 72 insertions(+), 48 deletions(-)
diff --git a/crypto/crypto_user_st
The use of the v64 intermediate variable is useless, and removing it
bring to much readable code.
Signed-off-by: Corentin Labbe
---
crypto/crypto_user_stat.c | 132 --
1 file changed, 41 insertions(+), 91 deletions(-)
diff --git a/crypto/crypto_user_stat.c b/
Since now all crypto stats are on their own structures, it is now
useless to have the algorithm name in the err_cnt member.
Signed-off-by: Corentin Labbe
---
crypto/algapi.c | 38 -
crypto/crypto_user_stat.c | 18
include/lin
All crypto_stats functions use the struct xxx_request for feeding stats,
but in some case this structure could already be freed.
For fixing this, the needed parameters (len and alg) will be stored
before the request being executed.
Fixes: cac5818c25d0 ("crypto: user - Implement a generic crypto st
Some error count use the wrong name for getting this data.
But this had not caused any reporting problem, since all error count are shared
in the same
union.
Signed-off-by: Corentin Labbe
---
crypto/crypto_user_stat.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cry
Like for userspace, this patch splits stats into multiple structures,
one for each algorithm class.
Signed-off-by: Corentin Labbe
---
crypto/algapi.c | 108 +++
crypto/crypto_user_stat.c | 82 -
include/linux/crypto.h| 180 +++
This patch converts the getstat example tool to the recent changes done in
crypto_user_stat
- changed all stats to u64
- separated struct stats for each crypto alg
Signed-off-by: Corentin Labbe
---
tools/crypto/getstat.c | 54 +-
1 file changed, 27 insert
Hello
This patchset fixes all reported problem by Eric biggers.
Regards
Changes since v3:
- moved all crypto_stats functions from header to algapi.c for using
crypto_alg_get/put
Changes since v2:
- Better locking of crypto_alg via crypto_alg_get/crypto_alg_put
- remove all intermediate variab
On 20/11/2018 09:16, Jonathan Cameron wrote:
> +CC Jean-Phillipe and iommu list.
Thanks for the Cc, sorry I don't have enough bandwidth to follow this
thread at the moment.
> In WarpDrive/uacce, we make this simple. If you support IOMMU and it
> support
> SVM/SVA. Everything will be
On Tue, Nov 20, 2018 at 10:30:56AM +, Kalyani Akula wrote:
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
On Tue, 20 Nov 2018 at 07:02, Herbert Xu wrote:
>
> On Mon, Nov 19, 2018 at 01:24:51PM +0800, Herbert Xu wrote:
> >
> > In response to Martin's patch-set which I merged last week, I think
> > here is quick way out for the zinc interface.
> >
> > Going through the past zinc discussions it would app
+CC Jean-Phillipe and iommu list.
On Mon, 19 Nov 2018 20:29:39 -0700
Jason Gunthorpe wrote:
> On Tue, Nov 20, 2018 at 11:07:02AM +0800, Kenneth Lee wrote:
> > On Mon, Nov 19, 2018 at 11:49:54AM -0700, Jason Gunthorpe wrote:
> > > Date: Mon, 19 Nov 2018 11:49:54 -0700
> > > From: Jason Gunthor
31 matches
Mail list logo
