On Fri, Jan 19, 2018 at 12:04:32PM +, Ard Biesheuvel wrote:
> This supersedes all outstanding patches from me related to SHA-3, SHA-512
> or SM-3.
>
> - fix a correctness issue in the SHA-3 code (#1) and a performance issue (#2),
> the first one is definitely a -stable candid
On 22 January 2018 at 20:51, Arnd Bergmann wrote:
> On Mon, Jan 22, 2018 at 3:54 PM, Arnd Bergmann wrote:
>> On Fri, Jan 19, 2018 at 1:04 PM, Ard Biesheuvel
>> I'm doing a little more randconfig build testing here now, will write back by
>> the end of today in the unlikely case that if I find any
On Mon, Jan 22, 2018 at 3:54 PM, Arnd Bergmann wrote:
> On Fri, Jan 19, 2018 at 1:04 PM, Ard Biesheuvel
> I'm doing a little more randconfig build testing here now, will write back by
> the end of today in the unlikely case that if I find anything else wrong.
Did a few hundred randconfig builds,
On Fri, Jan 19, 2018 at 1:04 PM, Ard Biesheuvel
wrote:
> This supersedes all outstanding patches from me related to SHA-3, SHA-512
> or SM-3.
>
> - fix a correctness issue in the SHA-3 code (#1) and a performance issue (#2),
> the first one is definitely a -stable candidate,
This supersedes all outstanding patches from me related to SHA-3, SHA-512
or SM-3.
- fix a correctness issue in the SHA-3 code (#1) and a performance issue (#2),
the first one is definitely a -stable candidate, the second one potentially
as well
- patches #3 and #4 make the generic SHA-3 code
On Tue, Jan 09, 2018 at 06:23:02PM +, Ard Biesheuvel wrote:
> Implement the SHA-512 using the new special instructions that have
> been introduced as an optional extension in ARMv8.2.
>
> Signed-off-by: Ard Biesheuvel
Patch applied. Thanks.
--
Email: Herbert Xu
Hom
On 16 January 2018 at 08:16, Steve Capper wrote:
> On Tue, Jan 09, 2018 at 06:23:02PM +, Ard Biesheuvel wrote:
>> Implement the SHA-512 using the new special instructions that have
>> been introduced as an optional extension in ARMv8.2.
>
> Hi Ard,
> I have tested thi
On Tue, Jan 09, 2018 at 06:23:02PM +, Ard Biesheuvel wrote:
> Implement the SHA-512 using the new special instructions that have
> been introduced as an optional extension in ARMv8.2.
Hi Ard,
I have tested this applied on top of 4.15-rc7 running in a model.
For sha512-ce, I verifie
Implement the SHA-512 using the new special instructions that have
been introduced as an optional extension in ARMv8.2.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 6 ++
arch/arm64/crypto/Makefile | 3 +
arch/arm64/crypto/sha512-ce-core.S | 207
On 11 May 2015 at 08:59, Herbert Xu wrote:
> On Fri, May 08, 2015 at 10:46:21AM +0200, Ard Biesheuvel wrote:
>>
>> diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
>> index 8da2207b0072..08b5fb85bff5 100644
>> --- a/arch/arm/crypto/Kconfig
>> +++ b/arch/arm/crypto/Kconfig
>> @@ -53,2
On 13 April 2015 at 06:13, Herbert Xu wrote:
> On Sat, Apr 11, 2015 at 09:15:10PM +0200, Ard Biesheuvel wrote:
>>
>> @Herbert: could you please apply this onto cryptodev before sending
>> out your pull request for v4.1?
>
> Done.
>
>> And please disregard $subject, I will post a v3 with a similar
On Sat, Apr 11, 2015 at 09:15:10PM +0200, Ard Biesheuvel wrote:
>
> @Herbert: could you please apply this onto cryptodev before sending
> out your pull request for v4.1?
Done.
> And please disregard $subject, I will post a v3 with a similar
> 'depends on' added (unless you're ok to add it yoursel
On Saturday 11 April 2015 12:27:18 Ard Biesheuvel wrote:
>
> Ah i see it now. The new Sha256 module as well as the Sha512 i am proposing
> here both use a single .o containing the !neon and neon implementations, and
> only expose the latter if KERNEL_MODE_NEON. This way, we can use the exact
>
On 11 April 2015 at 10:48, Arnd Bergmann wrote:
> On Saturday 11 April 2015 09:35:15 Ard Biesheuvel wrote:
>> On 10 April 2015 at 22:23, Ard Biesheuvel wrote:
>> >
>> >> On 10 apr. 2015, at 22:08, Arnd Bergmann wrote:
>> >>
>> >>> On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
>> >>> +#i
> On 11 apr. 2015, at 10:48, Arnd Bergmann wrote:
>
>> On Saturday 11 April 2015 09:35:15 Ard Biesheuvel wrote:
>>> On 10 April 2015 at 22:23, Ard Biesheuvel wrote:
>>>
> On 10 apr. 2015, at 22:08, Arnd Bergmann wrote:
>
> On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
>>
On Saturday 11 April 2015 09:35:15 Ard Biesheuvel wrote:
> On 10 April 2015 at 22:23, Ard Biesheuvel wrote:
> >
> >> On 10 apr. 2015, at 22:08, Arnd Bergmann wrote:
> >>
> >>> On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
> >>> +#if __ARM_MAX_ARCH__>=7
> >>> +.arch armv7-a
> >>> +.fpu
On 10 April 2015 at 22:23, Ard Biesheuvel wrote:
>
>> On 10 apr. 2015, at 22:08, Arnd Bergmann wrote:
>>
>>> On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
>>> +#if __ARM_MAX_ARCH__>=7
>>> +.arch armv7-a
>>> +.fpu neon
>>> +
>>
>> This will cause a build failure on an ARMv7-M build, wh
> On 10 apr. 2015, at 22:08, Arnd Bergmann wrote:
>
>> On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
>> +#if __ARM_MAX_ARCH__>=7
>> +.arch armv7-a
>> +.fpu neon
>> +
>
> This will cause a build failure on an ARMv7-M build, which is incompatible
> with .arch armv7-a and .fpu neon.
On Friday 10 April 2015 16:29:08 Ard Biesheuvel wrote:
> +#if __ARM_MAX_ARCH__>=7
> +.arch armv7-a
> +.fpu neon
> +
>
This will cause a build failure on an ARMv7-M build, which is incompatible
with .arch armv7-a and .fpu neon.
Arnd
--
To unsubscribe from this list: send the line "u
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
The users need to supply an implementation of
void
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
Signed-off-by: Ard Biesheuvel
---
include/crypto
On 29 March 2015 at 16:07, Andy Polyakov wrote:
>> This updates the SHA-512 NEON module with the faster and more
>> versatile implementation from the OpenSSL project. It consists
>> of both a NEON and a generic ASM version of the core SHA-512
>> transform, where the NEO
On Mon, Mar 30, 2015 at 11:48:20AM +0200, Ard Biesheuvel wrote:
> To reduce the number of copies of boilerplate code throughout
> the tree, this patch implements generic glue for the SHA-512
> algorithm. This allows a specific arch or hardware implementation
> to only implement
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig
This updates the SHA-512 NEON module with the faster and more
versatile implementation from the OpenSSL project. It consists
of both a NEON and a generic ASM version of the core SHA-512
transform, where the NEON version reverts to the ASM version
when invoked in non-process context.
Performance
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig
: Re: [RFC PATCH 1/6] crypto: sha512: implement base layer for SHA-512
>
>>> ...
>>> +int sha512_base_do_update(struct shash_desc *desc, const u8 *data,
>>> + unsigned int len, sha512_block_fn *block_fn, void
>>> *p)
>>&
> This updates the SHA-512 NEON module with the faster and more
> versatile implementation from the OpenSSL project. It consists
> of both a NEON and a generic ASM version of the core SHA-512
> transform, where the NEON version reverts to the ASM version
> when invoked in non-
ux-arm-ker...@lists.infradead.org; linux-crypto@vger.kernel.org;
>> samitolva...@google.com; herb...@gondor.apana.org.au; jussi.kivili...@iki.fi
>> Cc: Ard Biesheuvel
>> Betreff: [RFC PATCH 1/6] crypto: sha512: implement base layer for SHA-512
>>
>> To reduce the n
amitolva...@google.com; herb...@gondor.apana.org.au; jussi.kivili...@iki.fi
> Cc: Ard Biesheuvel
> Betreff: [RFC PATCH 1/6] crypto: sha512: implement base layer for SHA-512
>
> To reduce the number of copies of boilerplate code throughout
> the tree, this patch implements generic glue
This updates the SHA-512 NEON module with the faster and more
versatile implementation from the OpenSSL project. It consists
of both a NEON and a generic ASM version of the core SHA-512
transform, where the NEON version reverts to the ASM version
when invoked in non-process context.
Performance
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig
On 28.03.2015 09:28, Ard Biesheuvel wrote:
> This updates the SHA-512 NEON module with the faster and more
> versatile implementation from the OpenSSL project. It consists
> of both a NEON and a generic ASM version of the core SHA-512
> transform, where the NEON version reverts to the
This updates the SHA-512 NEON module with the faster and more
versatile implementation from the OpenSSL project. It consists
of both a NEON and a generic ASM version of the core SHA-512
transform, where the NEON version reverts to the ASM version
when invoked in non-process context.
Performance
The SHA-512 NEON works just fine under big endian, so remove the Kconfig
condition preventing it from being selected if CONFIG_CPU_BIG_ENDIAN is set.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/Kconfig b/crypto
On Sat, Apr 12, 2014 at 03:35:29PM +0300, Jussi Kivilinna wrote:
> Patch adds large test-vectors for SHA algorithms for better code coverage in
> optimized assembly implementations. Empty test-vectors are also added, as some
> crypto drivers appear to have special case handling for empty input.
>
Patch adds large test-vectors for SHA algorithms for better code coverage in
optimized assembly implementations. Empty test-vectors are also added, as some
crypto drivers appear to have special case handling for empty input.
Signed-off-by: Jussi Kivilinna
---
This patch depends on the "crypto: a
On Fri, Mar 16, 2012 at 08:26:28PM +, Kent Yoder wrote:
> The current code only increments the upper 64 bits of the SHA-512 byte
> counter when the number of bytes hashed happens to hit 2^64 exactly.
>
> This patch increments the upper 64 bits whenever the lower 64 bits
The current code only increments the upper 64 bits of the SHA-512 byte
counter when the number of bytes hashed happens to hit 2^64 exactly.
This patch increments the upper 64 bits whenever the lower 64 bits
overflows.
Signed-off-by: Kent Yoder
---
crypto/sha512_generic.c |2 +-
1 files
On Wed, Feb 15, 2012 at 04:00:10PM -0500, David Miller wrote:
>
> In fact, in my tree, this change brings the stack allocation instruction
> down to:
>
> save%sp, -824, %sp !
>
> which is actually BETTER than what the old per-cpu code got:
>
> save%sp, -984, %sp !
>
>
From: Alexey Dobriyan
Date: Wed, 15 Feb 2012 22:27:52 +0300
> On Wed, Feb 15, 2012 at 12:23:52AM -0500, David Miller wrote:
>> From: Herbert Xu
>> Date: Wed, 15 Feb 2012 16:16:08 +1100
>>
>> > OK, so we grew by 1136 - 888 = 248. Keep in mind that 128 of
>> > that is expected since we moved W o
On Wed, Feb 15, 2012 at 12:23:52AM -0500, David Miller wrote:
> From: Herbert Xu
> Date: Wed, 15 Feb 2012 16:16:08 +1100
>
> > OK, so we grew by 1136 - 888 = 248. Keep in mind that 128 of
> > that is expected since we moved W onto the stack.
>
> Right.
>
> > I guess we could go back to the per
From: Herbert Xu
Date: Wed, 15 Feb 2012 16:16:08 +1100
> OK, so we grew by 1136 - 888 = 248. Keep in mind that 128 of
> that is expected since we moved W onto the stack.
Right.
> I guess we could go back to the percpu solution, what do you
> think?
I'm not entirely sure, we might have to.
sh
On Wed, Feb 15, 2012 at 12:11:13AM -0500, David Miller wrote:
>
> > On Tue, Feb 14, 2012 at 10:58:33PM -0500, David Miller wrote:
> >>
> >> FYI, I just started seeing this on sparc32 after all those
> >> sha512 "optimizations":
> >>
> >> crypto/sha512_generic.c: In function 'sha512_transform':
>
From: Herbert Xu
Date: Wed, 15 Feb 2012 15:01:28 +1100
> On Tue, Feb 14, 2012 at 10:58:33PM -0500, David Miller wrote:
>>
>> FYI, I just started seeing this on sparc32 after all those
>> sha512 "optimizations":
>>
>> crypto/sha512_generic.c: In function 'sha512_transform':
>> crypto/sha512_gene
On Tue, Feb 14, 2012 at 10:58:33PM -0500, David Miller wrote:
>
> FYI, I just started seeing this on sparc32 after all those
> sha512 "optimizations":
>
> crypto/sha512_generic.c: In function 'sha512_transform':
> crypto/sha512_generic.c:135:1: warning: the frame size of 1136 bytes is
> larger t
FYI, I just started seeing this on sparc32 after all those
sha512 "optimizations":
crypto/sha512_generic.c: In function 'sha512_transform':
crypto/sha512_generic.c:135:1: warning: the frame size of 1136 bytes is larger
than 1024 bytes [-Wframe-larger-than=]
--
To unsubscribe from this list: send
47 matches
Mail list logo
