Hello again! The third and final phase of GSoC is coming to an end and I’m glad that I made it this far. In this blog post, I’d like to outline the work done in the last two weeks.
Compiler’s ASan instrumentation cannot insert
asan_store memory checks in the memory functions like
memcpy. This is because these functions are written in assembly.
While Linux kernel replaces these functions with their variants which are written in C, I took a different approach.
In coreboot, the assembly instructions for these memory functions are embedded into C code using GNU’s
asm extension. This provided me with an opportunity to use the ASan library function named
check_memory_region to manually check the memory state before performing each of these operations. At the start of each function, I added the following code snippet:
#if (ENV_ROMSTAGE && CONFIG(ASAN_IN_ROMSTAGE)) || (ENV_RAMSTAGE && CONFIG(ASAN_IN_RAMSTAGE)) check_memory_region((unsigned long)src, n, false, _RET_IP_); check_memory_region((unsigned long)dest, n, true, _RET_IP_); #endif
Since I finished a little early with what I had proposed to deliver, Werner suggested that I should write documentation on ASan and I am happy that he did. When I read the intro of the documentation guidelines, I realized how a feature as significant as ASan might go unnoticed and unused by many if it lacks proper documentation.
In ASan documentation, I have tried my best to answer questions like how to use ASan, what kind of bugs can be detected, what devices are currently supported, and how ASan support can be added to other architectures like ARM or RISC-V.
In the end, I’d like to announce that ASan patches have been merged into the coreboot source tree. You can go ahead and make use of this debugging tool to look for memory corruption bugs in your code.