On Thu, Dec 17, 2020 at 12:58:34PM -0800, Dave Hansen wrote:
> On 12/16/20 9:41 AM, Chang S. Bae wrote:
> > +config CRYPTO_AES_KL
> > + tristate "AES cipher algorithms (AES-KL)"
> > + depends on X86_KEYLOCKER
> > + select CRYPTO_AES_NI_INTEL
> > + help
> > + Use AES Key Locker instructi
On Wed, Dec 16, 2020 at 09:41:44AM -0800, Chang S. Bae wrote:
> + /* ENCODEKEY128 %EAX */
> + asm volatile (".byte 0xf3, 0xf, 0x38, 0xfa, 0xc0");
This is lacking a binutils version number. Boris, didn't you do a
checkpatch.pl thing for that?
On Wed, Dec 16, 2020 at 09:41:45AM -0800, Chang S. Bae wrote:
> diff --git a/arch/x86/include/asm/inst.h b/arch/x86/include/asm/inst.h
> index bd7f02480ca1..b719a11a2905 100644
> --- a/arch/x86/include/asm/inst.h
> +++ b/arch/x86/include/asm/inst.h
> @@ -122,9 +122,62 @@
> #endif
> .endm
>
> On Dec 18, 2020, at 19:11, Peter Zijlstra wrote:
>
> *groan*, so what actual version of binutils is needed and why is this
> driver important enough to build on ancient crud to warrant all this
> gunk?
The new Key Locker instructions look to be added a few month ago [1].
But the latest binuti
> On Dec 18, 2020, at 18:59, Peter Zijlstra wrote:
>
> On Wed, Dec 16, 2020 at 09:41:44AM -0800, Chang S. Bae wrote:
>> +/* ENCODEKEY128 %EAX */
>> +asm volatile (".byte 0xf3, 0xf, 0x38, 0xfa, 0xc0");
>
> This is lacking a binutils version number.
I will add the version number when an
On 14/12/2020 18:45, Scott Branden wrote:
>
>
> On 2020-12-14 8:04 a.m., matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> When trying to disable the block we bitwise or the control
>> register with value zero. This will leave the block always turned on.
>> Fix this by setting th
From: Matthias Brugger
When trying to disable the block we bitwise or the control
register with value zero. This is confusing as using bitwise or with
value zero doesn't have any effect at all. Drop this as we already set
the enable bit to zero by appling inverted RNG_RBGEN_MASK.
Signed-off-by:
From: Matthias Brugger
We are calling the same code for enable and disable the block in various
parts of the driver. Put that code into a new function to reduce code
duplication.
Signed-off-by: Matthias Brugger
Acked-by: Florian Fainelli
---
Changes in v2:
- rename function to iproc_rng200_e
On Fri, Dec 18, 2020 at 10:34:28AM +, Bae, Chang Seok wrote:
> I’m open to drop the macros if there is any better way to define them
> without binutils support.
Yap, make the driver build depend on the binutils version which supports
them.
--
Regards/Gruss,
Boris.
SUSE Software Solution
Hi, Ted and Jason.
Any updates on that?
I don't believe Torsten's concerns are simply about *applying* patches
but more about these long periods of radio silence. That kills
collaboration and disengage people. More than simply reviewing patches
I would expect a maintainer to give directions and d
On Fri, Dec 18, 2020 at 10:34:28AM +, Bae, Chang Seok wrote:
>
> > On Dec 18, 2020, at 19:11, Peter Zijlstra wrote:
> >
> > *groan*, so what actual version of binutils is needed and why is this
> > driver important enough to build on ancient crud to warrant all this
> > gunk?
>
> The new Ke
On Thu, Dec 17, 2020 at 11:25 PM Eric Biggers wrote:
>
> From: Eric Biggers
>
> When available, select the new implementation of BLAKE2s for 32-bit ARM.
> This is faster than the generic C implementation.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Jason A. Donenfeld
When this series is read
On Thu, Dec 17, 2020 at 11:25 PM Eric Biggers wrote:
>
> From: Eric Biggers
>
> Move the boilerplate code for setkey(), init(), update(), and final()
> from blake2s_generic.ko into a new module blake2s_helpers.ko, and export
> it so that it can be used by other shash implementations of BLAKE2s.
>
On Thu, 17 Dec 2020 at 23:24, Eric Biggers wrote:
>
> This patchset adds 32-bit ARM assembly language implementations of
> BLAKE2b and BLAKE2s.
>
> The BLAKE2b implementation is NEON-accelerated, while the BLAKE2s
> implementation uses scalar instructions since NEON doesn't work very
> well for it
[ TL;DR for the non-ARM folks on CC: disabling softirq processing when using
SIMD in kernel mode could reduce complexity and improve performance, but we
need to decide whether we can do this, and how much softirq processing
latency we can tolerate. If we can find a satisfactory solution for t
In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
skcipher encrypt and decrypt routines from outside of task or softirq
context.
Signed-off-by: Ard Biesheuvel
---
crypto/skcipher.c | 10 ++
1 file
In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
AEAD encrypt and decrypt routines from outside of task or softirq context.
Signed-off-by: Ard Biesheuvel
---
crypto/aead.c | 10 ++
1 file changed
Now that kernel mode SIMD is guaranteed to be available when executing
in task or softirq context, we no longer need scalar fallbacks to use
when the NEON is unavailable. So get rid of them.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/ghash-ce-glue.c | 209 +---
1 file ch
GCM mode is typically used for IPsec, but is now also used for software
kTLS, which means that we may end up operating on much larger inputs.
So let's wire up conditional NEON yield support for this driver, to ensure
that it does not cause scheduling blackouts when used with large inputs.
Given t
Kernel mode NEON can be used in task or softirq context, but only in
a non-nesting manner, i.e., softirq context is only permitted if the
interrupt was not taken at a point where the kernel was using the NEON
in task context.
This means all users of kernel mode NEON have to be aware of this
limita
On 12/18/20 2:57 AM, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When trying to disable the block we bitwise or the control
> register with value zero. This is confusing as using bitwise or with
> value zero doesn't have any effect at all. Drop this as we already set
> the enable
On 2020-12-18 2:57 a.m., matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When trying to disable the block we bitwise or the control
> register with value zero. This is confusing as using bitwise or with
> value zero doesn't have any effect at all. Drop this as we already set
> the e
On 2020-12-18 2:57 a.m., matthias@kernel.org wrote:
> From: Matthias Brugger
>
> We are calling the same code for enable and disable the block in various
> parts of the driver. Put that code into a new function to reduce code
> duplication.
>
> Signed-off-by: Matthias Brugger
> Acked-by: F
> On Dec 16, 2020, at 5:23 PM, Michał Mirosław wrote:
>
> On Wed, Dec 16, 2020 at 10:07:38PM +, Nick Terrell wrote:
> [...]
>> It is very large. If it helps, in the commit message I’ve provided this link
>> [0],
>> which provides the diff between upstream zstd as-is and the imported zstd,
On Fri, Dec 18, 2020 at 05:14:58PM +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 17, 2020 at 11:25 PM Eric Biggers wrote:
> >
> > From: Eric Biggers
> >
> > Move the boilerplate code for setkey(), init(), update(), and final()
> > from blake2s_generic.ko into a new module blake2s_helpers.ko, and
From: Kyung Min Park
Add speed test for optimized GHASH computations with vectorized
instructions. Introduce a new test suite to calculate the speed
for this algorithm.
Signed-off-by: Kyung Min Park
Signed-off-by: Megha Dey
---
crypto/tcrypt.c | 5 +
1 file changed, 5 insertions(+)
diff
Introduce the "by16" implementation of the AES CTR mode using AVX512
optimizations. "by16" means that 16 independent blocks (each block
being 128 bits) can be ciphered simultaneously as opposed to the
current 8 blocks.
The glue code in AESNI module overrides the existing "by8" CTR mode
encryption/
The if else block in aesni_init does not follow required coding
conventions. If other conditionals are added to the block, it
becomes very difficult to parse. Use the correct coding style
instead.
Signed-off-by: Megha Dey
---
arch/x86/crypto/aesni-intel_glue.c | 3 +--
1 file changed, 1 insertio
Optimize crypto algorithms using VPCLMULQDQ and VAES AVX512 instructions
(first implemented on Intel's Icelake client and Xeon CPUs).
These algorithms take advantage of the AVX512 registers to keep the CPU
busy and increase memory bandwidth utilization. They provide substantial
(2-10x) improvement
This is a preparatory patch to introduce the optimized crypto algorithms
using AVX512 instructions which would require VAES and VPLCMULQDQ support.
Check for VAES and VPCLMULQDQ assembler support using AVX512 registers.
Cc: x...@kernel.org
Signed-off-by: Megha Dey
---
arch/x86/Kconfig.assembler
Introduce the AVX512 implementation that optimizes the AESNI-GCM encode
and decode routines using VPCLMULQDQ.
The glue code in AESNI module overrides the existing AVX2 GCM mode
encryption/decryption routines with the AX512 AES GCM mode ones when the
following criteria are met:
At compile time:
1.
From: Kyung Min Park
Update the crc_pcl function that calculates T10 Data Integrity Field
CRC16 (CRC T10 DIF) using VPCLMULQDQ instruction. VPCLMULQDQ instruction
with AVX-512F adds EVEX encoded 512 bit version of PCLMULQDQ instruction.
The advantage comes from packing multiples of 4 * 128 bit da
From: Kyung Min Park
Optimize GHASH computations with the 512 bit wide VPCLMULQDQ instructions.
The new instruction allows to work on 4 x 16 byte blocks at the time.
For best parallelism and deeper out of order execution, the main loop of
the code works on 16 x 16 byte blocks at the time and perf
Hey Eric,
The solution you've proposed at the end of your email is actually kind
of similar to what we do with curve25519. Check out
include/crypto/curve25519.h. The critical difference between that and
the blake proposal is that it's in the header for curve25519, so the
indirection disappears.
C
On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote:
>
> Questions:
> - what did I miss or break horribly?
> - does any of this matter for RT? AIUI, RT runs softirqs from a dedicated
> kthread, so I don't think it cares.
> - what would be a reasonable upper bound to keep softirqs disab
This patch series is a result of running kernel crypto fuzz tests (by
enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS) on the transformations
currently supported via the Qualcomm crypto engine on sdm845.
The first four patches are fixes for various regressions found during
testing. The last two patches
Export and import interfaces save and restore partial transformation
states. The partial states were being stored and restored in struct
sha1_state for sha1/hmac(sha1) transformations and sha256_state for
sha256/hmac(sha256) transformations.This led to a bunch of corner cases
where improper state w
If the available data to transfer is exactly a multiple of block size, save
the last block to be transferred in qce_ahash_final (with the last block
bit set) if this is indeed the end of data stream. If not this saved block
will be transferred as part of next update. If this block is not held back
This patch contains the following fixes for the supported encryption
algorithms in the Qualcomm crypto engine(CE)
1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
does not support this and the operation causes the engine to hang.
2. Return unsupprted if any three keys are same fo
totallen is used to get the size of the data to be transformed.
This is also available via nbytes or cryptlen in the qce_sha_reqctx
and qce_cipher_ctx. Similarly offset convey nothing for the supported
encryption and authentication transformations and is always 0.
Remove these two redundant paramet
src_table is unused and hence remove it from struct qce_cipher_reqctx
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/cipher.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/qce/cipher.h b/drivers/crypto/qce/cipher.h
index cffa9fc628ff..850f257d00f3 100644
--- a/drivers/c
Set the register REG_ENCR_XTS_DU_SIZE to cryptlen for AES XTS
transformation. Anything else causes the engine to return back
wrong results.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/common.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qce
In case of error, we should call 'clk_disable_unprepare()' to undo a
previous 'clk_prepare_enable()' call, as already done in the remove
function.
Fixes: 406346d22278 ("hwrng: ingenic - Add hardware TRNG for Ingenic X1830")
Signed-off-by: Christophe JAILLET
---
drivers/char/hw_random/ingenic-trn
43 matches
Mail list logo
