程式和進程的記憶體分布解析

在多任務作業系統中的每一個進程都運行在一個屬於它自己的記憶體沙盤中。這個沙盤就是虛擬位址空間（virtual address space），在32位元模式下它總是一個4GB的記憶體位址塊。這些虛擬位址通過頁表（page table）映射到實體記憶體，頁表由作業系統維護並被處理器引用。每一個進程擁有一套屬於它自己的頁表，但是還有一個隱情。只要虛擬位址被使能，那麼它就會作用於這台機器上啟動並執行所有軟體，包括核心本身。因此一部分虛擬位址必須保留給核心使用：

這並不意味著核心使用了那麼多的實體記憶體，僅表示它可支配這麼大的地址空間，可根據核心需要，將其映射到實體記憶體。核心空間在頁表中擁有較高的特權級（ring 2或以下），因此只要使用者態的程式試圖訪問這些頁，就會導致一個頁錯誤（page fault）。在Linux中，核心空間是持續存在的，並且在所有進程中都映射到同樣的實體記憶體。核心代碼和資料總是可定址的，隨時準備處理中斷和系統調用。與此相反，使用者模式地址空間的映射隨進程切換的發生而不斷變化：

藍色地區表示映射到實體記憶體的虛擬位址，而白色地區表示未映射的部分。在上面的例子中，Firefox使用了相當多的虛擬位址空間，因為它是傳說中的吃記憶體大戶。地址空間中的各個條帶對應於不同的記憶體段（memory segment），如：堆、棧之類的。記住，這些段只是簡單的記憶體位址範圍，與Intel處理器的段沒有關係。不管怎樣，下面是一個Linux進程的標準的記憶體段布局：

查看本欄目更多精彩內容：http://www.bianceng.cnhttp://www.bianceng.cn/OS/unix/

當電腦開心、安全、可愛、正常的運轉時，幾乎每一個進程的各個段的起始虛擬位址都與上圖完全一致，這也給遠程發掘程式安全性漏洞開啟了方便之門。一個發掘過程往往需要引用絕對記憶體位址：棧地址，庫函數地址等。遠程攻擊者必須依賴地址空間布局的一致性，摸索著選擇這些地址。如果讓他們猜個正著，有人就會被整了。因此，地址空間的隨機排布方式逐漸流行起來。Linux通過對棧、記憶體映射段、堆的起始地址加上隨機的位移量來打亂布局。不幸的是，32位地址空間相當緊湊，給隨機化所留下的空當不大，削弱了這種技巧的效果。

進程地址空間中最頂部的段是棧，大多數程式設計語言將之用於儲存局部變數和函數參數。調用一個方法或函數會將一個新的棧楨（stack frame）壓入棧中。棧楨在函數返回時被清理。也許是因為資料嚴格的遵從LIFO的順序，這個簡單的設計意味著不必使用複雜的資料結構來追蹤棧的內容，只需要一個簡單的指標指向棧的頂端即可。因此壓棧（pushing）和退棧（popping）過程非常迅速、準確。另外，持續的重用棧空間有助於使活躍的棧記憶體保持在CPU緩衝中，從而加速訪問。進程中的每一個線程都有屬於自己的棧。

通過不斷向棧中壓入的資料，超出其容量就有會耗盡棧所對應的記憶體地區。這將觸發一個頁故障（page fault），並被Linux的expand_stack()處理，它會調用acct_stack_growth()來檢查是否還有合適的地方用於棧的增長。如果棧的大小低於RLIMIT_STACK（通常是8MB），那麼一般情況下棧會被加長，程式繼續愉快的運行，感覺不到發生了什麼事情。這是一種將棧擴充至所需大小的常規機制。然而，如果達到了最大的棧空間大小，就會棧溢出（stack overflow），程式收到一個段錯誤（Segmentation Fault）。當映射了的棧地區擴充到所需的大小後，它就不會再收縮回去，即使棧不那麼滿了。這就好比聯邦預算，它總是在增長的。