> In CVS OPENSSL_1_0_1-stable branch, on a ILP32 target (where > sizeof(long) == 4), the function OPENSSL_ia32cap_loc() is clearing > upper bits of capability vector which disable support for SSE3, AES-NI, > etc... > > A user program not reading/writing OPENSSL_ia32cap before using other > encryption, decryption or digest functions would benefit from SSE3, > AES-NI and such if available. But after calling the function, those > support would be disabled.
It's conscious choice to ensure binary compatibility. Reasoning is that libcrypto should behave consistently with 1.0.0 release toward programs that manipulate the value. It's possible to control complete vector through environment variable and I just back-ported support for ~0x????. > In CVS HEAD, the problem does not exist. OPENSSL_ia32cap_loc() returns a > pointer to int instead of a pointer to long (this is an ABI change > between 1.0.1 and HEAD), and doesn't clear upper bits. > > The solution currently in HEAD is not perfect since it doesn't allow > user program to read upper bits of the capability vector. Worse, it > doesn't allow it to write upper bits of the vector, for example to > disable some capabilities. Well, what prevents you from addressing (OPENSSL_ia32cap_loc())[1]? But yes, admittedly the interface is not perfect. Maybe bit-oriented interface like OPENSSL_ia32cap_bit_[get|set]() accepting bit position would be more appropriate. In which case attempt to address beyond current width would simply be no-op. On the other hand one can as well argue that there shouldn't be a way to manipulate it programmatically, controlling it through environment variable suffices. At the very least the only meaningful usage is to a) perform testing; b) disable XMM code paths (because there is no good way to detect it by looking at cpuid flags). ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
