GNU Arm Embedded Toolchain

Support of address sanitizer in GCC ARM Embedded 4.9?

Asked by Tamas Kleiber

Hi,

 I have tried to enable the address sanitizer feature of GCC in Rlease GCC ARM Embedded 4.9 by adding the -fsanitize=address option to my build command.

I used a very simple "int main(){ return 0;}" C source file and the following command: "arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Og main.c -lc -lnosys -fsanitize=address". The linker throws the following error message: "cannot find -lasan".

If I try to link in the static library version of libasan.a by adding the -static-libasan linker option I get the following error message: "arm-none-eabi-gcc: error: libsanitizer.spec: No such file or directory".

Does this mean that the address sanitizer feature is not supported?

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Joey Ye
Solved:
Last query:
Last reply:
Revision history for this message
Best Joey Ye (jinyun-ye) said : 		#1

Address sanitizer is not supported so far.

On Wed, Dec 10, 2014 at 9:06 PM, Tamas Kleiber <
<email address hidden>> wrote:

> New question #258875 on GCC ARM Embedded:
> https://answers.launchpad.net/gcc-arm-embedded/+question/258875
>
> Hi,
>
> I have tried to enable the address sanitizer feature of GCC in Rlease GCC
> ARM Embedded 4.9 by adding the -fsanitize=address option to my build
> command.
>
> I used a very simple "int main(){ return 0;}" C source file and the
> following command: "arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -Og main.c
> -lc -lnosys -fsanitize=address". The linker throws the following error
> message: "cannot find -lasan".
>
> If I try to link in the static library version of libasan.a by adding the
> -static-libasan linker option I get the following error message:
> "arm-none-eabi-gcc: error: libsanitizer.spec: No such file or directory".
>
> Does this mean that the address sanitizer feature is not supported?
>
>
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Revision history for this message
Tamas Kleiber (kleiber-tamas) said : 		#2

Thanks Joey Ye, that solved my question.

Revision history for this message
Terry Guo (terry.guo) said : 		#3

Hi Tamas,

What benefit will we have if we enable this feature to MCU project? Since MCU project tends to have less resources, does this feature occupies more resources? Thanks for your help.

Revision history for this message
Tamas Kleiber (kleiber-tamas) said : 		#4

Hi Terry,

 according to mainline GCC release documentation, the address sanitizer had been ported to ARM in GCC 4.9: https://gcc.gnu.org/gcc-4.9/changes.html . Quote: "AddressSanitizer, a fast memory error detector, is now available on ARM.". So I thought that it is available also for Cortex-M series, but as it turns out under ARM they meant only Android ARM...

On the official clang project page, http://clang.llvm.org/docs/AddressSanitizer.html, we can read that the following error types are detected by the feature:
    Out-of-bounds accesses to heap, stack and globals
    Use-after-free
    Use-after-return (to some extent)
    Double-free, invalid free
    Memory leaks (experimental)

Impressive list in my opinion. Even though robust interface design, a good static analyser and properly done interface level unit testing executed on a simulated target using code compiled with the target's compiler could catch most of these errors, out of my experience I could say that from 50 engineers 5 could write proper MC/DC unit tests and unfortunately I have to debug someone else's code tracking down code runaways due to buffer overflows each month.

On the clang project page it is implied that enabling the address sanitizer results in a typical slowdown of 2x.

Based on the address sanitizer algorithm documented here: https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm , the code size overhead is about 40 bytes per pointer access, RAM overhead is 1 to 8 so for 8K RAM additional 1K RAM would be needed. Still, on simulated targets through qemu, this would not be a problem at all and on real targets in most cases MCUs have scalability and development could be done on an MCU which has several times more flash/ram than on the real final target MCU...

Even if only a subset of the functionality would be available it would be a very big help. Most of the code runaways I have to analyse comes from smashed stacks caused by local buffer overflows/corruptions. If the compiler would inject a stack canary into the function prologue to catch stack smashing issues/attacks before returning from a function would already be a big help for me.

Best regards,
 Tamas

_

Revision history for this message
Joe Gorse (jhgorse) said : 		#5

What would it take to bring libasan to cortex-M? Is there a value to using it on completely statically allocated systems?

Cheers,
Joe