These assembler implementations of SHA1 and AES have been in the upstream source tree since September 2012 but need to be selected explicitly in order to be enabled.
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org --- linaro/configs/linaro-base.conf | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/linaro/configs/linaro-base.conf b/linaro/configs/linaro-base.conf index 5c748a7..ba7b97b 100644 --- a/linaro/configs/linaro-base.conf +++ b/linaro/configs/linaro-base.conf @@ -86,3 +86,5 @@ CONFIG_HW_PERF_EVENTS=y CONFIG_FUNCTION_TRACER=y CONFIG_ENABLE_DEFAULT_TRACERS=y CONFIG_PROC_DEVICETREE=y +CONFIG_CRYPTO_AES_ARM=y +CONFIG_CRYPTO_SHA1_ARM=y
On Tue, 2013-05-14 at 14:16 +0200, Ard Biesheuvel wrote:
These assembler implementations of SHA1 and AES have been in the upstream source tree since September 2012 but need to be selected explicitly in order to be enabled.
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org
linaro/configs/linaro-base.conf | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/linaro/configs/linaro-base.conf b/linaro/configs/linaro-base.conf index 5c748a7..ba7b97b 100644 --- a/linaro/configs/linaro-base.conf +++ b/linaro/configs/linaro-base.conf @@ -86,3 +86,5 @@ CONFIG_HW_PERF_EVENTS=y CONFIG_FUNCTION_TRACER=y CONFIG_ENABLE_DEFAULT_TRACERS=y CONFIG_PROC_DEVICETREE=y +CONFIG_CRYPTO_AES_ARM=y +CONFIG_CRYPTO_SHA1_ARM=y
This also enables CONFIG_CRYPTO_SHA1 which we didn't already have enabled in our builds, so I assume nothing actually needs this option. If that's true, then it doesn't seem worth enabling an optimised version of code which isn't going to be used. ;-)
Not trying to hijack this thread, but I studied in my security class that SHA1 is being attacked so to speak in terms of crypto analysis and it was suggested in the book that it not be used but something like SHA512 be used instead.
Just to give you all a heads up :)
On Tue, May 14, 2013 at 6:49 PM, Jon Medhurst (Tixy) tixy@linaro.orgwrote:
On Tue, 2013-05-14 at 14:16 +0200, Ard Biesheuvel wrote:
These assembler implementations of SHA1 and AES have been in the upstream source tree since September 2012 but need to be selected explicitly in order to be enabled.
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org
linaro/configs/linaro-base.conf | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/linaro/configs/linaro-base.conf
b/linaro/configs/linaro-base.conf
index 5c748a7..ba7b97b 100644 --- a/linaro/configs/linaro-base.conf +++ b/linaro/configs/linaro-base.conf @@ -86,3 +86,5 @@ CONFIG_HW_PERF_EVENTS=y CONFIG_FUNCTION_TRACER=y CONFIG_ENABLE_DEFAULT_TRACERS=y CONFIG_PROC_DEVICETREE=y +CONFIG_CRYPTO_AES_ARM=y +CONFIG_CRYPTO_SHA1_ARM=y
This also enables CONFIG_CRYPTO_SHA1 which we didn't already have enabled in our builds, so I assume nothing actually needs this option. If that's true, then it doesn't seem worth enabling an optimised version of code which isn't going to be used. ;-)
-- Tixy
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 15 May 2013 07:03, Jonathan Aquilina eagles051387@gmail.com wrote:
Not trying to hijack this thread, but I studied in my security class that SHA1 is being attacked so to speak in terms of crypto analysis and it was suggested in the book that it not be used but something like SHA512 be used instead.
Hello Jonathan,
Your professor is correct: SHA1 is not recommended for new development. However, as it is very widely used, we will still need to support it for a very long time.
Why not default to sha512 while still supporting sha1
On Wed, May 15, 2013 at 10:20 AM, Ard Biesheuvel ard.biesheuvel@linaro.orgwrote:
On 15 May 2013 07:03, Jonathan Aquilina eagles051387@gmail.com wrote:
Not trying to hijack this thread, but I studied in my security class that SHA1 is being attacked so to speak in terms of crypto analysis and it was suggested in the book that it not be used but something like SHA512 be
used
instead.
Hello Jonathan,
Your professor is correct: SHA1 is not recommended for new development. However, as it is very widely used, we will still need to support it for a very long time.
-- Ard.
Just to give you all a heads up :)
On Tue, May 14, 2013 at 6:49 PM, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Tue, 2013-05-14 at 14:16 +0200, Ard Biesheuvel wrote:
These assembler implementations of SHA1 and AES have been in the upstream source tree since September 2012 but need to be selected explicitly in order to be enabled.
Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org
linaro/configs/linaro-base.conf | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/linaro/configs/linaro-base.conf b/linaro/configs/linaro-base.conf index 5c748a7..ba7b97b 100644 --- a/linaro/configs/linaro-base.conf +++ b/linaro/configs/linaro-base.conf @@ -86,3 +86,5 @@ CONFIG_HW_PERF_EVENTS=y CONFIG_FUNCTION_TRACER=y CONFIG_ENABLE_DEFAULT_TRACERS=y CONFIG_PROC_DEVICETREE=y +CONFIG_CRYPTO_AES_ARM=y +CONFIG_CRYPTO_SHA1_ARM=y
This also enables CONFIG_CRYPTO_SHA1 which we didn't already have enabled in our builds, so I assume nothing actually needs this option. If that's true, then it doesn't seem worth enabling an optimised version of code which isn't going to be used. ;-)
-- Tixy
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- Jonathan Aquilina
On 14 May 2013 18:49, Jon Medhurst (Tixy) tixy@linaro.org wrote:
This also enables CONFIG_CRYPTO_SHA1 which we didn't already have enabled in our builds, so I assume nothing actually needs this option. If that's true, then it doesn't seem worth enabling an optimised version of code which isn't going to be used. ;-)
Good point. However, if I use merge_config to generate eg. arndale/ubuntu, I end up with a .config which does have SHA1 and AES enabled.
So what would be the best way to enable CONFIG_CRYPTO_SHA1_ARM automatically if some more specific config fragment enables CONFIG_CRYPTO_SHA1 (and CONFIG_ARM), even if only through implicit dependencies?
On Wed, 2013-05-15 at 10:17 +0200, Ard Biesheuvel wrote:
On 14 May 2013 18:49, Jon Medhurst (Tixy) tixy@linaro.org wrote:
This also enables CONFIG_CRYPTO_SHA1 which we didn't already have enabled in our builds, so I assume nothing actually needs this option. If that's true, then it doesn't seem worth enabling an optimised version of code which isn't going to be used. ;-)
Good point. However, if I use merge_config to generate eg. arndale/ubuntu, I end up with a .config which does have SHA1 and AES enabled.
I keep forgetting that some people still use ubuntu.conf, that enables the 2000+ config options used by Ubuntu for their desktop distro. We should really delete that and stick with ubuntu-minimal.conf (which I believe that Fathi was suggesting should become a generic linux disro config )
So what would be the best way to enable CONFIG_CRYPTO_SHA1_ARM automatically if some more specific config fragment enables CONFIG_CRYPTO_SHA1 (and CONFIG_ARM), even if only through implicit dependencies?
I was going to suggest we had a patch which makes CONFIG_CRYPTO_SHA1_ARM
default CONFIG_CRYPTO_SHA1
or something like that, but I see the dependency sort of goes the other way, because CRYPTO_SHA1_ARM selects CRYPTO_SHA1.
If the assembler version is always faster I would have thought that we should always have it enabled and not have it as a user visible option. Perhaps the fact that the assembler is specifically target at ARMv4 means that on ARMv7 CPUs the latest GCC's might generate better code by using newer features?
Either way, it won't hurt to enable it in Linaro kernels as it doesn't look like it is ever used, so would just add to the kernel size a bit.
On 15 May 2013 14:05, Jon Medhurst (Tixy) tixy@linaro.org wrote:
If the assembler version is always faster I would have thought that we should always have it enabled and not have it as a user visible option. Perhaps the fact that the assembler is specifically target at ARMv4 means that on ARMv7 CPUs the latest GCC's might generate better code by using newer features?
No, the v4 signifies that it supports v4 and up, but in fact the code is tuned for dual issue, i.e. Cortex and up. As far as I know, there is no reason not to use the asm versions if you need the algos in the first place.
On Wed, 2013-05-15 at 14:12 +0200, Ard Biesheuvel wrote:
On 15 May 2013 14:05, Jon Medhurst (Tixy) tixy@linaro.org wrote:
If the assembler version is always faster I would have thought that we should always have it enabled and not have it as a user visible option. Perhaps the fact that the assembler is specifically target at ARMv4 means that on ARMv7 CPUs the latest GCC's might generate better code by using newer features?
No, the v4 signifies that it supports v4 and up, but in fact the code is tuned for dual issue, i.e. Cortex and up. As far as I know, there is no reason not to use the asm versions if you need the algos in the first place.
I see that the ARM version is following the pattern of SPARC64 and X86 SSSE3 in how it is configured, so for fear of opening a can of worms, perhaps it's simpler if we just go with the linaro-base.conf patch which started this thread? :-)
On 15 May 2013 14:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
I see that the ARM version is following the pattern of SPARC64 and X86 SSSE3 in how it is configured, so for fear of opening a can of worms, perhaps it's simpler if we just go with the linaro-base.conf patch which started this thread? :-)
Yes please!
On Wed, 2013-05-15 at 14:41 +0200, Ard Biesheuvel wrote:
On 15 May 2013 14:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
I see that the ARM version is following the pattern of SPARC64 and X86 SSSE3 in how it is configured, so for fear of opening a can of worms, perhaps it's simpler if we just go with the linaro-base.conf patch which started this thread? :-)
Yes please!
I've just spotted that you have posted a fix to the ARM SHA1 code [1] so perhaps we shouldn't enable it until that fix works its way into the Linaro tree? (If it's important for Linaro work the perhaps you could ask Andrey to add the patch to the Linaro tree early.)
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168374.html
On 05/15/2013 05:02 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2013-05-15 at 14:41 +0200, Ard Biesheuvel wrote:
On 15 May 2013 14:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
I see that the ARM version is following the pattern of SPARC64 and X86 SSSE3 in how it is configured, so for fear of opening a can of worms, perhaps it's simpler if we just go with the linaro-base.conf patch which started this thread? :-)
Yes please!
I've just spotted that you have posted a fix to the ARM SHA1 code [1] so perhaps we shouldn't enable it until that fix works its way into the Linaro tree? (If it's important for Linaro work the perhaps you could ask Andrey to add the patch to the Linaro tree early.)
- added the "ARM: crypto: sha1-armv4-large.S: fix SP handling" patch to linux-linaro-core-tracking tree starting from tag llct-20130515.1
Thanks, Andrey
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168374.html
On Wed, 15 May 2013, Ard Biesheuvel wrote:
On 15 May 2013 14:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
I see that the ARM version is following the pattern of SPARC64 and X86 SSSE3 in how it is configured, so for fear of opening a can of worms, perhaps it's simpler if we just go with the linaro-base.conf patch which started this thread? :-)
Yes please!
Please make sure your sp adjustment patch is included or you'll get corrupted SHA1 digest whenever an interrupt is serviced in the middle of the SHA1 processing ( ... unless you have CONFIG_KPROBES=y in which case you would have been lucky to get headroom on the stack).
Nicolas
-
Andrey Konovalov -
Ard Biesheuvel -
Jon Medhurst (Tixy) -
Jonathan Aquilina -
Nicolas Pitre