From: "Martin Liška" <mliska@suse.cz>
To: Matthew Malcomson <Matthew.Malcomson@arm.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: "dodji@redhat.com" <dodji@redhat.com>, nd <nd@arm.com>,
"kcc@google.com" <kcc@google.com>,
"jakub@redhat.com" <jakub@redhat.com>,
"dvyukov@google.com" <dvyukov@google.com>
Subject: Re: [RFC][PATCH 5/X][libsanitizer] Introduce longjmp/setjmp interceptors to libhwasan
Date: Mon, 09 Sep 2019 10:49:00 -0000 [thread overview]
Message-ID: <32fb4525-2eda-ef6f-f4f3-3db87e259b40@suse.cz> (raw)
In-Reply-To: <c843cab2-9c7f-e025-912c-b326f2599483@arm.com>
On 9/9/19 12:29 PM, Matthew Malcomson wrote:
> On 09/09/19 11:01, Martin Liška wrote:
>> Hi.
>>
>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>>> Ensuring that the shadow stack is cleared on normal function exit will
>>> be done by adding instrumentation to the function epilogue through the
>>> compiler.
>>> longjmp and setjmp are some abnormal methods of exiting the function
>>> that can't be handled in the compiler since they can be called in
>>> uninstrumented code to unwind past instrumented function frames.
>>
>> I'm curious why you are adding a new code that is not part of libsanitizer runtime?
>> Does it mean the current LLVM implementation does not properly handle setjmp and
>> longjmp?
>
> Honestly -- I'm not sure.
>
> I did a basic test that seemed to show clang not supporting setjmp &
> longjmp and I made a bit of a foray into how one would approach the
> problem, but I then left it in a partially done state to focus on other
> things.
I see. Then I would probably file an issue and ask the community:
https://github.com/google/sanitizers/issues
>
> It also seems on first blush that C++ exceptions are not handled, but
> again I haven't yet gone and asked anyone in the know.
Likewise I would ask them for the C++ exceptions.
Martin
>
> (it's on the list of things to do, but not yet at the top).
>
>>
>> Note that rule of thumb is that we need to upstream all libsanitizer
>> changes before we merge libsanitizer. We are doing that in order to not
>> have a bug difference against upstream libsanitizer.
>
> That sounds good to me -- I will remember to go upstream when I look
> into this.
>
>>
>> Martin
>>
>
next prev parent reply other threads:[~2019-09-09 10:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-06 14:46 [Patch 0/X] [WIP][RFC][libsanitizer] Introduce HWASAN to GCC Matthew Malcomson
2019-09-06 14:46 ` [RFC][PATCH 3/X][libsanitizer] Allow compilation for HWASAN_WITH_INTERCEPTORS=OFF Matthew Malcomson
2019-09-09 9:27 ` Martin Liška
2019-09-06 14:46 ` [RFC][PATCH 4/X][libsanitizer] Pass size and pointer info to error reporting functions Matthew Malcomson
2019-09-09 9:27 ` Martin Liška
2019-09-06 14:46 ` [RFC][PATCH 2/X][libsanitizer] Tie the hwasan library into our build system Matthew Malcomson
2019-09-06 14:46 ` [RFC][PATCH 7/X][libsanitizer] Add option to bootstrap using HWASAN Matthew Malcomson
2019-09-06 14:46 ` [RFC][PATCH 5/X][libsanitizer] Introduce longjmp/setjmp interceptors to libhwasan Matthew Malcomson
2019-09-09 10:02 ` Martin Liška
2019-09-09 10:29 ` Matthew Malcomson
2019-09-09 10:49 ` Martin Liška [this message]
2019-09-06 14:46 ` [RFC][PATCH 8/X][libsanitizer] Ensure HWASAN required alignment for stack variables Matthew Malcomson
2019-09-06 14:46 ` [RFC][PATCH 1/X][libsanitizer] Introduce libsanitizer to GCC tree Matthew Malcomson
2019-09-09 9:26 ` Martin Liška
2019-09-06 14:46 ` [RFC][PATCH 14/X][libsanitizer] Introduce HWASAN block-scope poisoning Matthew Malcomson
2019-09-06 14:47 ` [RFC][PATCH 13/X][libsanitizer] Instrument known builtin function calls Matthew Malcomson
2019-09-06 14:47 ` [RFC][PATCH 10/X][libsanitizer] Colour the shadow stack for each stack variable Matthew Malcomson
2019-09-06 14:47 ` [RFC][PATCH 12/X][libsanitizer] Check pointer tags match address tags Matthew Malcomson
2019-09-06 14:47 ` [RFC][PATCH 11/X][libsanitizer] Uncolour stack frame on function exit Matthew Malcomson
2019-09-06 14:47 ` [RFC][PATCH 16/X][libsanitizer] Build libhwasan with interceptors Matthew Malcomson
2019-09-06 14:47 ` [RFC][PATCH 15/X][libsanitizer] Add in MTE stubs Matthew Malcomson
2019-09-06 14:47 ` [RFC][PATCH 6/X][libsanitizer] Add -fsanitize=hwaddress flags Matthew Malcomson
2019-09-09 10:06 ` Martin Liška
2019-09-09 10:18 ` Matthew Malcomson
2019-09-09 10:20 ` Martin Liška
2019-09-06 14:47 ` [RFC][PATCH 9/X][libsanitizer] Put tags into each stack variable pointer Matthew Malcomson
2019-09-09 10:47 ` [Patch 0/X] [WIP][RFC][libsanitizer] Introduce HWASAN to GCC Martin Liška
2019-09-09 15:55 ` Matthew Malcomson
2019-09-10 1:06 ` Kostya Serebryany via gcc-patches
2019-09-11 11:53 ` Martin Liška
2019-09-11 16:37 ` Matthew Malcomson
2019-09-11 18:34 ` Evgenii Stepanov via gcc-patches
2019-09-23 8:02 ` Martin Liška
2019-10-23 11:02 ` Matthew Malcomson
2019-10-24 10:11 ` Martin Liška
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32fb4525-2eda-ef6f-f4f3-3db87e259b40@suse.cz \
--to=mliska@suse.cz \
--cc=Matthew.Malcomson@arm.com \
--cc=dodji@redhat.com \
--cc=dvyukov@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=kcc@google.com \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).