> 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.
Thanks, this seems very promising. Did you figure this out by reverse engineering or did you find some documentation? Rolling this into the default build on Windows (along with the /SafeSEH, /NXCOMPAT, and /DYNAMICBASE flags) would probably be a good idea. John ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
