As requested in the bug. This also rips __memcpy_chk out of memcpy.S,
which lets us cut down on copypasta (all of the implementations look
identical).
Bug: 12231437
Test: mma on aosp_{arm,arm64,mips,x86,x86_64} internal master;
checkbuild on bullhead internal master; CtsBionicTestCases on bullhead.
No new failures.
Change-Id: I88c39ca166bacde0b692aa3063e743bb046a5d2f
This is no longer used in the platform, and shouldn't be used in NDK. Apps
should use the NDK's cpu-features module, which supports (a) more specific
queries and (b) all Android architectures, not just 32-bit ARM.
Bug: http://b/18556103
Test: builds
Change-Id: I544ef267a6d7d887223186180c77d9ad0321e605
There are a few instructions deprecated on armv8 that result in lots
of warnings. Add an arch directive so that these warnings go away.
This doesn't cause any problems because the instructions still
execute properly.
Bug: 38319728
Test: Built all of these assembler files and verified the warning are gone.
Change-Id: If063defdd16f290c01975233c8d257d1b2005e76
This library is used by a number of different libraries in the system.
Make it easy for platform libraries to use this library and create
an actual exported include file.
Change the names of the functions to reflect the new name of the library.
Run clang_format on the async_safe_log.cpp file since the formatting is
all over the place.
Bug: 31919199
Test: Compiled for angler/bullhead, and booted.
Test: Ran bionic unit tests.
Test: Ran the malloc debug tests.
Change-Id: I8071bf690c17b0ea3bc8dc5749cdd5b6ad58478a
BSD thinks you should only get the relocation constants for your target
architecture, but it's often useful to have them all available at once.
Rearrange the headers to enable that.
Also update the (modified) NetBSD files to CVS HEAD.
Also remove the unused BSDism R_TYPE.
Bug: N/A
Test: builds
Change-Id: Iad5ef29192a732696e2b36af35144a9ca116aa46
This change removes the kuser_helper note from building automatically
with any binary but leaves the note.
Also fixes a typo in the note.
Original patch adding the note:
Ib8366e2a0810092b71381d57dee4bdaa56369a24
Bug: 34815073
Test: Manual - Note is no longer added to binaries
Change-Id: Ieb81f9d9127d1f8a522434a31c696d743238e2a5
This patch adds clang-style FORTIFY to Bionic. For more information on
FORTIFY, please see https://goo.gl/8HS2dW . This implementation works
for versions of clang that don't support diagnose_if, so please see the
"without diagnose_if" sections. We plan to swap to a diagnose_if-based
FORTIFY later this year (since it doesn't really add any features; it
just simplifies the implementation a lot, and it gives us much prettier
diagnostics)
Bug: 32073964
Test: Builds on angler, bullhead, marlin, sailfish. Bionic CTS tests
pass on Angler and Bullhead.
Change-Id: I607aecbeee81529709b1eee7bef5b0836151eb2b
A kernel change is going in for 64bit arm to disable kuser_helper vector
pages for 32bit processes. This change adds a special elf note to
all arm32 binaries built with bionic. This note tells the kernel to
load the kuser_helper vector page for the process.
Bug: 33689037
Test: Manual - Phone boots, 32bit binaries have the notes, 64bit
binaries do not.
Change-Id: Ib8366e2a0810092b71381d57dee4bdaa56369a24
Stream-mode detection for L1 in A7-core is failing for
non cache-line-size (non 64 byte) aligned addresses.
This leads to destination data getting cached unnecessarily.
This A7 issue is confirmed by ARM
This issue is solved by aligning destination address to 64 byte before
entering the loop in memcpy routine.
Though we get lower score for micro_bench memcpy when L1 cache is bypassed,
it is desirable since it avoids unnecessary eviction of other process data
from L1 which is good for overall system performance.
Higher micro_bench memcpy numbers for < 64byte alignment shows good numbers
but this is at the cost of L1 cache pollution. During memcpy/memset,
unnecessary data is filled in L1 cache, this causes eviction of other
process data from L1.
For example during msmset(0), L1 cache gets filled with 0s which should be
avoided.
Additionally, there is another issue with cortex A7 that impacts performance
for all alignments / all Android Wear versions:
Store Buffer on A7 is 32 byte which limits the 32-byte back to back stores.
In the current implementation back to back 32bytes writes is causing CPU stalls.
This issue can be solved by interleaved Loads and Stores.
This helps in avoiding CPU stalls during memcpy by utilizing efficiently the
A7 internal load and store buffers.
Change-Id: Ie5f12f2bb5d86f627686730416279057e4f5f6d0
Some PoS internal system can't cope with more than 4 stack frames,
so the fact that our abort(3) implementation takes 4 frames by itself
makes it useless.
Re-reading POSIX, it only says "behaves as if", so the previous
implementation chain wasn't mandatory and we can just go straight to
calling tgkill...
Before:
#00 pc 0000000000069be4 /system/lib64/libc.so (tgkill+8)
#01 pc 0000000000066d50 /system/lib64/libc.so (pthread_kill+64)
#02 pc 0000000000028110 /system/lib64/libc.so (raise+24)
#03 pc 000000000001d4ec /system/lib64/libc.so (abort+52)
After:
#00 pc 0000000000069bc8 /system/lib64/libc.so (tgkill+8)
#01 pc 000000000001d4c8 /system/lib64/libc.so (abort+80)
#02 pc 0000000000001494 /system/xbin/crasher64 (_ZL9do_actionPKc+872)
#03 pc 00000000000010e0 /system/xbin/crasher64 (main+88)
This is less useful on 32-bit ARM because there there's an extra trampoline
from an assembler abort(3) implementation, so you'll still only get one
meaningful stack frame. But every other architecture will now get two!
But wait!
It turns out that the assembler hack isn't needed any more. Here we are
unwinding just fine all the way through the 32-bit ARM crasher:
Before (with direct call to tgkill but still using the assembler):
#00 pc 00049e7c /system/lib/libc.so (tgkill+12)
#01 pc 00019c6f /system/lib/libc.so (__libc_android_abort+50)
#02 pc 000181f8 /system/lib/libc.so (abort+4)
#03 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#04 pc 00017721 /system/lib/libc.so (__libc_init+48)
#05 pc 00000b38 /system/xbin/crasher (_start+96)
After:
#00 pc 00049e6c /system/lib/libc.so (tgkill+12)
#01 pc 00019c5f /system/lib/libc.so (abort+50)
#02 pc 00001025 /system/xbin/crasher (_ZL9do_actionPKc+656)
#03 pc 00017721 /system/lib/libc.so (__libc_init+48)
#04 pc 00000b38 /system/xbin/crasher (_start+96)
(As you can see, the fact that we see __libc_init rather than main was true
with the assembler stub too, so that's not a regression even if it does seem
odd...)
Bug: N/A
Test: ran crasher64
Change-Id: I9dd5b214c495604c8b502c7ec0de3631080d8c29
Test: Changed angler target to use cortex-a7 and I compiled.
Test: Booted this version on angler and ran bionic-unit-tests.
Change-Id: Ice7f6ea38a2569582161a8e659d7877918c1a45a
I accidentally broken the cortex-a53 because it directly includes files
from cortex-a15. Rather than revert that part, just copy over the files
that are needed directly so we don't run into this in the future.
Test: Built the aosp_angler-userdebug target using cortex-a53 as the
Test: arm target. Then built the bionic unit tests and ran them on
Test: an angler.
Change-Id: Id89e240b31f94e99f5076e1de973a9344486ec35
Remove new version of the cortex-a15 that caused a regression. We are never
going to revisit that code, and it is only confusing things.
Also remove the setting of MEMCPY_BASE and use the correct include
directly.
Test: Compiled angler with 32 bit arch as cortex-a15. Ran 32 bit bionic
Test: unit tests on angler.
Change-Id: I9372c01758fd7a596849c87b1a3f805bb477c94f
Regenerating the NOTICE file the other day left me scratching my head at
various "how do they differ?" cases, resolved by this patch.
Test: N/A
Change-Id: I4230bfa1d7ec842a4b9fb8c73dd3b39443d74054
All the other architectures name this label. Copy them.
(Following discussion of d30bc9e74b8ff3afceac973d334023564e64dbd2.)
Bug: https://llvm.org/bugs/show_bug.cgi?id=30308
Change-Id: I4f20163f569041180d87c79ce6ed856b70704271
Simple fix for the above error caused by the location
of a label "1:"
Change-Id: I9b1c816871e95f9bcf8135a5e0cc88de65771315
Signed-off-by: MinSeong Kim <minseong.kim@linaro.org>
These directories all have Android.bp files that are always used now,
delete the Android.mk files.
Change-Id: Ib0ba2d28bff88483b505426ba61606da314e03ab
It turns out that clang can emit code where the sp is saved in the r7
register on arm. Unfortunately, a lot of our syscalls overwrite that
value while the syscall is executing, so unwinding through that syscall
fails.
Update the syscall generation code to add unwinding information for
these uses.
Bug: 28411713
(cherry picked from commit 6e45d37dec)
Change-Id: Ib775effc44c4113735fe9032b0602b9d63e3e390
It turns out that at least the Nexus 9 kernel is built without CONFIG_QUOTA.
If we decide we're going to mandate quota functionality, I'm happy for us to
be a part of CTS that ensures that happens, but I don't want to be first, so
there's not much to test here other than "will it compile?". The strace
output looks right though.
Bug: http://b/27948821
Bug: http://b/27952303
Change-Id: If667195eee849ed17c8fa9110f6b02907fc8fc04
{get,set}domainname aren't in POSIX but are widely-implemented
extensions.
The Linux kernel provides a setdomainname syscall but not a symmetric
getdomainname syscall, since it expects userspace to get the domain name
from uname(2).
Change-Id: I96726c242f4bb646c130b361688328b0b97269a0
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Make it easier to diagnose applications mucking with the contents of
jmp_buf by checksumming its contents.
Bug: http://b/27417786
Change-Id: I9989e2ea3979a36ae0bc4c9e1bacafddbacc731b
This involves actually implementing assembler __memset_chk for arm64,
but that's easily done.
Obviously I'd like this for all architectures (and all the string functions),
but this is low-hanging fruit...
Change-Id: I70ec48c91aafd1f0feb974a2555c51611de9ef82
Our FORTIFY _chk functions' implementations were very repetitive and verbose
but not very helpful. We'd also screwed up and put the SSIZE_MAX checks where
they would never fire unless you actually had a buffer as large as half your
address space, which probably doesn't happen very often.
Factor out the duplication and take the opportunity to actually show details
like how big the overrun buffer was, or by how much it was overrun.
Also remove the obsolete FORTIFY event logging.
Also remove the unused __libc_fatal_no_abort.
This change doesn't improve the diagnostics from the optimized assembler
implementations.
Change-Id: I176a90701395404d50975b547a00bd2c654e1252
We had these symbols incorrectly versioned as LIBC_PRIVATE
in M release. This change moves __aeabi* symbols from LIBC
to LIBC_N and adds __gnu_Unwind_Find_exidx to the list
Bug: https://github.com/android-ndk/ndk/issues/1
Change-Id: I0b353012adeacb00ae29ea10c63b9d1cf1cadbe7
The mremap definition was incorrect (unsigned long instead of int) and
it was missing the optional new_address parameter.
Change-Id: Ib9d0675aaa098c21617cedc9b2b8cf267be3aec4
This moves the generic arm/arm64/x86 settings into the main makefiles
and makes the rest of them derivatives. This better aligns with how
soong handles arch/cpu variants.
Also updates the Android.bp to make it consistent with the make
versions.
Change-Id: I5a0275d992bc657459eb6fe1697ad2336731d122
ARM deprecates using the SP register in the register lists for ldm
and stm, which LLVM emits a warning for.
Bug: http://b/25017080
Change-Id: Ib427e3dfd5740e251f1ad91ebb66534e0d7b72a9
For the __release and __release_rt functions, the previous macros
would add a dwarf cfi entry for the function with no values. This works
with libunwind since it always tries the arm unwind information first.
This change removes those entries by creating a no dwarf version of the
assembler macro.
Change-Id: Ib93e42fff5a79b8d770eab0071fdee7d2afa988d
This bug will happen when these circumstances are met:
- Destination address & 0x7 == 1, strlen of src is 11, 12, 13.
- Destination address & 0x7 == 2, strlen of src is 10, 11, 12.
- Destination address & 0x7 == 3, strlen of src is 9, 10, 11.
- Destination address & 0x7 == 4, strlen of src is 8, 9, 10.
In these cases, the dest alignment code does a ldr which reads 4 bytes,
and it will read past the end of the source. In most cases, this is
probably benign, but if this crosses into a new page it could cause a
crash.
Fix the labels in the cortex-a9 strcat.
Modify the overread test to vary the dst alignment to expost this bug.
Also, shrink the strcat/strlcat overread cases since the dst alignment
variation increases the runtime too much.
Bug: 24345899
Change-Id: Ib34a559bfcebd89861985b29cae6c1e47b5b5855
The routines optimized for cortex-a7 and cortex-a53 cause performance
drops on cortex-a57. Instead create a target that is the middle ground
that works relatively well on either core.
Change-Id: Ie2b6cc9a59a01c7b30602ee368b2b90f5e886289
Reuse the top bits of _JB_SIGFLAG field previously used to store a
boolean to store a cookie that's validated by [sig]longjmp to make it
harder to use as a ROP gadget. Additionally, encrypt saved registers
with the cookie so that an attacker can't modify a register's value to
a specific value without knowing the cookie.
Bug: http://b/23942752
Change-Id: Id0eb8d06916e89d5d776bfcaa9458f8826717ba3
Add an optimized memset that is ~20% faster for cortex-a7 and
cortex-a53.
Add a 32 bit optimized cortex-a53 memcpy that is about ~20% faster
on cached data.
Fix the cortex-a15 __str{cat,cpy}_chk.S, memcpy_base.S to remove
the phony functions, since they aren't needed any more. Then add
a direct include of these for cortex-a53.
Verified the new functions by stepping through all of the major
paths and verifying the backtrace is still correct.
Bug: 22696180
Change-Id: Iec92a3f82d51243cca76c9aff9f35d920ff865ae
On the path that only uses r0 in both the krait and cortex-a9
memset, remove the push and use r3 instead.
In addition, for cortex-a9, remove the artificial function since
it's not needed since dwarf unwinding is now supported on arm.
Change-Id: Ia4ed1cc435b03627a7193215e76c8ea3335f949a
When there is arm assembler of this format:
ldmxx sp!, {..., lr} or pop {..., lr}
bx lr
It can be replaced with:
ldmxx sp!, {..., pc} or pop {..., pc}
Change-Id: Ic27048c52f90ac4360ad525daf0361a830dc22a3
A continuation of commit 2825f10b7f.
Add O_PATH compatibility support for flistxattr(). This allows
a process to list out all the extended attributes associated with
O_PATH file descriptors.
Change-Id: Ie2285ac7ad2e4eac427ddba6c2d182d41b130f75
Support O_PATH file descriptors when handling fgetxattr and fsetxattr.
This avoids requiring file read access to pull extended attributes.
This is needed to support O_PATH file descriptors when calling
SELinux's fgetfilecon() call. In particular, this allows the querying
and setting of SELinux file context by using something like the following
code:
int dirfd = open("/path/to/dir", O_DIRECTORY);
int fd = openat(dirfd, "file", O_PATH | O_NOFOLLOW);
char *context;
fgetfilecon(fd, &context);
This change was motivated by a comment in
https://android-review.googlesource.com/#/c/152680/1/toys/posix/ls.c
Change-Id: Ic0cdf9f9dd0e35a63b44a4c4a08400020041eddf
There's no reason to have multiple years in our own copyright headers,
and given the stupidity of our NOTICE file generation, it just creates
more junk.
Change-Id: I065a3811c2e2584e3b649a18ad9460286bc72b92
All arch-arm and arch-arm64 .S files were compiled
by gcc with and without this patch. The output object files
were identical. When compiled with llvm and this patch,
the output files were also identical to gcc's output.
BUG: 18061004
Change-Id: I458914d512ddf5496e4eb3d288bf032cd526d32b
With a different memcpy, __memcpy_base_aligned ceased to exist.
Instead, point to the name defined by whatever includes memcpy_base.S
Change-Id: I242cf49cbada35337ba155d7f170e86a905ff55f
This doesn't affect code like Chrome that correctly ignores EINTR on
close, makes code that tries TEMP_FAILURE_RETRY work (where before it might
have closed a different fd and appeared to succeed, or had a bogus EBADF),
and makes "goto fail" code work (instead of mistakenly assuming that EINTR
means that the close failed).
Who loses? Anyone actively trying to detect that they caught a signal while
in close(2). I don't think those people exist, and I think they have better
alternatives available.
Bug: https://code.google.com/p/chromium/issues/detail?id=269623
Bug: http://b/20501816
Change-Id: I11e2f66532fe5d1b0082b2433212e24bdda8219b
This makes unwind symbols 'protected',
which should prevent them from relocating
against libc++.so/libcutls.so.
This is temporary file and it is going
to be removed once libc.so stops exporting
them.
Bug: http://b/19958712
Change-Id: I96a765afe47e68d2e2ceb288870e63a25ca52081
The kernel system call faccessat() does not have any flags arguments,
so passing flags to the kernel is currently ignored.
Fix the kernel system call so that no flags argument is passed in.
Ensure that we don't support AT_SYMLINK_NOFOLLOW. This non-POSIX
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html)
flag is a glibc extension, and has non-intuitive, error prone behavior.
For example, consider the following code:
symlink("foo.is.dangling", "foo");
if (faccessat(AT_FDCWD, "foo", R_OK, AT_SYMLINK_NOFOLLOW) == 0) {
int fd = openat(AT_FDCWD, "foo", O_RDONLY | O_NOFOLLOW);
}
The faccessat() call in glibc will return true, but an attempt to
open the dangling symlink will end up failing. GLIBC documents this
as returning the access mode of the symlink itself, which will
always return true for any symlink on Linux.
Some further discussions of this are at:
* http://lists.landley.net/pipermail/toybox-landley.net/2014-September/003617.html
* http://permalink.gmane.org/gmane.linux.lib.musl.general/6952
AT_SYMLINK_NOFOLLOW seems broken by design. I suspect this is why this
function was never added to POSIX. (note that "access" is pretty much
broken by design too, since it introduces a race condition between
check and action). We shouldn't support this until it's clearly
documented by POSIX or we can have it produce intuitive results.
Don't support AT_EACCESS for now. Implementing it is complicated, and
pretty much useless on Android, since we don't have setuid binaries.
See http://git.musl-libc.org/cgit/musl/commit/?id=0a05eace163cee9b08571d2ff9d90f5e82d9c228
for how an implementation might look.
Bug: 18867827
Change-Id: I25b86c5020f3152ffa3ac3047f6c4152908d0e04
The overflow's actually in the generic C implementation of memchr.
While I'm here, let's switch our generic memrchr to the OpenBSD version too.
Bug: https://code.google.com/p/android/issues/detail?id=147048
Change-Id: I296ae06a1ee196d2c77c95a22f11ee4d658962da
* changes:
Use LOCAL_LDFLAGS_64 instead of enumerating 64-bit architectures
Fix typo in cpu variant makefile depenendency for arm64
Remove libc_static_common_src_files
Share LP32 makefile settings between arches
Add <var>_32 to patch-up-arch-specific-flags, and move the LP32
cruft varaibles from the 32-bit arch specific makefiles into the
top level Android.mk.
Change-Id: Id3fcf6805d4af048c2524c94b1295416ebe7d057
In https://android-review.googlesource.com/#/c/127908/5/libc/SYSCALLS.TXT@116
Elliott said:
for LP64 these will be hidden. for LP32 we were cowards and left
them all public for compatibility (though i don't think we ever
dremeled to see whether it was needed). we don't have an easy
way to recognize additions, though, so we can't prevent adding
new turds.
Add a mechanism to prevent the adding of new turds, and use that
mechanism on the fchmod/fchmodat system calls.
Bug: 19233951
Change-Id: I98f98345970b631a379f348df57858f9fc3d57c0
Many libc functions have an option to not follow symbolic
links. This is useful to avoid security sensitive code
from inadvertantly following attacker supplied symlinks
and taking inappropriate action on files it shouldn't.
For example, open() has O_NOFOLLOW, chown() has
lchown(), stat() has lstat(), etc.
There is no such equivalent function for chmod(), such as lchmod().
To address this, POSIX introduced fchmodat(AT_SYMLINK_NOFOLLOW),
which is intended to provide a way to perform a chmod operation
which doesn't follow symlinks.
Currently, the Linux kernel doesn't implement AT_SYMLINK_NOFOLLOW.
In GLIBC, attempting to use the AT_SYMLINK_NOFOLLOW flag causes
fchmodat to return ENOTSUP. Details are in "man fchmodat".
Bionic currently differs from GLIBC in that AT_SYMLINK_NOFOLLOW
is silently ignored and treated as if the flag wasn't present.
This patch provides a userspace implementation of
AT_SYMLINK_NOFOLLOW for bionic. Using open(O_PATH | O_NOFOLLOW),
we can provide a way to atomically change the permissions on
files without worrying about race conditions.
As part of this change, we add support for fchmod on O_PATH
file descriptors, because it's relatively straight forward
and could be useful in the future.
The basic idea behind this implementation comes from
https://sourceware.org/bugzilla/show_bug.cgi?id=14578 , specifically
comment #10.
Change-Id: I1eba0cdb2c509d9193ceecf28f13118188a3cfa7
Interestingly, this mostly involves cleaning up our implementation of
various <string.h> functions.
Change-Id: Ifaef49b5cb997134f7bc0cc31bdac844bdb9e089
I also suspect that libc/arch-arm/bionic/memcmp.S is supposed to like in the
generic directory these days, but this change just removes dead code.
Change-Id: I9072488df6e9b7261d79b6014914a0e937cb387b
Directly save data into stack without properly adjustment
of stack point is dangous. For example, if a signal comes,
kernel will put sigframe into userspace's stack, which
will overwrite the saved data if sp is not adjusted properly.
Bug: 15195265
Change-Id: Iea0cadfd3b94d50cf40252ad52fe5950811b9192
Signed-off-by: Jiangli Yuan <a6808c@motorola.com>
