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 ________________________________ From: Loic Etienne Sent: Wednesday, June 15, 2016 10:17:17 AM To: r...@openssl.org Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc Identifying the bits relevant to openssl for each architecture and making them available through architecture-independent functions (getter and setters) would be very convenient, indeed. At the risk that future architectures do not fit into the pattern defined today. If this approach is implemented, I suggest a copy of original capability vector to be kept, for the setter to fail if a bit is tentatively set on an unsuitable processor (otherwise, subsequent cryptographic operations affected by the bit in question would fail anyway). Thus a setter could return the previous value (0 or 1) on success, and -1 on failure. I think that implementing the architecture specific functions suggested in this ticket is easy and already useful. Defining architecture-independent functions probably requires more hard thinking, and could be done in a later step. ________________________________ From: Salz, Rich via RT <r...@openssl.org> Sent: Tuesday, June 14, 2016 6:41:02 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 Doesn't it make more sense to have a single API that returns the platform-specific flags? -- 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
