作者簡(jiǎn)介：

Baron (csdn:代碼改變世界ctw)，九年手機(jī)安全/SOC底層安全開發(fā)經(jīng)驗(yàn)。擅長trustzone/tee安全產(chǎn)品的設(shè)計(jì)和開發(fā)

（注：說明本文的介紹都是基于armv8-aarch64或armv9硬件架構(gòu)）

在mmu未開啟階段，PC操作的都是物理地址執(zhí)行程序，這樣看起來一切正常，沒啥問題。

例如：取指(到物理地址0x4000處取指)、譯碼、執(zhí)行取指(物理地址0x4004處取指)、譯碼、執(zhí)行取指(物理地址0x4008處取指)、譯碼、執(zhí)行取指(物理地址0x400C處取指)、譯碼、執(zhí)行

但是呢，假如程序在執(zhí)行的過程中，你突然打開了MMU，那么會(huì)發(fā)生什么呢？比如在前面的示例中，就會(huì)出現(xiàn)，程序本來執(zhí)行在0X4000、0x4004處好好的，而0x4004切好是enable_mmu指令，那么接下來PC將取值0x4008處地址的指令，由于此時(shí)MMU已經(jīng)被打開了，那么0x4008會(huì)被當(dāng)作虛擬地址，經(jīng)過MMU翻譯...

經(jīng)過MMU，那么就可能出現(xiàn)了兩種問題：一是虛擬地址0x4008所對(duì)應(yīng)的頁表沒有建立，此時(shí)會(huì)產(chǎn)生prefetch abort；二是虛擬地址0x4008所對(duì)應(yīng)的頁表已經(jīng)建立了（例如指向物理0x9004處），那么此時(shí)cpu期望訪問物理地址0x4008處的，就被突然變成了訪問物理地址0x9004處了。

取指(到到物理地址0x4000處取指)、譯碼、執(zhí)行取指(物理地址0x4004處取指)、譯碼、執(zhí)行 -- 這條指令是開啟MMU取指(到虛擬地址0x4008處取指，經(jīng)MMU單元后，要么是invalid，要么是0x9004)、譯碼、執(zhí)行......

為了解決上述描述的問題，下面給出了兩種解決方案：第一種方案：在開啟MMU之前，我先對(duì)正在執(zhí)行的這一小塊代碼建立個(gè)頁表（一一映射），那么此時(shí)的邏輯就變成了：

取指(到到物理地址0x4000處取指)、譯碼、執(zhí)行取指(物理地址0x4004處取指)、譯碼、執(zhí)行 -- 這條指令是開啟MMU取指(到虛擬地址0x4008處取指，經(jīng)MMU單元后，物理地址依然是是0x4008)、譯碼、執(zhí)行 -- 程序沒有跑飛......

第二種方案：在開啟MMU之前，我確實(shí)建立個(gè)頁表（不是一一映射哦，這是正常業(yè)務(wù)的頁表），此時(shí)的邏輯如下：

取指(到到物理地址0x4000處取指)、譯碼、執(zhí)行取指(物理地址0x4004處取指)、譯碼、執(zhí)行 -- 這條指令是開啟MMU取指，到虛擬地址0x4008處取指，經(jīng)MMU單元時(shí)在頁表是找不到0x4008這個(gè)虛擬地址的（因?yàn)闆]做map），所以會(huì)產(chǎn)生prefetch abort異常、而在異常代碼ERET返回時(shí)，正好返回到0xXXXX地址處，該地址是虛擬地址，正好MAP到0x4008物理地址，程序得到繼續(xù)執(zhí)行，譯碼、執(zhí)行 -- 程序很順利哦......

如果看到此處，您沒有看懂，沒關(guān)系，請(qǐng)看下列代碼示例：

程序在(1)處將 mmu_on_addr鏈接地址(虛擬地址)寫入到了X30寄存器中程序在(2)處enable MMU，此時(shí)下一條指令取指，將被當(dāng)作成虛擬地址，經(jīng)過MMU翻譯，而對(duì)應(yīng)的頁表中自然是沒有這個(gè)地址(物理地址被當(dāng)作成的虛擬地址)，所以此時(shí)將產(chǎn)生sync abort...程序在(3)處不會(huì)被執(zhí)行，因?yàn)樯厦嬉呀?jīng)sync abort了

跳轉(zhuǎn)到sync abort后，代碼如下方所示，什么都沒干，直接ret返回了。

1. vector_entry sync_exception_sp_elx

2. ret

ret指令返回的，PC自然是自動(dòng)指向X30地址處，即 mmu_on_addr鏈接地址(虛擬地址)，程序繼續(xù)跑，一切步入正常流程...