這篇文章是閱讀了 Kuon Ding 在 COSCUP 2016 發表的演講簡報「開源編譯器,如何實現系統安全最後一哩路」的一點想法。因為 COSCUP 一直待在場外聊天,未進入演講廳聽講,這些心得僅僅參考投影片的資訊。

私認為資訊安全沒有最後一哩路[1],需要保持紀律的環環層層不停的造橋鋪路。

這場演講分享了開放原始碼編譯工具針對系統安全的發展,編譯工具的確是重要一環,以 Ubuntu 為例[2], gcc 的 Stack Protector、built as PIE for exec ASLR、Fortify Source、Read-only relocation 都做額外的補釘加強安全性。然而 toolchain 不能提供獨立的安全保護,像是 Address Space Layout Randomization (ASLR) 必須是從 kernel 層做的。不管是融合桌面、手機環境的 Ubuntu 或是以手機為主的 Android 而言,安全性的發展都是盡可能的降低攻擊範圍(attack surface) 並層層疊加安全限制。

以最近發布的 Android 7[7][8] 為例子,針對系統面的保護改進用 SELinux 與 seccomp sandboxing 中減少 ioctl 的白名單呼叫範圍、 Library ASLR[3]、從 Grsecurity 學來的 CONFIG_DEBUG_RODATA 等等。這些都一步步的減少了攻擊暴露範圍。

舉例而言,文中提到了像是 2016/08 的 DEFCon 24 發布的 QuadRooter 相關漏洞[4],許多都是來自 SoC 的程式碼設計缺陷所造成,而這些缺陷很難透過代碼審查的方式查出,特別是由於智慧產權的限制,很多有問題的驅動程式是以二進位檔散布的,作業系統廠商或終端硬體品牌商是拿不到原始碼的。這些只能透過系統安全機制[15]來防護。

如 QuadRooter 中提到的 CVE-2016-2059: Linux IPC router binding any port as a control port,這個攻擊的前提是系統關掉 kASLR[5],然後才有機會做 Heap Spraying,但是要再拿到 root 還得關閉 SELinux 才行。而攻擊第一步 iocl 命令是可以透過 SELinux Policy 抑制的,例如 CVE-2016-0820 中,MediaTek 的 WiFi 驅動程式的 private ioctl 漏洞,可以關掉一般程式存取 device private commands[6].

編譯器未能防止類似的問題,必須依賴其他機制來保護系統。

編譯器[9]實踐的 KAsan (Kernel Address Sanitizer)[21] 功能可以查找 QuadRooter 中 CVE-2016-2503/CVE-2016-2504 等 use-after-free attack[22] 問題,但是一樣需要核心的支援[10]。而這個在 4.4 中的功能能夠發送到使用者手上尚須要一段時間[14],不僅僅是更新 toolchain 重新編譯即可。

不是所有的理論技術都可以在安全、便利性、效能上帶來好處,作業系統往往必須做出取捨。

  • 例如啟動了投影片中[1]提到 vtable verification feature[27],這個功能會讓一些重要的軟體如 Firefox 炸掉[11],因為開發者會對 vtable 用一些奇計淫巧。
  • 例如前述的 Ubuntu 中的 built as PIE 在 i686 平台上會造成 5-10% 的效能損失[12],只能挑某些重要的庫使用。到 16.10 才因為 64 bit 環境成熟而預設啟用。
  • 例如啟動了 Kernel Address Space Layout Randomisation (kASLR) 後,在 x86 上就無法讓電腦休眠[13] ,對沒電時需要緊急休眠的筆記型電腦使用者是無法接受的。

每項安全設計都不能只從單方面來看,需要全局的評估。有些無法在編譯器中實踐的功能,可以在 kernel 中完成,kenrel 的問題可以透過 app sandboxing 來補強。

而最近幾年的作業系統發展趨勢以 Isolation (Sandboxing) 為方向,像是 Android 使用 Selinux 的 Sandbox、ChoromeOS 中使用 Minijail[16],Linux Desktop 上的 xdg-app/Flatpak[17][18],以及 Ubuntu 使用 Snappy (Apparmor)[19][20] 等等技術。除了 Linux 以外,Apple OSX 基於 TrustedBSD Mandatory Access Control (MAC) Framework 的 Sandbox[23][24][25], 以及 Microsoft 的 Windows Runtime sandbox[26] 等等。這些系統的設計都是為了保護使用者的資料,除了防止惡意程式之外,如果程式遭到破解,所能造成的破壞也會被侷限在沙箱內。

最大的挑戰之一,或許是針對新的 security model 設計具備彈性 API,以及在多重限制的運行環境下仍可提供友善便利的使用者體驗吧。

[1] 開源編譯器,如何實現系統安全最後一哩路 by Funny Systems – https://speakerdeck.com/FunnySystems/kai-yuan-bian-yi-qi-ru-he-shi-xian-xi-tong-an-quan-zui-hou-li-lu
[2] https://wiki.ubuntu.com/Security/Features
[3] Implement Library Load Order Randomization – https://android.googlesource.com/platform/bionic/+/4f7a7ad3fed2ea90d454ec9f3cabfffb0deda8c4%5E%21/
[4] QuadRooter Research Report – https://www.checkpoint.com/downloads/resources/quadRooter-vulnerability-research-report.pdf
[5] Kernel address space layout randomization [LWN.net] – https://lwn.net/Articles/569635/
[6] Only allow shell user to access unprivileged socket ioctl commands. – https://android.googlesource.com/platform/external/sepolicy/+/57531ca%5E%21/
[7] Security | Android Open Source Project – https://source.android.com/security/
[8] Security Enhancements in Android 7.0 | Android Open Source Project – https://source.android.com/security/enhancements/enhancements70.html
[9] [ASan] Initial support for Kernel AddressSanitizer · llvm-mirror/llvm@e9149f4 – https://github.com/llvm-mirror/llvm/commit/e9149f4f8cd3b915ada134d80452c6eae7875ca4
[10] KASan support for arm64 – http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02583.html
[11] Crash in mozJSComponentLoader::ModuleEntry::GetFactory when compiled with GCC 4.9.0 and VTV – https://bugzilla.mozilla.org/show_bug.cgi?id=1046600
[12] PIE has a large (5-10%) performance penalty on architectures with small numbers of general registers (e.g. x86) – https://wiki.ubuntu.com/Security/Features#pie
[13] Prefer kASLR over Hibernation – Patchwork – https://patchwork.kernel.org/patch/8765121/
[14] KASan support for arm64 – http://lkml.iu.edu/hypermail/linux/kernel/1511.0/02583.html
[15] Google Online Security Blog: Protecting Android with more Linux kernel defenses – https://security.googleblog.com/2016/07/protecting-android-with-more-linux.html
[16] Chromium OS Sandboxing – The Chromium Projects – https://www.chromium.org/chromium-os/developer-guide/chromium-os-sandboxing#h.l7ou90opzirq
[17] Projects/SandboxedApps – GNOME Wiki! – https://wiki.gnome.org/Projects/SandboxedApps
[18] Sandbox · flatpak/flatpak Wiki – https://github.com/flatpak/flatpak/wiki/Sandbox
[19] snapcraft – Snaps are universal Linux packages – http://snapcraft.io/
[20] Snappy Interfaces | Labix Blog – http://blog.labix.org/2016/04/22/snappy-interfaces
[21] Kernel Address Sanitizer – https://github.com/google/kasan/wiki
[22] Four new Android privilege escalations [LWN.net] – https://lwn.net/Articles/696716/
[23] The Apple Sandbox https://media.blackhat.com/bh-dc-11/Blazakis/BlackHat_DC_2011_Blazakis_Apple%20Sandbox-Slides.pdf
[24] The Apple Sandbox https://media.blackhat.com/bh-dc-11/Blazakis/BlackHat_DC_2011_Blazakis_Apple_Sandbox-wp.pdf
[25] SandBlaster: Reversing the Apple Sandbox – https://arxiv.org/pdf/1608.04303.pdf
[26] WinRT: The Metro-politan Museum of Security https://conference.hitb.org/hitbsecconf2012ams/materials/D1T2%20-%20Sebastien%20Renaud%20and%20Kevin%20Szkudlapski%20-%20WinRT.pdf
[27] Improving Function Pointer Security for Virtual Method Dispatches https://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=cmtice.pdf

「利益揭露: 本文英文書籍連接使用 Amazon Associates Program.」

我相信絕大部分 Linux 開發者都會告訴你,Driver 的開發比 Linux Application 容易許多,即便寫驅動程式聽起來莫名偉大,其實也不過是一段 C/assembly 的組合程式碼。有別於桌面應用程式,Linux kernel API 較少因爲不同的新軟硬體規格,而進行大幅度 API 更動 (參數的簡化倒是十分常見),且由傑出的軟體開發者撰寫的核心架構,穩定性已經十分可靠。

相較與 userland 高度複雜的設定機制,Linux Kernel 暴露的界面十分簡單,在硬體穩定的前提之下,你也難得碰到 API 反應與預期不符合的處境。一般開發者對於核心驅動程式上手的時間,應該不會比開發桌面軟體來的更久。花費時間較多應該是研讀硬體手冊,以及不嚴謹的開發習慣造成臭蟲而所需的除錯時間。

對於深具經驗的開發者,在學習開發 Linux kernel driver 時,最快的方法莫過於直接解開 Kernel tarball, 切進欲開發的 subsystem 目錄,拿出 global, vim, LXR 直接把現成程式碼當作範例學習,很快就可以理解程式結構。不過,偶爾還是需要參考書來驗證對於架構得理解是否正確,另外接觸新的 subsystem 時先閱讀入門文章也可以減少無謂的撞牆期。

所幸,幾位 Linux kernel hacker 也是傑出的文件作者。在 Linux kernel sourc tree 中已有一些各子系統的架構、操作參考文件,涵蓋了基本的 coding style、設計哲學等。另外,像是 Robert Love, Greg Kroah-Hartman (PCI, USB maintainer) 等開發者也出版了完整的書籍,很值得參考。

不過市面上針對 Linux kernel 開發的書籍也不少,那一本是適合你的呢?這類的技術書籍,通常設定不同的讀者羣來設定內容,有的偏重知識,有的偏重操作實務。且出版版次也會影響所介紹的 API 差異,造成無法編譯其範例,但並非舊書,所談之理論就不正確。

以下分享不才對於市面上 2005 年之後出版的核心開發書籍的評論,希望對於想擴充團隊圖書館的朋友提供些參考。

Linux Kernel in a Nutshell 是 2006 年年底發行,作者是 GregKH,使用核心為 2.6.18,部分操作方式或指令已經略有更改。GregKH 基於讓更多新手參與開發行列,針對的讀者是從未編譯過 Linux kernel,想瞭解下載、設定、編譯需求等等細節,適合剛從其他平臺進入 Linux 核心開發的朋友,可以較快熟悉核心編譯的操作程序。書內主要介紹通用性知識,因此未提各 distro 間安裝 kernel 的細節 (如 initrd 建制方式)。

LKN 已採 CC BY-SA 2.5 授權。電子書可於 GregKH 的網頁下載

Understanding the Linux Kernel, Third Edition 這本由兩位博士 Daniel P. Bovet 與 Marco Cesati 所撰寫,從 2000 年底出版之後,到 2005 已經是第三版,介紹的核心是 2.6.11。有中譯版

此書結構以流水帳方式帶過各個子系統,但稍嫌膚淺的僅僅介紹表面的細節,未能給予概觀性的理論說明,也未能直指程式核心。篇幅常用於註記資料結構或函式用途,適合想尋著麵包屑理解 Linux kernel 運作的探險家使用。

Professional Linux Kernel Architecture 在2008 年出版,作者是 Wolfgang Mauerer,作者的背景是量子物理學家。在沒有社群內知名開發者的背書與協助下,他完成了一本巨大的書籍,篇幅高達 1368 頁。

有別於 UTLK,也許是為了非科班出生的讀者,作者試著詳盡的敘述作業系統的基本概念,另外一方面也以程式碼告訴讀者 Linux 的運作模式。

如果你讀不下純粹理論導向的作業系統教科書,而想透過 Linux理解一個作業系統的設計原理,這是適合你的書。本書基於 Linux kernel 2.6.24.

身為知名的 kernal hacker, Robert LoveLinux Kernel Development (3rd Edition) 一書中為讀者拆解 Linux kernel source tree, 直接從設計理念切入,酌以程式碼輔助,讀者需要有作業系統理論素養以及 Linux 開發經驗,才能消化理解筆者的解剖。最新第三版發表於 2010 年初版,更新到 2.6.34.

簡體中譯版 Linux 内核设计与实现 翻譯自 Linux Kernel Development 第二版。正體中文版有維科圖書有限公司出版沈中庸, 沈彥男翻譯的 Linux 核心開發指南, 2/e

Linux Network Internals 的作者是 Christian Benvenuti,發表於 2005 年。少數專談 Linux Network stacks 的書籍,作者循序的從設定工具、核心啟動開始,逐一介紹 封包傳送接受、Bridging、IPv4、Neighboring Subsystem 與 Routing。本書基於 2.6.12.

書中涵蓋了 Layer 2, Layer 3 等協定, 可惜遺漏了 IPv6, IGMP, PIM, Traffic Control, Netfilter, Virtual devices (802.1Q, bonding, IPIP, GRE) 等等重要原件。讀者需要基本開發能力與網路協定常識。此書有中譯版

The Linux TCP/IP Stack: Networking for Embedded Systems 第一版發表與 2004 年,最新第二版 2006 年,針對的版本是 2.6.16,作者是 Thomas F. Herbert。此書對於讀者的定位不明。雖然意圖以一個章節討論嵌入式系統中的 TCP/IP Stack,但除了說明一般嵌入式系統需求外,缺乏實際有用資訊。

書籍想涵蓋各種 TCP/IP Stack 所涵蓋的項目,但章節設計雜亂,從基本的 Network Stack 開始介紹,對於 API 部分又缺乏系統性描述。既無法瞭解網路協定,或撰寫網路程式或作業系統核心架構。

書中時常夾雜敘述與程式碼,令讀者難以連貫消化,讀者需要開啟原始程式碼才能領會作者的。這是一本關於網路協定的原始碼註記,適合已具核心開發經驗的開發者參考使用,考量其版本日期,書籍的功能可能比自行追蹤程式碼的效用還差。另外,若你想瞭解嵌入式系統,這也不是你該買的書。

Linux Device Drivers, 3rd Edition 的作者是 Jonathan Corbet (LWN創辦人)、Alessandro RubiniGreg Kroah-Hartman。即便 LDD3 已經出版許久,還是所有想寫 Linux kernel driver 的第一優先入門參考書阿。此書有中譯版

LDD3 務實的從實做範例開始,帶領讀者理解各種 subsystem,含括了入門操作與基本觀念,對於初次開發 lkm 的開發者提供了燈塔般的指引。

LDD3 授權採 CC BY-SA 2.0,線上版可於此下載 http://lwn.net/Kernel/LDD3/。但由於書籍年代較久,針對的核心版本為 2.6.10,書中範例需要一點調整才能正常運作。已有同好改了幾份擺在  github (jesstess, martinezjavier).

Essential Linux Device Drivers 的作者是長期在 IBM 工作的 Sreekrishnan Venkateswaran,參與 Linux Watch, PDA, Nurse Call Systems, Merlin Patient Care System 等等開發專案。有正體中譯版 Linux驅動程式開發實戰 以及簡體中譯版 精通Linux驅動程序開發

這本書是作者的實務工程筆記,出版於 2008 年,針對核心為 2.6.23/2.6.24,透過此書新手可以從中漫遊一個深具經驗的開發者,如何從原始碼迷霧之中理解 Linux device  driver,老手或可從雜亂的描述中再次驗證自己的理解。

雖然篇幅高達 744 頁,卻被引用程式碼佔了許多頁面。這本書不足以提供開發者撰寫驅動程式的基本觀念,也無法協助理解作業系統概觀。

作者另有一小冊 Debugging Linux Systems 電子書短短九十頁,帶過幾個常見的核心除錯工具與技巧,很有實務參考價值。

《The Linux(R) Kernel Primer: A Top-Down Approach for x86 and PowerPC Architectures》 出版於 2005 年,作者是 Claudia Salzberg Rodriguez, Gordon Fischer, Steven Smolski。有中文版,但評價頗差

書名讓人非常期待總算有一本核心介紹書籍 x86 外的硬體平臺,畢竟 RISC vs CISC 架構的不同, endianness, alignment, calling convention 等,應當有許多寫核心驅動程式應該注意得事項。但是整本書只在 2.2 節稍微說一下寫 Assembly 時,PowerPC, x86 的指令差異,剩下的細節根本沒提!

整本書還是著重在一般核心的結構介紹。

而書中除了少量的插圖之外,根本沒有沒有多少邏輯上的說明跟描述。通篇拆解程式碼,對資料結構作註解。這些資訊任何有點基礎的工程師都可自行閱讀程式碼及程式碼註解。新入門工程師還可能因爲書中解釋而疑惑。

除非你想寫沒有價值的書評,否則不建議購買。

Linux(R) Debugging and Performance Tuning: Tips and Techniques 出版於 2005, 作者是 Steve Best。此書少見的從除了應用程式之外,還從核心切入的除錯、效能測試書籍,因爲這方面的技術資訊總是一下就超過保鮮期。

作者試著含括基本的 Profiling 實務開始,介紹 gdb, 應用程式記憶體管理,再講核心的各種資訊界面。很可惜,以一本專講除錯與效能測試的書來說,範例與介紹過於粗淺,以第十二章 Dynamic Probes 為例,其介紹深度可能還比不上 Documents/kprobes.txt 中的概念介紹與 IBM developerWorks 的範例介紹

適合剛切換到 Linux 的開發者,可概略學得各種基本開發工具者的入門資訊。

2011-03-17 18:00 更新

增列相關中譯版本連接,感謝 ansoncat 告知資訊。

2011-05-15 18:00 更新

修正 UTLK 版本為 2.6.11, 補充 ULNI 版本為 2.6.12. 感謝讀者 Wayling 指出錯誤。

這段錄影已經躺在硬碟中很久,這兩日才利用通勤的時間消化了一番。這是 Linus Torvalds 在 Google 所進行的一段演講,身為一個性格強硬的硬底子駭客,他時常發出驚人的評論,有些有趣的言論甚至被整理成格言集,像是 The 10 Best Linus Torvalds QuotesLinus Torvalds Quotes

在這段演講中,身為 Git 計畫的發起人,Linus 說明了為什麼需要設計這樣的一套工具,基本的設計哲學與其他類似的工具的比較。

在技術的觀點上,他直接且尖銳的同時批判了 CVSSubversion,演講一開始 Linus 就給了 CVS 贊頌 – 負面的贊頌,雖然 Linus 從來不用 CVS 管理 Kernel source tree,但是還是在商業公司有過一段不短時間的使用經驗,而且 Linus 打從心裡強烈的厭惡這個工具。同時他也批判 Subversion 這個計畫是他看過最沒有意義的,因為 Subversion 從各方面試著去改善 CVS 的一些技術上的缺點,卻無法根本的解決一些基本使用限制。具體來說 Subversion 改善的創建分支的成本 (意思是相對 CVS 所利用的硬碟、計算資源比較少),但是卻沒辦法解決合併分支的需求,任何使用過 Subversion 合併分支的人都知道那是如何痛苦的折磨。而許多高度開發中的專案,都時常需要為不同的新功能開分支、合併,Subversion 解決了開分支的成本,卻沒有考慮到合併的人工成本。如此讓 Subversion 變成一個沒有未來的軟體計畫。

因此,基於過去在 BitKeeper 上得使用經驗,Linus 設計了新的 Git, 並將效能視為主要的需求。當然分散式的設計也是最重要的概念之一,Linus 提到幾個觀點,討論如下。

第一個是分散式的概念,解決了政治紛爭。所謂政治紛爭指 commit/checkout/create branch 的權利,傳統中央集權式開發模式,你若想要創建一個新的分支,或者進行一些實驗性的開發,通常必須獲得主開發者授予 提交者 (commitor) 的權限,意指你是受到信任的一份子,有權限可以自行修改軟體程式碼,被授權進行一些嘗試。(唐鳳的人人皆為提交者開發模式為例外)

這種模式,很自然的排擠了在所謂信任圈 (core developers) 外的人。對,你依然可以在中央控管的機制下嘗試,你依然可以透過 patch 提交你想要做的更動。但是工具本身的限制,直接的限縮了自由發展的可能性。舉例來說,你相對不容易組成一個工作小組 (Task Group),因為分享程式碼的變動並不容易,你可能必須建立另外一個獨立的程式碼管理系統給這個工作小組使用。而不像分散式的管理工具如 Git/Mercurial 開發者間可以透過數種管道接取/同步雙方的進度。

或者中央集權工具的另外一個根本上的問題是 – 它阻礙了開發者的實驗精神。

簡單講,就是開發者礙於每次提交 (commit),都可能因為程式碼的不相容性,造成其他人必須停下來彙整變更,影響到其他人的工作進度的後果,因此每次提交/儲存都會有所疑慮。因此很容易就演變成開發者埋頭苦幹,直到最後一刻才一口氣提交上線,結果造成的不相容與衝擊更大,反而造成最後的工作成果難以融合。

在分散式開發工具的輔助下,你可以隨意的開立新分支,自行修改、測試、同步、實驗,這些在本地的提交除了完全不會影響到其他人外,同時你也可以輕易的匯出成特定格式 (patches),讓他人更容易的整合。這大幅改善了協同開發模式的磨合問題。

Git 是以分散式開發模式為根本,自然可以融合於相對單純的中央集權  (cvs/svn) 的權利結構。Linus 在演講中也提出了一個我認為很值得討論的觀點,即是應用於 Linux kernel 開發的多層次分散權利結構。Linus 提了一個重點,基本上開發社群中有一種信任關係 (Web of trust),像 Linux Kernel 這樣的龐大計畫,每個版本參與的開發者大約千人。實際上主要開發者如 Linus 不可能認識這麼多人,很自然的,他只能信任最熟識的幾個人,他指知道幾個人的智商與能力都是足以信賴的,於是他只需要仰賴這些人的成果。而其他人在於自己的信賴圈內,找到其他可以仰賴的人,於是利用這樣的信賴機制來擴展成網狀的開發社群。

在實務上,社群中也會演化出幾個角色,像是司令官 (dictator)、副官 (lieutenants)、開發者。幾位副官只要專注在他們熟悉的領域,整合開發者的成果,並提交給司令官做最後的整合決策。這麼一來,各種不同的專業領域都可以交給最熟悉的開發人員管理,而開發不會被限制、停頓在某個角色身上,相對而言是一個比較具有效率的開發社群結構。且分散式開發,也讓不同的開發者得以有權利與自由自行發展,不受限於官僚機制的限制。

上述為演講內容的一些提要。

Web of trust 是我相當認同的一個概念,任何所謂社群中,都會自然的因為信賴關係存在更小的團體,有人誤解這是一種分裂,但是我認為這是一種演化,不該消弭小圈圈的存在,反而應該鼓勵小團體的成立,自行交流、合作,才有機會產生或再演化出更大、更有力量、更健康的社群。(應該有什麼什麼政治學、社會學的理論在講這件事情吧 ?)

另外也推薦一個網站,是即將被國家綁架去服役的 kanru 翻譯的「為什麼 Git 比 X 棒」(Why Git is Better than X)。這個網站簡約的說明了 git 與其他程式碼控制軟體的比較,可以讓你比較容易了解各種軟體間的差異細節。

另外 為什麼 Git 比 X 棒 這個網站中介紹的 github 服務,我個人相當欣賞,它基本上提供了 Git 的 hosting 服務,但同時也包含了更多 Web 2.0 的概念,是所謂 “Social coding hosting”,基本的功能除了提供 Git 外,像一般的社交網站一樣,你可以追蹤別人的狀態,別的網站你追蹤的是朋友發出來的訊息,這裡你追蹤的是朋友寫出來的程式碼,而且你可以直接在線上「複製」(branching) 別人的工作成果,也提供了相當美觀的介面,讓你看到程式碼更動的網路關聯圖,相當有趣。剛開始使用 Git 時,可以試試這個網站。

若想學習 Git, 請參考 Learning git 一文的連結。

這是 Arjan van de Ven 與 Auke Kok Linux Plumbers Conference 2008 上的展示畫面。

在讀 O’Really 對 Arjan van de Ven 的訪問 How PowerTOP, LatencyTOP, and Five-Second Boot Improve Desktop Linux) 時,知道了在 Intel Open Source Technology Center 工作的 Arjan 在 PowerTop, LatencyTop 上的努力,以及其他開發者如何利用這些工具來改進軟體的效能與品質。

在訪問後段提到了 Arjan 最近在 Linux Plumbers Conference 2008 上的實做展示,Arjan 的簡報中提到了開發的思維態度應該以五秒鐘內開機為目標,不要把加速開機當作目標。同時也不要弄先開機,再做後續處理,造成系統無法使用的暫時性解決方式。應該想辦法把正確的事情作對來加速速度,如開機時以平行執行方式 (Parallel boot) 啟動系統也不是正確的行為。

這樣的論點,當然讓長期使用這種解決方案的開發者不甚認同,像是 MandrivaFrederic Crozat 就跳出來說明過去幾年來各種平行執行的策略,並說明在 EeePC 上碰到的一些硬體問題,經過調整後,可以讓 Mandriva 在 Eee PC 上以 15 秒內開機。

而 Arjan 的作法是將開機分成四個程序,分別是 Kernel, Early boot, X Server, GUI/Desktop。其中除了 Desktop 系統外,其他的程序都只能花用一秒鐘執行!

在核心的主要修改是利用從 RedHat readahead 改來的 sreadhead 加速軟體的檔案載入速度 (上個月我也介紹過 readahead 加速 Linux 開機速度 ? 。另外 sreadhead 的原始碼會在 Moblin Project 釋出) ,並將所需驅動程式先編入核心,關掉 initrd,預先建好 /dev 下需要的 device files, 同時利用新的 asynchronous initcall level 來載入較不重要的核心模組。如此可將核心載入時間壓縮在一秒。

相關的新 APIs 已經丟到 LKML 上供檢閱,希望可以納入 2.6.28 中。

而開機程序 (init scripts) 則還是利用 sysvinit,不用平行執行 (Parallel Boot) 之方法,也不利用 udev 動態產出 /dev 下的檔案,而是先固定寫死。另外雖說 initscripts 都還保持著原本的版本,在此預設也是不執行的。

另外 X Server 則稍加修改了 xorg-x11-drv-intel 顯示卡驅動程式,讓其在偵測硬體時,就一併先進行硬體設定,且修正了一些 PCI posting 的臭蟲。而且修改 XKB 快取 keyboard mappings,因為 XKB 居然會每次開啟時呼叫 C preprocessor 來編譯 keyboard mappings!至於桌面系統則使用輕量的 XFCE,稍加修改讓桌面程式同時執行。

如此如此,讓 Arjan 硬幹出來的版本,讓那天展示的跑在 ASUS EeePC 901 上 FedoraMoblin 可以在五秒鐘內開機!相較於其他在 ASUS EeePC 901 上得套件系統開機動輒要約30秒到一分鐘,的確快了很多。

但是我要一個只有桌面沒有網路連線的機器要做什麼呢 ? 且許多硬幹的方法,必須針對特定硬體作調整,的確不適用一般新安裝的系統。不過 Arjan 的 Fastboot 的確很值得參考使用,另外許多低效能問題的解決方法也都可以採用。希望這些新的研究可以盡快的套用到更多的環境上才是。

對了 Arjan van de Ven 也是 Linux-ready Firmware Developer Kit 的發起人,Linux-ready Firmware Developer Kit 是協助 BIOS/EFI 開發工程師測試的工具,若你是開發主機板或 BIOS/EFI 軔體的工程師,請別忘了下載來玩玩,或許可以避免發生 Foxcomm 前陣子的窘狀

前陣子在 Tossug 的 IRC Channel 上討論除了訂閱 LKML 來了解 Linux Kernel 的各種開發進度外,是否還有其他更有效率的方法 ?

對,你可能是用了超新型電腦設備的資深使用者,或者是某某公司的 Linux kernel 維護/開發者,需要了解相關硬體驅動程式的開發支援狀態,或是 API 的改變。

當然,訂閱 LKML 可以確保你不會錯過任何一條新消息。但每日高達兩三百封電子郵件,許多信件中還包含 patches,光下載就花掉不少時間,更何況需要消化這些湧入的訊息。

比較容易的方式是透過 USENET 或 RSS Feeds 訂閱 LKML,如此只需要下載標題,再選擇標題閱讀即可。若不想透過電子郵件軟體閱讀訊息,網路上有相當多提供郵遞論壇轉網頁的網站可使用,如 Google GroupsThe Mail ArchiveNappleLKML.org 等,你尚可配合其內建或 Google 等網路搜尋引擎來查找你想要搜尋的關鍵字,還算相當方便。

許多網站都還提供 RSS 的訂閱機制,你可以直接在 RSS Reader 訂閱後,看到感興趣的標題在點入閱讀。不過大部份的網站都只讓你訂閱最新的標題,如此還是會收到相當多訊息,不甚方便。

LKML.org 提供了一個追星族 (groupie) 功能,我個人認為相當實用,這功能讓你可以訂閱特定開發者的發言!於是,你可以追蹤一些重要人士的發言,如 Linus Torvalds, Andrew Morton 等,以免錯過重要的決策資訊。

但是我要推薦的是 Gmane,一樣是將 LKML 轉換儲存,Gmane 提供了更多樣的介面,包含了

其中 RSS 訂閱機制,提供了高達四種訂閱方式!你可以

我個人習慣只訂閱郵件標題與內容摘錄,如此就可以只跟著感興趣的題目,而不會分心在其他的議題上。Gmane 除了訂閱方式多元以外,它的瀏覽介面與搜尋也相當神速與方便,特別是所謂的 Loom 瀏覽介面,配合鍵盤指令使用,比在本地端讀取還方便多了!同時也非常方便用來監視其他相關的郵遞論壇

除了追郵遞論壇的討論細節外,你也必須知道大方向的發展狀態。首先要推薦是 LWN,它提供最具深度與時效的報導,且一個月也才五元到十元美金,請以訂閱作為支持這個網站的行動吧。若你是為商業公司服務,請記得告訴你老闆可以使用團體帳號訂閱。若你不想花錢在這上面,上面的新聞只要過了時效就可以免費瀏覽了。

另外 KernelTrap 的熱門話題與新聞也應該要時常閱讀。並也可以透過 Kernel Newbies核心變動懶人包,來了解新版核心的變動資訊。

哈,終於我 Thinkpad X60 上的 Atheros AR5418 802.11abgn Wireless PCI Express Adapter 要有原生 (Native) 驅動程式了。

Linux Wireless Driver 強者 Luis R. Rodriguez (mcgrof) 加入 Atheros Communications Inc. 後,終於釋出了第一版的開放原碼驅動程式。ath9k 預計支援的晶片有

  • AR5418+AR5133
  • AR5416+AR5133
  • AR5416+AR2133
  • AR9160
  • AR9280
  • AR9281

目前只有 STA 功能,但是 AP, WDS, IBSS (for mesh) 都列在 TODO List 中了。最新的程式碼可以於此下載

git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/ath9k.git

當下的版本必須搭配最新的無線網路模組使用,可於此下載

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

或是從 Luis R. Rodriguez 的獨立開發分支中取出無線相關模組與 ath9k driver。

根據 Luis 的說明,ath9k 的程式碼目前已整合於

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

關於相關討論,可參考 ath9k-devel 郵遞論壇。依照目前的進度看起來,大約至少要到 2.6.27/2.6.28 才會整合到官方核心中。BTW, OpenWrt 是第一個整合 ath9k 的套件系統喔。;-)