> This initialization is used for selecting a code path that would use ADCX/ADOX > instructions when the processor supports them. The outcome depends only on > the appropriate CPUID bits. Therefore, there is no “thread-safe” issue (because > any thread would select the same path).
I understand that that's the idea, and would have considered the code to be safe a while ago (and might have written the initialization just like that), but actually compiler transformations that are legal with the C memory model could break this. See http://static.usenix.org/event/hotpar11/tech/final_files/Boehm.pdf for inspiration. >> Your ec_p256_points_mul implementation is much worse than necessary when then input comprises many points > Indeed right. However, this patch is intended to optimize ECDSA sign/verify (and ECDH). This usage does not require adding more than a single point. Sure, but there's no compelling reason to make the other (rarer) use cases slower. Also, adapting the addition/subtraction chain used in the existing crypto/ec/ecp_nistp256.c (modified Booth encoding instead of unsigned windows) could make the new implementation even faster. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
