Currently, the initialization of _nres is not thread-saferes_mkquery is not thread-safe,
which might cause memory double free problem if caller ran under multithread.
To fix it, only initialize _nres once.
Also remove the redundant code.
Test: atest DnsResolverTest
Bug: 166235340
Change-Id: I9caa6eab37cb530fc60dae9bcca9650973a4536a
arm64 was already being careful, but x86/x86-64 and 32-bit ARM could be
caught by a signal in a state where the stack pointer was mangled.
For 32-bit ARM I've taken care with the link register too, to avoid
potential issues with unwinding.
Bug: http://b/152210274
Test: treehugger
Change-Id: I1ce285b017a633c732dbe04743368f4cae27af85
This log message exists to provide more context (the property name) to
SELinux denials for the same access check. The SELinux log severity
is 'W' since SELinux denials do not necessarily point to user-visible
errors, therefore this message should be 'W' as well.
Bug: 181269159
Test: build
Change-Id: Ie25091d96214a175b7ca39d5615f9a09b789d1e3
FORTIFY'ed functions try to be as close to possible as 'invisible';
having stack protectors detracts from that.
Don't apply this to functions which clang has no chance of inlining
anyway (like variadic functions)
Bug: 182948263
Test: TreeHugger
Change-Id: I08cfec25464b8ea1e070942e3dc76fc84da73dd0
Resetting PAC keys on fork appears to lead to a number of problems. One
problem is that we are constrained in where we can run C++ code after
forking, and with ART those places are implementation-defined. For
example, in app zygotes, ART turns out to insert "interpreter frames"
in the stack trace. Returning into these interpreter frames may lead
to crashes due to failing the ROP protection check on return.
It seems better to reset keys on thread creation instead. We only need
to reset IA because only this key needs to be reset for reverse-edge
PAC, and resetting the other keys may be incompatible with future ABIs.
Chrome (and potentially other applications) has a sandbox that prevents
the use of the prctl, so we restrict its use to applications targeting
S and above.
Bug: 183024045
Change-Id: I1e6502a7d7df319d424e2b0f653aad9a343ae71b
As far as I can tell, clang never implemented this GCC workaround for
32-bit x86's terrible PIC code. Since the whole point of
__stack_chk_fail_local() requires that it's in the same executable or
library as its callers, any prebuilt with a dependency on this (because
it was built by GCC) already has its own copy anyway. And clang isn't
creating any new ones, so I think this has been dead for several years
now.
Test: treehugger
Change-Id: I96997bbf912bbff506db44c285d9941fef9f86ce
Motivated by the fact that bazel doesn't like #include "../", but this
feels like it could use a deeper clean.
In fact, even after this change, I think we should remove this entirely,
since as far as I can tell Clang never implemented this GCC workaround
for 32-bit x86's awful PIC code.
Test: treehugger
Change-Id: I72715ee46f873f42d5707712aebe246ef78fcde1
This is the second or third time I've scratched my head wondering why
this destructor has no coverage. I was tempted to leave it in with a
comment saying it should never be called, but that seemed sillier than
just replacing it with an assertion.
Test: treehugger
Change-Id: I3442d9f8a391fae668e77c6888a4457ededee494
This makes Bazel conversion easier (because in Bazel package boundaries really matter).
Test: m libc still builds, and m also builds.
Change-Id: I5cfc9d83dffd3110ffad9ce03198e6141c8c5b33
