summaryrefslogtreecommitdiffstats
path: root/ashmemd_client.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Reland 'Check /dev/binder access before calling defaultServiceManager()'android-q-preview-6android-q-preview-5android-q-preview-4android-q-preview-2.5Tri Vo2019-04-081-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vendor processes do not have access to /dev/binder. Calling defaultServiceManager() without RW permission will crash the process with error message "Binder driver could not be opened. Terminating." Normally, VNDK version of libcutils.so would not have the codepath of ashmemd. However, on non-VNDK this codepath is exercised. We check if the current process has permissions to /dev/binder before calling defaultServiceManager() to avoid crashing. The calling code in libcutils.so handles inability to connect ashmemd correctly. It will fall back to opening /dev/ashmem directly. Vendor code should already have permissions for that. This SELinux denial shows which permissions need to be checked for: avc: denied { read write } for name="binder" dev="tmpfs" ino=5570 scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:binder_device:s0 tclass=chr_file permissive=0 Note that the problem only manifests on non-VNDK devices. Bug: 129073672 Test: ashmemd_test Test: VtsHalSensorsV1_0TargetTest --gtest_filter=SensorsHidlTest.AccelerometerAshmemDirectReportOperationNormal Test: atest CtsOsTestCases:android.os.cts.SeccompTest#testIsolatedServicePolicy Change-Id: I23bef7986298811ce2bd84c3fdc9c9e22837c368
* Revert "Reland 'Check /dev/binder access before calling ↵Tri Vo2019-03-281-5/+0
| | | | | | | | | | defaultServiceManager()'" This reverts commit a526f3d41640506ebd457c2ed91b923d6f187d0b. Reason for revert: b/129483782 Isolated apps don't have seccomp permissions to access() syscall. CTS seccomp test is broken. Change-Id: I90ddf2016c8d2e433d2c8a4f8dd5e8563104533e
* Reland 'Check /dev/binder access before calling defaultServiceManager()'Tri Vo2019-03-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vendor processes do not have access to /dev/binder. Calling defaultServiceManager() without RW permission will crash the process with error message "Binder driver could not be opened. Terminating." Normally, VNDK version of libcutils.so would not have the codepath of ashmemd. However, on non-VNDK this codepath is exercised. We check if the current process has permissions to /dev/binder before calling defaultServiceManager() to avoid crashing. The calling code in libcutils.so handles inability to connect ashmemd correctly. It will fall back to opening /dev/ashmem directly. Vendor code should already have permissions for that. This SELinux denial shows which permissions need to be checked for: avc: denied { read write } for name="binder" dev="tmpfs" ino=5570 scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:binder_device:s0 tclass=chr_file permissive=0 Note that the problem only manifests on non-VNDK devices. Bug: 129073672 Test: ashmemd_test Test: VtsHalSensorsV1_0TargetTest --gtest_filter=SensorsHidlTest.AccelerometerAshmemDirectReportOperationNormal Change-Id: If7319d09d092946d6f9bfac0d15b6ca2eae85a24
* Revert "Check /dev/binder access before calling defaultServiceManager()"Tri Vo2019-03-251-5/+0
| | | | | | | | This reverts commit 41b7c708217752a4b30cc022b5917957274c47e2. Reason for revert: boot denial on sailfish/marlin Change-Id: I3dad32c3b07bcab0a0bfffb9a06d66f767af7391
* Check /dev/binder access before calling defaultServiceManager()Tri Vo2019-03-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Vendor processes do not have access to /dev/binder. Calling defaultServiceManager() without RW permission will crash the process with error message "Binder driver could not be opened. Terminating." Normally, VNDK version of libcutils.so would not have the codepath of ashmemd. However, on non-VNDK this codepath is exercised. We check if the current process has permissions to /dev/binder before calling defaultServiceManager() to avoid crashing. The calling code in libcutils.so handles inability to connect ashmemd correctly. It will fall back to opening /dev/ashmem directly. Vendor code should already have permissions for that. This SELinux denial shows which permissions need to be checked for: avc: denied { read write } for name="binder" dev="tmpfs" ino=5570 scontext=u:r:hal_sensors_default:s0 tcontext=u:object_r:binder_device:s0 tclass=chr_file permissive=0 Note that the problem only manifests on non-VNDK devices. Bug: 129073672 Test: ashmemd_test Test: VtsHalSensorsV1_0TargetTest --gtest_filter=SensorsHidlTest.AccelerometerAshmemDirectReportOperationNormal Change-Id: I6f4992fd701de77db7b0f9a1b0f1c7b58e547aec
* ashmemd: avoid sleep cycle on non-VNDK devices.android-q-preview-1Tri Vo2019-02-081-3/+10
| | | | | | | | | | | On non-VNDK device (e.g. sailfish) the code path to ashmemd is the same, which results in vendor processes always failing to get ashmemd service. Use checkService() to fail immediately, instead of waiting for the service. Fixes: 123999623 Test: boot sailfish, no sleep cycles when trying to reach ashmemd. Change-Id: I4fce14fad28b509cd112370bc4cc2eafd45c6c75
* ashmemd: daemon that provides /dev/ashmem fdsTri Vo2019-02-041-0/+49
Motivation: we want to replace /dev/ashmem with memfd. To do so we need all usage of /dev/ashmem to go through libcutils. Once that happens, we migrate libcutils to use memfd. ashmemd is our way to enforce that apps are using the existing ASharedMemory_create API and not bypassing it to go directly to /dev/ashmem. ashmemd serves opened file descriptors. The following way should be the only way for apps to open an fd to /dev/ashmem: app -> ASharedMemory_create -> libcutils -> ashmemd -> /dev/ashmem Bug: 113362644 Test: ashmemd_test Change-Id: I9068cefa950f91dba0f1b75daca23f02d933b1c8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 13:57:03 +0000