style="display:inline-block;width:300px;height:250px"
data-ad-client="ca-pub-5935214489160196"
data-ad-slot="8007533899">

ARMv8 與 Linux的新手筆記

ARMv8 與 Linux的新手筆記 […]

Android/Linux Kernel 記憶體管理-入門筆記

Android/Linux Kernel 記憶體管理–入門筆記

hlchou@gmail.com

by loda.chou

這是一篇寫給自己看的筆記,牽涉的範圍是Android/Linux Kernel上下層的記憶體管理機制,由於牽涉到基礎,核心與使用者空間的Framework,這系列的文章會分為幾個單元,依據筆者自己的時間安排,逐一分享出來,並希望對各位有所助益.

相對於整理Kernel 排程,FileSystem,與相關核心模組的知識,重新再去彙整Kernel記憶體機制的Topics,會發現表現上看似簡單的Malloc/Free,背後的諸多細節都有他不簡單的道理. 同時,所需供應的記憶體對象,還包括User-Space/Kernel-Space的應用需求,但考量到安全,記憶體的節省與效率,背後就會衍生出諸多設計去改善這些路徑,要能清楚的掌握,還須用功紮根才是. 雖然撰寫過程中盡可能確保資訊的完整與正確性,若仍有所不足還請見諒.

本文會以Linux Kernel 3.5.4為參考Source Code,目前Kernel已經演進到3.6.1 (http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.6.1.tar.bz2),Kernel Memory也有一些改善,後續的討論也會轉到3.6核心上,若各位手中的Kernel邏輯與筆者所參照有落差,請以自己手中所使用的Linux Kernel版本Source Code為主.

在軟體的世界,處理器需要記憶體上儲存的指令集與資料來運算開發者所設計好的邏輯,從一個Task的產生,就會涉及 Data/Code Segment Memory Mapping,Stack與Heap的Memory Allocation. 在non-MMU的世界,包括作業系統與應用程式都直接面對實體記憶體,在這階段的記憶體管理,由於保護機制的缺乏,一旦發生Corruption,要有效收斂的難度也相對較高. 但在有MMU的作業系統上,User與Kernel 世界的記憶體可以被切開,而User-Space Cross-Process之間的空間也彼此獨立,若有一個Process有設計上的缺陷,通常都可以控制在該Process運算空間內觸發問題,而針對該流程進行收斂. 若各位也走過non-MMU Real-Time OS到目前功能完備的Linux Kernel這段路,因此也會有所體會的.

參考Linux Kernel文件 “Documentation/memory.txt”,有如下對記憶體的簡述

“There are some motherboards that will not cache above a certain quantity […]

Android 4.1 Jelly Bean安全機制探討

Android 4.1 Jelly Bean安全機制探討

By loda

hlchou@gmail.com

有關手機或作業系統的安全議題一直就像是潘朵拉的盒子一樣,帶點神祕但卻又很吸引大家的目光.由於智慧型手機幾乎是現代人必備的隨身電子產品,若在智慧型手機上被找到安全漏洞,相對於原本個人電腦的世界,所引起的漣漪也將非比尋常.曾在“我是亞桑傑”這本書中讀到如下印象深刻的話語

”我憎恨對安全的歸類,他們的分類就是,’凡是沒有被明確允許就是不准’,他們以為他們是誰? 想用科技來掩護他們野蠻的行為.”

熟悉安全技術的演進,可讓我們除了理解系統核心外,還多了不同看系統的角度.或許有天,真有那樣的機會,這些安全技術真的可以幫助到各位當下所需解決的棘手難題也說不定.

Jelly Bean可說是目前為止,最安全的Android作業系統.

首先,本文將著重在Android 4.1 Jelly Bean中新增的安全機制,而討論Android安全議題最佳的入口網站是Google的網頁 “Android Security Overview” (http://source.android.com/tech/security/),在這網頁中有說明過去以來每一版本Android在安全Features上的差異點,對Android安全議題有興趣的開發者,絕對不可以錯過.

總結來說,Android主要的安全特徵演進簡述如下表

Android版本 說明 1.5之後 1,加上Stack Overflow Protector的編譯器選項 -fstack-protector,可在程式碼編譯過程中,在函式進入與離開時,檢查所加上的Stack Pattern是否有被改變,若有就表示有Stack Overflow的汙染,進而就位觸發Abort,讓開發者有機會即早預防.

(可參考 build/core/combo/linux-arm.mk中有關GLOBAL_CFLAGS編譯參數的設定.)

2, 採用 safe_iop (a safe integer operation library for C)的C函式庫. 並可提供相關乘法/除法/加法與減法的安全整數操作巨集(例如:safe_mul(),safe_div(),safe_add()與 safe_sub() )

(可參考網頁http://code.google.com/p/safe-iop/source/browse/tags/r0.3.0/README)

3, 採用dlmalloc記憶體配置與管理機制.這是由Doug Lea 從1987年開始開發的dlmalloc (全名為 Doug Lea’s Malloc).所有透過dlmalloc配置的Memory Chunk都會是8bytes Aignment,並根據Memory Chunk的使用狀況(例如:是否為Free)而有額外8或16 bytes的Chunk Header Struct成本.所配置的記憶體區塊小於256bytes就會置入SmallBin結構,如果大於256bytes就會導入TreeBin的結構中.預設的dlmalloc會以256kbytes作為要透過MMAP (以4kPage為單位配置)或BRK (延伸Data Segment的記憶體配置方式,效率較高)的判斷依據.但在Android系統中,則預設改為大於64kbytes會走MMAP,小於則走BRK. 2.3(GinberBread)之後 1, 加上format-security編譯選項,用以在使用像是printf/scanf這類會用到字串型態的函式中,可針對非字串格式的參數進行警告.在編譯參數上,設定的方式為 “-Werror=format-security”,v讓屬於 format-security 的警告,在編譯過程中會以Error的方式呈現.

2, 加上GCC編譯參數–noexecstack , 用以讓程式載入後Stack會透過MMU設定不可執行. (Hardware-based […]

Linux Kernel Heterogeneous Multi-Processor Scheduling筆記

Linux Kernel Heterogeneous Multi-Processor Scheduling筆記

by loda. hlchou@gmail.com

本文將不涉及過往在產品中已經很普及的ARM11+ARM9 或ARM9+DSP這類處理器指令集有差異或L2 Cache沒有共用的架構.而會專注在基於ARM指令集與Cache Coherency 共用的基礎上,所衍生的排程架構探討,並介紹目前兩種big.LITTLE排程機制的差異.

Linux Kernel 將導入Heterogeneous Scheduling的機制,簡單來說原本的Linux Kernel Scheduling會視每個參與排程的處理器都具備同樣的執行能力,也就是說當系統中有四個處理器時,每個處理器的執行效率應當都是一樣的,而Linux Kernel排程會透過 Scheduling Run Queue的Weight Loading,來適當的分配這四個處理器所承接的Tasks負荷.

但考慮到Heterogeneous Scheduling機制下,這四個處理器所具備的運算能力是不對等的,也就是說Linux Kernel在考慮要不要把一個Task轉移到這個處理器上時,還需要評估目前Task的”Real-Time”需求以及目標處理器的運算能力,原本只依據Run-Queue Weight Loading計算的結果是,只要每個處理器所承擔的工作夠平均,考慮到公平即可.但在Heterogeneous Scheduling架構下,平均變成不是重點,而是這個處理器運算能力相對於另一個處理器的比例與所要轉移過去的Task的即時性,在兩相衡量下才能讓排程做出Task Migration的決定.

目前ARM SMP主要有三種架構分別由 Qualcomm (aSMP, Asynchronous Symmetrical Multi-Processing), Nvidia (vSMP, Variable Symmetric Multiprocessing)與ARM big.LITTLE(Cortex A7+Cortex A15)所提出 ,有關Linux Kernel排程與aSMP/vSMP介紹,在此就不多說,各位可以自行參考之前的文章 ”Linux Kernel 排程機制介紹” (http://loda.hala01.com/2011/12/linux-kernel-%E6%8E%92%E7%A8%8B%E6%A9%9F%E5%88%B6%E4%BB%8B%E7%B4%B9/).

擷取另一段網路文章的討論 […]

HITCON 2012 – Hacks in Taiwan Conference 台灣駭客年會投影片

感謝HITCON朋友們的協助, 這次的聚會對自己收穫也很大, 尤其傍晚在台啤餐廳的Party真的很棒.

在Session結束時,有人提到投影片的更新問題, 我把最新版本放在這.

Introduce LLVM from a hacker’s view.

歡迎自行取用.

loda.

從LLVM談 Portable Native Client Software Fault Isolation技術

從LLVM談 Portable Native Client Software Fault Isolation技術

by loda

hlchou@mail2000.com.tw

有次在閱讀文章時,看到這段話 「不,知識是有限的,只有愚蠢才是無限的。」by  叔本華(十九世紀 德國哲學家),當下會心一笑,也覺得若我們認為自己無所不知,那可能就正好落入愚蠢的陷阱了…:^o^

會對SFI技術有興趣的主因在於,過去所認為的安全機制確保,不外乎就是透過User/Kernel Mode基於處理器的機制,把UnTrust Code的部分區隔出來,或像是透過Virtualization技術,以虛擬機環境實現同樣的目的.然而在接觸到LLVM與Google的Native Client技術後,才發現其實這條路上還有很多種可能,如果不是參考到這些作法,自己並不知道原來還可以有這樣的方案誕生. 也因此希望可以把這技術推廣給更多人知道,若能對各位有些許幫助,該當是最棒的事情了.

Google在瀏覽器上推廣Native Client技術,希望藉此讓Browser應用可以達到Native應用程式的效能.而Native Client之所以可以達到這樣的目標,正是因為他可以讓Browser執行Native Code,但若僅僅如此,那層出不窮的安全問題,將成為這方案最大的罩門.也因此,SFI技術成為Google在瀏覽器上運行Native Code的安全防護機制,透過Inner/Outer Sandbox機制,讓在瀏覽器中運行的Native應用程式雖然可以直接以處理器指令運行程式,但卻被限制在Google Sandbox所預設的行為範疇中.

既然SFI解決了Native Client亟需的安全問題,另一個能讓Native Client普及的利器就是LLVM,沒有LLVM之前的Native Client只能在x86 32/64bits環境下執行,對於目前以ARM為主的手持裝置來說,無疑就有推廣上的困難,也因此Google將LLVM的跨平台特性與Native Client進行結合,發展了名為Portable Native Client的新技術,讓基於LLVM所開發的BitCode可以透過瀏覽器下載到不同的平台上,再藉由PNaCl Translate技術,把BitCode根據不同平台的差異轉為適應於該平台的Native Code,並藉由原本的Native Client SFI 技術,確保既有跨平台的特性,又兼顧潛在的安全問題.

目前的Portable Native Client 可支援 ARM ,x86 32/64bits平台,藉此可橫跨一般的電腦與智慧型手機的應用.

參考下圖所示,除了Native […]