On Fri, 25 Jan 2019 at 08:29, Eric Biggers wrote:
>
> On Thu, Jan 24, 2019 at 07:27:12PM +0100, Ard Biesheuvel wrote:
> > The SIMD routine ported from x86 used to have a special code path
> > for inputs < 16 bytes, which got lost somewhere along the way.
> > Instead, the current glue code aligns t
On Fri, 25 Jan 2019 at 08:22, Eric Biggers wrote:
>
> On Thu, Jan 24, 2019 at 07:27:11PM +0100, Ard Biesheuvel wrote:
> > The SIMD routine ported from x86 used to have a special code path
> > for inputs < 16 bytes, which got lost somewhere along the way.
> > Instead, the current glue code aligns t
On Fri, 25 Jan 2019 at 07:42, Eric Biggers wrote:
>
> On Thu, Jan 24, 2019 at 05:33:44PM +0100, Ard Biesheuvel wrote:
> > Fix a couple of bugs found by Eric's new testing code, and another
> > issue found by inspection.
> >
> > Ard Biesheuvel (3):
> > crypto: arm64/aes-ccm - fix logical bug in A
On Fri, 25 Jan 2019 at 07:47, Herbert Xu wrote:
>
> On Thu, Jan 24, 2019 at 10:42:18PM -0800, Eric Biggers wrote:
> >
> > Reviewed-by: Eric Biggers
> >
> > However, can you add Cc stable to the first two?
>
> I will add them when I apply the patches.
>
Thanks. Also, Greg and Sasha tend to pick a
On Thu, Jan 24, 2019 at 07:27:12PM +0100, Ard Biesheuvel wrote:
> The SIMD routine ported from x86 used to have a special code path
> for inputs < 16 bytes, which got lost somewhere along the way.
> Instead, the current glue code aligns the input pointer to permit
> the NEON routine to use special
On Thu, Jan 24, 2019 at 07:27:11PM +0100, Ard Biesheuvel wrote:
> The SIMD routine ported from x86 used to have a special code path
> for inputs < 16 bytes, which got lost somewhere along the way.
> Instead, the current glue code aligns the input pointer to permit
> the NEON routine to use special
On Thu, Jan 24, 2019 at 10:42:18PM -0800, Eric Biggers wrote:
>
> Reviewed-by: Eric Biggers
>
> However, can you add Cc stable to the first two?
I will add them when I apply the patches.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana
On Thu, Jan 24, 2019 at 05:33:44PM +0100, Ard Biesheuvel wrote:
> Fix a couple of bugs found by Eric's new testing code, and another
> issue found by inspection.
>
> Ard Biesheuvel (3):
> crypto: arm64/aes-ccm - fix logical bug in AAD MAC handling
> crypto: arm64/aes-ccm - fix bugs in non-NEON
The header search path -I. in kernel Makefiles is very suspicious;
it allows the compiler to search for headers in the top of $(srctree),
where obviously no header file exists.
'git grep BCMDRIVER' has no hit. So, this macro is not referenced.
I was able to build this driver without the extra com
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consisten
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
[It's a minimal fix for a bug that was fixed incidentally by a large
refactoring in v4.8.]
In the CTS template, when the input length is <= one block cipher block
(e.g. <= 16 byt
The SIMD routine ported from x86 used to have a special code path
for inputs < 16 bytes, which got lost somewhere along the way.
Instead, the current glue code aligns the input pointer to permit
the NEON routine to use special versions of the vld1 instructions
that assume 16 byte alignment, but thi
Fix the issues in both NEON implementations of the CRC-T10DIF routines,
that were reported by Eric's new testing code.
Ard Biesheuvel (2):
crypto: arm/crct10dif - revert to C code for short inputs
crypto: arm64/crct10dif - revert to C code for short inputs
arch/arm/crypto/crct10dif-ce-core.S
The SIMD routine ported from x86 used to have a special code path
for inputs < 16 bytes, which got lost somewhere along the way.
Instead, the current glue code aligns the input pointer to permit
the NEON routine to use special versions of the vld1 instructions
that assume 16 byte alignment, but thi
On Thu, Jan 24, 2019 at 05:23:59PM +0800, Herbert Xu wrote:
> On Thu, Jan 24, 2019 at 09:50:35AM +0100, Ard Biesheuvel wrote:
> >
> > Thanks for yet another round of cleanup
> >
> > I'll look into these, but I'd like to clarify one thing first.
> >
> > IIUC, you are trying to deal with the case w
The NEON MAC calculation routine fails to handle the case correctly
where there is some data in the buffer, and the input fills it up
exactly. In this case, we enter the loop at the end with w8 == 0,
while a negative value is assumed, and so the loop carries on until
the increment of the 32-bit cou
Commit 5092fcf34908 ("crypto: arm64/aes-ce-ccm: add non-SIMD generic
fallback") introduced C fallback code to replace the NEON routines
when invoked from a context where the NEON is not available (i.e.,
from the context of a softirq taken while the NEON is already being
used in kernel process conte
Fix a couple of bugs found by Eric's new testing code, and another
issue found by inspection.
Ard Biesheuvel (3):
crypto: arm64/aes-ccm - fix logical bug in AAD MAC handling
crypto: arm64/aes-ccm - fix bugs in non-NEON fallback routine
crypto: arm64/aes-ccm - don't use an atomic walk needles
When the AES-CCM code was first added, the NEON register were saved
and restored eagerly, and so the code avoided doing so, and executed
the scatterwalk in atomic context inside the kernel_neon_begin/end
section.
This has been changed in the meantime, so switch to non-atomic
scatterwalks.
Fixes:
Document DT bindings for crypto Samsung Exynos5433 SlimSSS (Slim Security
SubSystem) IP.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Kamil Konieczny
---
.../devicetree/bindings/crypto/samsung-sss.txt | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Doc
Add slimSSS node to DT and crypto AES support for Exynos5433. Tested on
Exynos5433 board with crypto run-time self tests and with tcrypt with
command insmod tcrypt.ko mode=500 sec=1
Changes since v2:
- address Corentine Labbe note: add "const" to char* in declaration of
struct samsung_aes_varian
Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Kamil Konieczny
---
drivers/crypto/s5p-sss.c | 50
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/s
On 24.01.2019 15:39, Krzysztof Kozlowski wrote:
> On Thu, 24 Jan 2019 at 15:34, Kamil Konieczny
> wrote:
>>
>>
>>
>> On 24.01.2019 14:37, Corentin Labbe wrote:
>>> On Wed, Jan 23, 2019 at 05:55:33PM +0100, Kamil Konieczny wrote:
Add AES crypto HW acceleration for Exynos5433, with the help of
On Thu, 24 Jan 2019 at 15:34, Kamil Konieczny
wrote:
>
>
>
> On 24.01.2019 14:37, Corentin Labbe wrote:
> > On Wed, Jan 23, 2019 at 05:55:33PM +0100, Kamil Konieczny wrote:
> >> Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
> >>
> >> Signed-off-by: Kamil Konieczny
>
On 24.01.2019 14:37, Corentin Labbe wrote:
> On Wed, Jan 23, 2019 at 05:55:33PM +0100, Kamil Konieczny wrote:
>> Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
>>
>> Signed-off-by: Kamil Konieczny
>> ---
>> drivers/crypto/s5p-sss.c | 50
On Thu, 24 Jan 2019 at 14:14, Corentin Labbe wrote:
>
> On Thu, Jan 24, 2019 at 01:36:23PM +0100, Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 23:53, Eric Biggers wrote:
> > >
> > > From: Eric Biggers
> > >
> > > Convert alg_test_skcipher() to use the new test framework, adding a list
> > >
On Thu, 24 Jan 2019 at 18:01, Daniel Thompson
wrote:
>
> On Thu, Jan 24, 2019 at 11:24:39AM +0530, Sumit Garg wrote:
> > On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> > might not be accessible to normal world (linux in this case) and rather
> > accessible to secure world
On Wed, Jan 23, 2019 at 05:55:33PM +0100, Kamil Konieczny wrote:
> Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/crypto/s5p-sss.c | 50
> 1 file changed, 46 insertions(+), 4
On Thu, Jan 24, 2019 at 01:36:23PM +0100, Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 23:53, Eric Biggers wrote:
> >
> > From: Eric Biggers
> >
> > Convert alg_test_skcipher() to use the new test framework, adding a list
> > of testvec_configs to test by default. When the extra self-tests are
On Wed, 23 Jan 2019 at 23:53, Eric Biggers wrote:
>
> From: Eric Biggers
>
> Convert alg_test_skcipher() to use the new test framework, adding a list
> of testvec_configs to test by default. When the extra self-tests are
> enabled, randomly generated testvec_configs are tested as well.
>
> This
On Thu, Jan 24, 2019 at 11:24:39AM +0530, Sumit Garg wrote:
> On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> might not be accessible to normal world (linux in this case) and rather
> accessible to secure world (OP-TEE in this case) only. So this driver
> aims to provides a
On Wed, 23 Jan 2019 at 23:52, Eric Biggers wrote:
>
> From: Eric Biggers
>
> The arm64 NEON bit-sliced implementation of AES-CTR fails the improved
> skcipher tests because it sometimes produces the wrong ciphertext. The
> bug is that the final keystream block isn't returned from the assembly
>
On Thu, 24 Jan 2019 at 15:45, Daniel Thompson
wrote:
>
> On Thu, Jan 24, 2019 at 11:24:38AM +0530, Sumit Garg wrote:
> > OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/
> > services for TEE bus. So implement device enumeration using invoke
> > function: PTA_CMD_GET_DEVICES p
On Thu, Jan 24, 2019 at 3:49 PM Sumit Garg wrote:
>
> On Thu, 24 Jan 2019 at 15:15, Daniel Thompson
> wrote:
> >
> > On Thu, Jan 24, 2019 at 11:24:36AM +0530, Sumit Garg wrote:
> > > Introduce a generic TEE bus driver concept for TEE based kernel drivers
> > > which would like to communicate with
On Thu, Jan 24, 2019 at 11:16:23AM +0100, Ard Biesheuvel wrote:
>
> OK, so how many adjacent physical pages is a scatterlist entry
> permitted to cover? Unbounded?
Well the network stack is limited by packet size so it's less than
64K for practical purposes. However, the API itself doesn't specif
On Thu, 24 Jan 2019 at 15:15, Daniel Thompson
wrote:
>
> On Thu, Jan 24, 2019 at 11:24:36AM +0530, Sumit Garg wrote:
> > Introduce a generic TEE bus driver concept for TEE based kernel drivers
> > which would like to communicate with TEE based devices/services. Also
> > add support in module devic
On Thu, 24 Jan 2019 at 10:24, Herbert Xu wrote:
>
> On Thu, Jan 24, 2019 at 09:50:35AM +0100, Ard Biesheuvel wrote:
> >
> > Thanks for yet another round of cleanup
> >
> > I'll look into these, but I'd like to clarify one thing first.
> >
> > IIUC, you are trying to deal with the case where a sing
On Thu, Jan 24, 2019 at 11:24:38AM +0530, Sumit Garg wrote:
> OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/
> services for TEE bus. So implement device enumeration using invoke
> function: PTA_CMD_GET_DEVICES provided by pseudo TA to fetch array of
> device UUIDs. Also regi
On Wed, 23 Jan 2019 at 17:55, Kamil Konieczny
wrote:
>
> Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
>
> Signed-off-by: Kamil Konieczny
> ---
> drivers/crypto/s5p-sss.c | 50
> 1 file changed, 46 insertions(+), 4 deletions(
On Wed, 23 Jan 2019 at 17:55, Kamil Konieczny
wrote:
>
> Document DT bindings for crypto Samsung Exynos5433 SlimSSS (Slim Security
> SubSystem) IP.
>
> Signed-off-by: Kamil Konieczny
> ---
> .../devicetree/bindings/crypto/samsung-sss.txt | 14 +++---
> 1 file changed, 11 insertions(+
On Thu, Jan 24, 2019 at 11:24:37AM +0530, Sumit Garg wrote:
> This flag indicates that requests in this context should not wait for
> tee-supplicant daemon to be started if not present and just return
> with an error code. It is needed for requests which should be
> non-blocking in nature like ones
On Thu, Jan 24, 2019 at 11:24:36AM +0530, Sumit Garg wrote:
> Introduce a generic TEE bus driver concept for TEE based kernel drivers
> which would like to communicate with TEE based devices/services. Also
> add support in module device table for these new TEE based devices.
>
> In this TEE bus co
On Thu, Jan 24, 2019 at 09:50:35AM +0100, Ard Biesheuvel wrote:
>
> Thanks for yet another round of cleanup
>
> I'll look into these, but I'd like to clarify one thing first.
>
> IIUC, you are trying to deal with the case where a single scatterlist
> element describes a range that strides two pag
On Thu, 24 Jan 2019 at 09:48, Eric Biggers wrote:
>
> On Wed, Jan 23, 2019 at 02:49:11PM -0800, Eric Biggers wrote:
> > Hello,
> >
> > Crypto algorithms must produce the same output for the same input
> > regardless of data layout, i.e. how the src and dst scatterlists are
> > divided into chunks
On Wed, Jan 23, 2019 at 02:49:11PM -0800, Eric Biggers wrote:
> Hello,
>
> Crypto algorithms must produce the same output for the same input
> regardless of data layout, i.e. how the src and dst scatterlists are
> divided into chunks and how each chunk is aligned. Request flags such
> as CRYPTO_T
45 matches
Mail list logo
