> Those numbers are CPU time; only interesting relative to each other. > > Is a 2-4x speedup for RSA decryption consistent with what others have > seen? > > We are trying to evaluate whether to go forward with assembly optimized > versions of the library. Obviously, if there was no downside, we'd > choose the optimized version. But on Windows, there is a significant > disadvantage: the assembly optimizations preclude building the library > with the /SafeSEH linker option, an important security countermeasure.
First reaction is "how come?" Indeed, safe exception handling is pretty much about registering handlers in a special read-only segment, and if a module [such as any given OpenSSL assembler module] does not setup any exception handlers, then how come can it prevent linking? But it's apparently a fact... So I wondered what does it take to make linker accept an .obj module without above mentioned segment for /safeseh processing? As it turns out presence of absolute symbol named @feat.00 with value of 1. In other words, if one can make nasm emit such symbol into module's symbol table, then it's apparently possible to link this module with /safeseh. As matter of experiment[!] open crypto/perlasm/x86nasm.pl, locate ::file subroutine and prepend 'section .text code align=64' as following: absolute 1 @feat.00: section .text code align=64 and recompile... One can argue whether or not it's appropriate to hard-code such symbol into nasm, so that all modules come out seh-"capable." But it's probably would be as appropriate to provide support for handler registration, e.g. through safeseh or similar assembler directive... A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
