iOS 10 has <sys/random.h> with getentropy, glibc >= 2.25 has
<sys/random.h> with getentropy and getrandom. (glibc also pollutes
<unistd.h>, but that seems like a bad idea.)
Also, all supported devices now have kernels with the getrandom system
call.
We've had these available internally for a while, but it seems like the
time is ripe to expose them.
Bug: http://b/67014255
Test: ran tests
Change-Id: I76dde1e3a2d0bc82777eea437ac193f96964f138
GMM calls this system call directly at the moment. That's silly.
Bug: http://b/36405699
Test: ran tests
Change-Id: I1e14c0e5ce0bc2aa888d884845ac30dc20f13cd5
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
Both be91052932 and
e2faf07d65 were submitted about
two days ago. The former changed how the syscalls stubs were
generated, but the latter was submitted using the old stub
format.
Use the new stub format for setdomainname.S
Change-Id: I578acd7053f57a275f6831dd2404ef04826c578e
{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>
This patch uses __kernel_vsyscall instead of "int 0x80"
as the syscall entry point. AT_SYSINFO points to
an adapter to mask the arch specific difference and gives a
performance boost on i386 architecture.
Change-ID: Ib340c604d02c6c25714a95793737e3cfdc3fc5d7
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
The mremap definition was incorrect (unsigned long instead of int) and
it was missing the optional new_address parameter.
Change-Id: Ib9d0675aaa098c21617cedc9b2b8cf267be3aec4
This patch give the possibility of time vdso support on 32bit kernel.
If the 32bit x86 kernel provides gettimeofday() and clock_gettime()
primitives in vdso. In this case make bionic use them. If the kernel
doesn't provide them, fallback to the legacy system call versions.
Change-Id: I87b772a9486fa356903e1f98f486ab9eb0b6f6f7
Signed-off-by: Robert Jarzmik <robert.jarzmik@intel.com>
Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
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
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
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
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
Add the missing prototypes, fix the existing prototypes to use clockid_t
rather than int, fix clock_nanosleep's failure behavior, and add simple
tests.
Bug: 17644443
Bug: https://code.google.com/p/android/issues/detail?id=77372
Change-Id: I03fba369939403918abcabae9551a7123953d780
Signed-off-by: Haruki Hasegawa <h6a.h4i.0@gmail.com>
The use of the .hidden directive to avoid going via the PLT for
__set_errno had the side-effect of actually making __set_errno
hidden (which is odd because assembler directives don't usually
affect symbols defined in a different file --- you can't even
create a weak reference to a symbol that's defined in a different
file).
This change switches the system call stubs over to a new always-hidden
__set_errno_internal and has a visible __set_errno on LP32 just for
binary compatibility with old NDK apps.
(cherry-pick of 7efad83d430f4d824f2aaa75edea5106f6ff8aae.)
Bug: 17423135
Change-Id: I6b6d7a05dda85f923d22e5ffd169a91e23499b7b
In practice, with this implementation we never need to make a system call.
We get the main thread's tid (which is the same as our pid) back from
the set_tid_address system call we have to make during initialization.
A new pthread will have the same pid as its parent, and a fork child's
main (and only) thread will have a pid equal to its tid, which we get for
free from the kernel before clone returns.
The only time we'd actually have to make a getpid system call now is if
we take a signal during fork and the signal handler calls getpid. (That,
or we call getpid in the dynamic linker while it's still dealing with its
own relocations and hasn't even set up the main thread yet.)
Bug: 15387103
Change-Id: I6d4718ed0a5c912fc75b5f738c49a023dbed5189
__set_errno returns -1 exactly so that callers don't need to bother.
The other architectures were already taking advantage of this, but
no one had ever fixed x86 and x86_64.
Change-Id: Ie131494be664f6c4a1bbf8c61bbbed58eac56122
System calls can be pretty slow. This is mako, which has one of our
lowest latencies:
iterations ns/op
BM_unistd_getpid 10000000 209
BM_unistd_gettid 200000000 8
Bug: 15297299 (kernel panic from too many gettid calls)
Bug: 15315766 (excessive gettid overhead in liblogd)
Change-Id: I49656c0fc5b5d092390264a59e4f2c0d8a8b1aeb
The syscall generation always used 4 bytes for each push cfi directive.
However, the first push should always use an offset of 8 bytes, each
subsequent push after that is only 4 bytes though.
Change-Id: Ibaabd107f399ef67010b9a08213783957c2f74a9
The problem with the original patch was that using syscall(3) means that
errno can be set, but pthread_create(3) was abusing the TLS errno slot as
a pthread_mutex_t for the thread startup handshake.
There was also a mistake in the check for syscall failures --- it should
have checked against -1 instead of 0 (not just because that's the default
idiom, but also here because futex(2) can legitimately return values > 0).
This patch stops abusing the TLS errno slot and adds a pthread_mutex_t to
pthread_internal_t instead. (Note that for LP64 sizeof(pthread_mutex_t) >
sizeof(uintptr_t), so we could potentially clobber other TLS slots too.)
I've also rewritten the LP32 compatibility stubs to directly reuse the
code from the .h file.
This reverts commit 75c55ff84e.
Bug: 15195455
Change-Id: I6ffb13e5cf6a35d8f59f692d94192aae9ab4593d
This reverts commit ced906c849.
Causes issues on art / dalvik due to a broken return value
check and other undiagnosed issues.
bug: 15195455
Change-Id: I5d6bbb389ecefb0e33a5237421a9d56d32a9317c
glibc doesn't have tkill or tgkill and says "use syscall(3) instead".
I've left tgkill since it's quite widely used, but there's no reason
to have tkill as well.
Bug: 11156955
Change-Id: Ifc0af750320086f829bc9914551c172b501f3b60
This was accidentally added at a time when you couldn't add a constant
to <syscall.h> without generating an assembly stub! (You no longer need
to add the constants at all.)
Bug: 11156955
Change-Id: I053c17879138787976c744a5ecf7d30ee51dc48f
