llvm dev - May 2018 - ASan port for Myriad RTEMS

On RAM...

You chose the 32-byte shadow granularity to reduce the RAM overhead,
but I am afraid this will actually increase it due to extra alignment
requirements,
especially if an average allocation on your typical application is small.

The pointers are 32-bit, right?
Given how RAM-constrained your environment is, maybe you should consider
something more like HWASAN instead of ASAN.
https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
But you may not have enough address bits. :(

--kcc



On Fri, May 4, 2018 at 3:10 PM Kostya Serebryany <kcc at google.com>
wrote:
> Hi Walter,
>
> I've done a first quick scan.
> Overall looks reasonable, but I'd like to try reducing the number of
newly
> introduced platform-specific ifs.
>
> Vitaly, please also take a look (once my initial comments are addressed).
>
> One outstanding issue is your problem with initialization vs checking,
> which requires you to insert so many ifs.
> Is there any chance you can avoid this?
> If you control the OS, surely you can do at least minimal initialization
> of the shadow at a proper moment...
>
> --kcc
>
> On Fri, May 4, 2018 at 2:00 PM Walter Lee via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I have ported ASan in LLVM to Myriad RTEMS, and I would like to
>> upstream the port.  Below is the design doc.  Feedback welcome.
>>
>>
>>
https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM
>>
>> The port is expected to work with modified versions of RTEMS and
>> newlib.  I have a git repo with changes to those projects, that I can
>> make available if there is interest.
>>
>> Here is the patch series:
>> https://reviews.llvm.org/D46451 [asan] Add instrumentation support for
>> Myriad
>> https://reviews.llvm.org/D46452 [sanitizer] Don't add
--export-dynamic
>> for
>> Myriad
>> https://reviews.llvm.org/D46453 [sanitizer] Add definitions for Myriad
>> RTEMS platform
>> https://reviews.llvm.org/D46454 [sanitizer] Trivial portion of the port
>> to
>> Myriad RTEMS
>> https://reviews.llvm.org/D46456 [asan] Add support for Myriad RTEMS
>> memory
>> map
>> https://reviews.llvm.org/D46457 [asan] Add a magic shadow value for
shadw
>> gap
>> https://reviews.llvm.org/D46459 [asan] On RTEMS, checks for asan_inited
>> before entering ASan run-time
>> https://reviews.llvm.org/D46461 [asan] Set flags appropriately for
RTEMS
>> https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to
>> be
>> reused by Myriad RTEMS
>> https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion
>> when
>> reporting Mmap failure
>> https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to
RTEMS
>> https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to
>> support
>> thread restart
>> https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack
>> to
>> be initialized during thread init
>> https://reviews.llvm.org/D46468 [asan] Add target-specific files for
>> Myriad
>> RTEMS port
>> https://reviews.llvm.org/D46469 [sanitizer] Port fast stack unwinder to
>> sparcv8
>>
>> Thanks,
>>
>> Walter
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180504/b1384239/attachment.html>

On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <kcc at google.com>
wrote:
> On RAM...
> You chose the 32-byte shadow granularity to reduce the RAM overhead,
> but I am afraid this will actually increase it due to extra alignment
requirements,
> especially if an average allocation on your typical application is small.

Good point.  I will run our test suite with 8-byte shadow granularity and
do some measurements.

In general, the memory constraint hasn't been as big an issue as I
initially thought.  The mitigating factor is that we are focused on unit
tests as opposed to running the full blown application.

> The pointers are 32-bit, right?
> Given how RAM-constrained your environment is, maybe you should consider
something more like HWASAN instead of ASAN.
> https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> But you may not have enough address bits. :(
Pointers are 32 bits.  Interesting idea, but I agree I don't think we have
enough bits.  Even ignoring the sparsely used lower addresses, DDR + cache
bit leaves us with only 2 bits.

Thanks,

Walter

On Fri, May 4, 2018 at 7:09 PM Walter Lee <waltl at google.com> wrote:
> On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <kcc at google.com>
wrote:
>
> > On RAM...
>
> > You chose the 32-byte shadow granularity to reduce the RAM overhead,
> > but I am afraid this will actually increase it due to extra alignment
> requirements,
> > especially if an average allocation on your typical application is
small.
>
>
> Good point.  I will run our test suite with 8-byte shadow granularity and
> do some measurements.
>
try 16 as well.
Depending on your typical code and default alignment, I would expect 8 or
16 to be the best.

>
> In general, the memory constraint hasn't been as big an issue as I
> initially thought.  The mitigating factor is that we are focused on unit
> tests as opposed to running the full blown application.
>
>
> > The pointers are 32-bit, right?
> > Given how RAM-constrained your environment is, maybe you should
consider
> something more like HWASAN instead of ASAN.
> >
https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> > But you may not have enough address bits. :(
>
> Pointers are 32 bits.  Interesting idea, but I agree I don't think we
have
> enough bits.  Even ignoring the sparsely used lower addresses, DDR + cache
> bit leaves us with only 2 bits.
>
> Thanks,
>
> Walter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180507/6356afd0/attachment.html>