We should only be calling _real versions of the functions that use this
if the input size is verifiably <= SSIZE_MAX. Otherwise, just fall
through to _chk and let that handle it.
Bug: 131861088
Test: mma && bionic-unit-tests
Change-Id: Iba04e486ef91ea1b3539ab6df6260429264e66b4
As it says on the box.
Since realpath isn't a function definition, any attributes it provides
here just add to the "regular" realpath.
__wur is being added to realpath because it returns NULL on failure, and
the contents of the input buffer are undefined in that case. A blueline
checkbuild showed 0 complaints about this new __wur, so it seems
harmless to add.
Bug: 131861088
Test: mma
Change-Id: If5f47e0e290d86df69c0888711e29775c390fca4
This also adds _2-variants for these functions, for extra glorious
checking
Bug: 131861088
Test: mma
Change-Id: I80475ff4bb220c0c47894e9532426f53412f176f
This CL allows us to diagnose string functions that get an explicit size
passed into them, and string functions that are trivially misused.
Bug: 131861088
Test: mma
Change-Id: I894aec99420a75c6474cfd7d5010f0cf2f10ab21
My declval hack failed on x86_64 with:
```
substitution failure [with T = __va_list_tag [1]]: function cannot
return array type '__va_list_tag [1]'
```
...Because the type of va_list is compiler magic, it's fine for it to be
whatever the compiler wants it to be. Thankfully, pointers to arrays can
be returned, so let's use those instead.
Bug: 135210098
Test: mma on aosp_blueline-eng and aosp_x86_64-eng; the latter was
failing before this patch.
Change-Id: Iefd57c0f8e823653fd70633fb6ee75cfc0022430
Chrome OS has a fairly extensive FORTIFY test suite for both
compile-time and run-time diagnostics. It covers tons of edge cases, and
conveniently centralizes diagnostic and death testing.
A fair amount of it has been ifdef'ed out, since Bionic doesn't yet
diagnose (or crash on) some of these things. The intent is to explicitly
declare defeat on the things we don't care to FORTIFY, and slowly fix
the rest in easier-to-digest CLs.
Once that's done, we might be able to look into retiring some of the
FORTIFY testing that we don't share with the CrOS folks.
Bug: 131861088
Test: mma + bionic-unit-tests on blueline
Change-Id: I16734ea0769e03cf658ef10532d64f28fdb36a89
The tzdata file is being removed from the runtime mainline module
in an upcoming commit. This commit removes the bionic references
to it.
This commit also contains general comment tidy-ups.
Bug: 132168458
Test: build only
Change-Id: I83cd9ff756b36e1d1222b7830f97c8bde2885ce4
Historical research (see bug) suggests that these functions were all in
22. The map file believed this with one (presumably typoed) exception,
but the header file didn't match the map file. It looks like the map was
correct (modulo the one typo), so fix up all the disagreement.
Bug: http://b/113618851
Test: treehugger
Change-Id: Ia579f4e6163206abfac79aa54dc98c792f00ee86
Ordinary executables have a PT_INTERP path of /system/bin/linker[64], but:
- executables using bootstrap Bionic use /system/bin/bootstrap/linker[64]
- ASAN executables use /system/bin/linker_asan[64]
gdb appears to use the PT_INTERP path for debugging the dynamic linker
before the linker has initialized the r_debug module list. If the linker's
l_name differs from PT_INTERP, then gdb assumes that the linker has been
unloaded and searches for a new solib using the linker's l_name path.
gdb may print a warning like:
warning: Temporarily disabling breakpoints for unloaded shared library "$OUT/symbols/system/bin/linker64"
If I'm currently debugging the linker when this happens, gdb apparently
doesn't load debug symbols for the linker. This can be worked around with
gdb's "sharedlibrary" command, but it's better to avoid it.
Previously, when PT_INTERP was the bootstrap linker, but l_name was
"/system/bin/linker[64]", gdb would find the default non-bootstrap linker
binary and (presumably) get confused about symbol addresses.
(Also, remove the "static std::string exe_path" variable because the
soinfo::realpath_ field is a std::string that already lasts until exit. We
already use it for link_map_head.l_name in notify_gdb_of_load.)
Bug: http://b/134183407
Test: manual
Change-Id: I9a95425a3a5e9fd01e9dd272273c6ed3667dbb9a
Rearrange the st_dev and st_ino checks to reduce the number of
comparison needed.
Test: Ran cameraserver on a Go device. Measured time spent in the linker
and saw ~1% speed-up.
Change-Id: I8e977ff37925eae3ba8348e7c4a01ce8af3b9b6d
We're not going to change this code, ARM's not going to break it.
Silence the warnings.
Bug: http://b/114120867
Test: treehugger
Change-Id: Ie25ef44706c952efc5d54012391bee19af095818
Cleanup of references to 'coverage' in build files. Part of a larger
cleanup to make fuzzing work again in the Android build tree.
Also fixed a test issue with emulated TLS with the new changes, and
removed libc.so fuzzer support until a linked bug is fixed
(b/132640749).
Bug: 121042685
Test: With all patches in the bug merged: mmma bionic
Change-Id: I592352fe9210ff811a2660a88cbbfe48d70a1e57
Merged-In: I592352fe9210ff811a2660a88cbbfe48d70a1e57
In an attempt to make bionic's reporting of users and groups more
accurate, this change makes the user / group functions do the
following:
1) Fail to query a uid/gid for a secondary user when the uid/gid
doesn't exist. Currently bionic would return successfully but with
a empty string for the name.
2) Fail to query a platform uid/gid, except a limited pre-allocated
set for a secondary user, as these are not used by second users.
3) Fail to query uids for all users for the GID-only app ranges:
CACHE_GID, EXT_GID, EXT_CACHE_GID, SHARED_GID.
4) Fail to query gids in SHARED_GID range for secondary users, as
these GIDs are only allocated for the first user.
5) Use "u#_a#_ext" and u#_a#_ext_cache" for EXT_GID and EXT_CACHE_GID
ranges. This both allows querying based on these names and
returning these names for the appropriate uids/gids.
This also consolidates the tests for better readability.
Test: these unit tests, boot
Change-Id: I59a1af0792e7806d423439582e56ce7f9f801c94
This converts all of stdio to short-circuit _chk functions in trivially
safe cases.
Bug: 131861088
Test: checkbuild on internal master. blueline bionic tests pass + it
boots.
Change-Id: I981ac9bd19112492d5a47dc5277526426b9af710
This also lets us retire our |__enable_if| version of |strlen|, which
should catch strictly fewer cases where we can fold the string's length
to a constant than |__builtin_constant_p| inside of |strlen|.
Bug: 131861088
Test: checkbuild on internal master. blueline bionic tests pass + it
boots.
Change-Id: I21b750a24f7d1825591a88d12a385be03a0a7ca3
Android's current lld build has a hack that overaligns TLS segments, but
it broke glibc when it produced TLS segments where (p_vaddr % p_align) was
non-zero. Move the hack into Bionic's crtbegin instead. It will emit a
0-sized, 64-byte alignment TLS segment into executables that don't use
TLS, but that should be harmless.
This variant of the hack is compatible with the gold and lld linkers. The
ld.bfd linker will optimize the .tdata output section out if its size is
zero, preventing the overalignment in an executable that only has .tbss
sections. This problem could be fixed by adding a ". = .;" statement
inside .tdata in ld.bfd's linker script.
See discussion on https://reviews.llvm.org/D61824.
Bug: https://bugs.llvm.org/show_bug.cgi?id=41527
Test: bionic unit tests, boot a device
Change-Id: I34df8b5594b6518d4590e4861e3d0b74d6fa754e
|__builtin_constant_p| has become more flexible in clang. In particular,
it's no longer forcibly lowered before inlining, so we can actually use
it on function parameters (or |__bos(param)|).
This CL tweaks things so that trivially safe calls to FORTIFY'ed
functions compile into direct calls to those functions, rather than to
their _chk counterparts. This will be the most impactful with things
like |memset|, |memcpy|, etc., since clang has way more flexibility
about how to lower those than it does with |__memset_chk|,
|__memcpy_chk|, ...
As noted in the comments, the spelling of the new macros is meant to
match closely with the spelling of our |__bos_static| macros used in
|diagnose_if|.
This isn't a full cleanup of all of the cases in which we can do this.
Just a start on the super simple cases.
Bug: 131861088
Test: m checkbuild; blueline boots.
Change-Id: I696f42ce4a65231e0c4a78a4c5133a6be1cb7708
These were originally #defined so we could share them between our
GCC and clang FORTIFY implementations. Since we no longer have a GCC
FORTIFY, #defining them is sort of pointless.
Bug: 131861088
Test: mma
Change-Id: I2ae4e0bdebbed16c946f5df7cc38c471881b481e
Our diagnose_if conditions are repetitive. It's potentially convenient
to hide that behind a macro. There's an upcoming refactor to our
run-time checks; having static checks look super similar is convenient,
and makes correctness (hopefully) slightly more obvious.
Bug: 131861088
Test: checkbuild on internal master.
Change-Id: Ic39a3b6bf020734c1bef6be144f61ef81466aafe
A linker namespace lives longer than its caller. It is never deleted
once created in a process. Currently, the pointer to the name is simply
copied which results dangling reference when the name is actually from
temporary objects like std::object. Fixing the issue by strdup'ing the
name upon namespace creation.
Bug: 130388701
Test: atest CtsJniTestCases; the log does not show broken error messages
like
unexpected dlerror: dlopen failed: library "/system/lib64/android.frameworks.cameraservice.common@2.0.so" needed or dlopened by "/data/app/android.jni.cts-HP6GyGXYy5honHQAffUXgw==/lib/arm64/libjnitest.so" is not accessible for the namespace " mT?"
Change-Id: I25d9d76f8520f490755c189ded5659e6c9741f79
