1) Openssl works correctly (no crash, correct detection), as far as I can judge. By error-prone I mean, very defensively, that I (or others) could make a mistake, or that future versions of openssl could not work exactly the same way.
2) I would agree with your argumentation. But some customers want this anti-feature (no aes-ni), arguing that exactly those instruction are not trustworthy. And the customer is always right. There are already two similar options (which inspired the suggested no-hw-aes): no-hw, no-engines. But none of them excludes aes instructions, which is a bit misleading. Perhaps the documentation could be more explicit about that. no-asm is a possibility, indeed. At the price of the bit-slicing aes implementation and perhaps of some performance. A trade-off. But I understand that openssl cannot consider each and every wish. Such a no-hw-aes configuration option may be useful (at least for selling) to many other people, or not. Up to your judgment. Thanks for your attention anyway. ________________________________ From: Andy Polyakov via RT <r...@openssl.org> Sent: Friday, June 17, 2016 2:46:41 PM To: Loic Etienne Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes > 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 -- 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
