This is an archive of the discontinued LLVM Phabricator instance.

[cfi] Lazy CFI initialization
ClosedPublic

Authored by vitalybuka on Feb 22 2018, 7:27 PM.

Details

Summary

If SANITIZER_CAN_USE_PREINIT_ARRAY=0 interceptors or cfi callbacks can be called
before constructor.

Diff Detail

Repository
rL LLVM

Event Timeline

vitalybuka created this revision.Feb 22 2018, 7:27 PM
eugenis added inline comments.Feb 23 2018, 11:28 AM
compiler-rt/lib/cfi/cfi.cc
426 ↗(On Diff #135586)

This mutex is not very useful. An interceptor could still go ahead while cfi_init is running in another thread. And we probably can not afford a lock in cfi_slowpath.

Perhaps add a constructor to all cfi-instrumented binaries? Then we would not need lazy initialization in __cfi_slowpath, and I don't care how many locks dlopen() takes.

A constructor would also mitigate the dlopen issue (see the comment before the interceptor). Not that we've seen this issue in the wild.

vitalybuka planned changes to this revision.Feb 23 2018, 1:53 PM

As discussed offline, I going to keep primary initialization unchanged and make lazy only interceptors initialization.

just interceptors

vitalybuka marked an inline comment as done.Feb 23 2018, 3:25 PM
Harbormaster completed remote builds in B15378: Diff 135717.
eugenis added inline comments.Feb 23 2018, 6:32 PM
compiler-rt/lib/cfi/cfi.cc
416 ↗(On Diff #135717)

This is technically a data race. Let's just take a lock, this is not performance sensitive.

416 ↗(On Diff #135717)

call EnsureInterceptorsInitialized() here, or it may become a surprise if someone adds a new interceptor without that check

eugenis accepted this revision.Feb 23 2018, 6:33 PM
eugenis added inline comments.
compiler-rt/lib/cfi/cfi.cc
416 ↗(On Diff #135717)

I see, that's too early for that.

This revision is now accepted and ready to land.Feb 23 2018, 6:33 PM
This revision was automatically updated to reflect the committed changes.