ueventd为init进程的一个关联模块,为linux底层提供读取服务。
Android-Q版本后,google不在允许kernel直接访问一些设备树的文件节电(flip_opn, file_read等方法),统一要求采用request_firmware.如下所示,kernel属于coredomain集合,但是不在允许coredomain访问mnt/vendor路径下的文件。除了init进程ueventd进程vold进程以及system_writes属性进程(没找到这是啥,没有明确使用的地方)。
从这里可以看到,android还是为kernel访问文件留了后门的。
typeattribute kernel coredomain
neverallow {
coredomain
-init
-ueventd
-vold
-system_writes_mnt_vendor_violators
} mnt_vendor_file:dir *;
Request_firmware
驱动加载fw时,往往需要从文件系统中读取二进制文件。采用request_firmware方法有效的控制了入口的一致性,对安全性和debug以及google的GKI要求有了明显帮助。request_firmware方法具体流程如下:
request_firmware()
->_request_firmware(uevent)
->firmware_fallback_platform()
->kobject_uevent(&fw_sysfs->dev.kobj, KOBJ_ADD)
ueventd#ueventd_main()
->uevent_handler->HandleUevent()
-> FirmwareHandler#ProcessFirmwareEvent()
-> LoadFirmware(firmware_directory + file)
firmware_directory
对于fw而言,firmware_directory是一个在ueventd.rc中配置的变量,google允许开发者配置firmware_directory来确认自己的fw存放在哪个路径下。firmware_directory的最终值由以下几个文件决定:
system/etc/ueventd.rc
vendor/ueventd.rc
odm/ueventd.rc
最终firmware_directory的实际配置为:
firmware_directory = system/etc/ueventd.rc#firmware_directory +?vendor/ueventd.rc#firmware_directory +?odm/ueventd.rc#firmware_directory
这样各个厂商也可以自行配置firmware路径,形成差异化:具体代码如下
static UeventdConfiguration GetConfiguration() {
auto hardware = android::base::GetProperty("ro.hardware", "");
std::vector<std::string> legacy_paths{"/vendor/ueventd.rc", "/odm/ueventd.rc",
"/ueventd." + hardware + ".rc"};
std::vector<std::string> canonical{"/system/etc/ueventd.rc"};
if (android::base::GetIntProperty("ro.product.first_api_level", 10000) < __ANDROID_API_T__) {
// TODO: Remove these legacy paths once Android S is no longer supported.
canonical.insert(canonical.end(), legacy_paths.begin(), legacy_paths.end());
} else {
// Warn if newer device is using legacy paths.
for (const auto& path : legacy_paths) {
if (access(path.c_str(), F_OK) == 0) {
LOG(FATAL_WITHOUT_ABORT)
<< "Legacy ueventd configuration file detected and will not be parsed: "
<< path;
}
}
}
return ParseConfig(canonical);
}
|