深度揭密高通4/5G移動基帶消息系統和狀態機

作者： vessial
原文鏈接：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-6 offset 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_SM
state name: LTE_RRC_DT_SM //
state name: LTE_RRC_IRAT_TO_G_MGR_SM
state name: LTE_RRC_LLC_SM
state name: LTE_RRC_CAPABILITIES_SM
state name: LTE_RRC_IRAT_FROM_1X_MGR_SM
state name: LTE_RRC_SEC_SM //sim認證和密鑰協商管理相關的狀態機
state name: LTE_RRC_CRP_SM
state 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_SM
state name: LTE_RRC_MEAS_SM
state name: LTE_RRC_CEP_SM
state name: LTE_RRC_IRAT_TO_1X_MGR_SM
state name: LTE_RRC_IRAT_FROM_W_MGR_SM
state name: LTE_RRC_MDT_SM
state name: LTE_RRC_IRAT_TO_DO_MGR_SM
state name: LTE_RRC_CONTROLLER_SM //關鍵的LTE的控制狀態機，控制服務的停止和開啟
state name: LTE_RRC_IRAT_TO_TDS_MGR_SM
state name: LTE_RRC_IRAT_TO_W_MGR_SM //從LTE切換到WCDMA的管理狀態機
state name: LTE_RRC_EMP_SM
state 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的狀態機圖譜

狀態機操作實例

為了更直觀的理解消息狀態機的操作過程，我這里提供了一個例子來展示消息傳遞過程以及狀態機的處理過程，這個過程是在基帶處于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安全測試體系，通過對基帶系統的深刻認知，可以更好的對基站系統和核心網系統進行安全評估。

最后行文倉促，如有錯誤，歡迎反饋指正，預告下一章節將會介紹高通基帶系統的A2/IPA硬件IP加速功能模塊。

本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1555/