> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is > hidden, I still have to try over environment variables, which are not > as flexible for arm as for x86). > > > Anyway, it would be helpful to exclude hardware aes instructions at > compile-time: > > 1) Runtime checking is error prone (openssl and code using openssl > evolve)
How is it error-prone? Or more specifically have you ever ran into situation when it was *detected* incorrectly so that it resulted in application *crash*? > 2) Proving to a customer (or convincing myself) that no such > instructions will ever be used is much easier if such instructions > are not even compiled Then why just aes instructions? There is a number of code-paths that are selected at run-time that are dependent on processor capability detection. If aes instructions are considered "too fancy", there is no reason to consider *any* alternative code path as less "fancy". > I guess that some of the already existing no-xxx configuration > options have been introduced for similar reasons. no-asm. I'd argue that this ticket can be closed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
