Thanks for the explanations. In the code I am working with, I see: $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c unsigned long *OPENSSL_ia32cap_loc(void)
You may want to verify it. I happen to be using features introduced for testing and debugging, without knowing it. For debatable reasons, but it is my assignment to avoid aes-ni instructions. Maybe I will have to adapt openssl slightly, for instance making the capability vectors global (instead of hidden); or not to use the EVP interfaces. ________________________________ From: Andy Polyakov via RT <r...@openssl.org> Sent: Friday, June 17, 2016 3:32:19 PM To: Loic Etienne Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc > Two more observations. > > OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not > fitting into the expected integer size being zeroed. I do not know if it is > practically relevant, but it is strange that a read has side effects. It > would be a good reason for dedicated, architecture independent setters and > getters. > > The documentation > (https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap.html<https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html>) > says: > unsigned int *OPENSSL_ia32cap_loc(void) > it should say: > unsigned long *OPENSSL_ia32cap_loc(void) > like in openssl-1.0.2h/crypto/crypto.h No. It was 'int' upon initial release of 1.0.0 and has to remain same throughout all 1.0.x releases. Mentioned zeroing also has everything to do with it, i.e. with maintaining backward compatible behaviour within line of binary compatible releases. Rationale is that application should be given same control throughout *all* 1.0.x releases. Or in other words *if* application chooses to manipulate capability vector it will have same granularity as in 1.0.0. Note that in master branch words beyond 1st are not zeroed, don't have to. One can argue that it could be re-declared as long in master. Well, that declaration is shared between 32- and 64-bit builds, and having long would introduce ambiguity. Yes, one can argue that it's already ambiguous since OPENSSL_ia32cap.pod effectively describes 64-bit values. One has to recognize that original reason for exposing OPENSS_ia32cap_loc() was that binary *could* end up in situation when processor capability vector doesn't match OS capability. More specifically cpuid could say "this is SSE2-capable processor" but attempt to perform SSE2 operation on %xmm register could trigger invalid instruction exception nevertheless. Note that this can't happen with later register extensions like %ymm and %zmm, because one can detect even OS support. But back to OPENSSL_ia32cap_loc in master context. Actually one can as well proclaim that such old systems are no longer supported and omit OPENSSL_ia32cap_loc altogether. Naturally leaving setting environment variable alone as the only way to affect result of capability detection. This is really meant to be used for overly specific testing and debugging. And for this reason it doesn't really have to be pretty... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
