nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 09:58:01 +00:00
Code Issues Projects Releases Wiki Activity
65383082bf
putty-source/unix/uxutils.c

68 lines
1.4 KiB
C
Raw Normal View History

Check for auxv.h and hwcap.h before including them. uClibc-ng does not provide <sys/auxv.h>, and a non-Linux-kernel-based Unixlike system running on Arm will probably not provide <asm/hwcap.h>. Now we check for both of those headers at autoconf time, and if either one is absent, we don't do the runtime test for Arm crypto acceleration. This should only make a difference on systems where this module previously failed to compile at all. But obviously it would be nicer to find alternative ways to check for crypto acceleration on such systems; patches welcome.
2019-03-26 18:40:51 +00:00
#include "putty.h"
Support hardware AES on Arm platforms. The refactored sshaes.c gives me a convenient slot to drop in a second hardware-accelerated AES implementation, similar to the existing one but using Arm NEON intrinsics in place of the x86 AES-NI ones. This needed a minor structural change, because Arm systems are often heterogeneous, containing more than one type of CPU which won't necessarily all support the same set of architecture features. So you can't test at run time for the presence of AES acceleration by querying the CPU you're running on - even if you found a way to do it, the answer wouldn't be reliable once the OS started migrating your process between CPUs. Instead, you have to ask the OS itself, because only that knows about _all_ the CPUs on the system. So that means the aes_hw_available() mechanism has to extend a tentacle into each platform subdirectory. The trickiest part was the nest of ifdefs that tries to detect whether the compiler can support the necessary parts. I had successful test-compiles on several compilers, and was able to run the code directly on an AArch64 tablet (so I know it passes cryptsuite), but it's likely that at least some Arm platforms won't be able to build it because of some path through the ifdefs that I haven't been able to test yet.
2019-01-16 22:08:45 +00:00
#include "ssh.h"
Support FreeBSD's API for querying the ELF aux vector. We use this for detecting the Arm crypto extension and using it to enable accelerated AES and/or SHA-{1,2}. Previously, I had code that called glibc's getauxval(3) function, conditioned on #ifdef __linux__. Now, instead, I do an autoconf test to query the presence of getauxval itself (so that any other system with the same API can still work), and alongside it, also check for the analogous FreeBSD libc function elf_aux_info(3). As a result, building on Arm FreeBSD now gets the accelerated-crypto autodetection.
2020-10-09 18:14:57 +00:00
#if defined __arm__ || defined __aarch64__
Support hardware AES on Arm platforms. The refactored sshaes.c gives me a convenient slot to drop in a second hardware-accelerated AES implementation, similar to the existing one but using Arm NEON intrinsics in place of the x86 AES-NI ones. This needed a minor structural change, because Arm systems are often heterogeneous, containing more than one type of CPU which won't necessarily all support the same set of architecture features. So you can't test at run time for the presence of AES acceleration by querying the CPU you're running on - even if you found a way to do it, the answer wouldn't be reliable once the OS started migrating your process between CPUs. Instead, you have to ask the OS itself, because only that knows about _all_ the CPUs on the system. So that means the aes_hw_available() mechanism has to extend a tentacle into each platform subdirectory. The trickiest part was the nest of ifdefs that tries to detect whether the compiler can support the necessary parts. I had successful test-compiles on several compilers, and was able to run the code directly on an AArch64 tablet (so I know it passes cryptsuite), but it's likely that at least some Arm platforms won't be able to build it because of some path through the ifdefs that I haven't been able to test yet.
2019-01-16 22:08:45 +00:00
Support FreeBSD's API for querying the ELF aux vector. We use this for detecting the Arm crypto extension and using it to enable accelerated AES and/or SHA-{1,2}. Previously, I had code that called glibc's getauxval(3) function, conditioned on #ifdef __linux__. Now, instead, I do an autoconf test to query the presence of getauxval itself (so that any other system with the same API can still work), and alongside it, also check for the analogous FreeBSD libc function elf_aux_info(3). As a result, building on Arm FreeBSD now gets the accelerated-crypto autodetection.
2020-10-09 18:14:57 +00:00
#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
#ifdef HAVE_SYS_AUXV_H
Support hardware AES on Arm platforms. The refactored sshaes.c gives me a convenient slot to drop in a second hardware-accelerated AES implementation, similar to the existing one but using Arm NEON intrinsics in place of the x86 AES-NI ones. This needed a minor structural change, because Arm systems are often heterogeneous, containing more than one type of CPU which won't necessarily all support the same set of architecture features. So you can't test at run time for the presence of AES acceleration by querying the CPU you're running on - even if you found a way to do it, the answer wouldn't be reliable once the OS started migrating your process between CPUs. Instead, you have to ask the OS itself, because only that knows about _all_ the CPUs on the system. So that means the aes_hw_available() mechanism has to extend a tentacle into each platform subdirectory. The trickiest part was the nest of ifdefs that tries to detect whether the compiler can support the necessary parts. I had successful test-compiles on several compilers, and was able to run the code directly on an AArch64 tablet (so I know it passes cryptsuite), but it's likely that at least some Arm platforms won't be able to build it because of some path through the ifdefs that I haven't been able to test yet.
2019-01-16 22:08:45 +00:00
#include <sys/auxv.h>
Support FreeBSD's API for querying the ELF aux vector. We use this for detecting the Arm crypto extension and using it to enable accelerated AES and/or SHA-{1,2}. Previously, I had code that called glibc's getauxval(3) function, conditioned on #ifdef __linux__. Now, instead, I do an autoconf test to query the presence of getauxval itself (so that any other system with the same API can still work), and alongside it, also check for the analogous FreeBSD libc function elf_aux_info(3). As a result, building on Arm FreeBSD now gets the accelerated-crypto autodetection.
2020-10-09 18:14:57 +00:00
#endif
#ifdef HAVE_ASM_HWCAP_H
Support hardware AES on Arm platforms. The refactored sshaes.c gives me a convenient slot to drop in a second hardware-accelerated AES implementation, similar to the existing one but using Arm NEON intrinsics in place of the x86 AES-NI ones. This needed a minor structural change, because Arm systems are often heterogeneous, containing more than one type of CPU which won't necessarily all support the same set of architecture features. So you can't test at run time for the presence of AES acceleration by querying the CPU you're running on - even if you found a way to do it, the answer wouldn't be reliable once the OS started migrating your process between CPUs. Instead, you have to ask the OS itself, because only that knows about _all_ the CPUs on the system. So that means the aes_hw_available() mechanism has to extend a tentacle into each platform subdirectory. The trickiest part was the nest of ifdefs that tries to detect whether the compiler can support the necessary parts. I had successful test-compiles on several compilers, and was able to run the code directly on an AArch64 tablet (so I know it passes cryptsuite), but it's likely that at least some Arm platforms won't be able to build it because of some path through the ifdefs that I haven't been able to test yet.
2019-01-16 22:08:45 +00:00
#include <asm/hwcap.h>
Support FreeBSD's API for querying the ELF aux vector. We use this for detecting the Arm crypto extension and using it to enable accelerated AES and/or SHA-{1,2}. Previously, I had code that called glibc's getauxval(3) function, conditioned on #ifdef __linux__. Now, instead, I do an autoconf test to query the presence of getauxval itself (so that any other system with the same API can still work), and alongside it, also check for the analogous FreeBSD libc function elf_aux_info(3). As a result, building on Arm FreeBSD now gets the accelerated-crypto autodetection.
2020-10-09 18:14:57 +00:00
#endif
#if defined HAVE_GETAUXVAL
/* No code needed: getauxval has just the API we want already */
#elif defined HAVE_ELF_AUX_INFO
/* Implement the simple getauxval API in terms of FreeBSD elf_aux_info */
static inline u_long getauxval(int which)
{
u_long toret;
if (elf_aux_info(which, &toret, sizeof(toret)) != 0)
return 0; /* elf_aux_info didn't work */
return toret;
}
#else
/* Implement a stub getauxval which returns no capabilities */
static inline u_long getauxval(int which) { return 0; }
#endif
Support hardware AES on Arm platforms. The refactored sshaes.c gives me a convenient slot to drop in a second hardware-accelerated AES implementation, similar to the existing one but using Arm NEON intrinsics in place of the x86 AES-NI ones. This needed a minor structural change, because Arm systems are often heterogeneous, containing more than one type of CPU which won't necessarily all support the same set of architecture features. So you can't test at run time for the presence of AES acceleration by querying the CPU you're running on - even if you found a way to do it, the answer wouldn't be reliable once the OS started migrating your process between CPUs. Instead, you have to ask the OS itself, because only that knows about _all_ the CPUs on the system. So that means the aes_hw_available() mechanism has to extend a tentacle into each platform subdirectory. The trickiest part was the nest of ifdefs that tries to detect whether the compiler can support the necessary parts. I had successful test-compiles on several compilers, and was able to run the code directly on an AArch64 tablet (so I know it passes cryptsuite), but it's likely that at least some Arm platforms won't be able to build it because of some path through the ifdefs that I haven't been able to test yet.
2019-01-16 22:08:45 +00:00
bool platform_aes_hw_available(void)
{
#if defined HWCAP_AES
return getauxval(AT_HWCAP) & HWCAP_AES;
#elif defined HWCAP2_AES
return getauxval(AT_HWCAP2) & HWCAP2_AES;
#else
return false;
#endif
}
Support hardware SHA-256 and SHA-1 on Arm platforms. Similarly to my recent addition of NEON-accelerated AES, these new implementations drop in alongside the SHA-NI ones, under a different set of ifdefs. All the details of selection and detection are essentially the same as they were for the AES code.
2019-01-23 07:27:12 +00:00
bool platform_sha256_hw_available(void)
{
#if defined HWCAP_SHA2
return getauxval(AT_HWCAP) & HWCAP_SHA2;
#elif defined HWCAP2_SHA2
return getauxval(AT_HWCAP2) & HWCAP2_SHA2;
#else
return false;
#endif
}
bool platform_sha1_hw_available(void)
{
#if defined HWCAP_SHA1
return getauxval(AT_HWCAP) & HWCAP_SHA1;
#elif defined HWCAP2_SHA1
return getauxval(AT_HWCAP2) & HWCAP2_SHA1;
#else
return false;
#endif
}
Support FreeBSD's API for querying the ELF aux vector. We use this for detecting the Arm crypto extension and using it to enable accelerated AES and/or SHA-{1,2}. Previously, I had code that called glibc's getauxval(3) function, conditioned on #ifdef __linux__. Now, instead, I do an autoconf test to query the presence of getauxval itself (so that any other system with the same API can still work), and alongside it, also check for the analogous FreeBSD libc function elf_aux_info(3). As a result, building on Arm FreeBSD now gets the accelerated-crypto autodetection.
2020-10-09 18:14:57 +00:00
#endif /* defined __arm__ || defined __aarch64__ */
Reference in New Issue Copy Permalink