簡介

• 資訊工程學系 115 級
• Github: leowu0411
• HackMd: leowu0411

2025 Linux 核心設計/實作 春季班 自我評量

成果發表和貢獻

5 分。

針對以下教材格式以及拼字做出校正，在對如下進行修改前，對貢獻的看法總有些畏手畏腳，認為依照目前的實力還沒到做出貢獻的時候，但引用授課教師於自我評量的回顧，即使改正錯字也算得上貢獻，故嘗試對以下幾篇期末專題反覆閱讀之教材進行修正 – 不論處在什麼時期，都應該找出自己能夠貢獻的方式

• KVM: Linux 虛擬化基礎建設
  • virtual machine(VM) -> virtual machine (VM)
  • Qemu -> QEMU
  • 將以 「，」結尾的句子結尾更正為以 「。」結尾
  • 新增 「()」與文字間的空白
  • Stack Segment (SS). Pointer to the stack. -> Stack Segment (SS): Pointer to the stack.
  • paramters -> parameters
• 建構 User-Mode Linux 的實驗環境
  • 將以 「，」結尾的句子結尾更正為以 「。」結尾
• Linux 核心設計: 不僅是個執行單元的 Process
  • be waked up -> be woken up

作業/隨堂測驗

8 分。

• Homework (lab0)
  • 撰寫 Linux 核心風格的鏈結串列
    • 學會使用 container_of 巨集
    • 透過於結構體嵌入鏈結串列前後指標 list_head 管理資源
  • 統計學之重要性
    • 實作 Fisher–Yates shuffle 演算法，對佇列進行隨機排序，並利用 Pearson’s chi-squared test 驗證亂度是否足夠
    • 研讀〈Dude, is my code constant time?〉 利用 Welch’s t-test 驗證實作是否為常數時間，避免側通道攻擊
  • tiny-web-server : 理解如何利用 select() 系統呼叫達到 I/O 多工 (同時處理 socket 以及 stdin)
  • 透過信號處理認識 setjump/lomgjump 對於後續理解 corotine 奠定基礎。
  • 撰寫統一規範，以及基於 what, why, how 撰寫的 git commit message，實際應用於大三專題協作以及本身在進行的電子靶場專案，提供清楚的專案開發軌跡方可使成果能夠分享與交接。
• Homework (kxo)
  • 閱讀 LKMPG 學習如何撰寫核心模組，透過核心模組如何註冊回呼函式深刻理解到 everything is a file 帶來的益處
  • 核心模組如何與使用者空間溝通傳遞資料
• Homework (assessment)
  • 閱讀 cs:app 第二章重新認識資料的表示以及處理，理解有號數無號數的運算行為。
  • 認識 corotine，單一執行緒多工，在此之前的認知，伺服器就是一個請求一個執行緒; 透過實際觀察 caldera 這個開放的自動化攻擊平台，其做法也是利用 corotine 單一執行緒，同時處理使用者請求、與後門程式溝通、發送資料等工作 (python eventloop)。
• Homework (khttpd)
  • 閱讀 cs:app 第 11 章與 kecho 的實作方式，認識 socket programming，理解 bind(), accept(), ntohs()、htonl() 等函式以及其背後設計考量
  • 透過 user-echo-server 認識 Reactor Pattern，利用 epoll 以及 non-blocking 的方式於單一執行緒運行伺服器
  • 實際利用 CMWQ，替換伺服器 khttpd 原本使用 Kthread 服務連線的方式，藉由降低建立執行緒的成本帶來約 2.25 倍的吞吐量。

期末專題

9分。

Linux 核心專題: 輕量級隔離運行環境

• 整理與介紹 MicroVM, Unikernel, container
  • 介紹三種隔離方式對於宿主環境的安全性與設計考量
  • 理解為何對於容器此種隔離方式，我們難以限縮其攻擊面，而透過 vmm 就能做到
• Nabla container：透過此專案理解限縮攻擊面的具體方式：限縮 VMM 以限縮 hypercall，精簡作業系統使客體行程只擁有最低限度的能力
• Nabla linux：整理 um-nommu 時為了理解 ptrace 為何帶來效能衝擊而重新閱讀 uml 的實作方式，進一步重新審視自己對於作業系統的認知
  • 如何進行系統呼叫、信號處理：
    • 當執行到系統呼叫指令，作業系統如何切換至核心模式，保存暫存器，呼叫系統呼叫
    • Linux/UNIX 信號處理機制，當行程收到信號，核心如何保存當前狀態並跳躍至使用者註冊的信號處理函式，任務完成後如何回到程式原本的執行位置
  • 虛擬記憶體
    • 閱讀 cs:app 第九章
    • MMU 如何保護行程間與核心的記憶體不會被非法存取，uml 是透過何種手法允許客體核心操作其他定址空間，如何維護自己的分頁表，如何區別客體核心與客體使用者
    • mmap() 的使用以及 uml 如何利用其作為虛擬「實體記憶體」
    • 當客體發生非法記憶體存取，page fault 的處理程序，uml 如何導入自己的 page fault handler
  • 為了不使用 ptrace 移除 MMU 的考量以及影響
• zpoline
  • 理解系統呼叫攔截的考量與不同做法的效能瓶頸
  • 閱讀 cs:app 第七章
    • 程式如何被載入定址空間，如何重定位符號引用，loader 的工作內容
    • 多個目標檔（object file）如何被鏈結成可執行檔，linker 的工作內容
    • 如何在程式執行時、運行時載入動態函式庫
    • 瞭解符號（symbol）的角色，static 的作用，以及全域變數與函式符號為何會影響鏈結

與授課教師的互動

5分。

• 2025-05-13 問答簡記：當時在課堂上討論到 fork() 之後，如何安全地處理 socket 以及其他來自親代行程的檔案描述子。授課教師提到可以利用 dup() 系統呼叫來達成。由於當時認為這個系統呼叫無法避免父子行程同時操作同一個描述子的問題，因此在課間與教授討論，並將相關內容整理於此。
• 2025-05-27 問答簡記：探討 Nabla contianer 的實作考量，以及 KVM 搭配 VirtIO 時的執行時期成本以及資料複製次數
• 一對一討論：5/15

所見所聞所感

10分。

• 因為自動飲料機而延畢的那一年 – 閱讀心得

誠實面對自己究竟有多難? 至少在選修這堂課之前，我是一點也沒做到。在學校的考試或課程中，多數情況下只要考前幾天背一下、刷個考古題，就能取得高分。或多或少，之前的自己也隱約察覺過：難道這樣的積累就足以在實際世界中做出貢獻嗎？但每當真正面對堆積如山的難題，總是能很有效率地再次把眼睛矇住、選擇視而不見。

這學期在實作與閱讀教材的過程中，這些過去的逃避被毫不留情地攤開。對於才剛選修過作業系統的我，竟無法解釋「程式如何被鏈結而後載入到定址空間」，也無法清楚說明「中斷發生時 CPU 與作業系統的行為」。不只是這門課，其餘的學科也有相同的問題。課程剛開始，由於急著產出進度，對於教材的閱讀非常躁進，總想直接開始開發，不懂就直接丟給 Chatgpt，試圖以此來逃避面對堆積如山的「不知道」，但在觀摩其他同學 lab0 的作業產出後感受到極大的落差，發現依照之前的方式，頂多只能機械地完成作業要求，卻無法分析問題、提出改進。「身為一個工程師能做到的事，只有做出為世界所應用的貢獻。」在如今軟體工程如此龐大且複雜的情況下，若持續逃避自己的不足，只會讓自己離真正的貢獻越來越遠。

• 因此，我開始嘗試靜下心來閱讀教材和《CS:APP》（希望大一就能知道這本書）後再開始理解作業描述與執行專題，發現在這樣的情況下，開始能夠理解這些問題如何於現行的機制中出現，開發者的癥結點為何，以及其進行改善時的考量。
• 另外針對不懂的問題，也改變習慣，首先參閱第一手官方資料，而非 Google 搜尋或者詢問大語言模型。開始這麼做後才發現這些文件往往提供了清晰而完整的說明，包含設計時的考量、甚至建議的使用場景。以系統呼叫為例，過去的我通常只是照著找到的 API 範例直接呼叫，但在開始查閱 man page 後才發現，它實際上對各個系統呼叫的參數用途都有深入淺出的解釋，還會提醒在什麼情境下應該使用或避免使用，甚至不用網路就能夠利用 man 2 參閱。

此外從第一堂課開始，不論是資訊詞彙的使用還是 commit message 的撰寫，授課教師都嚴格要求規範。當我在閱讀期末專題的材料與相關專案時，才真正體會到落實這些細節的重要性。對工程學來說，最珍貴的價值就在於成果能被全世界共享，得益於此，科技才能以指數型的速度成長。期末專題所參考的專案與技術文章，皆具備完善且清晰的紀錄，也因此各地的開發者能夠透過這些紀錄發出問題、提出 PR，甚至進一步基於別人的成果衍生出更完整、更優秀的應用。注重這些細節同樣是做出貢獻時不可或缺的一步。

另一項深刻的體會是，實驗對工程師的重要性，其在撰寫作業和閱讀教材的過程中不斷被驗證。透過實驗，工程師能夠客觀地描述問題與成因，而不只是依賴模糊的直覺判斷；以 khttpd 的為例，重點並不只是停在「cmwq 因為省去建立執行緒的成本，所以在高吞吐情況下優於 kthread」這種直覺結論，而是實際使用 ftrace 進行追蹤分析，才能釐清真正的性能成本所在。在期末專題中，透過觀察作者如何設計實驗並親自動手操作的過程，也幫助我理解專案的瓶頸究竟在哪裡。僅憑直覺開發就像是瞎子摸象，既無法準確定位問題，更無法進一步提出改進方案。

在這 20 週的課程中，深刻體會到，一知半解或急於求成只會讓自己想要逃避那些真正困難、最需要理解的部分。現實世界的問題之所以尚未被解決，往往正是因為它們本身就艱難而複雜。唯有注重細節、步步為營，持續補足自己的不足，才能真正做出有價值的貢獻。

自我評量 (1 ~ 10)：

$GEOMEAN = ( 5 )^{1/5} = 7.0966682076 $

方案 B ：\(1 + floor(GEOMEAN) = 1 + 7 = 8\)