This has been in the standard since C99, but we've never supported it
before. It's apparently used by SPIRV-Tools.
I tried implementing this the other way (with fcntl(2)) first, but
eventually realized that that's more complicated and gives worse
results. This implementation assumes that /proc is mounted, but so much
of libc relies on that at this point that I don't think there's any
realistic case where the fcntl(2) implementation would be preferable,
and there are many where it's not.
The fact that no-one's mentioned this until now suggests that it's not a
heavily used feature anyway.
I've also replaced AssertCloseOnExec() with a CloseOnExec()
boolean-valued function instead, because it's really annoying getting
assertion failures that don't point you at the test line in question,
and instead point to some common helper code.
Test: treehugger
Change-Id: Ia2e53bf2664a4f782581042054ecd492830e2aed
The triggering reason for this change is that the SDK snapshot
generation cannot readily handle header libraries that are required for
targets that the SDK itself isn't available for. However, these include
files shouldn't be used without Bionic anyway.
Relanding unchanged - the build problem was due to a split topic.
Test: m checkbuild (on aosp_taimen)
Test: m (on aosp_taimen_hwasan)
Test: atest CtsBionicTestCases
Test: lunch fvp-userdebug && mmm bionic
Bug: 152255951
Change-Id: Iaf49597ea265e6f2a042de5ee873238073b2e545
Reason for revert: Breaks rvc-d1-dev-plus-aosp: http://ab/6443190
Reverted Changes:
Ide447b89a:bionic_libc_platform_headers is only available whe...
Ia93cd3ec8:bionic_libc_platform_headers is only available whe...
Icdc495588:Make bionic_platform_headers available only for Bi...
Idfd7c87dc:bionic_libc_platform_headers is only available whe...
Bug: 152255951
Bug: 155269399
Change-Id: I214f1165bb0a7e59d3b35a13b3cceb1965be922b
The triggering reason for this change is that the SDK snapshot
generation cannot readily handle header libraries that are required for
targets that the SDK itself isn't available for. However, these include
files shouldn't be used without Bionic anyway.
Test: m checkbuild (on aosp_taimen)
Test: m (on aosp_taimen_hwasan)
Test: atest CtsBionicTestCases
Test: lunch fvp-userdebug && mmm bionic
Bug: 152255951
Change-Id: Icdc49558893c5355860f78d23275c49ba0119900
We had two copies of this function, one (not quite correct) in tests/utils.h
and another in bionic/macros.h. Delete the former and have the users include
the latter.
Also, create an overload of the function that takes a uintptr_t, which will
be useful for out-of-process scenarios such as the MTE support in debuggerd.
Bug: 135772972
Change-Id: Ia3c2652c97797663146b3f05fa786afe09f7ea97
This patch introduces tagged pointers to bionic. We add a static tag to
all pointers on arm64 compatible platforms (needs requisite
top-byte-ignore hardware feature and relevant kernel patches).
We dynamically detect TBI-compatible devices (a device with the TBI feature and
kernel support) at process start time, and insert an implementation-dependent
tag into the top byte of the pointer for all heap allocations. We then check
that the tag has not been truncated when deallocating the memory.
If an application incorrectly writes to the top byte of the pointer, we
terminate the process at time of detection. This will allow MTE-incompatible
applications to be caught early.
Bug: 135754954
Bug: 147147490
Test: cd bionic && atest .
Change-Id: Ie424325ba1e3c4443040ac265aeaa28d9e405d28
This reverts commit 43d5f9d4dd.
Bug: 135754954
Bug: 147147490
Exempt-From-Owner-Approval: clean revert
Reason for revert: Breaks ART gtest, see:
https://ci.chromium.org/p/art/builders/ci/angler-armv8-non-gen-cc/561
The crash happens on mprotect of a page, the test crashes with ENOMEM.
Change-Id: I52eea1abbfaf8d8e2226f92d30aa55aba3810528
This patch introduces tagged pointers to bionic. We add a static tag to
all pointers on arm64 compatible platforms (needs requisite
top-byte-ignore hardware feature and relevant kernel patches).
We dynamically detect TBI-compatible devices (a device with the TBI feature and
kernel support) at process start time, and insert an implementation-dependent
tag into the top byte of the pointer for all heap allocations. We then check
that the tag has not been truncated when deallocating the memory.
If an application incorrectly writes to the top byte of the pointer, we
terminate the process at time of detection. This will allow MTE-incompatible
applications to be caught early.
Bug: 135754954
Bug: 147147490
Test: cd bionic && atest .
Change-Id: I6e5b809fc81f55dd517f845eaf20f3c0ebd4d86e
Upstream keeps rearranging the deckchairs for these, so let's just
switch to the [roughly] one-liners rather than track that...
Test: treehugger
Change-Id: If655cf7a7f316657de44d41fadd43a8c55ee6f23
The tests were patched earlier to run with tagging heap allocator.
This change enables hwasan code instrumentation in the tests themselves,
and fixes the issues that arise, mainly in the code that:
* compares addresses of unrelated stack variables
* compares address of a stack variable with stack limits as found in
/proc/self/maps
* writes address of a stack variable to a hardware watchpoint register
etc.
Note that static tests are broken at the moment, like all static
binaries. Dynamic tests pass 100% with this change.
Bug: 114279110, 124007027
Test: SANITIZE_TARGET=hwaddress; run dynamic bionic tests
Change-Id: I68b8df9dd3e30b47734ddc083811a75a7f27deaa
* HWASan report invalid use of the allocator api (like alignment not
being power of two, or allocation size too large) in a way tests do not
expect.
* Code in .preinit_array runs before HWASan shadow is initialized and
needs to be excluded from instrumentation.
* It looks that mm system calls (mmap/mprotect/etc) will not allow
tagged pointers. In fact, the use of mprotect on malloc()ed memory is
doubtful - one can imagine some kind of speculative load from such
memory, as compiler knows that it is addressable.
Bug: 114279110
Test: bionic-unit-tests with hwasan
Change-Id: I6ba4b46a0d554de77c923ad134cf156ce4ddba1b
The executable can be inside a zip file using the same syntax used for
shared objects: path.zip!/libentry.so.
The linker currently requires an absolute path. This restriction could be
loosened, but it didn't seem important? If it allowed non-absolute paths,
we'd need to decide how to handle:
- foo/bar (relative to CWD?)
- foo (search PATH / LD_LIBRARY_PATH, or also relative to CWD?)
- foo.zip!/bar (normalize_path() requires an absolute path)
The linker adjusts the argc/argv passed to main() and to constructor
functions to hide the initial linker argument, but doesn't adjust the auxv
vector or files like /proc/self/{exe,cmdline,auxv,stat}. Those files will
report that the kernel loaded the linker as an executable.
I think the linker_logger.cpp change guarding against (g_argv == NULL)
isn't actually necessary, but it seemed like a good idea given that I'm
delaying initialization of g_argv until after C++ constructors have run.
Bug: http://b/112050209
Test: bionic unit tests
Change-Id: I846faf98b16fd34218946f6167e8b451897debe5
Use the malloc debug framework to implement the malloc debug hooks
since it can introduce a performance issue.
Also, modify the bionic/tests/utils.h slightly to dump an error message
when the exe failed.
Bug: 30561479
Test: Ran malloc hook unit tests.
Test: Ran malloc debug unit tests.
Test: Enabled malloc hooks and ran bionic unit tests and verified no
Test: unexpected failures.
Test: Enabled malloc debug and malloc hooks and verified malloc debug wins.
Test: Enabled malloc debug using env, property, and property with name
Test: still works.
Change-Id: Ib50046a0493c5c2050cf831befb812310bdcc249
There were a bunch more unreasonable/incorrect ones, but these ones
seemed legit. Nothing very interesting, though.
Bug: N/A
Test: ran tests, benchmarks
Change-Id: If66971194d4a7b4bf6d0251bedb88e8cdc88a76f
Based on gaps in the list of functions not referenced by the test
executable.
Bug: N/A
Test: ran tests
Change-Id: I73c238e7cf360f94670c7cd13eb954341c940b7b
Strictly not needed in the WNOHANG case, but it's probably best to have
every waitpid wrapped for future copy & pasters.
Bug: https://issuetracker.google.com/69525592
Test: ran tests
Change-Id: I013b0a52d2753e3d32638e9b84c79af7327fb405
Stop allocating and deallocating memory as part of the test itself.
There's still the fopen, but since our stdio reuses existing structs,
that doesn't seem to be a problem in practice.
Bug: http://b/67077411
Test: ran tests with --gtest_repeat=1000
Change-Id: I99de5de0911161ec04afe75653075f1ccefb01a5
Do not load second copy of libraries that are supposed to
be provided by linked namespaces. Also do not print
error in the log if caller tries to open shared library
using absolute path for apps targeting N+.
Bug: http://b/35454141
Bug: http://b/26833548
Bug: http://b/35338922
Test: run bionic-unit-tests --gtest_filter=dl*
Change-Id: Icf3aeedff18d287d2ba0b3df3808b100f3ef5f7a
Tag fmemopen_NULL as a known failure, and make it reliably fail by
memsetting the buffer we read to.
Bug: http://b/33251022
Test: bionic-unit-tests/bionic-unit-tests64 on bullhead
Test: bionic-unit-tests-glibc --gtest_filter="*memopen*"
Change-Id: I381783282359851c9de47146dafbb5a291960c2a
Also add another test for dlsym(RTLD_NEXT, ..)
Bug: http://b/33106624
Test: run bionic-unit-tests-glibc and bionic-unit-tests
Change-Id: I340165d66bf2360b0e3273d3561a08cb5e7bd025
Move libraries used in bionic-unit-tests out of system partition to
/data/nativetests../bionic-loader-test-libs
Bug: http://b/22182538
Test: build bionic and run bionic-unit-tests
Change-Id: I170177bef782839d0b4970ae4418bf54d0a77836
The glibc implementation of the loader passes argc/argv/envp
to all elf constructors. This change makes bionic linker
behave in the same way.
Bug: http://b/30145768
Change-Id: I1c65c42aa5305a5b133c64b5748205bbde869e0e
Test: run bionic-unit-tests --gtest_filter=dl*:Dl*
This CL adds initialization of inode for the main executable
which enables linker to resolve the correct soinfo when
application calls dlopen with absolute path to the
main executable.
Bug: http://b/28420266
Change-Id: I102e07bde454bd44c6e46075e3faeeb5092830d8
Print properties of the namespace on "library is not accessible"
error to better diagnose problems with native library accessiblity
Bug: http://b/27406143
Change-Id: Icf3d6c604f09dfa015de863fdb1267d343930d2a
(cherry picked from commit 350bdad61c)
It is reported by tsan that funlockfile() can unlock an unlocked mutex.
It happens when printf() is called before fopen() or other stdio stuff.
As FLOCKFILE(fp) is called before __sinit(), _stdio_handles_locking is false,
and _FLOCK(fp) will not be locked. But then cantwrite(fp) in __vfprintf()
calls__sinit(), which makes _stdio_handles_locking become true, and
FUNLOCKFILE(fp) unlocks _FLOCK(fp).
Change _stdio_handles_locking into _caller_handles_locking,
so __sinit() won't change its value. Add test due to my previous fault.
Bug: 25392375
Change-Id: I483e3c3cdb28da65e62f1fd9615bf58c5403b4dd
This change adds realpath to soinfo and
extends limit on filenames from 128 to PATH_MAX.
It also removes soinfo::name field, linker uses
dt_soname instead.
Bug: http://b/19818481
Bug: https://code.google.com/p/android/issues/detail?id=80336
Change-Id: I9cff4cb5bda3ee2bc74e1bbded9594ea7fbe2a08
