nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-25 09:12:24 +00:00
Code Issues Projects Releases Wiki Activity
b6b95f23e5
putty-source/unix/utils/arm_arch_queries.c

121 lines
3.2 KiB
C
Raw Normal View History

New library-style 'utils' subdirectories. Now that the new CMake build system is encouraging us to lay out the code like a set of libraries, it seems like a good idea to make them look more _like_ libraries, by putting things into separate modules as far as possible. This fixes several previous annoyances in which you had to link against some object in order to get a function you needed, but that object also contained other functions you didn't need which included link-time symbol references you didn't want to have to deal with. The usual offender was subsidiary supporting programs including misc.c for some innocuous function and then finding they had to deal with the requirements of buildinfo(). This big reorganisation introduces three new subdirectories called 'utils', one at the top level and one in each platform subdir. In each case, the directory contains basically the same files that were previously placed in the 'utils' build-time library, except that the ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c, winmisc.c, winmiscs.c, winutils.c) have been split up into much smaller pieces.
2021-04-17 14:22:20 +00:00
/*
* Unix implementation of the OS query functions that detect Arm
* architecture extensions.
*/
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"
New library-style 'utils' subdirectories. Now that the new CMake build system is encouraging us to lay out the code like a set of libraries, it seems like a good idea to make them look more _like_ libraries, by putting things into separate modules as far as possible. This fixes several previous annoyances in which you had to link against some object in order to get a function you needed, but that object also contained other functions you didn't need which included link-time symbol references you didn't want to have to deal with. The usual offender was subsidiary supporting programs including misc.c for some innocuous function and then finding they had to deal with the requirements of buildinfo(). This big reorganisation introduces three new subdirectories called 'utils', one at the top level and one in each platform subdir. In each case, the directory contains basically the same files that were previously placed in the 'utils' build-time library, except that the ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c, winmisc.c, winmiscs.c, winutils.c) have been split up into much smaller pieces.
2021-04-17 14:22:20 +00:00
#include "utils/arm_arch_queries.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
uxutils.c: move some definitions into a header file. If the autoconf/ifdef system ends up taking the trivial branch through all the Arm-architecture ifdefs, then we define the always-fail version of getauxval as a 'static inline' function, and then (because none of our desired HWCAP_FOO values is defined at all) never call it. This leads to a compiler warning because we defined a static function and never called it - i.e. at the default -Werror, a build failure. Of course it's perfectly sensible to define a static inline function that never gets called! Header files do it all the time, and nobody is expected to ensure that if they include a header file then they take care to refer to every static inline function it defines. But if the definition is in the _source_ file rather than a header file, then clang (in particular on macOS) will give a warning. So the easy solution is to move the inline definitions of getauxval into a header file, which suppresses the warning without requiring me to faff about with further ifdefs to make the definitions conditional on at least one use.
2020-12-24 09:34:13 +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
Break up crypto modules containing HW acceleration. This applies to all of AES, SHA-1, SHA-256 and SHA-512. All those source files previously contained multiple implementations of the algorithm, enabled or disabled by ifdefs detecting whether they would work on a given compiler. And in order to get advanced machine instructions like AES-NI or NEON crypto into the output file when the compile flags hadn't enabled them, we had to do nasty stuff with compiler-specific pragmas or attributes. Now we can do the detection at cmake time, and enable advanced instructions in the more sensible way, by compile-time flags. So I've broken up each of these modules into lots of sub-pieces: a file called (e.g.) 'foo-common.c' containing common definitions across all implementations (such as round constants), one called 'foo-select.c' containing the top-level vtable(s), and a separate file for each implementation exporting just the vtable(s) for that implementation. One advantage of this is that it depends a lot less on compiler- specific bodgery. My particular least favourite part of the previous setup was the part where I had to _manually_ define some Arm ACLE feature macros before including <arm_neon.h>, so that it would define the intrinsics I wanted. Now I'm enabling interesting architecture features in the normal way, on the compiler command line, there's no need for that kind of trick: the right feature macros are already defined and <arm_neon.h> does the right thing. Another change in this reorganisation is that I've stopped assuming there's just one hardware implementation per platform. Previously, the accelerated vtables were called things like sha256_hw, and varied between FOO-NI and NEON depending on platform; and the selection code would simply ask 'is hw available? if so, use hw, else sw'. Now, each HW acceleration strategy names its vtable its own way, and the selection vtable has a whole list of possibilities to iterate over looking for a supported one. So if someone feels like writing a second accelerated implementation of something for a given platform - for example, I've heard you can use plain NEON to speed up AES somewhat even without the crypto extension - then it will now have somewhere to drop in alongside the existing ones.
2021-04-19 05:42:12 +00:00
bool platform_aes_neon_available(void)
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
{
#if defined HWCAP_AES
return getauxval(AT_HWCAP) & HWCAP_AES;
#elif defined HWCAP2_AES
return getauxval(AT_HWCAP2) & HWCAP2_AES;
uxutils.c: add special case for M1 macOS. The M1 chip in the new range of Macs includes the crypto extension that permits AES, SHA-1 and SHA-256 acceleration. But you can't find that out by querying the ELF aux vector, because macOS isn't even ELF-based at all, so there isn't an ELF aux vector, and no web search I've tried has turned up any MachO thing obviously analogous to it. Running 'sysctl -a' does show some flags indicating CPU architecture extensions, but they're more advanced ones than this. So I think we have to assume that if we're on the new M1 macOS at all, then we have the basic crypto extension available. Accordingly, I've added a special case to all the query functions that simply returns true if defined __APPLE__.
2020-12-24 10:04:08 +00:00
#elif defined __APPLE__
Add CPU feature checks on M1 macOS. I booted my M1 Mac into macOS rather than Asahi for the first time in a while, and discovered that an OS update seems to have added some sysctl flags indicating the presence of the CPU extensions that I previously knew of no way to check for! Added them checks to arm_arch_queries.c, though I've also retained backwards compat with the previous OS version which didn't have them at all.
2022-08-16 17:39:12 +00:00
SysctlResult res = test_sysctl_flag("hw.optional.arm.FEAT_AES");
/* Older M1 macOS didn't provide this flag, but as far as I know
* implemented the crypto extension anyway, so treat 'feature
* missing' as 'implemented' */
return res != SYSCTL_OFF;
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
#else
return false;
#endif
}
Implement AES-GCM using the @openssh.com protocol IDs. I only recently found out that OpenSSH defined their own protocol IDs for AES-GCM, defined to work the same as the standard ones except that they fixed the semantics for how you select the linked cipher+MAC pair during key exchange. (RFC 5647 defines protocol ids for AES-GCM in both the cipher and MAC namespaces, and requires that you MUST select both or neither - but this contradicts the selection policy set out in the base SSH RFCs, and there's no discussion of how you resolve a conflict between them! OpenSSH's answer is to do it the same way ChaCha20-Poly1305 works, because that will ensure the two suites don't fight.) People do occasionally ask us for this linked cipher/MAC pair, and now I know it's actually feasible, I've implemented it, including a pair of vector implementations for x86 and Arm using their respective architecture extensions for multiplying polynomials over GF(2). Unlike ChaCha20-Poly1305, I've kept the cipher and MAC implementations in separate objects, with an arm's-length link between them that the MAC uses when it needs to encrypt single cipher blocks to use as the inputs to the MAC algorithm. That enables the cipher and the MAC to be independently selected from their hardware-accelerated versions, just in case someone runs on a system that has polynomial multiplication instructions but not AES acceleration, or vice versa. There's a fourth implementation of the GCM MAC, which is a pure software implementation of the same algorithm used in the vectorised versions. It's too slow to use live, but I've kept it in the code for future testing needs, and because it's a convenient place to dump my design comments. The vectorised implementations are fairly crude as far as optimisation goes. I'm sure serious x86 _or_ Arm optimisation engineers would look at them and laugh. But GCM is a fast MAC compared to HMAC-SHA-256 (indeed compared to HMAC-anything-at-all), so it should at least be good enough to use. And we've got a working version with some tests now, so if someone else wants to improve them, they can.
2022-08-16 17:36:58 +00:00
bool platform_pmull_neon_available(void)
{
#if defined HWCAP_PMULL
return getauxval(AT_HWCAP) & HWCAP_PMULL;
#elif defined HWCAP2_PMULL
return getauxval(AT_HWCAP2) & HWCAP2_PMULL;
#elif defined __APPLE__
SysctlResult res = test_sysctl_flag("hw.optional.arm.FEAT_PMULL");
/* As above, treat 'missing' as enabled */
return res != SYSCTL_OFF;
#else
return false;
#endif
}
Break up crypto modules containing HW acceleration. This applies to all of AES, SHA-1, SHA-256 and SHA-512. All those source files previously contained multiple implementations of the algorithm, enabled or disabled by ifdefs detecting whether they would work on a given compiler. And in order to get advanced machine instructions like AES-NI or NEON crypto into the output file when the compile flags hadn't enabled them, we had to do nasty stuff with compiler-specific pragmas or attributes. Now we can do the detection at cmake time, and enable advanced instructions in the more sensible way, by compile-time flags. So I've broken up each of these modules into lots of sub-pieces: a file called (e.g.) 'foo-common.c' containing common definitions across all implementations (such as round constants), one called 'foo-select.c' containing the top-level vtable(s), and a separate file for each implementation exporting just the vtable(s) for that implementation. One advantage of this is that it depends a lot less on compiler- specific bodgery. My particular least favourite part of the previous setup was the part where I had to _manually_ define some Arm ACLE feature macros before including <arm_neon.h>, so that it would define the intrinsics I wanted. Now I'm enabling interesting architecture features in the normal way, on the compiler command line, there's no need for that kind of trick: the right feature macros are already defined and <arm_neon.h> does the right thing. Another change in this reorganisation is that I've stopped assuming there's just one hardware implementation per platform. Previously, the accelerated vtables were called things like sha256_hw, and varied between FOO-NI and NEON depending on platform; and the selection code would simply ask 'is hw available? if so, use hw, else sw'. Now, each HW acceleration strategy names its vtable its own way, and the selection vtable has a whole list of possibilities to iterate over looking for a supported one. So if someone feels like writing a second accelerated implementation of something for a given platform - for example, I've heard you can use plain NEON to speed up AES somewhat even without the crypto extension - then it will now have somewhere to drop in alongside the existing ones.
2021-04-19 05:42:12 +00:00
bool platform_sha256_neon_available(void)
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
{
#if defined HWCAP_SHA2
return getauxval(AT_HWCAP) & HWCAP_SHA2;
#elif defined HWCAP2_SHA2
return getauxval(AT_HWCAP2) & HWCAP2_SHA2;
uxutils.c: add special case for M1 macOS. The M1 chip in the new range of Macs includes the crypto extension that permits AES, SHA-1 and SHA-256 acceleration. But you can't find that out by querying the ELF aux vector, because macOS isn't even ELF-based at all, so there isn't an ELF aux vector, and no web search I've tried has turned up any MachO thing obviously analogous to it. Running 'sysctl -a' does show some flags indicating CPU architecture extensions, but they're more advanced ones than this. So I think we have to assume that if we're on the new M1 macOS at all, then we have the basic crypto extension available. Accordingly, I've added a special case to all the query functions that simply returns true if defined __APPLE__.
2020-12-24 10:04:08 +00:00
#elif defined __APPLE__
Add CPU feature checks on M1 macOS. I booted my M1 Mac into macOS rather than Asahi for the first time in a while, and discovered that an OS update seems to have added some sysctl flags indicating the presence of the CPU extensions that I previously knew of no way to check for! Added them checks to arm_arch_queries.c, though I've also retained backwards compat with the previous OS version which didn't have them at all.
2022-08-16 17:39:12 +00:00
SysctlResult res = test_sysctl_flag("hw.optional.arm.FEAT_SHA256");
/* As above, treat 'missing' as enabled */
return res != SYSCTL_OFF;
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
#else
return false;
#endif
}
Break up crypto modules containing HW acceleration. This applies to all of AES, SHA-1, SHA-256 and SHA-512. All those source files previously contained multiple implementations of the algorithm, enabled or disabled by ifdefs detecting whether they would work on a given compiler. And in order to get advanced machine instructions like AES-NI or NEON crypto into the output file when the compile flags hadn't enabled them, we had to do nasty stuff with compiler-specific pragmas or attributes. Now we can do the detection at cmake time, and enable advanced instructions in the more sensible way, by compile-time flags. So I've broken up each of these modules into lots of sub-pieces: a file called (e.g.) 'foo-common.c' containing common definitions across all implementations (such as round constants), one called 'foo-select.c' containing the top-level vtable(s), and a separate file for each implementation exporting just the vtable(s) for that implementation. One advantage of this is that it depends a lot less on compiler- specific bodgery. My particular least favourite part of the previous setup was the part where I had to _manually_ define some Arm ACLE feature macros before including <arm_neon.h>, so that it would define the intrinsics I wanted. Now I'm enabling interesting architecture features in the normal way, on the compiler command line, there's no need for that kind of trick: the right feature macros are already defined and <arm_neon.h> does the right thing. Another change in this reorganisation is that I've stopped assuming there's just one hardware implementation per platform. Previously, the accelerated vtables were called things like sha256_hw, and varied between FOO-NI and NEON depending on platform; and the selection code would simply ask 'is hw available? if so, use hw, else sw'. Now, each HW acceleration strategy names its vtable its own way, and the selection vtable has a whole list of possibilities to iterate over looking for a supported one. So if someone feels like writing a second accelerated implementation of something for a given platform - for example, I've heard you can use plain NEON to speed up AES somewhat even without the crypto extension - then it will now have somewhere to drop in alongside the existing ones.
2021-04-19 05:42:12 +00:00
bool platform_sha1_neon_available(void)
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
{
#if defined HWCAP_SHA1
return getauxval(AT_HWCAP) & HWCAP_SHA1;
#elif defined HWCAP2_SHA1
return getauxval(AT_HWCAP2) & HWCAP2_SHA1;
uxutils.c: add special case for M1 macOS. The M1 chip in the new range of Macs includes the crypto extension that permits AES, SHA-1 and SHA-256 acceleration. But you can't find that out by querying the ELF aux vector, because macOS isn't even ELF-based at all, so there isn't an ELF aux vector, and no web search I've tried has turned up any MachO thing obviously analogous to it. Running 'sysctl -a' does show some flags indicating CPU architecture extensions, but they're more advanced ones than this. So I think we have to assume that if we're on the new M1 macOS at all, then we have the basic crypto extension available. Accordingly, I've added a special case to all the query functions that simply returns true if defined __APPLE__.
2020-12-24 10:04:08 +00:00
#elif defined __APPLE__
Add CPU feature checks on M1 macOS. I booted my M1 Mac into macOS rather than Asahi for the first time in a while, and discovered that an OS update seems to have added some sysctl flags indicating the presence of the CPU extensions that I previously knew of no way to check for! Added them checks to arm_arch_queries.c, though I've also retained backwards compat with the previous OS version which didn't have them at all.
2022-08-16 17:39:12 +00:00
SysctlResult res = test_sysctl_flag("hw.optional.arm.FEAT_SHA1");
/* As above, treat 'missing' as enabled */
return res != SYSCTL_OFF;
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
#else
return false;
#endif
}
Break up crypto modules containing HW acceleration. This applies to all of AES, SHA-1, SHA-256 and SHA-512. All those source files previously contained multiple implementations of the algorithm, enabled or disabled by ifdefs detecting whether they would work on a given compiler. And in order to get advanced machine instructions like AES-NI or NEON crypto into the output file when the compile flags hadn't enabled them, we had to do nasty stuff with compiler-specific pragmas or attributes. Now we can do the detection at cmake time, and enable advanced instructions in the more sensible way, by compile-time flags. So I've broken up each of these modules into lots of sub-pieces: a file called (e.g.) 'foo-common.c' containing common definitions across all implementations (such as round constants), one called 'foo-select.c' containing the top-level vtable(s), and a separate file for each implementation exporting just the vtable(s) for that implementation. One advantage of this is that it depends a lot less on compiler- specific bodgery. My particular least favourite part of the previous setup was the part where I had to _manually_ define some Arm ACLE feature macros before including <arm_neon.h>, so that it would define the intrinsics I wanted. Now I'm enabling interesting architecture features in the normal way, on the compiler command line, there's no need for that kind of trick: the right feature macros are already defined and <arm_neon.h> does the right thing. Another change in this reorganisation is that I've stopped assuming there's just one hardware implementation per platform. Previously, the accelerated vtables were called things like sha256_hw, and varied between FOO-NI and NEON depending on platform; and the selection code would simply ask 'is hw available? if so, use hw, else sw'. Now, each HW acceleration strategy names its vtable its own way, and the selection vtable has a whole list of possibilities to iterate over looking for a supported one. So if someone feels like writing a second accelerated implementation of something for a given platform - for example, I've heard you can use plain NEON to speed up AES somewhat even without the crypto extension - then it will now have somewhere to drop in alongside the existing ones.
2021-04-19 05:42:12 +00:00
bool platform_sha512_neon_available(void)
Hardware-accelerated SHA-512 on the Arm architecture. The NEON support for SHA-512 acceleration looks very like SHA-256, with a pair of chained instructions to generate a 128-bit vector register full of message schedule, and another pair to update the hash state based on those. But since SHA-512 is twice as big in all dimensions, those four instructions between them only account for two rounds of it, in place of four rounds of SHA-256. Also, it's a tighter squeeze to fit all the data needed by those instructions into their limited number of register operands. The NEON SHA-256 implementation was able to keep its hash state and message schedule stored as 128-bit vectors and then pass combinations of those vectors directly to the instructions that did the work; for SHA-512, in several places you have to make one of the input operands to the main instruction by combining two halves of different vectors from your existing state. But that operation is a quick single EXT instruction, so no trouble. The only other problem I've found is that clang - in particular the version on M1 macOS, but as far as I can tell, even on current trunk - doesn't seem to implement the NEON intrinsics for the SHA-512 extension. So I had to bodge my own versions with inline assembler in order to get my implementation to compile under clang. Hopefully at some point in the future the gap might be filled and I can relegate that to a backwards-compatibility hack! This commit adds the same kind of switching mechanism for SHA-512 that we already had for SHA-256, SHA-1 and AES, and as with all of those, plumbs it through to testcrypt so that you can explicitly ask for the hardware or software version of SHA-512. So the test suite can run the standard test vectors against both implementations in turn. On M1 macOS, I'm testing at run time for the presence of SHA-512 by checking a sysctl setting. You can perform the same test on the command line by running "sysctl hw.optional.armv8_2_sha512". As far as I can tell, on Windows there is not yet any flag to test for this CPU feature, so for the moment, the new accelerated SHA-512 is turned off unconditionally on Windows.
2020-12-24 11:40:15 +00:00
{
#if defined HWCAP_SHA512
return getauxval(AT_HWCAP) & HWCAP_SHA512;
#elif defined HWCAP2_SHA512
return getauxval(AT_HWCAP2) & HWCAP2_SHA512;
#elif defined __APPLE__
Add CPU feature checks on M1 macOS. I booted my M1 Mac into macOS rather than Asahi for the first time in a while, and discovered that an OS update seems to have added some sysctl flags indicating the presence of the CPU extensions that I previously knew of no way to check for! Added them checks to arm_arch_queries.c, though I've also retained backwards compat with the previous OS version which didn't have them at all.
2022-08-16 17:39:12 +00:00
/* There are two sysctl flags for this, apparently invented at
* different times. Try both, falling back to the older one. */
SysctlResult res = test_sysctl_flag("hw.optional.arm.FEAT_SHA512");
if (res != SYSCTL_MISSING)
return res == SYSCTL_ON;
res = test_sysctl_flag("hw.optional.armv8_2_sha512");
return res == SYSCTL_ON;
Hardware-accelerated SHA-512 on the Arm architecture. The NEON support for SHA-512 acceleration looks very like SHA-256, with a pair of chained instructions to generate a 128-bit vector register full of message schedule, and another pair to update the hash state based on those. But since SHA-512 is twice as big in all dimensions, those four instructions between them only account for two rounds of it, in place of four rounds of SHA-256. Also, it's a tighter squeeze to fit all the data needed by those instructions into their limited number of register operands. The NEON SHA-256 implementation was able to keep its hash state and message schedule stored as 128-bit vectors and then pass combinations of those vectors directly to the instructions that did the work; for SHA-512, in several places you have to make one of the input operands to the main instruction by combining two halves of different vectors from your existing state. But that operation is a quick single EXT instruction, so no trouble. The only other problem I've found is that clang - in particular the version on M1 macOS, but as far as I can tell, even on current trunk - doesn't seem to implement the NEON intrinsics for the SHA-512 extension. So I had to bodge my own versions with inline assembler in order to get my implementation to compile under clang. Hopefully at some point in the future the gap might be filled and I can relegate that to a backwards-compatibility hack! This commit adds the same kind of switching mechanism for SHA-512 that we already had for SHA-256, SHA-1 and AES, and as with all of those, plumbs it through to testcrypt so that you can explicitly ask for the hardware or software version of SHA-512. So the test suite can run the standard test vectors against both implementations in turn. On M1 macOS, I'm testing at run time for the presence of SHA-512 by checking a sysctl setting. You can perform the same test on the command line by running "sysctl hw.optional.armv8_2_sha512". As far as I can tell, on Windows there is not yet any flag to test for this CPU feature, so for the moment, the new accelerated SHA-512 is turned off unconditionally on Windows.
2020-12-24 11:40:15 +00:00
#else
return false;
#endif
}
Arm: turn on PSTATE.DIT if available and needed. DIT, for 'Data-Independent Timing', is a bit you can set in the processor state on sufficiently new Arm CPUs, which promises that a long list of instructions will deliberately avoid varying their timing based on the input register values. Just what you want for keeping your constant-time crypto primitives constant-time. As far as I'm aware, no CPU has _yet_ implemented any data-dependent optimisations, so DIT is a safety precaution against them doing so in future. It would be embarrassing to be caught without it if a future CPU does do that, so we now turn on DIT in the PuTTY process state. I've put a call to the new enable_dit() function at the start of every main() and WinMain() belonging to a program that might do cryptography (even testcrypt, in case someone uses it for something!), and in case I missed one there, also added a second call at the first moment that any cryptography-using part of the code looks as if it might become active: when an instance of the SSH protocol object is configured, when the system PRNG is initialised, and when selecting any cryptographic authentication protocol in an HTTP or SOCKS proxy connection. With any luck those precautions between them should ensure it's on whenever we need it. Arm's own recommendation is that you should carefully choose the granularity at which you enable and disable DIT: there's a potential time cost to turning it on and off (I'm not sure what, but plausibly something of the order of a pipeline flush), so it's a performance hit to do it _inside_ each individual crypto function, but if CPUs start supporting significant data-dependent optimisation in future, then it will also become a noticeable performance hit to just leave it on across the whole process. So you'd like to do it somewhere in the middle: for example, you might turn on DIT once around the whole process of verifying and decrypting an SSH packet, instead of once for decryption and once for MAC. With all respect to that recommendation as a strategy for maximum performance, I'm not following it here. I turn on DIT at the start of the PuTTY process, and then leave it on. Rationale: 1. PuTTY is not otherwise a performance-critical application: it's not likely to max out your CPU for any purpose _other_ than cryptography. The most CPU-intensive non-cryptographic thing I can imagine a PuTTY process doing is the complicated computation of font rendering in the terminal, and that will normally be cached (you don't recompute each glyph from its outline and hints for every time you display it). 2. I think a bigger risk lies in accidental side channels from having DIT turned off when it should have been on. I can imagine lots of causes for that. Missing a crypto operation in some unswept corner of the code; confusing control flow (like my coroutine macros) jumping with DIT clear into the middle of a region of code that expected DIT to have been set at the beginning; having a reference counter of DIT requests and getting it out of sync. In a more sophisticated programming language, it might be possible to avoid the risk in #2 by cleverness with the type system. For example, in Rust, you could have a zero-sized type that acts as a proof token for DIT being enabled (it would be constructed by a function that also sets DIT, have a Drop implementation that clears DIT, and be !Send so you couldn't use it in a thread other than the one where DIT was set), and then you could require all the actual crypto functions to take a DitToken as an extra parameter, at zero runtime cost. Then "oops I forgot to set DIT around this piece of crypto" would become a compile error. Even so, you'd have to take some care with coroutine-structured code (what happens if a Rust async function yields while holding a DIT token?) and with nesting (if you have two DIT tokens, you don't want dropping the inner one to clear DIT while the outer one is still there to wrongly convince callees that it's set). Maybe in Rust you could get this all to work reliably. But not in C! DIT is an optional feature of the Arm architecture, so we must first test to see if it's supported. This is done the same way as we already do for the various Arm crypto accelerators: on ELF-based systems, check the appropriate bit in the 'hwcap' words in the ELF aux vector; on Mac, look for an appropriate sysctl flag. On Windows I don't know of a way to query the DIT feature, _or_ of a way to write the necessary enabling instruction in an MSVC-compatible way. I've _heard_ that it might not be necessary, because Windows might just turn on DIT unconditionally and leave it on, in an even more extreme version of my own strategy. I don't have a source for that - I heard it by word of mouth - but I _hope_ it's true, because that would suit me very well! Certainly I can't write code to enable DIT without knowing (a) how to do it, (b) how to know if it's safe. Nonetheless, I've put the enable_dit() call in all the right places in the Windows main programs as well as the Unix and cross-platform code, so that if I later find out that I _can_ put in an explicit enable of DIT in some way, I'll only have to arrange to set HAVE_ARM_DIT and compile the enable_dit() function appropriately.
2024-12-19 08:47:08 +00:00
bool platform_dit_available(void)
{
#if defined HWCAP_DIT
return getauxval(AT_HWCAP) & HWCAP_DIT;
#elif defined HWCAP2_DIT
return getauxval(AT_HWCAP2) & HWCAP2_DIT;
#elif defined __APPLE__
SysctlResult res = test_sysctl_flag("hw.optional.arm.FEAT_DIT");
/* As above, treat 'missing' as enabled */
return res != SYSCTL_OFF;
#else
return false;
#endif
}
New library-style 'utils' subdirectories. Now that the new CMake build system is encouraging us to lay out the code like a set of libraries, it seems like a good idea to make them look more _like_ libraries, by putting things into separate modules as far as possible. This fixes several previous annoyances in which you had to link against some object in order to get a function you needed, but that object also contained other functions you didn't need which included link-time symbol references you didn't want to have to deal with. The usual offender was subsidiary supporting programs including misc.c for some innocuous function and then finding they had to deal with the requirements of buildinfo(). This big reorganisation introduces three new subdirectories called 'utils', one at the top level and one in each platform subdir. In each case, the directory contains basically the same files that were previously placed in the 'utils' build-time library, except that the ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c, winmisc.c, winmiscs.c, winutils.c) have been split up into much smaller pieces.
2021-04-17 14:22:20 +00:00
#else /* defined __arm__ || defined __aarch64__ */
/*
* Include _something_ in this file to prevent an annoying compiler
* warning, and to avoid having to condition out this file in
* CMakeLists. It's in a library, so this variable shouldn't end up in
* any actual program, because nothing will refer to it.
*/
const int arm_arch_queries_dummy_variable = 0;
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