> when running my application under valgrind, i get a bazillion of > different reports of this type: > > ... > ==9583== Uninitialised value was created by a stack allocation > ==9583== at 0x54AD3F7: aesni_cbc_encrypt (aesni-x86_64.s:2081) > > reading the code reveals that this is right after a return from a > function. preliminary discussion with the valgrind folks suggests that > this code may be violating the ABI by storing data below the reserved > stack frame. apart from making valgrind mostly useless, this is very bad > idea, as asynchronously delivered signals may mess up the stack.
No, they won't. Quoting ABI specification: "The 128-byte area beyond the location pointed to by %rsp is considered to be reserved and shall not be modified by signal or interrupt handlers. Therefore, functions may use this area for temporary data that is not needed across function calls. In particular, leaf functions may use this area for their entire stack frame, rather than adjusting the stack pointer in the prologue and epilogue. This area is known as the red zone." One can argue that the way the red zone is used in this particular case is not in formal compliance with specification, but how would it be different from pulling return address, pushing it to stack and performing jump instead of call (because jumps are not regulated by ABI specification)? Well, it's rhetorical question. The point is that it's not bug (at least in sense that it's not result of oversight and is totally intentional) and the code is actually safe. > is it possible to suppress the use of this (over-)optimized cipher > routine via the environment/configuration? You can disable AES-NI code by setting OPENSSL_ia32cap environment variable to ~0x200000000000000. You can re-configure with no-asm argument. You can replace your copy of aesni-x86_64.pl with latest version from development branch. The latter was modified to operate without red zone, because there was request to make the module work in kernel, which is compiled with -mno-red-zone. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
