A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.8.0 2023-05-27T09:18:17+00:00 2023-05-27T09:18:17+00:00 jsing 2023-05-27T09:18:17+00:00 urn:sha1:fce75c36c6fda1fa1488c600abe6490c27e90d75 This recommits r1.37 of sha512.c, however uses uint8_t * instead of void * for the crypto_load_* functions and primarily uses const uint8_t * to track input, only casting to const SHA_LONG64 * once we know that it is suitably aligned. This prevents the compiler from implying alignment based on type. Tested by tb@ and deraadt@ on platforms with gcc and strict alignment. ok tb@ 2023-05-19T00:54:28+00:00 deraadt 2023-05-19T00:54:28+00:00 urn:sha1:3dc51b1807e9a69624721300010e6e6ce16d5709 2023-05-17T06:37:14+00:00 jsing 2023-05-17T06:37:14+00:00 urn:sha1:5d9c22eaef33c903e296cd1e7e2c0592e3286672 All assembly implementations are required to perform their own alignment handling. In the case of the C implementation, on strict alignment platforms, unaligned data will be copied into an aligned buffer. However, most platforms then perform byte-by-byte reads (via the PULL64 macros). Instead, remove SHA512_BLOCK_CAN_MANAGE_UNALIGNED_DATA and alignment handling to sha512_block_data_order() - if the data is aligned then simply perform 64 bit loads and then do endian conversion via be64toh(). If the data is unaligned then use memcpy() and be64toh() (in the form of crypto_load_be64toh()). Overall this reduces complexity and can improve performance (on aarch64 we get a ~10% performance gain with aligned input and about ~1-2% gain on armv7), while the same movq/bswapq is generated for amd64 and movl/bswapl for i386. ok tb@ 2023-05-16T07:04:57+00:00 jsing 2023-05-16T07:04:57+00:00 urn:sha1:1b444f75a951b233b38acfea196d180bbb134432 Avoid reach around and initialisation outside of the macro, cleaning up the call sites to remove the initialisation. Use a T2 variable to more closely follow the documented algorithm and remove the gorgeous compound statement X = Y += A + B + C. There is no change to the clang generated assembly on aarch64. ok tb@ 2023-05-12T10:10:55+00:00 jsing 2023-05-12T10:10:55+00:00 urn:sha1:a16324e54a8b77c1b2e74836e3e7d439d2ed63fd We currently have three C implementations for SHA-512 - a version that is optimised for CPUs with minimal registers (specifically i386), a regular implementation and a semi-unrolled implementation. Testing on a ~15 year old i386 CPU, the fastest version is actually the semi-unrolled version (not to mention that we still currently have an i586 assembly implementation that is used on i386 instead...). More decent architectures do not seem to care between the regular and semi-unrolled version, presumably since they are effectively doing the same thing in hardware during execution. Remove all except the semi-unrolled version. ok tb@ 2023-04-25T19:32:19+00:00 tb 2023-04-25T19:32:19+00:00 urn:sha1:241d43b2b24344a3196eb6c46c3513c7f5a69a13 2023-04-25T15:47:29+00:00 tb 2023-04-25T15:47:29+00:00 urn:sha1:ce06a4ca1e5719ee36f665b7473fb078d8d34a0f 2023-04-25T04:42:26+00:00 deraadt 2023-04-25T04:42:26+00:00 urn:sha1:f56bc15e44b93e564d434a7d0b5c8f837812aac3 ok jsing, and kind of tb an earlier version 2023-04-16T17:06:19+00:00 jsing 2023-04-16T17:06:19+00:00 urn:sha1:4b973a635aefcde8476827db5990f5afeb2f858a ok tb@ 2023-04-16T16:42:06+00:00 jsing 2023-04-16T16:42:06+00:00 urn:sha1:f4810c6bc277cfaab018eeaf4a4d06bb68addf21 ok tb@