llvm dev - May 2018 - ASan port for Myriad RTEMS

Hi Kostya.  Thanks for the quick feedback.  I will work on addressing your
comments.

In regard to initialization checks, I can eliminate most of them by
initializing the shadow memory very early, but I still need to do something
in two places, __asan_handle_no_return and GetFakeStackFast.  Would it be
ok to have guards for those two places only?

Walter
On Fri, May 4, 2018 at 6: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

On Fri, May 4, 2018 at 6:29 PM Walter Lee <waltl at google.com> wrote:
> Hi Kostya.  Thanks for the quick feedback.  I will work on addressing your
> comments.
>
> In regard to initialization checks, I can eliminate most of them by
> initializing the shadow memory very early,

This will be a very good way to handle this.

> but I still need to do something
> in two places, __asan_handle_no_return

I think it might be fine. Let me look at the code once the rest is done.

> and GetFakeStackFast.

Not sure. Why don't just disable stack-use-after-return?

> Would it be
> ok to have guards for those two places only?
>
> Walter
> On Fri, May 4, 2018 at 6: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/20180507/16957700/attachment.html>

On Mon, May 7, 2018 at 2:05 PM Kostya Serebryany <kcc at google.com>
wrote:
>
>
>> and GetFakeStackFast.
>
>
> Not sure. Why don't just disable stack-use-after-return?
>
Yeah originally I was going to do that, but:

1. We had a stack use-after-return last month that people had to debug by
hand. that would have been caught by ASan with stack-use-after-return.  So
it seems like a worthwhile feature to support.

2. Initially I was concerned about code size and one thing I was planning
to do was to disable stack-use-after-return instrumentation.  But in
practice, we find that this was a non-issue: we are able to run the same
number of tests with and without such instrumentation.

3. It seems like a good idea to keep the same default behavior and feature
parity with x86 ASan when possible.

Thanks,

Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180507/df58132f/attachment.html>