There is a desire to ensure that modprobe as a service can log to
kmesg to help triage issues, so add support for the -s or --syslog
flag to do so.
Bug: 159424228
Bug: 151950334
Test: use modprobe as a service to load modules, check logs
Change-Id: I884995f364b0fc604861797eb90d7225a372f864
Some vendor apps are using platform key for signing.
This moves them to untrusted_app domain when the system partition is
switched to a Generic System Image (GSI), because the value of
platform's seinfo in /system/etc/selinux/plat_mac_permissions.xml
has been changed.
Duplicating the device-specific platform seinfo into
/vendor/etc/selinux/vendor_mac_permissions.xml to make it
self-contained within the vendor partition.
Bug: 157141777
Test: boot the device with a GSI, then `adb shell ps -eZ | grep qtidata`
Test: ./build/make/tools/releasetools/sign_target_files_apks \
--default_key_mappings path/to/keydir \
-o out/dist/<lunch>-target_files-*.zip \
signed-tardis-target_files.zip and checks the platform seinfo in
/vendor/etc/selinux/vendor_mac_permissions.xml is replaced.
Change-Id: Ic9a79780e30f456138e4de67210cc60ac2e490d6
Merged-In: Ic9a79780e30f456138e4de67210cc60ac2e490d6
(cherry picked from commit 8a86424e34)
Some vendor apps are using platform key for signing.
This moves them to untrusted_app domain when the system partition is
switched to a Generic System Image (GSI), because the value of
platform's seinfo in /system/etc/selinux/plat_mac_permissions.xml
has been changed.
Duplicating the device-specific platform seinfo into
/vendor/etc/selinux/vendor_mac_permissions.xml to make it
self-contained within the vendor partition.
Bug: 157141777
Test: boot the device with a GSI, then `adb shell ps -eZ | grep qtidata`
Test: ./build/make/tools/releasetools/sign_target_files_apks \
--default_key_mappings path/to/keydir \
-o out/dist/<lunch>-target_files-*.zip \
signed-tardis-target_files.zip and checks the platform seinfo in
/vendor/etc/selinux/vendor_mac_permissions.xml is replaced.
Change-Id: Ic9a79780e30f456138e4de67210cc60ac2e490d6
This is unused currently & there are no concrete plans to use it
in the future.
Bug: 130080335
Test: Device boots up & connects to networks.
Test: Will send for regression tests
Change-Id: I785389bc2c934c8792c8f631362d6aa0298007af
Merged-In: I785389bc2c934c8792c8f631362d6aa0298007af
(cherry picked from commit 56dfc06397)
This is needed for libmodprobe to pass module options on the kernel
commandline to kernel modules when they are loaded.
Bug: 155422904
Change-Id: I9df7e211765268815bfb9269365264f5ca468712
Merged-In: I9df7e211765268815bfb9269365264f5ca468712
This is needed for libmodprobe to pass module options on the kernel
commandline to kernel modules when they are loaded.
Bug: 155422904
Change-Id: I9df7e211765268815bfb9269365264f5ca468712
Tuner default implementation is testing with Ion buffer on Cuttlefish
to make sure the secure handle merchanism would work with media data
pass between the Tuner Hal and the Tuner Java.
Ion access would be needed for all the Tuner Hal implementation
Test: atest
Bug: 150952766
Change-Id: I39117f96bdc84ce24afcb3ef528b6d942ded505e
Bug: 148098383
Test: built and ran with new version
Change-Id: I06f8f2cd73dce73111559664871bdd3c9b814d7c
Merged-In: I06f8f2cd73dce73111559664871bdd3c9b814d7c
(cherry picked from commit a010cef7ad)
This grants default access to the new GNSS subsystem for Linux to the
GNSS HAL default implementation. The GNSS subsystem creates character
devices similar to ttys but without much unneeded complexity. The GNSS
device class is specific to location use cases.
Bug: 151670529
Change-Id: I03b27aa5bbfdf600eb830de1c8748aacb9bf4663
CAN HAL needs access to /sys/devices to search for USB serial numbers
for SocketCAN devices and for USB serial devices.
Bug: 142654031
Test: Manual + VTS
Change-Id: I3d9bff94f8d8f936f7d859c01b9ff920fcbc5130
This is useful for tools like dumpsys, so that they work on all services
equally as well. Also, so that there is no difference with the regular
service manager.
Bug: 150579832
Test: 'adb shell /vendor/bin/dumpsys -l' shows 'manager'
Test: denial is no longer present:
03-05 12:23:47.346 221 221 E SELinux : avc: denied { add } for pid=221 uid=1000 name=manager scontext=u:r:vndservicemanager:s0 tcontext=u:object_r:service_manager_vndservice:s0 tclass=service_manager permissive=0
Change-Id: Id6126e8277462a2c4d5f6022ab67a4bacaa3241e
(cherry picked from commit 52a96cc7dd)
This is useful for tools like dumpsys, so that they work on all services
equally as well. Also, so that there is no difference with the regular
service manager.
Bug: 150579832
Test: 'adb shell /vendor/bin/dumpsys -l' shows 'manager'
Test: denial is no longer present:
03-05 12:23:47.346 221 221 E SELinux : avc: denied { add } for pid=221 uid=1000 name=manager scontext=u:r:vndservicemanager:s0 tcontext=u:object_r:service_manager_vndservice:s0 tclass=service_manager permissive=0
Change-Id: Id6126e8277462a2c4d5f6022ab67a4bacaa3241e
This change updates sepolicies for automotive display service to make it
available to the vendor processes.
Bug: 149017572
Test: m -j selinux_policy
Change-Id: I48708fe25e260f9302e02749c3777c0ca0d84e4b
Signed-off-by: Changyeon Jo <changyeon@google.com>
(cherry picked from commit 17b38d526d)
This change updates sepolicies for automotive display service to make it
available to the vendor processes.
Bug: 149017572
Test: m -j selinux_policy
Change-Id: I48708fe25e260f9302e02749c3777c0ca0d84e4b
Signed-off-by: Changyeon Jo <changyeon@google.com>
The credstore service is a system service which backs the
android.security.identity.* Framework APIs. It essentially calls into
the Identity Credential HAL while providing persistent storage for
credentials.
Bug: 111446262
Test: atest android.security.identity.cts
Test: VtsHalIdentityTargetTest
Test: android.hardware.identity-support-lib-test
Change-Id: I5cd9a6ae810e764326355c0842e88c490f214c60
Fixes the following denial:
type=1400 audit(0.0:4): avc: denied { read } for comm="android.hardwar" name="compatible" dev="sysfs" ino=28205 scontext=u:r:hal_bootctl_default:s0 tcontext=u:object_r:sysfs_dt_firmware_android:s0 tclass=file permissive=0
This permission is needed for ReadDefaultFstab, which searches the device tree for fstab entries. Devices that use dt-fstab may fail to find the misc block device.
Bug: 143589455
Test: manual test
Change-Id: Ied52fe9b1056d26b4dd00811c4690fa4c505fae8
pmem uses a block file while access_ramoops uses a char file. Allow both for
now until we can unify on pmem.
Additionally allow the reading of vendor properties so it can read the
path to the character or block device to open.
Test: atest VtsHalRebootEscrowTargetTest
Bug: 146400078
Change-Id: Ief61534e0946480a01c635ce1672579959ec8db5
This adds the type and permissions for the default implementation to talk to
its kernel module.
Bug: 63928581
Test: boot Pixel 4 with default implementation
Change-Id: Ie847e4db975b95e90ea64937401e8d8a8ed812cb
When an OTA is downloaded, the RecoverySystem can be triggered to store
the user's lock screen knowledge factor in a secure way using the
IRebootEscrow HAL. This will allow the credential encrypted (CE)
storage, keymaster credentials, and possibly others to be unlocked when
the device reboots after an OTA.
Bug: 63928581
Test: make
Test: boot emulator with default implementation
Test: boot Pixel 4 with default implementation
Change-Id: I1f02e7a502478715fd642049da01eb0c01d112f6
SLCAN setup requires certain ioctls and read/write operations to
certain tty's. This change allows the HAL to set up SLCAN devices while
complying with SEPolicy.
In addition to adding support for SLCAN, I've also included permissions
for using setsockopt. In order for the CAN HAL receive error frames from
the CAN bus controller, we need to first set the error mask and filter
via setsockopt.
Test: manual
Bug: 144458917
Bug: 144513919
Change-Id: I63a48ad6677a22f05d50d665a81868011c027898
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the sepolicy changes to move the recovery resources from
system to vendor. The big change is renaming install_recovery*.te to
vendor_install_recovery*.te to emphasize the move to vendor. Other changes
follow from that. The net result is that the application of the recovery patch
has the same permissions that it had when it lived in system.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: If29cb22b2a7a5ce1b25d45ef8635e6cb81103327
Since these libraries were vndk-sp, previously, passthrough HALs were
able to load them. However, now that they have been removed from the
vndk-sp set (these libraries are empty), marking them as
same_process_hal_file so that vendor passthrough implementations that
still link against these empty libraries can still use them.
Bug: 135686713
Test: boot device using these libraries from an sphal (otherwise,
bootloops)
Change-Id: Ic5170eb0fcbb87c82bbea840dcfcb17899eaa899
(cherry picked from commit 71a596a49b443e5ae3518301ffdf9e6b95d4d94d)
Since these libraries were vndk-sp, previously, passthrough HALs were
able to load them. However, now that they have been removed from the
vndk-sp set (these libraries are empty), marking them as
same_process_hal_file so that vendor passthrough implementations that
still link against these empty libraries can still use them.
Bug: 135686713
Test: boot device using these libraries from an sphal (otherwise,
bootloops)
Change-Id: Ic5170eb0fcbb87c82bbea840dcfcb17899eaa899
This duplicated ashmem device is intended to replace ashmemd.
Ashmem fd has a label of the domain that opens it. Now with ashmemd
removed, ashmem fds can have labels other than "ashmemd", e.g.
"system_server". We add missing permissions to make ashmem fds usable.
Bug: 139855428
Test: boot device
Change-Id: Iec8352567f1e4f171f76db1272935eee59156954
Since this was an example service providing no real functionality and
accidentally got installed on a device.
Bug: 140115084
Test: install on test device and see that it runs
Change-Id: I553da8e1f4da7d6a9f0c3e7d4a3561f0b22321dc
The audio HAL service name previously contained the audio HAL version
of the first audio HAL it supported.
Nevertheless, the same service can and do host all audio HAL versions.
Aka there is only one audio HAL service, and the version in its name is
technical dept and should not be changed.
This caused many confusions during vendor HAL upgrade as the
service version number was erroneously updated leading to
device boot loop.
The new service name is:
android.hardware.audio.service
The old one was:
android.hardware.audio@2.0-service
Keeping both names valid as most phones will not rename
the service immediately.
Bug: 78516186
Test: boot & check the audio HAL is up with the old and new name
Change-Id: I2ce0182fd919af6eb8325d49682b4374be00344e
Signed-off-by: Kevin Rocard <krocard@google.com>
![](/avatar/ef4a85532a29218c6b19b60e782b0746?size=56 "Harpreet \\"Eli\\" Sangha"){kind=small}
