On 64-bit (amd64/x86_64) Redhat / CentOS 6.x (kernel 2.6.32), vanilla, I have experienced an issue with the execve stub. While indeed we can hook stub_execve, record the arguments e.g. the program being called, the environment, the cli arguments, etc. and programs will run fine there are others that outright crash. The stack apparently gets damaged in some way and I suppose it has something to do with the way that we hook it, do our own things on the stack with our hook function, and then return to stub_exec. Something certainly is not working as expected.
This is evident when the 'psmonko.ko' module is loaded.
Programs that I have found to fail are the linker during the linking phase of compilation as well as gdb.
To replicate this, load psmonko.ko (in 1-sys_call_table/psmon) and run a few regular programs and see the module's output in /var/log/messgaes; everything is well and good. However, then run 'gdb' or a 'make'; or run gcc with linking an application as the goal, such as gcc -o test test.c. You will get segmentation faults. I have the core dump and then proceed to unload the module, load the core dump on the binary, and see statements/warnings about there being stack issues.
Any idea how to get around this? Do we need to do something to the stack in our execve stugb hook prior to jumping to to the original?
Thanks
On 64-bit (amd64/x86_64) Redhat / CentOS 6.x (kernel 2.6.32), vanilla, I have experienced an issue with the execve stub. While indeed we can hook stub_execve, record the arguments e.g. the program being called, the environment, the cli arguments, etc. and programs will run fine there are others that outright crash. The stack apparently gets damaged in some way and I suppose it has something to do with the way that we hook it, do our own things on the stack with our hook function, and then return to stub_exec. Something certainly is not working as expected.
This is evident when the 'psmonko.ko' module is loaded.
Programs that I have found to fail are the linker during the linking phase of compilation as well as gdb.
To replicate this, load psmonko.ko (in 1-sys_call_table/psmon) and run a few regular programs and see the module's output in /var/log/messgaes; everything is well and good. However, then run 'gdb' or a 'make'; or run gcc with linking an application as the goal, such as gcc -o test test.c. You will get segmentation faults. I have the core dump and then proceed to unload the module, load the core dump on the binary, and see statements/warnings about there being stack issues.
Any idea how to get around this? Do we need to do something to the stack in our execve stugb hook prior to jumping to to the original?
Thanks