Skip to contentSkip to conversation

arm64/lib: add optimized implementation of sha_transform

PATCH New Ard Biesheuvel 2 participants 4 messages Mar 14, 2014 – Mar 18, 2014

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 arm64/lib: add optimized implementation of sha_transform

This implementation keeps the 64 bytes of workspace in registers rather than on the stack, eliminating most of the loads and stores, and reducing the instruction count by about 25%.

---
Hello all,

No performance numbers I am allowed to share, unfortunately, so if anyone else (with access to actual, representative hardware) would care to have a go, I would be very grateful.

This can be done by building the tcrypt.ko module (CONFIG_CRYPTO_TEST=m), and inserting the module using 'mode=303' as a parameter (note that the insmod always fails, but produces its test output to the kernel log). Also note that the sha_transform() function will be part of the kernel proper, so just rebuilding the sha1_generic module is not sufficient.

Cheers,

 arch/arm64/kernel/arm64ksyms.c |   3 +
 arch/arm64/lib/Makefile        |   2 +-
 arch/arm64/lib/sha1.S          | 256 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 260 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/lib/sha1.S
arch/arm64/kernel/arm64ksyms.c +3 -0
index 338b568cd8ae..1f5693fb5d93 100644
@@ -56,3 +56,6 @@ EXPORT_SYMBOL(clear_bit);
 EXPORT_SYMBOL(test_and_clear_bit);
 EXPORT_SYMBOL(change_bit);
 EXPORT_SYMBOL(test_and_change_bit);
+
+	/* SHA-1 implementation under lib/ */
+EXPORT_SYMBOL(sha_transform);
arch/arm64/lib/Makefile +1 -1
index 328ce1a99daa..ea093ebb9a9a 100644
@@ -1,4 +1,4 @@
 lib-y		:= bitops.o clear_user.o delay.o copy_from_user.o	\
 		   copy_to_user.o copy_in_user.o copy_page.o		\
 		   clear_page.o memchr.o memcpy.o memmove.o memset.o	\
-		   strchr.o strrchr.o
+		   strchr.o strrchr.o sha1.o
arch/arm64/lib/sha1.S new file +256 -0

256 lines not on this page · raw message

Signature · 1 line
1.8.3.2
#1 lore raw

PATCH 1/1 arm64/lib: add optimized implementation of sha_transform

Quoted 12 lines · Ard Biesheuvel

This implementation keeps the 64 bytes of workspace in registers rather than on the stack, eliminating most of the loads and stores, and reducing the instruction count by about 25%.

---
Hello all,

No performance numbers I am allowed to share, unfortunately, so if anyone else (with access to actual, representative hardware) would care to have a go, I would be very grateful.

Quoted 7 lines

This can be done by building the tcrypt.ko module (CONFIG_CRYPTO_TEST=m), and inserting the module using 'mode=303' as a parameter (note that the insmod always fails, but produces its test output to the kernel log). Also note that the sha_transform() function will be part of the kernel proper, so just rebuilding the sha1_generic module is not sufficient.

Cheers,

Won't the function sha_transform() collide with the one in lib/sha1.c ? Or will the one in lib/sha1.c be overriden somehow ?

Otherwise:

Best regards,
Marek Vasut

#2 lore raw

PATCH 1/1 arm64/lib: add optimized implementation of sha_transform

Quoted 19 lines · Marek Vasut
Quoted 18 lines · Ard Biesheuvel

This implementation keeps the 64 bytes of workspace in registers rather than on the stack, eliminating most of the loads and stores, and reducing the instruction count by about 25%.

---
Hello all,

No performance numbers I am allowed to share, unfortunately, so if anyone else (with access to actual, representative hardware) would care to have a go, I would be very grateful.

This can be done by building the tcrypt.ko module (CONFIG_CRYPTO_TEST=m), and inserting the module using 'mode=303' as a parameter (note that the insmod always fails, but produces its test output to the kernel log). Also note that the sha_transform() function will be part of the kernel proper, so just rebuilding the sha1_generic module is not sufficient.

Quoted 5 lines
Quoted 1 line

Cheers,

Won't the function sha_transform() collide with the one in lib/sha1.c ? Or will the one in lib/sha1.c be overriden somehow ?

No, this works pretty well, in fact: arch/*/lib has precedence over lib/, and objects (declared with lib-y +=) are only included to satisfy unresolved dependencies. So the second (generic) sha1.o will not get linked.

Quoted 4 lines

Otherwise:

Thanks. I did send a v2 which is actually a lot different from the version you reviewed, so I won't carry over your reviewed-by without your acknowledgement.

Cheers,
Ard.

#3 lore raw

PATCH 1/1 arm64/lib: add optimized implementation of sha_transform

Quoted 23 lines · Ard Biesheuvel
Quoted 22 lines · Marek Vasut
Quoted 20 lines · Ard Biesheuvel

This implementation keeps the 64 bytes of workspace in registers rather than on the stack, eliminating most of the loads and stores, and reducing the instruction count by about 25%.

---
Hello all,

No performance numbers I am allowed to share, unfortunately, so if anyone else (with access to actual, representative hardware) would care to have a go, I would be very grateful.

This can be done by building the tcrypt.ko module (CONFIG_CRYPTO_TEST=m), and inserting the module using 'mode=303' as a parameter (note that the insmod always fails, but produces its test output to the kernel log). Also note that the sha_transform() function will be part of the kernel proper, so just rebuilding the sha1_generic module is not sufficient.

Cheers,

Quoted 7 lines
Quoted 2 lines

Won't the function sha_transform() collide with the one in lib/sha1.c ? Or will the one in lib/sha1.c be overriden somehow ?

No, this works pretty well, in fact: arch/*/lib has precedence over lib/, and objects (declared with lib-y +=) are only included to satisfy unresolved dependencies. So the second (generic) sha1.o will not get linked.

Thanks for clearing this !

Quoted 7 lines
Quoted 3 lines

Otherwise:

Thanks. I did send a v2 which is actually a lot different from the version you reviewed, so I won't carry over your reviewed-by without your acknowledgement.

Thanks!

Best regards,
Marek Vasut