To pave the way to reducing app's kernel attack surface, this change
split the single filter into one for system and one for apps. Note that
there is current no change between them.
Zygote will apply these filters appropriately to system server and apps.
Keep set_seccomp_filter() for now until the caller has switched to the
new API, which I will do immediately after this before the two filters
diverse.
Also remove get_seccomp_filter() since it doesn't seem to be used
anyway.
Test: diff the generated code, no difference except the variable names
Test: cts -m CtsSecurityTestCases -t android.security.cts.SeccompTest
Bug: 63944145
Change-Id: Id8ba05a87332c92ec697926af77bc5742eb04b23
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
We've never really used __restrict: only <string.h> and <stdio.h> (which
are still very similar to upstream BSD headers) consistently have these
annotations. Neither clang nor GCC warns for trivial cases, and there's
little obvious documentation benefit.
Bug: http://b/30833514
Test: builds
Change-Id: I3e4384281865475d0c55d764b546d8166419ee31
This seccomp failure is in the fault handler:
05-25 12:03:25.042 10201 27425 27425 F DEBUG : backtrace:
05-25 12:03:25.042 10201 27425 27425 F DEBUG : #00 pc 00015380
/data/data/redacted/files/storage/lib/libcrashsdk.so
So whenever an app using this crash sdk crashes it looks like a seccomp
problem. Fixing this won't stop the apps crashing, but will make the
crash reports accurate and useful.
So yes, the bug below is already fixed, but this issue has come back 2
or 3 times with different apps (latest is b/62874867). This change
doesn't fix that crash either, but again it improves the reporting.
Bug: 62090571
Test: Device boots, app still fails but no longer with SECCOMP error
Change-Id: Ie0f8dc965001c8bc43f6a545b35bdcd38f006213
fstat64/fstatat64/_flush_cache were accidentally put in SYSCALLS.TXT in:
https://android-review.googlesource.com/#/c/390454/
This patch just moves them to SECCOMP_WHITELIST.TXT because we do not
want stubs accidenatally generated for the mentioned syscalls using
gensyscalls.py script.
This commit does not introduce any functional changes to mips64_policy.cpp.
Test: Run genseccomp.py -> File seccomp/mips64_policy.cpp not changed.
Test: Run gensyscalls.py -> INFO:root:no changes detected!
Change-Id: I3b527b3d9f18715c44a4e6ddc6db6e49f48f4890
Signed-off-by: Miodrag Dinic <miodrag.dinic@imgtec.com>
Add some useful new syscalls that we currently aren't using in bionic,
but might in the future to the seccomp whitelist.
Bug: http://b/37317198
Test: mma
Change-Id: I6550867da152cea84fb13d0c15a399cdb2acf1aa
Bug: 37253880
Test: Make sure device boots
Run pylint on genseccomp.py, test_genseccomp.py
Run test_genseccomp.py
Run new CTS test
cts-tradefed run cts -m CtsSecurityTestCases -t android.security.cts.SeccompTest
Change-Id: I833a5364a1481d65173e77654da1798dc45a3f9d
Test: Make sure arm, x86, x86_64, mips, mips64 emulators boot
Make sure sailfish still boots
Ran CTS test from
https://android-review.googlesource.com/#/c/348671/3 and it passed
The instructions for how to run mips emulators above worked, but
the CTS tests did not seem to actually run.
Change-Id: Iddee5acdb19ed32c7bd4657573313ca439cf6a49
