Memory corruptions can be dealt in two approaches:
- Avoid/Mitigate before they manifest:
- Code review
- Static Analysis helps in detecting memory corruptions even before tests are run. Apart from traditional static analysis tools, I discussed an additional mechanism - Stack Usage Static Analysis to deal with uspace/kspace stack overflow & corruption.
All memory corruptions can't be avoided proactively. Static analysis and code reviews can't be comprehensive due to diminishing returns rule. Also, some memory corruptions can't be caught with static analysis because they build dynamically during run time. So, memory corruptions creep into the code during initial stages of development as well as in later stages.
This creates the need to detect memory corruptions & troubleshoot the source of memory corruptions.
- Effectively troubleshoot after they manifest: Debugging memory corruptions requires three major solutions:
- Hardening tools against memory corruptions so that system is brought down as early after a memory corruption happens. This hardening prevents security vulnerabilities and incorrect functionality. Also, such early detection provides a better opportunity to troubleshoot memory corruptions offline by reducing the extent of corrupted memory. Some of this hardening can be enabled by default while the rest can be enabled in debugging environments alone.
- Live debugging tools that can be enabled to efficiently corner down the code causing memory corruption.
- Offline debugging tools that can help root cause the code causing memory corruption.
In separate posts, I have covered various features/tools available in linux in the above areas:
- Kernel Space memory corruptions:
- Heap Corruption: To detect kernel space memory corruptions, I used slub_debug in the past. slub_debug is not just a memory corruption detection tool, but can also detect other run-time heap memory errors such as illegal memory operations(double free) etc. Here are my posts on slub_debug:
- Stack Corruption: Two basic approaches should be followed to effectively troubleshoot stack overflows. First, proactively log information about excessive stack usage building up towards stack overflows. For this reason, monitor usage at runtime and report any critical stack usage as a log message. Some of the monitoring tools can only be enabled only in debug environment. Second, to avoid contagious corruptions/mis-functionality resulting from initial stack corruption, harden against stack corruptions so that stack corruptions are detected as early as possible & the application/system is aborted for further analysis.
- User space memory corruptions:
- Heap Corruption: To detect user space memory corruptions, I used Valgrind's memcheck in the past. memcheck is not just a memory corruption detection tool, but can also detect other run-time heap memory errors such as memory leaks, illegal memory operations (double free) etc. Here are my posts on Valgrind:
- Stack Corruption: The stack corruption ideas discussed in Kernel space above are applicable even for user space applications.
Hope this helps.
No comments:
Post a Comment