作者：阿里安全 謝君
公眾號：vessial的安全Trash Can

背景

隨著5G大浪潮的推進，未來萬物互聯將會有極大的井噴爆發的可能，而移動基帶系統作為連接世界的橋梁，必將成為未來非常重要的基礎設施，而基礎設施的技術自主能力已經上升到非常重要的國家層面上的戰略意義，從美國對待中國的通信產商華為的禁令就可以看得出基礎技術的發展對一個國家的震懾，現今人類的生產生活已經離不開移動通信，未來也將會繼續是引領人類科技的發展的重要媒介，人工智能，自動駕駛，物聯網以及你所能想到的一切科技相關的發展都會與移動通信產生重要的聯系，在此之上其安全性和可靠性將會成為人類所關心的重要問題，這也是筆者為了寫這個系列文章的初衷，也希望更多的安全研究人員參與到基礎設施的安全研究當中來，挖掘出更多的缺陷與隱患，完善未來的基礎設施的安全。

概念和研究目的

3GPP移動通信的標準化組織3rd 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。

  • 一個基于ARM的微處理子系統

    a. ARM1136 à MDM6600

    b. ARM Cortex-A5 + Hexagon DSP à MDM9215

  • 一個基于高通Hexagon QDSP架構的Modem DSP(mDSP)

  • 一個基于高通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（小堆）

大堆在不同應用初始化的時候指定內存的起始地址與長度，而且根據應用功能的不同，分配方式也不同，小堆將會在大堆上進行分配使用，大堆由于給使用的應用不同，分配小堆的方式有所不同。

  • 大堆類型1,內存連續，分配小堆的方式是順序分配，前面是分配好的小堆，后面是連續的空閑堆塊，分配小堆只會在連續的空閑塊上進行分配，例如前面多個分配好的小堆其中一個需要被釋放后，只是把這個小堆的屬性標記為freed，但由于它后面的小堆到連續的空閑塊中間有標記為已經分配屬性，所以后續在分配小堆的過程中不會考慮這塊已經被釋放的內存，除非要釋放的小堆內存和連續的空閑塊緊挨著，下一次分配內存時才會從這個已經標記為釋放的內存上進行分配，而是直接到后面的連續空閑塊上進行分配，這樣做的目的是為了分配和釋放內存更高效，雖然犧牲了一些空間，結構如下圖。

下圖是這種chunk上分配小堆的狀態信息示例

  • 大堆類型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字節
     Uint32pre_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個小時。

定時任務功能特性：

  • 通過設置TimeTick的match value來決定計數器計數到這個值后產生一個中斷，中斷里面可以處理相應的定時任務，以及設置新的TimeTickmatch value。

  • 所有的定時任務都會存儲在定時任務列表中，提供定時任務的插入，刪除，暫停，喚醒執行等功能。

下圖描繪了定時器任務執行的基本過程

在基帶系統中存在多個應用任務，每個任務的執行都是依賴內核的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任務具有最低運行優先級

用戶態的任務創建和運行流程如下圖：

用戶態任務運行特性：

  1. 每個被創建后的任務會被調度運行起來后，直至到等待信號的循環，阻塞接收消息，此時交出cpu執行權，切換執行任務。

  2. 當某個任務接收到消息后，任務等待信號的循環返回，根據接受到信號去處理相應的例程，然后清除接受到的信號值，繼續新一輪的信號等待。

  3. 任務通過設置接受信號的掩碼來設置多個信號處理例程，每個任務最多支持設置32個信號接受值。

  4. 信號接受值和信號接受掩碼會在utcb結構中設置。

IPC任務間通信

IPC通信是多任務協作通知和同步數據，非常重要的系統機制，在實時操作系統中應用廣泛，對于無線通信復雜的狀態機制以及低延時同步處理，IPC通信起到了至關重要的作用。

從上圖我們可知每個運行的任務都有獨立運行環境，有自己的堆棧空間，當不同任務之間進行數據交換和同步的時候，這時候就需要用到IPC機制了，我們把用戶任務的rex_tcb結構作為任務的唯一標示，用它與之不同的任務進行通信，這里用到了很重要的信號通知和等待信號通知的機制，從上面我們可知每個任務可以定義最多32個信號量來區分接收到的不同信號，然后根據接受到的不同信號進行相應的處理。

例如A任務需要告之B任務，處理B任務里面的某個分支邏輯時，A只需要設置B任務rex_tcb結構里面信號值即可，當B任務被調度起來后的接受信號等待函數會立即返回取出A發送來的信號值，然后B任務作相應的處理。

該IPC通知機制在基帶系統里面應用廣泛，后續我也會提到。

任務調度機制：

  1. 中斷發生時，cpu將調度到IST接管中斷處理，因為IST的優先級比較高

  2. 當任務等待消息阻塞時，任務主動交出cpu控制權

  3. 應用任務都在等待時，rootTask和Main Task接管CPU，類似idleloop

  4. 當各個任務都有接受到消息時，根據任務的優先級和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的實現上，并且挖掘其安全攻擊面，希望能夠堅持下去。

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