# 2017q3 Homework8 (sandbox) - 自我檢查
contributed by <`Feng270`, `FATESAIKOU`>

## 隔離執行環境的建構
### Trusted Execution Environment (TEE) 的應用為何？(舉出共筆以外的真實世界案例)
#### ARM TrustZone
[官方網站](https://www.arm.com/products/security-on-arm/trustzone)
ARM TrustZone 是個使用硬體作為區分的 TEE 系統。不安全以及安全的程式執行時透過控制硬體資源的調度分配來確保安全執行的環境。根據官方網站的說明，不安全以及安全程式在互相調度時使用的是軟體實作的 secure moniter (Cortex-A 系列)或者是硬體的核心邏輯 (Cortex-M系列)。

其主要應用於需要在硬體層級確保安全執行的環境，如：
* 認證機制確保
* 加解密
* 數位版權管理 (DRM)

其實作，以 Cortex-A 系列為例，為了完整劃分 Trusted 以及 Non Trusted 兩個世界，其透過 [AMBA](https://www.wikiwand.com/en/Advanced_Microcontroller_Bus_Architecture)、外部設備(peripherals)以及處理器內部的硬體實現。每個物理處理器核心皆有兩個虛擬核心可使用，其一為安全的另一個則是不安全的，並且提供上下文切換機制(secure moniter exception)，使用時可以使用其提供的指令(SMC - Secure Moniter Call)或者引發一些其他例外中斷，促使 secure moniter 進行上下文切換。實際切換的方法是儲存目前的程式執行狀態至外部，接著恢復欲切換進來的程式執行狀態。

#### arm-trusted-firmware
上面提到的 secure moniter 本身亦被 ARM 所實作，並開放原始碼於 Github，命名為 [arm-trusted-firmware](https://github.com/ARM-software/arm-trusted-firmware)，其當然不只有 secure moniter，如下圖：
這個專案可以理解為一個 firmware，其運行於作業系統(或虛擬機之管理系統 Hypervisor) 之下，根據作業系統本身是否為 Trusted 來決定執行環境。

#### OP-TEE/optee_os
在開源世界中亦有人在 ARM 的 TrustZone 技術之上實作了一個可信任的虛擬作業系統(Trusted OS) - [optee_os](https://github.com/OP-TEE/optee_os)。
當然，其實際上支援了數十種平台如以下：

Allwinner A80 Board
ARM Juno Board
Atmel ATSAMA5D2-XULT Board
FSL ls1021a
NXP ls1043ardb
NXP ls1046ardb
NXP ls1012ardb
FSL i.MX6 Quad SABRE Lite Board
FSL i.MX6 Quad SABRE SD Board
FSL i.MX6 UltraLite EVK Board
NXP i.MX7Dual SabreSD Board
ARM Foundation FVP
HiSilicon D02
HiKey Board
HiKey960 Board
Marvell ARMADA 7K Family
Marvell ARMADA 8K Family
MediaTek MT8173 EVB Board
QEMU
QEMUv8
Raspberry Pi 3
Renesas RCAR
Rockchip RK322X
STMicroelectronics b2260 - h410 (96boards fmt)	
STMicroelectronics b2120 - h310 / h410
Texas Instruments DRA7xx
Texas Instruments AM57xx
Texas Instruments AM43xx
Xilinx Zynq 7000 ZC702
Xilinx Zynq UltraScale+ MPSOC

#### QEMU
在這個 TEE 技術中，身為處理器模擬大老理所當然也支援 ```Arm-TrustZone``` 的技術。透過這款模擬器，便可不必購買昂貴的硬體開發包以及NDAs條款的簽署，我們便可以於 QEMU 之上建立一套 TEE 系統。


以上是使用 QEMU 模擬時採用 ```Arm-TrustedZone``` 技術的架構圖，可以發現其在系統中跟 [arm-trusted-firmware](#arm-trusted-firmware) 幾乎是相同的位置，其都位於 Trusted OS 之下，但實際上 QEMU 可以說是整台電腦的模擬器甚至是個 hypervisor，並且於其中包裝 ```Arm-TrustedZone``` 使得使用者可以直接於其上安全的運行程式。

#### TEE Use case
這樣的 TEE 技術在真實世界中有幾個主流的應用領域：
* "安全" 的實作根據
聯網裝置在進行聯網認證時需要一個認證的基礎(常為一個 key)，這類需求常會出現在需要進行無線更新的移動裝置(e.g. 手機)，當這類裝置需要更新韌體時其必須百般確保更新進來的韌體是正確的。利用 TEE，其可以將認證用的資訊存入受保護的記憶體空間，即使裝置上的應用程式遭到感染並嘗試攻擊系統，依然可以避免系統韌體遭到置換。

* 物聯網設備之安全管理
許多物聯網設備必須儲存管理各種敏感資料，若硬體支援 TEE，則可以將這些資訊儲存於受保護的安全空間中，使得未經認證的應用程式無法碰觸到甚至修改這些敏感資訊。

* 韌體保護
韌體所控制的裝置當中亦包含不少有價值並且敏感的硬體(e.g. 金融卡讀卡機、行動支付)，為避免其資料輕易遭到竊取以及竄改，韌體在從外部裝置搬運資料至記憶體時，可以為其準備受保護的記憶體空間，確保資訊無法被外部應用程式竊取。

* 使用認證過的軟體控制硬體
許多的 ASSP (e.g. 藍芽晶片組) 雖包含預裝軟體，但其依然允許開發人員使用自製的軟體控制。為了防止產品出產後遭到惡意程式竄改甚至取代出廠時所裝配的軟體，將其放置於受保護的記憶體空間中，即可確保這個控制軟體的正確性，並降低遭到逆向的可能。

實際的應用則有以下：
* [Android TEE](https://source.android.com/security/trusty/)
* [阿里雲 IoT-TEE 安全套件](https://iot.aliyun.com/product/tee)
* [專題報導 行動支付安全元件之存取控制](https://www.fisc.com.tw/Upload/9920fd22-3489-406f-957d-a7acff52e251/TC/08.%20蘇偉慶、黃建隆.pdf)

這裡僅擷取部份應用，實際上應用十分大量，而這些應用都是聚焦在於不安全的環境創造安全的環境並執行程式。

### 是否已詳細閱讀 Moxie 處理器架構的 Architecture 文件？能否用 Moxie 組合語言寫出迴圈版本的 Fibonacci 數列程式？

### binutils, gcc, glibc, qemu 到 libffi 這些專案的作用為何？
××

### Intel 的 Software Guard Extensions 關鍵特性為何？並舉出共筆以外的應用案例
與以往沙盒系統不同的是，SGX 將欲保護的程式放進 enclave 中，而這塊 enclave 是獨立的一塊記憶體，程式透過 API 能夠進到這塊受保護的區域，而任何未經授權的動作都會被拒絕，另外該區塊的程式 swap 出 CPU 時會經過加密，如下圖所示，如果直接讀取記憶體的話只會拿到加密後的結果，使得安全性程式能夠得到完整的保護不受攻擊。
在找 SGX 的應用時偶然發現了 UHD 的關鍵字，再搜尋發現原來認證影片的 DRM 也是使用 SGX 來實作。

### moxiebox 打造出隔離執行 (sandbox) 的運作環境該如何與外界溝通？列出對應的程式碼並解讀
* 提示: mmap 系統呼叫

### 是否已詳閱文件 sandbox execution environment 呢？解釋 法國的加密貨幣硬體錢包公司 Ledger 的 BOLOS 運作原理

### 何謂 cross compiler 呢？我們為何需要？
所謂 cross compiler 是指在 CPU 為 A 架構電腦編譯 B 架構程式的編譯器，通常是為了得到更好的編譯效能及環境，針對硬體效能較有限的嵌入式裝置來說，塞入完整的 GCC Toolchain 不是個明智的選擇，舉個較好理解的例子，Mediatek 有製作一系列的 IOT 開發套件，其中有一個型號稱作 MT7688，上面跑的是 580 Mhz 的 MIPS32 CPU，而儲存空間僅有 32 MB，上面跑的是 Busybox + OpenWRT 提供服務，可想而知在上面建立完整的編譯環境是不可能的，因此為了克服硬體限制，Mediatek 提供了 Cross Compiler Toolchain。而當然爾，每個不同架構的 CPU 都可能有自己的 Cross Compiler。

而下一個問題就是要如何使用這些 Toolchain 呢？最簡單的方法就是直接使用 Toolchain 中的 gcc 即可，但面對較完整有 Comfigure 及 Makefile 的專案明顯是不足的，這時候就要透過 `target` 參數的幫助了，在 configure 時加上 --target=mipsel-openwrt-linux-uclibc（以 MT7688 為例）就會自動去找 Toolchain 且寫入 Makefile 的 CC 哦（當然 Toolchain 也要在 PATH 裡面才行），不過由於 Toolchain 通常只會包含最基本的 C/C++ 支援，因此找不到 library 是常有的事，但比起有限的硬體環境還是好過許多。

### ELF 執行檔格式包含哪些 section 呢？又在哪裡可見到詳細描述？
××

### 是否已掌握 GNU gprof 的使用？運作原理為何？
* 提示: 參閱 raytracing 作業規範和共筆成果

### 是否已操作 remote GDB 呢？如何在執行時期檢驗載入的 ELF 執行檔裡頭 .text 和 .data section 內容呢？

#### 是否詳讀文件 遠端除錯 並記錄心得呢？是否在 GNU/Linux 實際照著操作？又，遇到什麼問題呢？
* 提示: 硬體架構以不同，文章提及 IA32，但現在已是 x86_64 架構

### GDB 命令如 step 是如何透過 GDB stub 傳遞到 moxiebox 裡頭呢？兩邊的通訊協定又為何？
* 提示: 需要對照看 moxiebox 的 src/sandbox.cc 檔案內容和 GDB Remote Serial Protocol

### 是否理解 GDB Macro 和 Command Files 呢？能否透過 moxiebox 進行練習呢？

### 參考資料
* [ARM TrustZone](https://www.arm.com/products/security-on-arm/trustzone)
* [AMBA](https://www.wikiwand.com/en/Advanced_Microcontroller_Bus_Architecture)
* [arm-trusted-firmware](https://github.com/ARM-software/arm-trusted-firmware)
* [optee_os](https://github.com/OP-TEE/optee_os)
* [ARM TrustZone in QEMU](https://www.linaro.org/blog/core-dump/arm-trustzone-qemu/)
* [Android TEE](https://source.android.com/security/trusty/)
* [阿里雲 IoT-TEE 安全套件](https://iot.aliyun.com/product/tee)
* [專題報導 行動支付安全元件之存取控制](https://www.fisc.com.tw/Upload/9920fd22-3489-406f-957d-a7acff52e251/TC/08.%20蘇偉慶、黃建隆.pdf)
* [Intel Skylake 微架構處理器小異動，新出貨版本將具備 SGX 安全功能](https://www.techbang.com/posts/39194-intel-skylake-microarchitecture-processors-will-open-sgx-security-features)
* [Intel® SGX Details](https://software.intel.com/en-us/sgx/details)