[openssl] openssl asynch_mode 使用libasan时的OOM问题
[classic_tong: https://www.cnblogs.com/hugetong/p/14231782.html]
概述
openssl支持async mode. 在定位越界问题时,我使用了libasan, 之后就OOM了, 能够看见在这个地方:
原因是因为, memset的size参数特别大, (程序本身的虚拟内存就占了很多, 随着memset的写入,会不断申请更多的真实内存,最后OOM ?? )
接下来将重点分析为什么size会这么大
使用
openssl 使用libasan的方法
config时,使用选项 enable-asan
./Configure --prefix=/root/debug/ shared enable-asan \ LDFLAGS="-Wl,-rpath,/root/debug/lib" \ linux-x86_64
用户程序使用libasan的方法:
因为我的程序是用来了openssl, 所以两边都要同时加, 实践过程中, 如果用户程序不加只在openssl上加是不行的.
LDFLAGS也要叫两个-f参数, 不然会coredump, 我也不知道为什么.
CFLAGS+=-fsanitize=address -fno-omit-frame-pointer LDFLAGS+= -lssl -lcrypto LDFLAGS+=-fsanitize=address -fno-omit-frame-pointer LDFLAGS+= -lasan
分析
一 libasan
libasan怎么检测longjmp API, 以下是gcc4.8.5里边的代码
大概意思是, gcc使用libasan之后, hock了longjmp, 在真正进入longjmp之前调用函数__asan_handle_no_return() 进行内存检测.
在该函数里, top是之前保存的调用栈的栈顶. &local_stack是取了临时变量的地址也就是当前使用的调用栈的栈底地址.
然后会memset, 把整个调用栈(maybe?) 写0, 而我当前出现的问题就是临时变量的地址没有取到pthread的调用栈的地址上.
所以两个一减, size就特别大.
我们知道调用栈的地址是0x7fff是正常的, 这个local_stack的0x609200值,很明显是不正常的, 从而导致了size不正常, 接下来继续分析
这个值为什么是这样的.
二 async
上文中调用栈的值的变化,主要是由api setcontext 导致的, 见如下:
上文中提到的OOM复现过程是这样的, openssl进入SSL_accept函数之后, 在61行进行了第一次上下文切换, 之后在第59行进行了如上文调用栈图片所示的,
有qatengine触发的第二次上下文切换. 于是进入了libasan的__asan_handle_no_return() 并触发OOM.
setcontext函数切换了整个调用栈的栈指针, 所以会有上文0x60开头的栈地址,而不是0x7f, 如下图的registers的rsp可见:
函数调用前:
函数调用后:
扩展
longjmp与setcontext都是用来做上下文切换的API, 功能可以相互替换.
setcontext之所以使用了新的地址,而不是就得0x7f地址, 推测是为了提高效率防止拷贝. 带来的一个隐形坏处是gdb不能继续单步执行, 单步执行的下一步就是它
切回来的时候, 继续使用gdb的方法是, 在即将切换的那个函数上加一个断点.
longjmp没有这个gdb的困扰问题, 推测它每次切换都会做一次栈拷贝.
此类API的主要用途: 实现协程, 实现信号处理, 实现异常处理.
