OpenHarmony 3.1 Release + Linux 原厂内核Launcher起不来问题分析报告

详情：OpenHarmony 3.1 Release + Linux 原厂内核Launcher起不来问题分析报告

1、关键字

Launcher无法启动；原厂内核；Access Token ID；

2、问题描述

芯片：rk3566；rk3399

内核版本：Linux 4.19，是RK芯片原厂发布的rk356x 4.19稳定版内核

OH版本：OpenHarmony 3.1 Release

问题现象：将OpenHarmony kernel修改移植到rk3566上，对接OpenHarmony 3.1 Release版本，Launcher起不来，移植停留在开机动画界面。

移植步骤：

1)、导入rk356x芯片厂家内核到构建系统中。

2)、收到合入hdf patch

3)、移植accesstoken id驱动

4)、dts文件适配开发板

5)、defconfig使用的是Linux 5.10 rk3568的config文件

3、问题原因

3.1 正常机制

应用能够正常安装

3.1.1 应用安装相关过程

应用安装时会使用分布式数据库KvStore更新metaData，KvStore会调用阮总先接口获取LocalDeviceId。

对应代码调用关系：

KvStoreDataService::UpdateMetaData()

-->kv_store，DeviceKvStoreImpl::GetLocalDeviceId()

--> kv_store，KvStoreUtils::GetProviderInstance().GetLocalDevice()

-->SoftBus IPC接口，SoftBusAdapter::GetLocalDevice()

-->SoftBus IPC接口，GetLocalNodeDeviceInfo()

-->SoftBus Server，GetLocalNodeDeviceInfo()

3.1.2 软总线SA初始化相关过程

SoftBusServer::OnStart() // 软总线SA启动函数

foundation\communication\dsoftbus\core\frame\standard\init\src\softbus_server.cpp softbus_server.cpp

----> InitSoftBusServer() // 调用软总线初始化

foundation\communication\dsoftbus\core\frame\common\src\softbus_server_frame.c

----> AuthInit() // 调用认证管理模块初始化

foundation\communication\dsoftbus\core\authentication\src\auth_manager.c auth_manager.c

----> HichainServiceInit() // 调用Hichain初始化

foundation\communication\dsoftbus\core\authentication\src\auth_manager.c auth_manager.c

---->GetGmInstance()->regDataChangeListener

// 调用安全子系统设备互信认证部件的接口获取设备群组管理实例，然后注册数据变化Listener

foundation\communication\dsoftbus\core\authentication\src\auth_manager.c auth_manager.c

---->IpcGmRegDataChangeListener() //即调用中的IpcGmRegDataChangeListener函数

base\security\deviceauth\frameworks\src\ipc_sdk.c

---->DoBinderCall()

base\security\deviceauth\frameworks\src\standard\ipc_adapt.cpp

----> ProxyDevAuthData::ActCall

base\security\deviceauth\frameworks\src\standard\ipc_dev_auth_proxy.cpp

----> ProxyDevAuth::DoCallRequest()

base\security\deviceauth\frameworks\src\standard\ipc_dev_auth_proxy.cpp

----> ServiceDevAuth::OnRemoteRequest //IPC调用到服务端

base\security\deviceauth\frameworks\src\standard\ipc_dev_auth_stub.cpp

----> Security::AccessToken::CheckPermission() //调用AccessTokenKit检验调用者权限

base\security\deviceauth\services\frameworks\src\permission_adapter\permission_adapter.cpp

3.2 异常机制

Access Token补丁没有合入全面，导致软总线SA初始化失败，导致服务异常、分布式数据库GetLocalDevice失败，进一步导致应用安装失败

4 解决方案

补齐kernel/fork.c中关于Access Token的修改，补齐后验证应用可以正常起来。

5 定位过程

5.1 应用安装失败的原因

软总线SA初始化失败，导致服务异常或者Crash，导致分布式数据库GetLocalDevice失败，进一步导致应用安装失败。

关键异常打印如下：

dsoftbus_standard: [LNN]init softbus failed

SoftBusAdapter::GetLocalDevice: GetLocalNodeDeviceInfo error

KvStoreDataService::UpdateMetaData: failed to get local device id KvStoreDataService::GetSingleKvStore: failed to write meta

BundleMgrService: [distributed_data_storage.cpp(GetKvStore):237] return error

5.2 软总线SA初始化失败的原因

因为软总线SA的AccessToken tokenID不合法，在Hichain初始化时ProxyDevAuth::DoCallRequest被设备认证服务端校验权限不通过，打印tokenID is invalid，导致hichain init failed，进一步导致softbus framework init failed。

关键异常打印如下：

08-04 09:00:28.085 291 1127 I 00000/[DEVAUTH]: DoCallRequest: ProxyDevAuth, SendRequest...

08-04 09:00:28.085 263 536 I 02f01/AccessTokenKit: [GetTokenType]:GetTokenType called

08-04 09:00:28.085 263 536 E 02f01/AccessTokenKit: [GetTokenType]:tokenID is invalid

08-04 09:00:28.085 263 536 E 00000/[DEVAUTH]: CheckPermission: Invalid token type: -1

08-04 09:00:28.085 291 1127 I 00000/[DEVAUTH]: DoCallRequest: SendRequest done, ret -1

08-04 09:00:28.085 291 1127 I 00000/[DEVAUTH]: IpcGmRegDataChangeListener: process done, ret 12289

08-04 09:00:28.085 291 1127 E 015c0/dsoftbus_standard: [AUTH]auth RegDataChangeListener failed

08-04 09:00:28.085 291 1127 E 015c0/dsoftbus_standard: [AUTH]auth hichain init failed

08-04 09:00:28.085 291 1127 E 015c0/dsoftbus_standard: [COMM]softbus auth init failed.

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [AUTH]unregister auth trans callback, module = 1.

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [TRAN]PendigPackManagerDeinit init ok

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [AUTH]unregister auth trans callback, module = 0.

08-04 09:00:28.085 291 1127 I 015c0/dsoftbus_standard: [TRAN]server trans udp channel deinit success.

08-04 09:00:28.086 291 1127 E 015c0/dsoftbus_standard: [COMM]softbus framework init failed.

5.3 AccessToken TokenID不合法的原因

跑access_token_id的XTS用例，发现如下用例不过，子线程的access token id信息不对，ftoken跟父线程一致，实际应该为0。

推断创建线程时给token id初始化的值不对，可能是kernel/fork.c中kernel/fork.c的patch没打上。

让伙伴检查这段代码，确定是上述kernel/fork.c中的代码漏合导致。

6 知识分享

6.1 Access Token介绍

Access Token是3.1 release安全子系统新增的应用权限访问控制功能和权限增强特性，支持应用程序或者其他SA查询和校验应用权限、APL(Ability Privilege Level )等信息。

在OpenHarmony服务化的应用程序框架中，一切程序都是服务（元能力）。任何元能力间的访问，都需要进行访问权限控制。访问控制的机制通过采用AT访问令牌传递和令牌访问控制的策略来实现。

一个AT访问令牌由：

• 设备标识 DevID
• 应用身份标识APP ID
• 子用户ID
• 应用分身索引信息
• SA 服务ID( SA服务名字)
• TokenID ，表示权限令牌ID， 跨设备全局唯一。64bit。由以上字段结合场景进行组合生成，以lib形式提供生成 TokenID.

Android的应用访问权限管控手段，是面向实现的设计，比较混乱，包括Platform签名、Privilege特权应用、UID=1000特权、MDM权限证书等等，且不能应用于分布式场景。OpenHarmony的Access Token机制，有总体的设计，能够分布式传输。

OpenHarmony应用程序框架提供的API，分成Signature、Privilege和Normal三级。

API等级/APL等级	APL 3	APL 2	APL 1
API Level Signature	Y	N	N
API Level Privilege	Y	Y	N
API Level Normal	Y	Y	Y

凡是不能访问的API，必须通过AACL（API ACL）机制来实现策略的关联。

6.2 Access Token内核补丁

在使用三方内核适配OpenHarmony系统时，需要打上Access Token内核补丁，补丁链接如下。

https://gitee.com/openharmony/kernel_linux_4.19/pulls/4

https://gitee.com/openharmony/kernel_linux_4.19/pulls/5

6.3 Access Token调测知识

补丁打成功后，会有相应的的字符设备/dev/access_token用于和用户态交互。

并且在每个进程或线程的pcb信息中会有tokenid信息，包括自身tokenid和首调者tokenid。