(+ Eric)
TL;DR can we find a way to use synchronous SIMD skciphers/aeads
without cryptd or scalar fallbacks
On Thu, 10 Dec 2020 at 13:19, Ard Biesheuvel wrote:
>
> On Thu, 10 Dec 2020 at 13:16, Herbert Xu wrote:
> >
> > On Thu, Dec 10, 2020 at 01:03:56PM +0100, Ard Biesheuvel wrote:
> > >
> > >
On Mon, Dec 14, 2020 at 11:59:52AM +0800, Tony W Wang-oc wrote:
Didn't I mention something about a comment?
> static const struct x86_cpu_id crc32c_cpu_id[] = {
> + X86_MATCH_VENDOR_FAM_FEATURE(ZHAOXIN, 0x6, X86_FEATURE_XMM4_2, 1),
> + X86_MATCH_VENDOR_FAM_MODEL_FEATURE(ZHAOXIN, 0x7, 0x1
On Tue, Dec 15, 2020 at 09:55:37AM +0100, Ard Biesheuvel wrote:
>
> So the question is then how granular these kernel mode SIMD regions
> need to be to avoid excessive latencies in softirq handling.
Can you get some real world numbers on what the latency is like?
Then we could take it to the sche
On Mon, Dec 14, 2020 at 2:44 PM Stephen Rothwell wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> MAINTAINERS
>
> between commit:
>
> 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4")
>
> from the crypto tree and commit:
>
> ed794057b052 ("drm/km
On 15/12/2020 16:58, Peter Zijlstra wrote:
> On Mon, Dec 14, 2020 at 11:59:52AM +0800, Tony W Wang-oc wrote:
>
> Didn't I mention something about a comment?
>
Really sorry for this.
>> static const struct x86_cpu_id crc32c_cpu_id[] = {
>> +X86_MATCH_VENDOR_FAM_FEATURE(ZHAOXIN, 0x6, X86_FE
The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
On platforms with Zhaoxin CPUs supporting this X86 feature, when
crc32c-intel and crc32c-generic are both registered, system will
use crc32c-intel because its .cra_priority is greater than
crc32c-generic.
When doing lmbench3 Create
On Tue, Dec 15, 2020 at 10:15:29AM +0800, Tony W Wang-oc wrote:
>
> On 15/12/2020 04:41, Eric Biggers wrote:
> > On Mon, Dec 14, 2020 at 10:28:19AM +0800, Tony W Wang-oc wrote:
> >> On 12/12/2020 01:43, Eric Biggers wrote:
> >>> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> >>>
> On Dec 3, 2020, at 12:51 PM, Nick Terrell wrote:
>
> From: Nick Terrell
>
> Please pull from
>
> g...@github.com:terrelln/linux.git tags/v7-zstd-1.4.6
>
> to get these changes. Alternatively the patchset is included.
Is it possible to get this patchset merged in the 5.11 merge window?
From: Eric Biggers
Rename some BLAKE2b-related constants to be consistent with the names
used in the BLAKE2s implementation (see include/crypto/blake2s.h):
BLAKE2B_*_DIGEST_SIZE => BLAKE2B_*_HASH_SIZE
BLAKE2B_BLOCKBYTES => BLAKE2B_BLOCK_SIZE
BLAKE2B_KEYBYTES =>
From: Eric Biggers
The shash_alg structs for the four variants of BLAKE2b are identical
except for the algorithm name, driver name, and digest size. So, avoid
code duplication by using a macro to define these structs.
Signed-off-by: Eric Biggers
---
crypto/blake2b_generic.c | 82 -
From: Eric Biggers
Add a NEON-optimized implementation of BLAKE2b.
On Cortex-A7 (which these days is the most common ARM processor that
doesn't have the ARMv8 Crypto Extensions), this is over twice as fast as
SHA-256, and slightly faster than SHA-1. It is also almost three times
as fast as the
From: Eric Biggers
In preparation for adding architecture-specific implementations of
BLAKE2b, create a header that contains common
constants, structs, and helper functions for BLAKE2b.
Furthermore, export the BLAKE2b generic setkey(), init(), update(), and
final() functions, and add functions
This patchset adds a NEON implementation of BLAKE2b for 32-bit ARM.
Patches 1-4 prepare for it by making some updates to the generic
implementation, while patch 5 adds the actual NEON implementation.
On Cortex-A7 (which these days is the most common ARM processor that
doesn't have the ARMv8 Crypto
From: Eric Biggers
The file comment for blake2b_generic.c makes it sound like it's the
reference implementation of BLAKE2b with only minor changes. But it's
actually been changed a lot. Update the comment to make this clearer.
Signed-off-by: Eric Biggers
---
crypto/blake2b_generic.c | 23 +++
Just saw Lucas Stach's post "CAAM RNG trouble" from yesterday which
seems to be describing this same issue - added to CC.
On Tue, 2020-12-15 at 17:31 -0600, Robert Hancock wrote:
> Hello,
>
> We have an iMX6D-based board which was previously using 5.4.x
> kernels.
> I have recently started testin
Hello,
We have an iMX6D-based board which was previously using 5.4.x kernels.
I have recently started testing v5.10.1 on this board and am running
into an issue with the CAAM RNG. The dmesg is getting output like this
and all reads from /dev/hwrng are failing with EINVAL:
[ 17.368368] caam_jr 2
On Tue, Dec 15, 2020 at 08:58:52PM +, Nick Terrell via Linux-f2fs-devel
wrote:
>
>
> > On Dec 3, 2020, at 12:51 PM, Nick Terrell wrote:
> >
> > From: Nick Terrell
> >
> > Please pull from
> >
> > g...@github.com:terrelln/linux.git tags/v7-zstd-1.4.6
> >
> > to get these changes. Alter
> On Dec 15, 2020, at 4:00 PM, Eric Biggers wrote:
>
> On Tue, Dec 15, 2020 at 08:58:52PM +, Nick Terrell via Linux-f2fs-devel
> wrote:
>>
>>
>>> On Dec 3, 2020, at 12:51 PM, Nick Terrell wrote:
>>>
>>> From: Nick Terrell
>>>
>>> Please pull from
>>>
>>> g...@github.com:terrelln/lin
On Wed, Dec 16, 2020 at 12:48:51AM +, Nick Terrell wrote:
>
> Thanks for the advice! The first zstd patches went through Herbert’s tree,
> which is
> why I’ve sent them this way.
Sorry, but I'm not touch these patches as Christoph's objections
don't seem to have been addressed.
Cheers,
--
E
On Tue, Dec 15, 2020 at 10:58:52AM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 14, 2020 at 2:44 PM Stephen Rothwell
> wrote:
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > MAINTAINERS
> >
> > between commit:
> >
> > 885743324513 ("crypto: keembay - Add support for
> On Dec 15, 2020, at 4:58 PM, Herbert Xu wrote:
>
> On Wed, Dec 16, 2020 at 12:48:51AM +, Nick Terrell wrote:
>>
>> Thanks for the advice! The first zstd patches went through Herbert’s tree,
>> which is
>> why I’ve sent them this way.
>
> Sorry, but I'm not touch these patches as Christ
Meng,
It looks like not just definitions but some static data is moved to
includes. Why?
Thanks,
Yes, as both 'crypto' and HPRE use elliptic curves parameters, once
we keep them in 'include/crypto/ecc_curve_defs.h', crypto drivers
can use curves parameters without redefining them.
Thanks,
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
+/* size in bytes of the n prime */
+#define HPRE_ECC_NIST_P128_N_SIZE 16
Do we truly need P-128? Besides, I do not see that curve being defined in
contemporary cipher specs.
+#define HPRE_ECC_NIST_P192_N_SIZE 24
+#defin
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
+/* curve25519 */
+static u64 curve25519_g_x[] = { 0x0009, 0x,
+ 0x, 0x };
+static u64 curve25519_p[] = { 0xffed, 0x
24 matches
Mail list logo
