背景MarkDown格式可以直接github上查看https://github.com/vessial/ba

背景

MarkDown格式可以直接github上查看

https://github.com/vessial/baseband/blob/master/Qualcomm_BaseBand_Messaging_and_State_Machine.md

本技术分析文章通过对高通的4/5G移动基带系统进行深入逆向工程提示其内部消息通信机制以及核心架构设计逻辑，本文的研究基于高通的4G基带MDM9707以及5G基带模块sdx55的固件之上分析完成，高通基带系统现在都是基于高通主流的hexagon DSP指令架构来实现，该架构非常适合应用于音视频编解码，计算机视觉等，软件无线电等应用中的浮点和向量计算，在高通骁龙处理器的子系统中大量使用，大多应用于手机，汽车，可穿戴设备以及移动通信设备中，Hexagon DSP相关信息可以从这里获取，运行在Hexagon DSP芯片上的操作系统QuRT是由高通设计的实时操作系统，高通基带系统所有的上层业务将会运行在该操作系统之上，阅读该技术分析文章之前，假定你已经对操作系统的原理有所了解，例如CPU调度，IPC(进程间通信)，以及基本的数据队列enqueue/dequeue的操作。

消息机制简介

一个系统里面运行着不同的任务，不同任务在不同的运行状态在处理相应的业务逻辑时可能需要与其它任务交换数据或者同步信息，这里面就需要操作系统的底层IPC机制来完成了，3GPP组织定义了不同移动通信技术从物理层/链路层/逻辑处理层等各种标准，例如（5GNR/4GLTE/3G WCDMA/TD-SCDMA/CDMA2000/2G /GSM等通信技术），这些技术标准在基带系统里面实现会被划分成不同的任务来维护不同的状态，处理不同的消息信令，以及维护不同通信技术的切换等操作，比如现在的大部分智能手机基带系统基本上都支持2/3/4G通信相关的技术，这些基带系统根据移动运营商支持的移动通信技术和国家区域支持的标准的不同会使用相应的移动通信技术，比如中国在3G时代中国移动使用的TD-SCDMA，而中国联通使用的是WCDMA技术，为了保证移动设备的一些基本功能的可用性（语音通信和sms短信息），比如某些地方部署了4G基站，你可以在那里使用4G LTE的（Voice-over-IP/SMS-over-IP）通信技术，在一些偏远的地区可能只部署了2G基站，这时基带系统根据环境切换到GSM的协议栈，这些功能的维护与切换从基带系统层面来讲都需要系统消息机制来配合完成。

高通基带系统的消息机制建立在运行的实时操作系统QuRT之上，之前我有一篇文章有简单介绍过底层IPC机制，今天我将详细介绍上层业务逻辑相关的消息传递机制与数据结构。我们把运行在基带系统上的业务逻辑实体的最小单位定义为线程（thread），根据线程生命周期的不同分为以下两大类：

• 短生命周期线程

• 驱动/任务初始化线程（Driver initiator/Services Launcher)

• 中断服务例程（IST)

• 长生命周期线程

• 阻塞型消息接受线程

消息通信底层API封装简介：

//信号发送
int rex_send_sigs(utcb *dst_task_obj,unsigned int signal_id);
//第一个参数为向目标任务发送消息的结构定义，第二个参数为要发送的信号id
int rex_wait_sigs(unsigned int recv_sigs_masks);
//第一个参数为可以允许接受信号id的掩码，每个任务最多可以设置可接受信号id个数为32个，每个任务可以接受多个信号id时，通过信号id的或操作来得到该任务可以接受信号的掩码，返回值为接受到的信号id
//如果是带数据的信号发送，封装底层API，类似如下
int send_sigs_with_dat(utcb *dst_task_obj,unsigned int signal_id,data_queue *send_data_queue);
int recv_sigs_with_dat(unsigned int recv_sigs_masks,data_queue *recv_data_queue);

而根据任务线程的业务功能的不同划分成以下几大类：

• 系统功能任务

• 通信技术协议栈分层任务

• GSM/WCDMA/TDSCDMA/LTE L1/L2/L3相关的协议栈的任务等

• 上层应用任务

• IMS volte/ecall/数据服务/包服务等

• 外设相关的任务

• UIM/SIO/A2等

我在这里记录了高通MDM9607基带系统一次实时运行的任务快照列表。

高通基带系统消息机制

消息通信核心架构设计逻辑

• 兼容性

• 在新的基带芯片上面开发新的移动通信技术单元的同时，保证老的功能模块能够正常使用，例如在开发5G功能的同时，以往的4G/3G/2G功能都能够正常使用和切换。

• 可扩展性

• 在已有的功能模块上增加新的功能，具备灵活的扩展性，而不需要作太大的软件和硬件改动。

• 低耦合性

• 新增的功能模块与已有系统上功能模块的耦合度低，接口少，减少引入问题的接口点和测试成本。

基于以上的设计理念，高通设计一套灵活的消息通信系统，一直到现在5GNR的基带系统也在用，接下来我将详细介绍该消息系统的架构，相关的算法和数据结构。

消息通信架构

为了区分不同任务所接受到的消息以及任务所能处理相应消息的原语操作权限，通过接受到的消息来区分消息来源以及接受到相应消息后的相应的处理动作，高通的消息系统引入了任务消息接受体（msgr_client）和UMID（Unique Message ID）的机制，任务消息接受体由相应的任务创建生成，并通过初始注册可接受消息UMID来设置任务相应原语操作的权限，每个任务可以创建一个或者多个msgr_client，每一个UMID消息也可以注册给多个msgr_client，每一个UMID消息标示着一次相应的原语操作，在MDM9607里面定义的UMID数量多达1万多个，而在最新高通的5G基带里面可使用的UMID高达2万多，每个UMID背后都对应着相应的原语操作，UMID的值与相应的命名规则如下。

UMID由32位组成，结构如下表

注：if type_id>9 ,type_id=type_id-6offset bit 8~15 8bits type_id list

举个例子UMID 0x40D120E 对应的描述原语是LTE_RRC_IRAT_FROM_LTE_TO_G_RESEL_REQI，拆分结果如下:

注：这种UMID值的解析方法在某些定义里面并不适用，比如LTE_ML1_DLM_TST_SKIP_RACH_REQ的值为6，就没法用上面的方法解析，有些值并不严格遵循这种解析算法，可能是由于历史原因，定义UMID值的规则不一样。

基带系统把任务标示为多个不同的技术大类，来标示和模块化相应的子功能，以MDM9607为例：

模块ID

下图是MDM9607 LTE的部分子模块ID的对应关系

关键消息发送API:

msgr_send(umsg *buf,uint32 buf_size);
struct umsg{
       struct msgr_hdr_struct_type{ 
                uint32  dest_umid;  //offset 0      ，要发送的UMID号
                uint16  src_tech_mod_id; //offset 4，发送源tech_mod_id的标识
                uint8    num_attach;// offset 7
                uint8    tail_flag ;// offset 8 ，头部结尾标志0x7f
                uint8    inst_id;// offset 9，
    }
         uint8 send_dsm_flag;//offset 0x10 ,置1表示发送数据通过dsm结构承载的标志
         dsm *dsm_obj;//offset 0x14 , 发送数据dsm结构指针
 }
msgrq_wait(void *msgr_client_ptr,void *msg_recv_buf,uint32 msg_recv_buf_size,uint32 *msg_recvd_size_ptr);//接受消息的函数
msgr_register(uint16 mod_id,void *msgr_client_ptr,void *mailbox_obj,uint32 umid);//msgr_client注册umid的消息路由

消息路由

我们已经了解到UMID所对应原语操作的含义，如果需要执行相应的原语操作，只需要向注册过UMID的模块发送umid消息即可，接下来我们需要了解umid消息是如何路由到相应模块(tech_mod_id)的消息接收器(msgr_client)的，下面会详细介绍相应的算法和数据结构，我整理了几张表来描述。

struct msgr_client_desc{ //全局msgr_client结构描述
    uint32 umids_registered;
    uint16 msgr_client_reg_type;//1 ->msgrq_sig type,2-> rexq_sig
    uint16 tech_mod_id;//
    union *msg_sig_p{ //offset 0x10
        struct msgrq_sig *msgq_p;//msgr reg type 1,4G及以后使用的mailbox消息传递系统
        struct rexq_sig *rexq_p;//msgr reg type 2,兼容2G/3G时代使用的Rex IPC消息传递系统
    }
    struct msgrq *msgrq_p;//offset 0x14 ,if reg type 1    
    struct msgr_client_obj *msgr_client_obj_ptr;//offset 0x30
    
}
struct msgr_client_obj{//msgr_client结构体
     unsigned int msgr_client_reg_type;//1-> msgrq aka mailbox,2->rex_q,接受消息的方式
     unsigned int register_umid_counts;//offset 8 ,消息接受器注册的umid的总数
     unsigned int total_reged_recv_signal_counts;//offset 0x0c,注册的接受消息的signal的个数
     union sig_recv_obj{
       msgrq_sig  *msgrq_signal_obj;// offset 0x10 msgrq_sig type,4/5G未来的主流类型
       rexq_sig *rex_signal_obj;//offset 0x10  rexq_sig type ,这个主要是为了兼容之前2/3G的系统的数据结构
     }    
     unsigned int task_recv_signal_set_mask;//offset 0x14 ,注册的接受消息的signal号的掩码
     uint32 err_counts;//offset 0x18
     unsigned int recvd_signal_id;//offset 0x1c,当前接受到的signal id,msgr_client_reg_type为1
     struct msgrq *recvd_msgrq_ptr;//offset 0x20,当前接受消息承载的msgrq对象,msgr_client_reg_type为1
     struct msgrq *msgrq_first_entry;// offset 0x24,接受msgrq消息链表结构指针,msgr_client_reg_type为1
     unsigned int total_msgrq_counts;//offset 0x28, 可以接受msgrq消息的总数,通过可以task_recv_signal_set_mask来确定,msgr_client_reg_type为1
 }
 
 struct msgrq_sig{
    uint32 sig_ready_flag;//must be 1
    struct sig_def{
        uint32 signal_id_for_recv;//offset 8
        uint32 signal_reged_wait_mask;//offset 0xc
        void * kernel_msg_queue;
        unsigned int attribute;
    };
    
    
 }
 struct rexq_sig{ //size 0x1c, 兼容2/3G系统的数据结构
     utcb *msgr_client_utcb_ptr;//offset 0  任务接受消息使用的utcb标识
     uint32 msgr_client_signal_id;//offset 4 接受消息使用的signal id
     msg_queue *msgr_out_msg_q;//offset 0x8
     msg_queue *rex_msg_in_q;//offset 0xc
     uint16 msg_data_q_used_size;//offset 0x10
     uint16 rexq_id;//offset 0x12
     uint16 msg_data_q_size;//offset 0x14
 }
  struct msg_data_q{
         struct msg_data_q *prev_q;
         struct msg_data_q *next_q;
         char data[msg_data_q_size-8];
     }
 struct msg_queue{
    struct msg_data_q *headp;
    struct msg_data_q *tailp;
    uint32 total_q_counts;
 }
 
 struct msgrq{
    void *msg_recv_buf_header;//offset 0
    void *msg_recv_end_buf;//offset 4
    char msgrq_name[16];//offset 0x10
    int msgrq_recvd_seq;//ofset 0x18
    unsigned int reged_recv_signal_id_mask;//offset 0x1c,可供接受消息signal的掩码
    void *msgr_buf_remain_ptr;//offset 0x20,可供接受消息的剩余空间起始地址
    void *msgr_recv_buf;//offset 0x24,当前接受到消息的buf地址
    uint32 msgr_buf_remain_size;//offset 0x28
    unsigned int total_msg_recv_buf_size;//offset 0x30
    int8 is_buf_in_use;//offset 0x70 ,0-> in use, 1-> not in use
    uint32 recvd_msg_blocks;//offset 0x58 ,收到的消息次数总和
    struct msgrq *next_msgrq;//offset 0x74
 }

为了更方便的理解上述的数据结构的关系与操作算法，画了一张简单的图来加深该消息系统的理解。通过以上算法和数据结构，可以很方便的完成UMID与tech_mod_id的消息路由的注册，消息发送等操作。

需要说明的一点就是一个tech_mod_id可能会关联多个msgr_client，所以msgr_client_id就成了消息传递的唯一标识，通过msgr_client_id得到全局的msgr_client_desc的结构定义，该结构体里面包含接受消息的任务utcb和接受消息的signal id，这里通过tech_mod_id 0xf19对应的MM（Mobility Management）任务进行举例。

我在一个实时运行的MDM9607系统上面，描绘出所有UMID和tech_mod_id之间的消息路由情况，由于实在太大，可以在https://github.com/vessial/baseband/blob/master/umid_pro.svg 进行查看。

消息状态机（State Machine）

高通基带系统里面的消息状态机，是实现3GPP定义功能最重要的组成部分，消息状态机在移动通信系统里面扮演着非常重要的角色，也是多模移动通信系统的核心，3GPP在定义的多个移动通信技术的分层协议栈时，不同的通信技术模式之间切换，会通过状态机来维护相应的分层逻辑的状态和可操作功能，接下来将重要介绍高通基带系统使用的状态机数据结构以及相关算法，本文将研究主要流4G LTE和5G NR系统上使用的第二代状态机消息系统，老的第一代状态机系统不在这里介绍了。

struct sm_state_instance{ //eg ,size 0x1c
    struct sm_obj *sm;//状态机对象定义
    unsigned int current_state_id;//状态机当前所处的状态id
    unsigned int recvd_umid_in_sm_entity_seq;//offset 8, 状态机当前收到的umid所在状态机umid列表中的序列号
    unsigned int instance_id;// 状态机实例编号
    uint8 sm_state_lock;//offset 0x11 0->state unlock,1-> state lock 状态机锁的状态
    void *stm_idle_buf;//offset 0x14 状态机操作可能需要的buf空间
    unsigned int debug_code;//offset 0x18 状态机调试码
}
struct sm_obj{ //状态机的定义结构
    struct msgr_stm_obj *stm;
    unsigned char *stm_obj_name; //状态机的名称，例如LTE_RRC_SIB_SM
    unsigned int stm_obj_name_hash; //状态机名称的hash值
    unsigned int stm_inst_id;//stm instance id ，状态机的实例编号，状态机可能存在多个实例，通过这个编号来区别不同的状态机实体
}
struct msgr_stm_obj {
    int instance_counts; //该状态机支持的实例个数
    int state_cnts; //该状态机的状态数量
    struct state_status_def *state_def;//状态机每个不同状态的定义的数据结构,size state_cnts*0x10
    int umid_cnts;//状态机注册的可接受umid总数
    struct umid_msg_list *umid_msg_def;//存储umid和umid描述信息的指针,size umid_cnts*8
    
    struct umid_msg_states_func_cb_list *umid_in_state_cb;//存储着所有umid对应每个状态的回调操作函数
    void *cb_func1;// stm enter //offset 0x18 ,进入该状态机的回调函数
    void *cb_func2;// stm exit  //offset 0x1c ,退出该状态机的回调函数
    void *cb_func3;// stm error //offset 0x20 ,状态机出错的回调函数
    void *cb_func4; //stm debug //offset  0x24 ,状态机调试的回调函数
    unsigned int  init_state_id; // default 0 ,状态机初始默认状态id
}
struct umid_msg_states_func_cb_list {//状态机在接受到相应的umid后的原语操作回调函数
        void *umid_msg_in_states_1_cb_list[umid_cnts];
        void *umid_msg_in_states_2_cb_list[umid_cnts];
        void *umid_msg_in_states_3_cb_list[umid_cnts];
        ...
        void *umid_msg_in_states_state_cnts_cb_list[umid_cnts];
    }
struct state_status_def{//每个状态的定义
    unsigned char *state_name; //状态名称，eg,active/inactive etc
    void *cb_func1; //state enter //状态机进入该状态的回调函数
    void *cb_func2; //state exit  //状态机退出该状态的回调函数
    void *cb_func3; //state debug ?//可能是调试函数
}
struct umid_msg_list{//状态机可接受的umid消息定义
    unsigned char *umid_msg_name; //umid对应的描述名称
    unsigned int umid;            //umid
}
关键API描述
stm_instance_activate(struct sm_state_instance *sm_st_inst,uint32 inst_id,uint32 initial_state_id);//初始化状态机实例
stm_instance_process_input(uint32 state_id,struct sm_state_instance *sm_st_inst,uint32 sm_inst_id,uint32 umid_input,void *stm_payload_ptr);//对状态机接受到的umid和数据进行原语操作

我从MDM9607固件里面提取的详细的状态机信息可以在https://github.com/vessial/baseband/blob/master/lte_sm.log 进行查看。

3GPP定义的L3层的RRC(Radio Resource Control)的状态机是最为复杂的，高通在实现4G LTE的RRC时使用了大量的状态机进行功能管理。MDM9607 4G LTE RRC状态机类型如下:state name: LTE_RRC_CSG_ASF_SMstate name: LTE_RRC_DT_SM       //state name: LTE_RRC_IRAT_TO_G_MGR_SMstate name: LTE_RRC_LLC_SMstate name: LTE_RRC_CAPABILITIES_SMstate name: LTE_RRC_IRAT_FROM_1X_MGR_SMstate name: LTE_RRC_SEC_SM //sim认证和密钥协商管理相关的状态机state name: LTE_RRC_CRP_SMstate name: LTE_RRC_IRAT_FROM_DO_MGR_SM //负责从CDMA-EVDO切换到LTE的管理状态机state name: LTE_RRC_IRAT_FROM_TDS_MGR_SM //负责从TDSCDMA切换到LTE的状态机state name: LTE_RRC_PAGING_SM //寻呼管理的状态机state name: LTE_RRC_CONFIG_SM state name: LTE_RRC_MISC_SMstate name: LTE_RRC_MEAS_SMstate name: LTE_RRC_CEP_SMstate name: LTE_RRC_IRAT_TO_1X_MGR_SMstate name: LTE_RRC_IRAT_FROM_W_MGR_SMstate name: LTE_RRC_MDT_SMstate name: LTE_RRC_IRAT_TO_DO_MGR_SMstate name: LTE_RRC_CONTROLLER_SM  //关键的LTE的控制状态机，控制服务的停止和开启state name: LTE_RRC_IRAT_TO_TDS_MGR_SMstate name: LTE_RRC_IRAT_TO_W_MGR_SM  //从LTE切换到WCDMA的管理状态机state name: LTE_RRC_EMP_SMstate name: LTE_RRC_MH_SM
state name: LTE_RRC_UEINFO_SM  //UE信息管理的状态机state name: LTE_RRC_SIB_SM     //系统信息块的管理状态机state name: LTE_RRC_PLMN_SEARCH_SM  //搜索网络使用的状态机state name: LTE_RRC_IRAT_FROM_G_MGR_SM  //从GSM切换到LTE的状态机state name: LTE_RRC_CSP_SM  //cell search plmn状态机state name: LTE_RRC_ESMGR_SM // EMBMS管理状态机state name: LTE_RRC_CRE_SM

我们拿LTE_RRC_PAGING_SM状态机定义作例子与之对应的数据结构作解析

LTE_RRC_PAGING_SM addr 0xd10b35e0
     state machine name: LTE_RRC_PAGING_SM inst_cnts 1 total states 3  total umid 10
     state name: INITIAL state enter 0xd0b923a8 state exit 0xd0b923c8 state debug 0x0
     state name: IDLE_CAMPED state enter 0xd0b923e0 state exit 0xd0b92400 state debug 0x0
     state name: CONNECTED state enter 0xd0b92418 state exit 0xd0b92450 state debug 0x0
0x040d140c   LTE_RRC_CAMPED_INDI
0x040d0207   LTE_RRC_DRX_INFO_REQ
0x040d0206   LTE_RRC_SIM_UPDATE_REQ
0x040d0401   LTE_RRC_SERVICE_IND
0x040d0710   LTE_RRC_PAGING_DLM
0x040d1405   LTE_RRC_CONNECTED_INDI
0x040d022a   LTE_RRC_MTC_CFG_REQ
0x040d1400   LTE_RRC_STOPPED_INDI
0x040d140b   LTE_RRC_NOT_CAMPED_INDI
0x040d1402   LTE_RRC_SIB_UPDATED_INDI

下图为MDM9607 4G LTE_RRC的状态机图谱

<img src="https://github.com/vessial/baseband/raw/master/sm.svg" style="max-width:100%;">

状态机操作实例

为了更直观的理解消息状态机的操作过程，我这里提供了一个例子来展示消息传递过程以及状态机的处理过程，这个过程是在基带处理IDLE状态下，没有接入任何移动通信网络，到基带一次接入4G LTE网络到SIM认证的过程，这里只提供RRC的状态机的处理过程。

DL_DCCH的Information Transfer字段里面包含了来自MME发送过来的认证请求数据(LTE NAS EMM信令消息id 0x52)，包含有nas key set id, 16个字节的认证随机数据auth_param rand，以及16个字节的auth param AUTN数据，SIM卡通过收到的这两个关键信息进行认证，并计算生成Auth_resp发送给MME进行比较完成本地端和服务器端的认证，本地端计算如下。 

本地端收到的rand(16bytes)+AUTN(16bytes)
K为sim卡和MME都持有的sim卡的唯一隐私数据，sim卡端只有sim卡芯片可以读取。 

SIM卡端密钥派生认证过程，f1/2/3/4/5为sim卡的计算功能函数  

AK=f5(K,rand)  

IK=f4(K,rand)  

CK=f3(K,rand)  

RES=f2(K,rand) //计算给MME进行认证SIM卡的数据  

SQN=AUTN^AK  (6bytes)
AMF=AUTN[6:8]  

MAC=f1(K,SQN,rand,AMF)  

SIM卡端认证MME端过程  

sim_autn=SQN^AK(6bytes)+AMF(2bytes)+MAC(8bytes)  

比较MME发过来的AUTN和sim_autn ，相等则认为MME合法。 

基带把sim卡计算得到的RES通过LTE NAS EMM 信令消息号0x53包裹到UL_DCCH的InformationTransfer字段里面发给基站进而到MME进行认证。 

MME认证SIM卡的过程就比较简单了。MME端计算XRES=f2(K,rand)，然后比较收到的RES，相等表示MME认证SIM卡成功，至此认证完成。由于上述操作涉及EMM和RRC之间的交互过程比较复杂，这里只是简单提一下，EMM的状态机会在下一篇文章里面单独详细介绍。

结语

由于从全球公开的信息渠道中并不能获取高通基带系统的深入信息，所以花费1年多的时间通过对底层操作系统和上层3GPP实现的业务系统进行深度逆向工程，这篇文章只是系统性的介绍了高通4/5G基带系统的消息机制和消息状态机，我认为这是一个关键的架构设计，梳理清楚其消息架构对于理解3GPP实现的消息原语操作以及对移动通信技术的多模分层设计有非常大的帮助，该消息系统架构设计具有非常好的扩展性，可以很灵活的增加新的功能到该消息框架中去，可以很好的减少系统测试成本，有很多设计理念值得学习和借鉴，由于现今高通5G基带所支持的UMID操作数高达2万多个，所以这里的展示的例子只是揭示了状态机功能操作的冰山一角，后续会持续研究对于状态机安全漏洞的挖掘研究，实现高效的5G安全测试体系，通过对基带系统的深刻认知，可以更好的对基站系统和核心网系统进行安全评估。

阅读原文

跳转微信打开

Qualcomm QSEECOM接口漏洞

（CVE-2019-14040）漏洞分析

QualcommQSEECOM接口漏洞（CVE-2019-14040）漏洞分析

背景：

今天看到腾讯玄武实验室推送的一篇国外的安全公司zimperium的研究人员写的一篇他们分析发现的高通的QSEECOM接口漏洞文章，https://blog.zimperium.com/multiple-kernel-vulnerabilities-affecting-all-qualcomm-devices/其中一个Use-After-Free的漏洞（CVE-2019-14041）我觉得挺有意思，但是原文有些部分写的比较生涩或者没有提到关键点上，所以我想稍微续叼写的更具体一些，以及我对这种类型漏洞的一些思考或者是对我的启发，以及安全研究人员和产品开发人员对安全的理解方式。

这名叫TamirZahavi-Brunner的安全研究者在2019年的7月底发现两个高通QSEECOM接口的漏洞，一个是条件竞争的漏洞CVE-2019-14041，一个就是我今天要讲的内核内存映射相关的Use-After-Free漏洞CVE-2019-14040。

简单介绍一下这个QSEECOM接口，它是一个内核驱动连接用户态Normal world和Secure world的一个桥梁，Secure world就是我们常说的Trustzone/TEE/Security Enclave安全运行环境，Normalworld就是非安全运行环境，这个高通的QSEECOM接口可以实现一些从用户态加载/卸载一些安全的TA（TrustApplcation）到TrustZone中去运行，比如我们手机常用的指纹/人脸识别的应用，这些应用都是在TrustZone中运行的，在这种运行环境下，可以保证我们用户的关键隐私不被窃取，这个QSEECOM架构如下。

要想了解这个漏洞的成因，需要先了解这个QSEECOM接口的功能处理逻辑，用户态通过ION设备（一个内存管理器，可以通过打开/dev/ion进行访问）申请的内存可以通过QSEECOM接口映射到内核地址空间，可供内核或者TrustZone访问，而对于QSEECOM驱动模型中（/dev/qseecom）提供给用户的接口有open/close/ioctl，对应着QSEECOM内核处理函数为qseecom_open/qseecom_ioctl/qseecom_release。

漏洞成因：

说到Use-After-Free漏洞，我们需要先了解内存在哪里Free掉的，然后是在哪里Use的，如何Use的。

Free操作过程：

用户态每次打开qseecom设备（/dev/qseecom），都会在内核态生成一个qseecom_dev_handle的结构指针，这个结构指针会被关闭qseecom设备（用户态通过close函数）或者来自用户的IO操作号QSEECOM_IOCTL_UNLOAD_APP_REQ请求予以销毁，需要了解这个结构指针的销毁过程，那么得先了解这个指针的初始化过程。

打开qseecom设备时会调用qseecom_open分配一个qseecom_dev_handle结构体

static int qseecom_open(struct inode *inode, struct file*file)

{

    int ret = 0;

    structqseecom_dev_handle *data;

    data = kzalloc(sizeof(*data), GFP_KERNEL);

    if (!data)

       return -ENOMEM;

    file->private_data= data;

    data->abort = 0;

    …

用户通过QSEECOM_IOCTL_SET_MEM_PARAM_REQ ioctl请求通过函数qseecom_set_client_mem_param来建立用户态ion内存在内核地址空间的映射，而qseecom_set_client_mem_param函数通过copy_from_user函数来获取用户传递的ion用户内存的地址信息以及这个内存的长度信息，我把关键的代码标示出来。

staticint qseecom_set_client_mem_param(struct qseecom_dev_handle *data,

                     void __user *argp)

{

    ion_phys_addr_t pa;

    int32_t ret;

    struct qseecom_set_sb_mem_param_req req;

    size_t len;

    /* Copy the relevant information needed forloading the image */

    if (copy_from_user(&req, (void __user*)argp, sizeof(req)))

       return -EFAULT;

    ...

    data->client.ihandle =ion_import_dma_buf_fd(qseecom.ion_clnt,

                     req.ifd_data_fd);

    ...

    /* Get the physical address of the ION BUF*/

    ret =ion_phys(qseecom.ion_clnt, data->client.ihandle, &pa, &len);

    if (ret) {

       pr_err("Cannot get phys_addr for theIon Client, ret = %d\n",

           ret);

       return ret;

    }

    if (len < req.sb_len) {

       pr_err("Requested length (0x%x) is> allocated (%zu)\n",

           req.sb_len, len);

       return -EINVAL;

    }

    /* Populate the structure for sending scmcall to load image */

    data->client.sb_virt = (char *)ion_map_kernel(qseecom.ion_clnt,

                         data->client.ihandle);

    if (IS_ERR_OR_NULL(data->client.sb_virt)){

       pr_err("ION memory mapping forclient shared buf failed\n");

       return -ENOMEM;

    }

    data->client.sb_phys = (phys_addr_t)pa;

    data->client.sb_length = req.sb_len;

    data->client.user_virt_sb_base =(uintptr_t)req.virt_sb_base;

    return 0;

}

这个代码流程如下：

我们从qseecom_dev_handle结构体上能够发现client是它的子成员结构体

struct qseecom_dev_handle {

    enumqseecom_client_handle_type type;

    union {

        structqseecom_client_handle client;//这个指针没有置空

       structqseecom_listener_handle listener;

    };

    bool released;

…

struct qseecom_client_handle {

    u32  app_id;

    u8 *sb_virt;

    phys_addr_t sb_phys;

    unsigned longuser_virt_sb_base;

    size_t sb_length;

    struct ion_handle *ihandle;     /*Retrieve phy addr */

    charapp_name[MAX_APP_NAME_SIZE];

    u32  app_arch;

    structqseecom_sec_buf_fd_info sec_buf_fd[MAX_ION_FD];

    bool from_smcinvoke;

};

而销毁qseecom_dev_handle结构指针的时候只是把子成员结构体client的子成员ion_handle结构指针ihandle给置空了，client结构体的其它成员并没有置空，也就是说client结构体中的sb_virt地址还sb_length的值还是残留的，这也为后续的freed的内存重新use提供了前提。

static int qseecom_unmap_ion_allocated_memory(struct qseecom_dev_handle*data)

{

       int ret = 0;

       if(!IS_ERR_OR_NULL(data->client.ihandle)) {

              ion_unmap_kernel(qseecom.ion_clnt,data->client.ihandle);//解除用户态  ion内存到内核态的映射

              ion_free(qseecom.ion_clnt,data->client.ihandle);//

              data->client.ihandle= NULL; //只是把这个指针置空了

       }

       return ret;

}

Use的过程：

上面我们已经讲了qseecom_dev_handle的销毁的过程，接下来我们看看攻击者是如何使用释放掉的内存的。

我们知道当释放掉的内存被以同样大小以及同样的内存分配式来申请的时候，之前释放掉的内存是很容易被重新命中的，同理常见于浏览器use-after-free漏洞通过heap spray的方式进行大量内存申请来命中之前被释放掉的对象。之前我们说过了，通过qseecom_open打开qseecom设备的时候会分配一个qseecom_dev_handle结构体，但是很不幸的是这个初始化过程也没有完全把这片内存给清0。

static int qseecom_open(struct inode *inode, struct file *file)

{

       int ret = 0;

       structqseecom_dev_handle *data;

       data =kzalloc(sizeof(*data), GFP_KERNEL);

       if (!data)

              return -ENOMEM;

       file->private_data =data;

       data->abort = 0;

       data->type =QSEECOM_GENERIC;

       data->released =false;

       memset((void*)data->client.app_name, 0, MAX_APP_NAME_SIZE);//似乎还差一点点

这个初始化前后的内存对比是这样的

接下来就是use过程的关键了，我们的目标就是能够使用这些free掉的结构中残留的数据，如何能够保证残留数据可用，第一，残留的关键数据不被接下来的流程所覆盖，第二，保护流程正常走下去，现有的qseecom_dev_handle结构不被无效的操作释放。为了保证满足第二条，我们需要满足qseecom_dev_handle成员client的ihandle指针不能为空（__validate_send_service_cmd_inputs会检查），因为之前释放的时候这里被置空了。好的，现在只需要保证第一条，关键的残留数据不被覆盖就好了。

为了达到这个残留数据不被覆盖的目标，只需要用户态发送一个QSEECOM_IOCTL_SET_MEM_PARAM_REQ ioctl请求，且用户提交的ION内存分配的长度信息大于实际用户所分配的大小即可（例如用户只分配了0x1000字节内存，但是用户提交给内核说我分配了0x2000个字节，当然内核也不是傻子，你说多少就多少，内核说我要检查一下，检查发现，好小子你才分配了0x1000字节的内存，你却告诉我有0x2000字节，是不是当我傻，内核就立即返回操作出错的信息给用户），还记得上面提到的qseecom_set_client_mem_param函数处理流程吗? 虽然内核直接返回操作错误告之给用户态，但是最重要的是qseecom_dev_handle指针没有被销毁，而且就是因为这个错误的操作，那个残留数据也没有被覆盖，且结构体里面的ihandle也赋值了不为空，两个条件都满足了，然后接下来的正常业务处理逻辑将会把之前残留的sb_virt/sb_phys地址用于内存读写操作，完成真正的use操作。

当然最后这个漏洞的修补过程也比较简单，把client结构成员全部清空即可。

写到这里漏洞分析过程就结束了，这个漏洞的利用危害，我觉得比较容易实现的一点可能是泄露一些内存信息，这个需要关联上下文深入研究，作者说可能用于提权获取root权限，我觉得还是挺麻烦的，而且需要把不太可控的读写转化成可控的读写，比较复杂，最终也有可能利用不成功，因为越是复杂的系统掺杂的噪音越多，需要排查的东西也越多。

最后的一些思考：

也是我觉得比较有意思的一点，这个漏洞的根源当然是释放的内存没有清空，但是有一个很重要点就是内核态和用户态的状态机制不同步造成的（不知道这样说对不对），比如内核返回给用户说，我判断了，你给我的信息不对，你的行为不对，我警告过你了，但是用户根本不管，我继续做我认为是正确的事情，从这里可以看出安全研究人员与开发人员对于安全风险视角的不同了，或者可以看出安全研究人员是如何定位攻击面，如何挖掘漏洞的。

阅读原文

跳转微信打开

移动基带安全研究系列文章概念和系统篇 背景随着5G大浪潮的推进，未来万物互联将会有极大的井喷爆发的可能，而

移动基带安全研究系列文章

概念和系统篇

• 背景

随着5G大浪潮的推进，未来万物互联将会有极大的井喷爆发的可能，而移动基带系统作为连接世界的桥梁，必将成为未来非常重要的基础设施，而基础设施的技术自主能力已经上升到非常重要的国家层面上的战略意义，从美国对待中国的通信产商华为的禁令就可以看得出基础技术的发展对一个国家的震慑，现今人类的生产生活已经离不开移动通信，未来也将会继续是引领人类科技的发展的重要媒介，人工智能，自动驾驶，物联网以及你所能想到的一切科技相关的发展都会与移动通信产生重要的联系，在此之上其安全性和可靠性将会成为人类所关心的重要问题，这也是笔者为了写这个系列文章的初衷，也希望更多的安全研究人员参与到基础设施的安全研究当中来，挖掘出更多的缺陷与隐患，完善未来的基础设施的安全。

• 概念和研究目的

  3GPP  移动通信的标准化组织3^rd Generation Partnership Project，成立于上世纪末，主要职能是为了制订移动通信的技术标准，保证各个不同国家以及运营商在移动通信方面的兼容性，最常见的例子就是能够让我们的手机可以做到在不同的国家漫游使用。

3GPP所制定的移动通信技术标准涵盖了所有的2/3/4/5G通信相关的技术体系，产生了大量的技术文档供研究人员学习和参考，有兴趣的可以从3GPP的官方网站获取。

  本系列文章研究对像是指3GPP定义的移动通信相关2/3/4/5G的基带软硬件和通信系统，例如手机的语音/短信/数据流量，以及物联网中使用的相关移动通信技术的端设备。基带系统本身是泛指无线通信系统里面的软/硬件和通信技术的集合体，例如蓝牙/Wi-Fi/GSM都有基带系统，所以本系列文章所指的基带系统单指移动通信相关的2/3/4/5G技术相关的基带系统。

  研究对象和目的：高通的基带芯片以及对3GPP定义的对通信协议栈的实现，基带系统是一个非常庞大且复杂的系统，包括软/硬件和通信技术的完美融合，所以具有相关设计能力的芯片产商很少，从2018年基带芯片的市场份额分布，高通是这个领域市场份额做的最大的芯片产商，高通是多个国内手机产商的供应商，例如小米，oppo/vivo等，而华为现在已经有了自己基于海思芯片设计的基带系统，打破了国外基带芯片市场的垄断，现在华为的手机产品都是用的海思基带芯片，不过软件系统还是基于人家的vxworks，而基带系统又是非常封闭的系统，我研究的目的之一就是挖掘里面的一些设计逻辑，结合3GPP的协议的定义来更好的理解整个基带系统的实现，并且深入挖掘里面的攻击面以及如何更好的发现里面的安全问题。

上面图片来源strategyanalytics

研究方法：

整个系列文章将会围绕高通基带系统对3GPP定义的协议栈的实现来挖掘里面的一些业务逻辑以及挖掘相关的攻击面来进行，所以我的研究方法会针对如下层次来进行。

1．  操作系统

2．  应用系统

3．  3GPP实现的协议栈

4．  攻击面研究以及缺陷挖掘

封闭的基带系统需要大量的逆向工程的工作，来获取对基带系统行为的了解，逆向工程是安全研究者在挖掘未知的必备技能，什么时候需要逆向工程，在你无法获取目标研究对象的源代码和设计文档或者仅能够获取极少文档信息的情况下，想了解其目标对象的一些设计逻辑，原理和算法，这个时候你只能通过逆向工程这种合法手段来达到上面的目的。

逆向工程也分软件和硬件，现今的数字系统基本上都是通过软件来定义的，我们对于硬件的逆向工程就不展开讲了，有机会单独写出来，所以本文讨论的也基本上是软件层面上的逆向工程，而基带系统与硬件结合又是非常紧密的，所以对基带系统的逆向工程也需要硬件研究能力的支撑，逆向工程的难易程度也是分等级的，如下是我个人对逆向工程难易的理解，默认下面所有应用的固件都可以获取，通过研究工具的获取和研究的成本来分类。

而我们选择的研究对象高通的MDM系列芯片按我的理解难度应该在上图的L3的级别，非常有限的芯片信息的情况下，下图就是我们将研究的对象。

• 高通基带硬件系统介绍

高通的基带硬件按照功能的不同分为两类：

1．  MSM系列   （MobileStation Modem）

2．  MDM系列    (Mobile DataModem)

MSM系列主要是给手持移动通信设备使用，例如手机等

MDM系列主要是给移动数据流量设备使用，车联网或其它物联网设备等

MSM系列与MDM系列的区别

MSM系列芯片包括应用处理器（Application Processor）和基带系统处理器(Baseband Processor)还有Wi-Fi，蓝牙等,这个主要是提供整体的手机解决方案来给手机产商使用，Android生态的大部分手机都是运行在高通的MSM系列的SoC之上，例如小米5手机搭载的高通骁龙系列S820的SoC就是MSM8996系列的芯片，应用处理器运行的是Android系统。

MDM系列早期只包含（Baseband Processor），主要是提供数据modem和语音的功能，苹果手机生态和车联网以及4G无线上网卡等应用中比较常见，比如iPhone8/8 Plus和iPhone X都是配备的高通MDM9655的基带芯片，而宝马/奥迪车联网的TBOX则配备的MDM6x00系列的基带芯片,而15年生产的通用安吉星系统TBOX则采用的是MDM9215系列，为了能够提供更强大的业务逻辑能力，MDM系列基带芯片SoC剥离了基带系统和业务系统，由两个core组成，比如mdm9xxx系列芯片包含一个hexagon的DSP基带处理核，以及一个ARM Cortex-A系列的核。

从功能上来说，MSM系列的功能是包含了MDM系列的功能

所以高通的MDM系列的BasebandProcessor并不是严格意义上的一块处理器，而是至少有3个core。

1．  一个基于ARM的微处理子系统

a. ARM1136                                                      à MDM6600

b. ARM Cortex-A5 + Hexagon DSP   à MDM9215

2．  一个基于高通Hexagon QDSP架构的Modem DSP(mDSP)

3．  一个基于高通Hexagon QDSP架构的ApplicationDSP(aDSP)

这3个core的主要功能如下：

1．  这个基于ARM的微处理器属于基带系统的子系统（MDM6x00基于ARM1136的架构，MDM9x15系列基于ARMCortex-A5以及新增了一个hexagon DSP处理器），它将协助mDSP和aDSP的初始化和与这两个core进行通信交互以及实现3GPP定义通信的所需的协议栈功能和算法，也可作为特定应用相关处理平台，例如在车联网中会将它作为TBOX的应用逻辑的处理器，MDM9x15把3GPP协议栈的实现转移到了hexagon DSP上，而MDM6x00的3GPP协议栈的实现是在这个ARM1136上完成。

2．  mDSP的主要功能就是无线信号的调制与解调，在3G为代表的MDM6x00系列的mDSP主要实现CDMA/WCDMA/GSM/GNSS信号的调制与解调，在4G为代表的MDM9x15系列主要实现了包括CDMA/WCDMA/GSM/LTE/GNSS信号的调制与解调。

3．  aDSP(ApplicationDSP)，主要功能是实现与应用相关的信号调制与解调，例如语音信号的调制与解调（Audio DSP），常见的应用就是我们手机语音通话时编码与解码以及压缩就是通过这个aDSP来实现。

下图为高通MDM系列基带芯片的一些特性：

上面图片来源高通

• 高通基带软件系统介绍

高通基带的软件系统从2000年左右就开始应用他们自己设计的嵌入式rtos系统REX来构建他们自己的手机基带应用系统AMSS，而且基础的应用软件架构一直沿用至今，由于基带应用系统其复杂的特性以及大量的功能应用，为了保证其应用良好的移植性和兼容性，所以基带的底层系统采用精简的微内核系统OKL4，这是一个开源的微内核系统，基于ARM的基带处理器都是采用的OKL4微内核，自从高通开发的新的hexagon DSP基带处理芯片后，一个名为QuRT嵌入式微内核系统因此而产生，这个QuRT前期也叫Blast，它的出现应该是专门为QDSPv6架构的DSP处理器而开发的，我们今天分析的MDM6600基带芯片是基于OKL4的微内核+REX AMSS应用系统，而我们重点关注的其实也是运行在REX之上的AMSS应用，下图是整个基带系统的基于ARM和基于hexagon QDSP架构逻辑，未来5G应用还会继续沿用右边的架构。

    微内核的好处在于，应用系统可以保持高度的可移植性，微内核系统只要满足基本的IPC通信机制，内存管理，CPU调度机制即可，驱动文件系统等以及应用都可以在用户态来初始化完成，这对于需要支持多个硬件平台的高通来说无疑非常高效的做法，如下图是高通的系统架构。

基带软件系统主要包括如下部分：

a.     启动管理

b.    内存管理

c.     文件系统

d.    定时器机制

e.     任务管理和IPC通信机制

f.      中断管理

a.     基带系统启动过程

高通基带芯片很早就引入了secureboot的启动验证机制，来防止启动过程中运行的代码或数据被篡改，旨在安全可信计算，现在大部分高通系的手机都有这个功能，芯片上电后先被芯片的BootRom接管，该BootRom里面的代码不可篡改，里面存有flash控制器的基本读写功能，而且芯片的OTP区域可以存储产商授权的公钥证书，用于签名认证启动过程中需要认证的分区数据。以MDM6600芯片在某个车联网应用基带设备为例，它的启动过程如下：

芯片上电后执行BootRom里面代码检测是否从flash启动，如果是从flash的第一个扇区读入数据到内存并搜索secureboot启动的MagicHeader，然后解析头部相应的数据结构，获取代码和数据的大小和偏移以及装载到内存的地址信息，签名/证书数据偏移和长度，如下图是DBL头部区域信息。

0x00- CodeWord ("D1 DC 4B 84")

0x04- Magic ("34 10 D7 73")

0x14– Body start offset (0x2050)

0x18- Loading address (0x20012000)

0x1C- Body size (Code + Signature + Certificate store size)

0x20- Code size

0x24- Signature address

0x28- Signature length (256 bytes)

0x2C- Certificate store address

0x30- Certificate store length

证书信息截图

当BootRom验证DBL代码和数据签名成功后，此后DBL的代码接管执行，然后搜索MIBIB分区表，获取各个分区的起始block信息，然后在相应的块去读取相应的数据，接着就是验证相应分区数据的签名，然后相应的分区代码接管，完成一系列的信任启动链，DBL验证成功后，验证FSBL，然后是OSBL，最后是AMSS。

0x00- CodeWord ("AA 73 EE 55")

0x04- Magic ("DB BD 5E E3")

0x0C– Partition Nums (0xa)

每个分区表信息长度0x1c，例如

0x00– 0x10 partition name (0:FSBL)

0x10– Partition start block information (0x0f)

0x14– Partition block length (0x2)

   这里定义的每个页是0x800字节，每个块block有64个页，所以每个block的长度是0x20000字节，所以根据这个信息我们就可以定位这些分区的物理偏移信息。

例如FSBL的物理偏移为0x20000*0xf=0x1e0000

AMSS的物理偏移为0x20000*0x16=0x2c0000

b.    基带系统内存管理

当基带系统的安全信任启动链验证完成后，最后系统被AMSS系统代码接管， AMSS系统定义了代码执行的内核特权模式以及AMSS应用模式，设置页表（映射硬件外设地址到页表中）并且开启MMU(内存管理单元)，在某些敏感的内存地址区域通过MPU的特性来进行保护，只有特定权限的应用的可以访问，应用模式的代码想要进入内核态（例如IPC消息发送），可以通过设置的特权中断指令SVC进入内核态，下图就是进入特权syscall的中断向量表入口。

通过初始化页表完成内核地址空间和外设硬件地址映射，开启mmu，进入用户空间创建第一个rootTask任务，初始化用户态需要创建的应用与驱动，这里主要介绍应用层堆内存结构以及内存分配和回收算法。

REX系统堆内存分两种类型：

Big chunk（大堆）

small heap（小堆）

大堆在不同应用初始化的时候指定内存的起始地址与长度，而且根据应用功能的不同，分配方式也不同，小堆将会在大堆上进行分配使用，大堆由于给使用的应用不同，分配小堆的方式有所不同。

a．  大堆类型1,内存连续，分配小堆的方式是顺序分配，前面是分配好的小堆，后面是连续的空闲堆块，分配小堆只会在连续的空闲块上进行分配，例如前面多个分配好的小堆其中一个需要被释放后，只是把这个小堆的属性标记为freed，但由于它后面的小堆到连续的空闲块中间有标记为已经分配属性，所以后续在分配小堆的过程中不会考虑这块已经被释放的内存，除非要释放的小堆内存和连续的空闲块紧挨着，下一次分配内存时才会从这个已经标记为释放的内存上进行分配，而是直接到后面的连续空闲块上进行分配，这样做的目的是为了分配和释放内存更高效，虽然牺牲了一些空间，结构如下图。

下图是这种chunk上分配小堆的状态信息示例

b．大堆类型2,（modem chunk）,也是一个连续内存区域，但是chunk header在内存的底部，上部为分配小堆区域，分配顺序也是从上往下分配，小堆的头部数据结构中会指向上一个已经分配好的小堆，通过单向链表进行小堆内存的回溯，最上面的小堆回溯指针为空，但是它的内存分配算法跟上面的不同，就算要被释放的小堆内存和空闲块不挨着，但是它任能在下一次的堆内存申请中被重用，只要它的大小合适，而且小堆数据结构与类型1也不同，基本结构如下图。

Modem使用大堆结构示例

我们可以看到chunk类型1和chunk类型2上面分配的小堆内存结构稍有不同，数据结构如下：

Smallheap1{

Uint32size;//+0 分配内存空间的长度加上头部长度0xc字节

Uint8  mem_flag;//+0x4 内存属性标志，0表示已分配，0xff表示释放掉的内存

Uint8  extr_mem_flag;//+0x5 扩展内存属性标志，0表示内存分配过，0xff表示

//内存空间，没有被使用过

Uint8  mem_extra_size;//+0x6 额外分配的内存长度，为了内存0x10字节对齐

//所额外增加的申请内存长度，必须小0x10字节

Uint8  mem_pad_char;//+0x7 填充字节0xaa

Uint16 crc16_cookie;//+0x8  对传入的第三个参数的crc16计算的值

Uint16 mem_id;//0x0a   内存标识,第四个参数传入

Uint8 mem_buffer[size-0x0c];//+0xc 用户使用内存buffer

}

Smallmodem heap{

  Uint32size;// +0 分配内存空间的长度加上头部长度0x10字节

  Uint32*pre_alloc_ptr;//+4 指向上一个分配好的小堆内存头部指针

  Uint8client_id;//+8 申请内存的应用id值，modem功能中定义了

//RRC/CM/SM/RLC/gstk/wms等多个应用，这个id来标识申请内

//存的应用来自于哪个业务应用

  Uint8  mem_flag;//+0x9 内存属性标志，0表示分配了，1表示释放了，

//3表示未使用

  Uint8 unknown_byte;//+0xa

  Uint8  mem_guard_bits;//+0xbmodem内存保护标志0x6a

  Uint32  alloc_ret_addr;//+0xc 分配内存函数的下一条指令地址，目的是为了

//确定执行内存分配行为的精确地址

  Uint8 mem_buf[0xsize-0x10]; //+0x10 供用户使用的内存buffer

}

c.     基带系统文件系统

由于篇幅问题，我会对Qualcomm基带的文件系统EFS单独写一篇详细的分析文章。

d.    高通基带芯片定时器（Timer）

定时器是嵌入式芯片非常重要的组成部分，它在嵌入式操作系统的CPU调度和定时任务执行，以及精确的延时等待等操作中扮演着非常重要的角色，高通的基带芯片的定时器调度算法大体都差不太多，我们基于ARM1136架构的MDM6600基带芯片对定时器算法进行了深入分析。

MDM6600的定时器是通过SleepTimer控制器来实现的，它包含两个16位的Timer0和Timer1，以及一个32位的TimeTick的计数器(counter)，它们的功能用途如下.

1．Timer0   供watchdog使用

2．Timer1   供3G的wcdma的功能模块使用

3．TimeTick 系统计数器，服务于系统的子任务模块创建的定时器任务的执行以及延时功能的使用

Timer0应用于watchdog功能中，Watchdog在实时嵌入式系统中扮演着非常重要的角色，它监控任务的正常运行，监控的任务必须定时喂狗（feeddog），watchdog才认为你在正常工作，要不然就可能会直接reset系统，后续也会介绍它在基带里面具体监控的应用。

Timer1将会在3GWCDMA应用中收发相关的定时中断中会详细介绍。

TimeTick是一个32位的系统计数器，初始化后会从0开始计数，计数到0xfffffff后溢出到0后重新开始计数，主要功能如下：

1．  执行定时任务

a.     执行一次

b.    周期性执行

2．  执行延时功能

a.     延时等待

   TimeTick的时钟源为32768Hz，这意味着这个计数器1秒钟会计数32768次，通过这个信息我们可以大致计算出从0计数到0xffffffff需要36个小时。

   定时任务功能特性：

a.     通过设置TimeTick的match value来决定计数器计数到这个值后产生一个中断，中断里面可以处理相应的定时任务，以及设置新的TimeTickmatch value。

b.    所有的定时任务都会存储在定时任务列表中，提供定时任务的插入，删除，暂停，唤醒执行等功能。

下图描绘了定时器任务执行的基本过程

在基带系统中存在多个应用任务，每个任务的执行都是依赖内核的CPU调度，常见的方式就是时间片和优先级切换让各个不同的任务有机会得到执行，而某些任务在运行过程中的某个时机可能会创建一个或者多个定时器任务，例如上图所示的任务Task1创建的定时器任务Timer1，Task2创建的定时器任务Timer2和Timer3，处理这些任务的算法如下：

1．  创建定时任务时，获取当前TimeTick的计数

2．  把延时换算法成计数，比如1秒等于32768次计数

3．  把当前timetick计数加上延时的计数值作为该定时任务中断触发的match value

4．  遍历所有定时任务，根据任务设置的定时任务中断触发的match value大小排序插入到定时任务列表

5．  当timetick的计数到达某个定时任务的Match value的时候产生中断，中断处理例程ISR会通过向DPC（Deferred Procedure Calls）发送执行定时任务的消息去执行该定时任务的例程函数，如果只是延时任务就不需要执行了，同时更新timetick的下一次中断产生的match value，并把这个定时任务从定时任务列表中移除

如上图举例：

按照时间推进过程，这些定时任务执行需要设置的Match value来产生中断的顺序依次是：

M1 à M4 à M3 à M5 àM6 à M7

所以在基带系统里面会有一个专门的定时器应用任务来管理维护其它应用任务产生的定时器任务的调度。

e.     任务管理和IPC通信机制

  上面提到基带系统从内核态切入到应用态会创建第一个rootTask应用任务，这个任务有点类似linux系统里面的init进程，rootTask接下来会创建应用权限很高的DPC_task任务（负责高实时异步任务执行），权限仅次于IST（interruptservice threads,中断服务接管线程），然后是应用层的全局管理任务main_task将会启动，接下来业务所需的各种驱动相关的初始化和通信业务逻辑任务将在main_task任务中得以创建，例如中断接管服务相关的IST(interruptService Threads)，定时器业务相关的timer_task，qualcommEFS文件系统相关的fs_task，任务监控相关的watchdog_task，以及GSM/UMTS业务相关的通信层面的各个任务。

每个任务被创建时，REX内核和用户态各自会维护一套数据结构，以及用户自定义的一套TCB结构：

内核态—>KTCB（Kernel Task Control Block）

用户态—>UTCB（User Task Control Block）

用户态—>REX_TCB(用户自定义TCB结构)

在内核态，cpu通过KTCB来管理调度所有的任务，以及管理用户态任务在切换时存储任务的context信息。

内核态的KTCB列表包含1个idle内核线程,8个IRQ和1个FIQ内核线程任务KTCB结构，以及每一个用户任务UTCB对应的在内核空间存储的KTCB结构。

在用户态，每一个任务都会通过UTCB结构存储任务信息供用户读写，并且该UTCB结构也会映射到内核空间供内核读写，而用户态的REX_TCB是供用户自定义的数据结构，用户可以自定义一些方便业务间通信的数据结构。

任务的几个重要的特性：

1. 内核态读取0xf0000008地址存储着当前活动任务的KTCB指针

2. 内核态0xf001e000存储着所有KTCB结构的列表

3. 在用户态读取0xff000ff0地址值可以获取当前活动任务的UTCB指针

KTCB，UTCB和用户定义的TCB结构关系如下图：

从上图可知，UTCB结构通过内存映射的方式会被内核态和用户态共同读写，utcb通过timetick计数器来记录任务使用了多少cpu时间，为任务调度提供了很好的判断条件。

每个被创建的任务都包含一些信息，初始化时会存储在UTCB结构和用户定义的TCB结构中:

1. 任务的执行函数地址

2. 任务执行函数参数

3. 堆栈起始地址

4. 堆栈的长度

5. 任务优先级别

6. 存储用户tcb地址

7. 任务名称

任务创建函数定义类似结构如下，不同的版本可能会有一些变形：

Void *createTask(void *utcb,void*task_func_ptr,uint32 stack_size,void *stack_buttom,void *stack_top,uint32task_priority，void *pararm)

用户定义tcb结构是一个双向链表结构，每个用户tcb会把高于自己优先的任务插入到前链，低于自己优先级的任务插入到后链，所有的任务中中断接受任务中的FIQ任务的优先级是最高的，它用于快速处理来自于fiq中断请求。

下图是枚举出的部分运行的任务列表：

所有的任务通过优先级的高低，利用双向链表链接起来，如下图，FIQ任务具有最高优先级。

而sleep任务具有最低运行优先级。

用户态的任务创建和运行流程如下图：

用户态任务运行特性：

a.     每个被创建后的任务会被调度运行起来后，直至到等待信号的循环，阻塞接收消息，此时交出cpu执行权，切换执行任务。

b.    当某个任务接收到消息后，任务等待信号的循环返回，根据接受到信号去处理相应的例程，然后清除接受到的信号值，继续新一轮的信号等待。

c.     任务通过设置接受信号的掩码来设置多个信号处理例程，每个任务最多支持设置32个信号接受值。

d.    信号接受值和信号接受掩码会在utcb结构中设置。

IPC任务间通信

IPC通信是多任务协作通知和同步数据，非常重要的系统机制，在实时操作系统中应用广泛，对于无线通信复杂的状态机制以及低延时同步处理，IPC通信起到了至关重要的作用。

从上图我们可知每个运行的任务都有独立运行环境，有自己的堆栈空间，当不同任务之间进行数据交换和同步的时候，这时候就需要用到IPC机制了，我们把用户任务的rex_tcb结构作为任务的唯一标示，用它与之不同的任务进行通信，这里用到了很重要的信号通知和等待信号通知的机制，从上面我们可知每个任务可以定义最多32个信号量来区分接收到的不同信号，然后根据接受到的不同信号进行相应的处理。

例如A任务需要告之B任务，处理B任务里面的某个分支逻辑时，A只需要设置B任务rex_tcb结构里面信号值即可，当B任务被调度起来后的接受信号等待函数会立即返回取出A发送来的信号值，然后B任务作相应的处理。

该IPC通知机制在基带系统里面应用广泛，后续我也会提到。

任务调度机制：

a.    中断发生时，cpu将调度到IST接管中断处理，因为IST的优先级比较高

b.    当任务等待消息阻塞时，任务主动交出cpu控制权

c.    应用任务都在等待时，rootTask和Main Task接管CPU，类似idleloop

d.    当各个任务都有接受到消息时，根据任务的优先级和cpu使用时间进行调度

如下图系统初始化过程中的任务的切换过程以及CPU使用时间统计。

我们可以看到，在系统初始化过程中，各个任务的初始化过程，cpu使用时间都差不太多，因为初始化完了都处于阻塞状态了，只有rootTask和Main Task占有大量的CPU时间，因为rootTask需要负责大量的KTCB切换的通知操作，而且Main Task主动初始化那些应用任务。

f.      中断管理

基带系统在系统初始化过程中会初始化中断控制器，注册相应的中断服务例程，设置中断优先级，并且生效中断响应，在高通的MDM6600基带系统中设置了8个响应IRQ的IST任务，和1个响应FIQ的IST任务，优先级依次提升，FIQ的IST任务具有最高的优先级别，因为在中断处理过程，可能会有更高优先级的中断产生，这时需要有高优先级的IST来接管响应来提升中断响应的实时性，由于中断是由硬件产生，而IST在应用态，所以中断处理过程如下。

1．  硬件中断产生                                                        （物理层）

2．  判断是否是generic irq还是fiq                                                    （物理层）

3．  进入到irq exception或者fiq exception向量表                             （内核）

4．  投递到相应中断处理分发器                                            （内核）

5．  查询IRQ和FIQ的内核KTCB状态是否空闲                                  （内核）

6．  通过KTCB结构找到相应的IST任务                                                  （内核）

7．  相应的IST接管中断，锁定该IST，并查询中断号对应的ISR  （应用层）

8．  执行ISR后，清除中断状态，解锁IST，等待新的中断响应  （应用层）

• 结语

    本文章的目的主要是为了对高通的基带系统有一个体系化的了解，操作系统作为承载业务系统的基础设施，了解其运行原理对于研究上层业务会有很大的帮助，由于高通的的基带系统非常封闭，研究需要大量的逆向工程的工作，记录了大量的笔记，无法一一整理发出，所以也有可能会有一些遗漏和不足，如果有熟悉的同学，也希望能够指出有错误的地方，便于改正，接下来系列的研究文章将针对高通基带对于3GPP定义的GSM/UMTS/LTE，以及5G的实现上，并且挖掘其安全攻击面，希望能够坚持下去。

阅读原文

跳转微信打开