-
上下文定义
标准的label取名方式是需要被遵守的,因为很多宏里面就直接用了。。
hwservice_contexts
这里标注的是使用
hwbinder
的服务通信的接口标准的label取名方式是以
_hwservice
结尾hwbinder
是框架与供应商内容之间的ipc通信模块同理,还有个
vndbinder
,是供应商内容之间的ipc通信模块Android 8 之后,原先的
binder
只适用于框架内通信service_contexts
这里记录的是注册/寻找 binder service 的时候的key
对应到的是ServiceManager.addService(String name, IBinder service)
publishBinderService(String name, IBinder service)
ServiceManager.getService(String name)
中的name
标准的label取名方式是以
_service
结尾file_contexts / genfs_contexts
它们都是用来指定文件的上下文标签
一般来说,file_contexts
用来指定那些inode
能够保存上下文信息的文件系统 的 文件上下文
比如system
和vendor
分区这些上下文被应用的时机是打包生成镜像的时候genfs_contexts
则一般用来记录诸如/sys
、/proc
这样的没有inode
的文件系统的 上下文信息genfs_contexts
被应用的时机是在开机时但是,有一种特殊情况,那就是由于
genfs_contexts
并不支持正则匹配,因此某些需要正则匹配的/sys
或者/proc
内容依然会被放到file_contexts
中,这些内容的应用时机也是在开机时标准的label取名方式:
- 可执行文件 以
_exec
结尾 - 其它文件,按需 或 按照
system/sepolicy
中的某些已经type
的东西进行定义
- 可执行文件 以
宏定义
hal_attribute(<hal_name>)
用来定义三个
attribute
分别是hal_<hal_name>
hal_<hal_name>_client
hal_<hal_name>_server
但是在device tree中直接使用这个宏会导致大规模的neverallow错误,第三方有个workaroundhttps://review.lineageos.org/c/LineageOS/android_device_lineage_sepolicy/+/286541
暂时还不明白原理hal_client_domain(, <hal_type>)
将
<domain>
定义为<hal_type>_client
hal_server_domain(, <hal_type>)
将
<domain>
定义为<hal_type>_server
domain_auto_trans(, , )
当
<olddomain>
执行label为<type>
的文件时,自动转换进程的domain为<newdomain>
init_daemon_domain()
这是对上面那个宏的进一步封装
当init
进程(domain为init
的进程)执行被label为<domain>_exec
的文件时,自动转换进程domain为<domain>
这是非常常用且重要的一个宏,在为新的可执行文件配置sepolicy的时候必然会用到
从这里可以看出按照标准进行命名的重要性了吧
-
binder_use / vndbinder_use / hwbinder_use ()
允许
<domain>
使用不同种类的binder如果一个服务需要使用binder进行通信(包括向对应service manager注册服务),则需要进行此声明
注意:对于使用
hwbinder
的服务,如果已经为其定义了hal_server_domain
或hal_client_domain
,则无需再声明hwbinder_use
,原因是上述两个宏会自动将<domain>
标注为halserverdomain
,从而间接获得hwbinder
的使用权限binder_call(, )
允许
<clientdomain>
向<serverdomain>
发起binder IPC通信add_hwservice(, )
允许
<domain>
向hwservice manager
注册<service>
接口<service>
接口的具体信息定义在hwservice_contexts
中它会自动生成
neverallow
规则,不再允许别的服务注册这一接口hal_attribute_hwservice(, )
这是对上面那个宏的进一步封装
它调用add_hwservice(<attribute>_server, <service>)
并允许<attribute>_client
向hwservice manager
搜索这个服务
它会自动生成neverallow
规则,不再允许非_server
或_client
的domain
注册或查找服务说白了,允许服务端增加服务接口,允许客户端查找获取服务
很显然,它是需要与
hal_attribute
、hal_client_domain
、hal_server_domain
配合使用的又是一个规范命名的重要性? -
流程
常见的,套路?
一般可执行文件
- 创建两个
type
。一个作为可执行文件执行时的domain
,另一个则是给可执行文件的本体使用(<domain>_exec
) - 在
file_contexts
中,为可执行文件本体打上<domain>_exec
的type
- 使用
init_daemon_domain
来实现执行可执行文件时自动切换domain
(否则所有的scontext
都会为init
) - 根据其所需权限,为其撰写规则
HIDL HAL
- HAL本身是可执行文件,因此在可执行文件的基础上进行
- 配置
hwservice_contexts
,声明HAL的接口 - 额外声明
hal_attribute
,即hal本体、_server
和_client
的attribute
- 使用
hal_server_domain
将上述“一般可执行文件”中的domain
定义为server - 将使用HAL的对象定义为
hal_client_domain
- 使用
add_hwservice
允许server增加服务 - 使用
binder_call
允许server和client之间进行通信 - link: https://blog.xzr.moe/archives/111/
- 创建两个
08-08
2007
![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png)
05-08
3946
![](https://csdnimg.cn/release/blogv2/dist/pc/img/readCountWhite.png)