『壹』 飛機tlb飛機TLB是什麼
1、arm的trustzone是怎樣保證硬體安全的？2、如果看待國航機長肆意將隨機機務趕下飛機的行為？3、解釋下龍芯4、飛機維修記錄和維修單是一個東西嗎arm的trustzone是怎樣保證硬體安全的？
Trustzone可以追溯到十多年前飛機tlb，ARMv7公布的時候就有飛機tlb了，可惜一直沒有什麼實際應用。直到近幾年開始，才真正的有廠商開始把這個方案大規模用於晶元里。目前看到的主要有四個應用領域：x0dx0a 第一是無人機晶元，大疆已經走在了最前面，第二名連影子都沒看見。無人機上幾大應用，圖像傳輸，圖像處理，識別，飛控，存儲，每一塊都有安全的訴求。利用Trustzone可以做到，在晶元里流動的數據，每一步都在安全系統的控制之下，哪怕飛機被人搶去，都需要極大的代價才能拿到快閃記憶體以及內存裡面的數據。如果以後上安卓或者其他操作系統，哪怕軟體系統被黑客攻破，數據和控制還是安全的。最後，如果國家或者行業出台政策，要求實施禁飛區，那麼哪怕無人機的主人自己去修改快閃記憶體和軟體，都可以被強制接管。這些功能必須在晶元設計階段就考慮到，大疆在這方面的眼光確實比別人長遠。x0dx0a 第二是DRM，數字版權管理，也就是內容保護。如果國內用戶要在手機上看最新好萊塢大片，那麼播放設備必須經過一個認證，這個認證可以用trustzone來實現。國內已經在積極的推動這個事情，估計再過一段時間就可以實現了。當然，這是一把雙刃劍，肯定也有用戶反而不願買支持DRM的設備，而去看盜版。用了Trustzone本身並不限制盜版，只不過多了一個看好萊塢大片的渠道。x0dx0a 第三是支付。把Trustzone用於支付支付在技術上沒有困難，對晶元性能要求也不高，難的是把各個利益方擺平。銀行和運營商想把支付控制權握在自己手裡，所以會去大力推廣NFC，會去和蘋果合作。而手機支付軟體廠商，比如支付寶和微信，想通過和手機晶元和硬體廠商，把所有功能都自己的平台上實現。目前的支付大多數還是基於軟體和遠端密鑰驗證。如果有人把手機破解，那還是可以讀取到支付圖層的密碼的。而trustzone做的，就是硬體上杜絕這類情況。x0dx0a 第四是物聯網。物聯網的安全有好幾種做法，可以把安全檢測放在伺服器端或者末端晶元上。末端通常是一個MCU加上感測器和互聯模塊，面積較小。用硬體trustzone實現的話，加解密和密鑰管理等功能會需要額外內模塊，可能比MCU本身都大，成本太高。但如果是附加值高的晶元就沒什麼問題。x0dx0a 讓我們從技術層面來定義Trustzone到底能做什麼：x0dx0a 1、防止操作系統被攻破後關鍵數據泄密，關鍵數據存放在特定內存區域，而那塊區域，只有安全操作系統才有可能讀到。x0dx0a 2、防止通過JTAG等調試介面讀到寄存器，緩存，內存或者快閃記憶體數據。x0dx0a 3、從晶元製造開始，最初的密鑰可以用晶元熔絲實現，往後啟動的每一步都需要最高特權級和密鑰驗證，建立信任鏈，杜絕軟體被替換或者被惡意讀取。x0dx0a 4、防止邊帶攻擊，比如量取內存顆粒的信號猜測數據，製造故障讓檢驗模塊停止工作，替換外圍器件，輸入特定數據確定電磁信號特徵，打開晶元直接量內部信號線等。x0dx0ax0dx0a上一個典型的ARM SoC內部結構，在這個結構里，Trustzone做的事情是保護數據在晶元內部的安全，不允許非授權的訪問，哪怕這個訪問來自CPU。初看有些復雜，不過我們可以拆開慢慢分析。從硬體角度開始比軟體更清楚些，說不定哪天過認證的時候需要答辯，從頭到尾解釋系統安全設計。x0dx0a 首先，按照Trustzone的劃分，一個晶元內被劃分為安全世界和非安全世界。上圖中，中間黑色的部分是匯流排，匯流排上面是主設備，下面是從設備（主設備中的緩存是例外，這個以後說）。讀寫請求總是從主設備發往從設備的。x0dx0a 作為從設備，區分它是不是屬於安全世界相對簡單。如果一個從設備不存在成塊的空間映射，比如I2C或者PWM，那麼我只要在匯流排訪問它的時候，額外的加入一個管腳(取名為PROT)，就可以告訴它本次訪問是不是來自安全世界。如果從設備本身是完全屬於被保護的安全世界，不接受非安全的訪問，那麼只要簡單的拒絕，返回錯誤或者無意義數據即可。同樣，如果從設備本身處於非安全世界，那麼對於安全和非安全訪問，都可以返回正確數據。還有，從設備所處於的世界，是可以動態配置的，且動態配置本身需要處在安全世界，這個以後討論。x0dx0a 對於塊設備，包括快閃記憶體，sram和內存等，它們的某些地址塊需要處於安全世界，其他的處於非安全世界。為了實現這一點，就需要在它們前面插入一個檢驗模塊（例如圖中左方，DDR上面的TZC400），來判斷某個地址是不是能被訪問。當地址被送到這個檢驗模塊，模塊會結合PROT管腳去查表，看看本次訪問是不是被允許，然後做相應措施。表本身和之前的動態配置一樣，必須是在安全世界裡面配置的。x0dx0a 至此，從設備就分析完了，是不是感覺特別簡單？還有些細節，在把主設備也講完後，我們會從系統角度來關注。x0dx0a 對於一般主設備，不考慮自帶的緩存時，其實和從設備也差不多，也分為安全和非安全，可以在安全世界動態配置。配置完成後，這些主設備會按照自己所處的世界，驅動PROT管腳和地址來訪問從設備，得到相應返回。不過這里的一般主設備不包括中斷控制器，系統MMU，調試模塊和處理器，接下來對這些例外模塊進行具體分析。x0dx0ax0dx0a首先是處理器。x0dx0a 在上圖情況，接了CCI匯流排後，處理器接在緩存一致性埠ACE上（不明白的請參考以前的文章），它的緩存是可以被別人訪問的，並且這個訪問，是從主設備到主設備（當然，在處理器內部是從埠），不會經過匯流排送到內存，也不會經過檢驗模塊TZC400。這時就有個漏洞，通過操縱一個非安全世界的模塊，比如上圖的橙色主設備，假裝去讀一個被安全世界保護的內存地址。這個地址本來存在於內存，被TZC400保護，可是由於匯流排的監聽功能，讀請求有可能被發往處理器緩存，從而繞過保護。x0dx0a 為了防止這種情況，處理器在所有的頁表和緩存都做了特殊設計，加了一個標志位，標志本緩存行是否屬於安全世界。如果別的非安全世界主設備來監聽安全世界緩存行，由於安全位不同，處理器會認為這是兩個不同地址，哪怕它們的地址一致，返回緩存未命中。這樣，就不會把數據泄漏。x0dx0a 有人會問，這個標志位來源於頁表，改了頁表中的這一位不就可以訪問了？其實不行。因為安全世界頁表位於被保護的內存區域或者緩存，就算破解了操作系統也無法訪問。x0dx0a 又有人會說，那改了非安全世界的頁表中安全位，並偽造一個安全世界的地址，豈不是可以讓CPU模擬出一個訪問安全世界的傳輸，送到匯流排和TZC400？TZC400或者對端緩存一看地址和PROT管腳都是符合要求的，應該就會返回保密數據吧？想法是不錯，可是當CPU位於非安全世界時，它會忽略頁表中的安全位，所以不可能發出PROT為安全的傳輸。所以，我們可以對這點放心。x0dx0a 以上是別的主設備訪問處理器，那如果處理器本身處於非安全世界，有沒有可能訪問其他主設備的安全緩存？當然有。所以不要把其他主設備接到ACE埠，以免被監聽，一般主設備是不會做緩存上的安全與非安全區分的。接到ACE-Lite介面無所謂，反正設計上就無法被讀取緩存數據。x0dx0a 除此之外，還存在一個例外，就是GPU。在最新的ARM G71圖形處理器上，是支持雙向硬體一致性的。也就是說，GPU也可以被監聽緩存的。為了簡化設計，圖形處理器被設成永遠處於非安全世界，CPU盡管讀，不在乎，它使用另外一種機制來保護數據，以後介紹。x0dx0a 對處理器緩存熟悉的人可能會想到用跨緩存行的非安全變數來訪問被保護的數據。沒用的，處理器設計者早就想到這點，要不就是非對齊訪問異常（包含exclusive access的時候），要不就不會給你數據，具體到每個處理器有所不同。x0dx0a 還有一個漏洞沒堵上，那就是緩存維護，TLB和分支預測操作。ACE埠包含了DVM操作來維護它們，安全性如何保障？同樣的，地址中也有安全和非安全位。不過話說回來，DVM操作無非就是無效化某些緩存，分支預測和TLB項，不存在安全數據被讀取，TLB被篡改的情況。x0dx0a 到這里可能你會覺得有點暈，不少漏洞需要堵。我們可以回顧一下，需要記住的是各種緩存操作，通過安全標志位保護，避免漏洞。對比處理器設計者所要考慮的情況，這點漏洞不值一提。x0dx0a 杜絕了緩存漏洞後，還有別的隱患，比如模擬器。調試模塊可以被用來訪問各個從設備，也可以訪問和影響處理器內部資源。從設備側的防護很容易，把調試模塊當成一般的主設備處理就行。處理器內部的寄存器，緩存等資源，需要處理器從設計開始，就要為所有資源定義安全級別。被保護的資源對於來自調試模塊的未授權訪問會被禁止。只有通過安全啟動鏈，安全世界的軟體才能打開寄存器SDER，從而允許外部模擬器影響被保護的安全世界資源和處理器運行狀態，訪問被保護的資源。x0dx0a 那處理器內部的資源是怎麼劃分的？以ARMv8舉例，如下圖：x0dx0ax0dx0a這幅圖相信很多人都看到過。ARMv8的處理器被分成四個特權等級，通常EL0跑用戶態程序，EL1內核，EL2虛擬機。EL0-1分為安全與非安全，EL3隻有安全世界，EL2不區分，兩個世界的切換必須經過EL3。我們談到的處理器內部資源，包括寄存器，緩存，異常，MMU，很多都會分組，組之間看不到或者低級不可訪問高級，從而保證安全。沒有分組的，比如通用寄存器，就需要軟體來維護，防止非安全世界的看到安全世界的數據。x0dx0a 引起安全切換的會有幾種可能：中斷和SMC指令。中斷分為如下幾種情況：x0dx0ax0dx0a非安全世界下，在EL1或者EL0，當一個非安全中斷來臨，那麼系統沒必要切換安全狀態，作為一般中斷處理，切到EL1即可。x0dx0a 非安全世界下，在EL1或者EL0，當一個安全中斷來臨，那麼系統必須先切到EL3，不然就沒法做安全世界切換。x0dx0a 安全世界下，在EL1或者EL0，當一個安全中斷來臨，沒必要做安全世界切換，作為一般中斷處理，切到EL1即可。x0dx0a 安全世界下，在EL1或者EL0，當一個非安全中斷來臨，那麼系統必須先切到EL3，不然就沒法做安全世界切換。x0dx0a 當跳到EL3的Secure Monitor程序處理上下文切換時，IRQ/FIQ中斷屏蔽位不起作用，哪怕打開了也不會觸發，直到Secure Monitor處理完，向下跳到相應的安全世界EL1時，才會讓原來的中斷屏蔽恢復，從而觸發中斷。此時處理中斷的是安全世界的中斷程序，處於被保護的內存區域，杜絕非安全世界的程序篡改。x0dx0a 那怎樣觸發安全與非安全中斷呢？這在中斷控制器里有定義，早年的定義中只有FIQ可以作為安全中斷，後期的可配置，並且，相應的安全世界配置寄存器只有在處理器的安全世界中才可以訪問。x0dx0a SMC指令和中斷觸發類似，只不過軟體就可以觸發，切換到Secure Monitor。這里，非安全軟體可以提出觸發請求，在通用寄存器填入參數，卻無法控制安全世界的處理程序做什麼，也依然看不到被保護內存數據。所以防止數據泄密的任務就靠安全操作系統了。x0dx0a 至此，安全啟動後的基本硬體防護已經完成，但如果你以為這就是Trustzone，那就錯了，精彩的在後面。x0dx0a 我們可以把Trustzone放到實際應用裡面看看是不是可行。以DRM舉例，如下圖：x0dx0ax0dx0a在播放授權 視頻的時候，視頻流來自網路或者快閃記憶體，它們不需要在安全世界，因為數據本身就是加密過的。然後被解密並放到被保護內存，等待解碼。上圖中，密碼保護和解密是通過安全硬體模塊Crypto來完成的，這個我們以後再分析，先處理解密完成後的視頻流。此時有兩種方案：x0dx0a 第一中，非常自然的，可以把所有的過程在安全世界完成，那麼圖形處理器，視頻處理器和顯示模塊必須都工作在安全世界，能訪問安全世界的數據，才能完成工作。可這樣就帶來一個問題，那就是驅動。我們知道，圖形處理器的驅動是非常復雜的，並且手機上只存在Linux和windows下的圖形驅動，和OpenGL ES/DirectX配合。x0dx0a 而安全世界的操作系統（TEE，Trusted Execution Environment）是完全不兼容的安全系統，甚至有的都不支持SMP， 完全不存在可能性把圖形驅動移植上去，也沒有任何意義。這樣的話，就只能把圖形處理器從流程中挖掉，只留下相對簡單也不需要生態的視頻和顯示模塊的驅動，工作在安全世界，而GPU的輸出送到顯示模塊，由顯示模塊進行混合。x0dx0a 這是一種可行的方案，也確實有公司這么做。但是從長遠看，圖形處理器總是會參與到這個過程的，別的不說，只說VR和AR流行以後，要是虛擬個顯示屏出來，上面播放視頻，然後放在一個虛擬出的房間，那他們之間肯定是要進行互動的，此時顯示模塊就需要把視頻圖層送回GPU進行運算。如果GPU不在安全世界，那就會造成泄密。x0dx0a 為了解決上述問題，有了第二種解決方案，稱作TZMP1（Trustzone Media Protection 1），引入了保護世界的概念。x0dx0a 保護世界工作於非安全世界，這樣才能兼容圖形驅動。那安全怎麼辦？它需要添加四根管腳NSAID，類似於安全世界的PROT信號，只不過做了更細的劃分，使得GPU/視頻/顯示模塊要訪問被保護內存時，預先定義好了許可權。而這個許可權的設置，也是通過前文的TZC400來實現的，在安全啟動鏈中就完成。CPU的許可權通常是0，也就是最低。而顯示控制器許可權是只讀。x0dx0a 這樣一來，我們之前的老問題，惡意緩存監聽，又回來了。在新的A73和G71加CCI500/550匯流排系統里，可以支持雙向硬體一致性。這意味著GPU也能被監聽。這下大家都在非安全世界，緩存里的安全位不起作用，怎麼解決？這需要匯流排的配合。x0dx0a ARM的匯流排CCI500/550，有一個保護模式，打開後，不光支持上文的NSAID管腳，還可以在監聽的時候，把監聽傳輸替換成緩存行無效化命令，直接讓目標把相應緩存行無效化。這樣一來，數據還是需要從內存讀取，保證安全。並且這個過程對軟體透明，無需做任何改動。x0dx0a 可是此時，辛辛苦苦設計的硬體一致性就完全起不到加速作用了，性能受到影響。好在運行OpenGL ES的時候，GPU是不會發出共享傳輸的，CPU也不會沒事去監聽GPU的數據。而下一代的圖形介面Vulkan，會開始使用GPU雙向一致性，那時候會有影響。還有一點不利的是，如果同時運行OpenCL和DRM，OpenCL也用不上雙向硬體一致性，必須重啟系統切換到非保護模式才行。x0dx0a 還有，在實際使用中，現有的TZC400作為內存保護模塊，有幾個致命的缺陷。x0dx0a 第一，它的配置只能在啟動時完成，無法動態改變，也就是說，一旦某塊內存給了安全世界，就無法再被非安全世界的操作系統使用，哪怕它是空閑的。在4K視頻播放時，需要分配幾百兆內存，還不止一塊。x0dx0a 如果一直被占著，這對於4GB內存手機來說是個沉重的負擔。怎麼解決？只能改成動態配置。此時，如果內存不夠了，非安全操作系統提請求給安全系統，讓它把暫時不用的物理內存設到非保護內存區，並定個時間收回。不過這樣一來內存分配機制就復雜了，說不定還得改內核，很危險。x0dx0a 如果忽視這點，繼續往下走，還會遇到第二個問題。TZC400和它的改進版最多隻能支持最小顆粒度為2MB的內存塊管理。為什麼不弄細些呢？很簡單，如果設成4KB，和系統頁大小一致，那麼4GB的物理內存就需要一百萬條目來管理。如果做成片上內存，比二級緩存還大，不現實。x0dx0a 而做內存映射，就和MMU一樣了，經過CPU的MMU後，數據訪問還要再穿越一次MMU，延遲顯然大。此外，這一層的MMU無法利用一二級緩存放頁表，效率極低。如果繼續保持2MB的顆粒，那麼在分配內存的時候，很快就會因為塊太大而用完。就算使用了上一節的方法，問題也沒法很好解決。這就是TZMP2V1。x0dx0a 在這種情況下，第三種基於虛擬機的方案就出現了。不過這個方案基本上推翻了Trustzone最初的設計意圖，我們來看下圖：x0dx0ax0dx0a在這里，作為內存保護的TZC400完全移除，而系統MMU加了進來。內存保護怎麼做？靠物理地址重映射。先看處理器。在啟動鏈中，從EL3向EL2跳的過程時，就定義好保護內存，並且EL2,也就是虛擬機的頁表存放於保護內存，EL1的安全頁也同樣放在保護內存。x0dx0a 這樣，當處理器進入到EL1，哪怕通過篡改EL1非安全頁表的安全位，也最終會被映射到它所不能訪問的安全內存，從而起到保護作用。同樣的，給處於非安全世界的控制器也加上系統MMU，讓設備虛擬化，同樣可以控制安全。這就是TZMP2V2。有了系統MMU，頁表可以做成4KB大小了，也不用擔心CPU那裡穿越兩次MMU。這時候，也不用擔心惡意監聽緩存，因為所有穿過二級MMU的訪問里，安全位都是經過檢驗的的。x0dx0a 但是，不看別的，光是為設備加入這些系統MMU，就會增加很多面積。還有，光加MMU不夠，還要加入系統的三級甚至四級緩存，才能讓MMU效率更高，不然延遲太大。當然，如果設備使用的頁表並不很多，可以對MMU簡化，比如增大最小顆粒度，減少映射范圍，直接使用片內內存。這需要系統設計者來做均衡。對於GPU來說，要支持雙向一致性，還得考慮讓監聽傳輸通過MMU，不然功能就出問題了。x0dx0a 如果使用了TZMP2V2，那麼虛擬化就變成了一個切實需求。然後會發現，ARM的中斷和設備的虛擬化還很不完善。接下來我從硬體角度解釋下虛擬化。x0dx0a 說到虛擬化，先要解釋系統MMU。x0dx0ax0dx0a如上圖所示，系統MMU其實很簡單，就是個二層地址轉換。第一層，虛地址到實地址，第二層，實地址到物理地址。請注意，沒有第二層轉換時，實地址等同於物理地址。這個模塊既可以兩層都打開，也可以只開一層，看情況而定。x0dx0ax0dx0a上圖比較清楚的顯示了一層映射的過程。其中，設備發出的虛地址請求，會先經過TLB，它裡面存了以前訪問過的頁表項，如果有，就直接返回，沒有就往下走到第二步table walk。x0dx0a 第二步里，MMU會按照預設的多級基址寄存器，一級級訪問到最終頁表。如果MMU位於CPU內，那table walk過程中每次訪問的基址和表項，都可以存放於緩存中，大大提高效率。如果在設備上，只有內建的TLB表項，後面沒有緩存，那未命中TLB的都是訪問DDR，效率自然下降。x0dx0a 所以CPU和GPU等經常訪存的設備，都是自帶第一層MMU和緩存。而對於沒有內部MMU，切換頁表又不是很頻繁的設備，比如DMA控制器，可以在下面掛第一層MMU，此時驅動就簡單了，直接把應用程序看到的虛地址給DMA的寄存器就行，MMU會自己按照基地址去查找相應頁表並翻譯，把實地址送到匯流排。不然，驅動還要自己查找實地址再寫入寄存器。x0dx0a 我們前面說過，在TZMP1和TZMP2v1中，內存保護是靠TZC400來完成的。而到了TZMP2v2，取消了TZC400，這時靠虛擬化的二層地址映射。x0dx0a 二層映射的過程和一層映射基本一樣，不再詳述，但是性能問題會被放大。假設在一層中，經過四級基址查到最終頁，而在二層中，這每一級的基址查找，又會引入新的四級基址訪問。所以至少要經過4x4+4=20次訪存，才能確定物理地址。如果沒有緩存的幫助，效率會非常低。x0dx0a 其他可行的辦法是減少基址級數，比如linux只用了三級頁表，但即使如此，也需要3x3+3=12次查找。在包含緩存的ARM CPU上，虛擬機的效率可以做到80%以上。而二層MMU應用於設備實現設備虛擬化的時候，就需要小心設計了。x0dx0a 有了系統MMU，我們就有了全晶元虛擬化的基礎。那在對系統性能和成本做完平衡，採取合適的系統MMU設計之後，是不是就可以實現虛擬化，並且靠虛擬化實現安全了？沒那麼容易，還有其它問題需要考慮。x0dx0a 虛擬化脫胎於模擬器，就是在一個平台上模擬出另一個平台。在指令集相同的時候，沒有必要翻譯每一條指令，可以讓指令直接被硬體執行，這樣指令的效率算是得到了解決。當然，對於某些特殊指令和寄存器訪問，還是需要hypervisor處理的。接著第二個問題，訪存。x0dx0a 我們前面解釋過，對CPU來說，高效的虛擬化訪存，就是讓指令高效的經過兩層翻譯，而不是每次訪存都需要觸發虛擬機EL2的異常，切到Hypervisor，再得到最終物理地址。這一點在沒有缺頁異常的時候，ARM的虛擬化也已經做到了，而有缺頁異常時還是需要Hypervisor處理。再接著是設備訪存虛擬化，有了系統MMU，也可以高效做到。再就是處理器和設備中斷虛擬化。x0dx0a 最後，設備的虛擬化需要管理，那設備本身需要支持虛擬設備號和虛擬中斷號。更多內容請期待。
如果看待國航機長肆意將隨機機務趕下飛機的行為？
由於廣元機場無機務，需跟班放行，本來是休息時間的我，一早的來到機場，乘坐機組車與機組一同前往飛機，期間無任何異常，經過2個半小時的飛行，順利到達廣元，廣元小雨，我冒著雨，轉飛機仔細檢查完成過站工卡，當我濕漉漉的回到飛機上，准備簽署TLB時候，機長沈偉峰 竟然告知我：他不同意我繼續乘坐飛機，要不是在北京時間緊，在北京就把我趕下去了，理由是沒人通知他有跟班機務，當我渾身滴著水，拿出我的公務乘機證明和機務隨機派遣單時候，沈偉峰一邊坐在頭等艙吃著他的機組餐，當著全機組，乘務組，還有當地機場工作人員的面，指著我的鼻子，要我滾下他的飛機，並同時告訴我，飛機上沒有我的吃的，沒有我的位置 ，從早上6點從家裡出來，我還沒有吃任何東西，最快也要等到下午3點才能回到北京，我懷著滿心得委屈，打電話給MCC，幾經轉接，電話那頭，要我先完成我的工作，我只得含著眼淚簽署TLB，沈偉峰卻喊著：他自己可以無故障放行，不需要我的放行。參加工作這么多年，努力學習，辛苦的考取了執照，拿到了授權，每天維護這些熟悉的飛機 ，頭一次要被人敢下（趕下-編注）飛機，兄弟們，都說機務地位越來越低，卻沒成想低到如此地步，這TM就是國航的機長！就是這么對待機務的！
解釋下龍芯
關於CPU和晶元，我們標準的操作系統，大約有350個C函數，這種操作系統叫標準的操作系統，IEEE
POSIX這就是標准操作系統的規范，但是事實上，美國很多軍方的CPU和工控，飛機製造和武器工業控制領域很多晶元是不支持這個標準的，比如軍隊的OpenRISC派系的晶元，只能支持大約100~150個標准C函數，當然了，剩下的200多個函數可以使用這個100多個函數來用軟體來實現，但是，這些用軟體實現的庫和函數，運行速度相當的慢。
實際上mips就是當年早期OpenRISC商業化的產物，但是Mips走的更遠，主要解決大規模並行的浮點數運算問題。mips是支持linux操作系統的，但是這個CPU只能順利的運行大約150個標準的操作系統的C函數。
現在C++標准庫STL一共又20個大類，超過了1000個函數或者模板實現，而boost庫（STL的升級版）有超過2000個復雜函數或者模板實現，這些函數如果在intel或者AMD的晶元上執行得到的結果，跟在arm上執行得到的結果很多都是不同的，尤其是執行效率問題，很多在arm上慢的要死，比java還要慢（現在安卓機主要使用java開發應用軟體，編譯器是使用J2SDK修改的編譯器）。蘋果公司在這方面有比較深入的研究。這個不細談。
如果這個C++函數在mips晶元上執行，這裡面有一多半是根本無法執行的，也就是說