In Pie, Google added checks to prevent destroying of the same mutexes
consecutively, and aborts the program on fortify fatal call.
Our camera blobs trigger this check when tearing down an ISP session,
destroying the same mutex consecutively by adding a destroy instruction
in a loop. This causes the whole daemon to crash and fail.
(Specifically, the violating instructions were from isp_module_stop_session
and when isp_module_start_session fails to create a thread.)
Workaround the issue by shimming the function; catching destroyed
mutexes and returning -EBUSY without passing on the bad mutexes to libc.
Change-Id: I4f8542a496dc25c53f8208a647cc0d6acc8662eb
* The shim is only used for converting timespecs, rename the shim lib
to suggest such.
* Build it with Clang since it doesn't break anything.
Change-Id: I8cfed10b73655f9aa1f4780dffc5106347441c3e
-> [1] added tests to ensure nano timespecs are below 1000000000
-> Legacy blobs before N were able to use tv_nsec > 100000000
-> One such example would be our libmmcamera2_sensor_modules.so, which
have instances of timeouts of 5000000000 nsecs.
-> The previous workaround was to shim the old libc functions to
skip these tests, but that was really ugly since we leave out bug fixes
and security patches introduced from MM up till Oreo.
-> Current workaround is applied on the latest bionic code by correcting
the invalid timespecs, taking out each second from tv_nsec, and then
adding them to tv_sec, until tv_nsec goes below 1 second.
-> Due to bionic's tight security, we've got no choice but to copy-paste
its functions here.
[1]: https://android.googlesource.com/platform/bionic/+/c9a659c
Change-Id: I271f2899db54a252d0d2a018cf4eb7877b97a02a
