[ASAN] Support for baremetal platform

429 views
Skip to first unread message

Cupertino Miranda

unread,
Jun 6, 2016, 5:17:00 AM6/6/16
to address-sanitizer
Hi all, 

I am part of the team developing the GNU toolchain for the ARC architecture from Synopsys. Our toolchain supports two platforms:
  - Baremetal - with libc support through newlib,
  - Linux - currently using uClibc (glibc is being ported).

Recently, we have noticed an increasingly interest in your tools from our customers/users and we would very much like to contribute with a port to our architecture.

From all I read, it seems that support for any of the already supported platforms should be relatively easy, considering that instrumentation occurs early in a generic phase (at least in GCC). 
So we don't expect any big difficulty porting it to Linux.

However, our problem and my questions are:
 - How difficult or what would be the expected challenges making the AddressSanitizer support a baremetal environment?
 - Is an operating system a real requirement?
 - Is anyone else working on this?

Best regards,
Cupertino

Dmitry Vyukov

unread,
Jun 6, 2016, 5:25:54 AM6/6/16
to address-sanitizer
Hi Cupertino,

We've ported asan to Linux kernel:
https://www.kernel.org/doc/Documentation/kasan.txt
The main difficulty is mapping direct shadow memory. Reporting and
interception of non-instrumented libraries is more or less trivial.

We've also ported tsan to Linux kernel:
https://github.com/google/ktsan
It's far more challenging. Basically you need to rewrite all race
detection logic and hook into scheduler and all synchronization
primitives.

Nobody is working on a baremetal implementation as far as I can tell.

Cupertino Miranda

unread,
Jun 6, 2016, 6:15:03 AM6/6/16
to address-sanitizer
Hi Dmitry,

At the moment, for baremetal, I care only about libasan.
Considering that we do not have virtual memory addressing we will need to hand set the address range and shadow memory through linker scripts.

One of the difficulties I am having though the code is how to remove the dependencies on system calls.
Any suggestion you can give on that respect?

Theoretically, nothing in libasan looks like it needs system calls or even an OS. However, code suggests that it depends on it. Am I wrong, and the OS is really a requirement?

Dmitry Vyukov

unread,
Jun 6, 2016, 6:19:05 AM6/6/16
to address-sanitizer
On Mon, Jun 6, 2016 at 12:15 PM, Cupertino Miranda
<cupertin...@gmail.com> wrote:
> Hi Dmitry,
>
> At the moment, for baremetal, I care only about libasan.
> Considering that we do not have virtual memory addressing we will need to
> hand set the address range and shadow memory through linker scripts.
>
> One of the difficulties I am having though the code is how to remove the
> dependencies on system calls.
> Any suggestion you can give on that respect?
>
> Theoretically, nothing in libasan looks like it needs system calls or even
> an OS. However, code suggests that it depends on it. Am I wrong, and the OS
> is really a requirement?

What exactly system calls do you mean?

We developed it assuming an OS under us. I guess it should be possible
to port it to baremetal, but it is just not what we assumed so it may
require considerable changes.

I think on baremetal you don't need most of the interceptors (e.g. for
syscalls). And you can also strip lots of optional functionality like
background thread and symbolizer.
> --
> You received this message because you are subscribed to the Google Groups
> "address-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to address-saniti...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages