On Wed, Jul 18, 2018 at 12:34:28PM -0700, Kostya Serebryany wrote:
> On Wed, Jul 18, 2018 at 12:29 PM H.J. Lu <hjl.to...@gmail.com> wrote:
> >
> > On Wed, Jul 18, 2018 at 11:45 AM, Kostya Serebryany <k...@google.com> wrote:
> > > On Wed, Jul 18, 2018 at 11:40 AM H.J. Lu <hjl.to...@gmail.com> wrote:
> > >>
> > >> On Wed, Jul 18, 2018 at 11:18 AM, Kostya Serebryany <k...@google.com>
> > >> wrote:
> > >> > What's ENDBR and do we really need to have it in compiler-rt?
> > >>
> > >> When shadow stack from Intel CET is enabled, the first instruction of
> > >> all
> > >> indirect branch targets must be a special instruction, ENDBR. In this
> > >> case,
> > >
> > > I am confused.
> > > CET is a security mitigation feature (and ENDBR is a pretty weak form of
> > > such),
> > > while ASAN is a testing tool, rarely used in production is almost
> > > never as a mitigation (which it is not!).
> > > Why would anyone need to combine CET and ASAN in one process?
> > >
> >
> > CET is transparent to ASAN. It is perfectly OK to use -fcf-protection to
> > enable CET together with ASAN.
>
> It is ok, but does it make any sense?
> If anything, the current ASAN's intereceptors are a large blob of
> security vulnerabilities.
> If we ever want to use ASAN (or, more likely, HWASAN) as a security
> mitigation feature,
> we will need to get rid of these interceptors entirely.
>
>
> >
> > > Also, CET doesn't exist in the hardware yet, at least not publicly
> > > available.
> > > Which means there should be no rush (am I wrong?) and we can do things
> > > in the correct order:
> > > implement the Clang/LLVM support, make the compiler-rt change in LLVM,
> > > merge back to GCC.
> >
> > I am working with our LLVM people to address this.
>
> Cool!
>
I am testing this patch and will submit it upstream.
H.J.
---
asan/asan_interceptors.cc has
...
int res = REAL(swapcontext)(oucp, ucp);
...
REAL(swapcontext) is a function pointer to swapcontext in libc. Since
swapcontext may return via indirect branch on x86 when shadow stack is
enabled, we need to call REAL(swapcontext) with indirect_return attribute
on x86 so that compiler can insert ENDBR after REAL(swapcontext) call.
PR target/86560
* asan/asan_interceptors.cc (swapcontext): Call REAL(swapcontext)
with indirect_return attribute on x86 if indirect_return attribute
is available.
---
libsanitizer/asan/asan_interceptors.cc | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/libsanitizer/asan/asan_interceptors.cc
b/libsanitizer/asan/asan_interceptors.cc
index a8f4b72723f..3ae473f210a 100644
--- a/libsanitizer/asan/asan_interceptors.cc
+++ b/libsanitizer/asan/asan_interceptors.cc
@@ -267,7 +267,16 @@ INTERCEPTOR(int, swapcontext, struct ucontext_t *oucp,
uptr stack, ssize;
ReadContextStack(ucp, &stack, &ssize);
ClearShadowMemoryForContextStack(stack, ssize);
+#if defined(__has_attribute) && (defined(__x86_64__) || defined(__i386__))
+ int (*real_swapcontext) (struct ucontext_t *, struct ucontext_t *)
+# if __has_attribute (__indirect_return__)
+ __attribute__((__indirect_return__))
+# endif
+ = REAL(swapcontext);
+ int res = real_swapcontext(oucp, ucp);
+#else
int res = REAL(swapcontext)(oucp, ucp);
+#endif
// swapcontext technically does not return, but program may swap context to
// "oucp" later, that would look as if swapcontext() returned 0.
// We need to clear shadow for ucp once again, as it may be in arbitrary
--
2.17.1
