Chrome OS and Native Client

[chihchun]

一些淺見
http://people.debian.org.tw/~chihchun/2 ... ve-client/

昨日晚去 Tossug 聽 Chrome OS 團隊的Google 工程師談偉航介紹 Chromium OS，ericsk 前輩對此聚會寫了演講摘要紀錄。演講的內容大約不外乎推廣 Chrome OS 設計理念，也就是「快速」、「簡單」、「安全」。

關於這個演講，我自己所見的疑問之一，是使用者資料安全的問題。雖說 Google 倡議其設計會將個人資料加密後存於本機，既使實體電腦遺失也不用擔心資料被竊走 (所謂豔照門 ?)，但其資料是會存至雲端系統，功能是讓你在不同的機器上同步個人資料與設定。不過目前網路上還沒有文件或技術規格說明其如何儲存個人資料，而個人資料的可儲存空間收費方式也是一個待議的問題。

作為一個使用者，我實在不希望任何的設定或文件以明碼的方式存於 Google，這家公司已經掌握太多個人資料了。一些使用者願意使用像是 Google Desktop 之類可以帶來一些便利的工具，但實質上是自願拿個人隱私與獨大公司交換便利性。這個代價實在太大了一點。

查了一下目前版本的 cryptohome 設計是預設以一動態金鑰對加目錄作 aes-cbc-essiv:sha256 加密。因整合一 pam_google 模組，各帳號登入時會自動掛載，並獨立加密。至於資料傳到雲端的部份，目前尚不知其如何作。
Native Client

另外一議題，似乎還沒有多少人重視，但我仍期待的是 Native Client。在當代的作業系統上，即便你有超過一半以上的時間可能都只是發發信件、瀏覽網站、上上社交網站，但是還是有許多使用者期待良好的影音效果或遊戲。雖說現在有各家利用 JIT 技術激烈激烈的 ECMA Script (Java Script) Engine，再配合 HTML5 已經可以作相當多應用。不過這種系統介面無法滿足想用盡每一個處理器指令集的多媒體解碼器或遊戲製造商，而且這些軟體開發者手上都已經有不少 code base，他們會希望可以移植，而不是從頭開發。

所以最好還是在系統上挖一個洞，讓開發者可以在瀏覽器上用盡所有硬體資源。業界的一個實做方式是 Microsoft 的 ActiveX，基本概念上就是讓你可以存取作業系統上的各種軟體元件。但是其安全機制一是透過數位簽章 (digital signing) 確保安裝檔未被竄改，一則是詢問使用者是否允許安裝。而這種模式輕易的讓許多麻瓜的電腦上種滿了木馬。

其中一個選擇是使用 NPAPI 的 Plugin. 雖說現在 Chrome Browser 已經開放了 NPAPI 的外掛支援。但是其實 NPAPI 相當不安全，且不甚方便的。不安全指 NPAPI 的權限極大，現有的架構讓 Plugin 可以讓人存取系統資料。而避免安全問題的方式，就是不自動安裝，除了熱門外掛外，其餘的皆讓使用者自己去尋找官方安裝檔。這有效的降低中毒機會，因為麻瓜往往不知道從哪下載木馬。實際的使用經驗仍不便利。

另外一種模式是建立一個沙箱 (Sandbox)，讓所有的程式都在安全的 VM 上跑。這種實做之一是 Adobe 的 Alchemy 計畫，Alchemy 的作法是利用 LLVM 與調整過得 gcc 將 C/C++ 原始碼編譯成給 Action Script Virtual Machine 2 用的 bytecode。於是你可以將原本的 C/C++ 軟體移植到 VM 上，並在瀏覽器中執行。好處是安全，壞處是這樣降低了一些效能，同時也無法用到特定硬體上的多媒體處理指令集。

而 Google 所倡議的作法是 Native Client. 基本作法是希望可以既提供便利性，也可以涵蓋安全與效能之需求。在 IEEE Symposium on Security and Privacy (Oakland'09) 所發表的這篇論文 Native Client: A Sandbox for Portable, Untrusted x86 Native Code 中詳盡的描述了在 x86 的一些策略與作法。

基本上，Native Client 的架構分為

* 內部沙箱：binary validation
* 外部沙箱：OS system-call interception
* service runtime binary module loader
* service runtime trampoline interfaces
* IMC (Inter Mdule Communication) (aka SRPC, Simple RPC)
* NPAPI

目的是為了達到 Software Fault Isolation，安全上的設計用了 x86 memory segmentation 來限制軟體可存取之記憶體與資料範圍，另外也控制 system-call 的限制，僅開放特定 API。另外若該軟體呼叫了不支援的指令集，則系統會以 HLT 指令避開，避免程式執行錯誤。

使用時，瀏覽器外掛會直接下載已編譯的 nexe 檔案，並用其特製 loader 載入執行，使用時不像傳統外掛模式，還需逐同意或手動安裝，方便許多。而與網頁的互動也可以用 Java Script 透過 SRPC 或 NPAPI 控制。

若想進一步瞭解，請閱讀 Native Client: A Sandbox for Portable, Untrusted x86 Native Code 一文 (請參考簡體中文摘要)，以及 Brad Chen 的技術演講，技術演講頗多場，可參考 Google I/O video (簡報) 這場，或較新的 Velocity video 這場或在 University of Washington 的演講。

沒時間看的話，可以看上述的短片的簡介，影片中稍微展示了利用 Native Client 解決影片解碼軟體的問題。目前的軟體架構已經擺入如 SDL, termcap 等，因此你可以玩玩最常被拿來展示的 SDL Doom 或是嵌入 Web 的 VIM!

Native Client 的架構與效能，相較於其他的 sandbox 環境應該是簡單且快一點，至少跟 Microsoft Xax 比起來容易許多。剩下的問題就是能否贏得開發者與使用者的青睞，Native Client 必須要證明其是絕對安全，為了確保安全性，今年，Google 甚至還辦了一個競賽，邀請大家來協助破解。另外一個重要的課題是，移植軟體的相容性與除錯性也會是非常重要，這點還沒有經驗或文件，尚無法判斷。

目前使用 NPAPI 時，現有 API 有些問題，容易造成與 HTML 混用時的一些排版或顯示錯誤。關於這方面 Google 也已經提議了一組新的解決方法在 Mozilla 的 PlatformIndependentNPAPI。
其他

另外一些關於 Chrome OS 平台的筆記

* 目前輸入法架構是 iBus.
* 無線網路設定機制是 Moblin ConnMan, 前端之 Control Panel 是一 Python 設定工具透過 DBus 進行設定。
* 對使用者經驗的設計仍在改進中，除了現有的 Window UI, Tab UI, Apps Menu, Panels ，以及 clutter-based 的客製化 compositing window manager 外。還有像是 Browser Actions 等功能正在規劃中。