深度揭密高通4/5G移动基带消息系统和状态机

阿里安全 谢君 2021-04-09 17:31

背景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安全测试体系，通过对基带系统的深刻认知，可以更好的对基站系统和核心网系统进行安全评估。

阅读原文

跳转微信打开