Log for Ubuntu 台灣社群
「%CPU 利用率」其實是個謊言 （★ 135 分）
在 IT 營運中，常用命令工具如 top 或其他系統監控工具監視網路、記憶體與 CPU (中央處理器) 利用率，以判斷伺服器工作負載是否接近極限。然而實測發現，所謂的「%CPU 利用率」並不是線性指標：當系統回報 50% 利用率時，實際執行工作量往往已達到 60–100% 之間，事實與直覺大相逕庭。
作者在 Ubuntu 系統上使用 Ryzen 9 5900X (12 核心／24 執行緒) 處理器，並啟用 Precision Boost Overdrive (即 Turbo, AMD Turbo Core) 後，以自製腳本結合 stress-ng 進行壓力測試，先讓 24 個執行緒在 1% 至 100% 之間變化，再讓 1 至 24 個執行緒全速運行，並以 Bogo ops (參考 BogoMIPS 基準) 量化每秒執行次數。測試結果顯示，一般 CPU 基準與 64 位元整數運算在回報 50% 利用率時，實際效能已達 65–85%；矩陣運算更在相同回報下跑到 80–100%。主因在於超執行緒技術 (SMT, simultaneous multithreading) 共享實體核心資源，以及 Turbo 加速頻率隨核心數增加而下降等因素，使得「忙碌時脈數／總時脈數」的計算方式導致利用率指標被低估。作者建議以實際應用為基準：先做基準測試找出伺服器最大可接受負載，再以目前流量或請求量做相對比對，取代單純參考 CPU 利用率。
社群討論中，多位專業人士引用廚房與廁紙比喻說明超執行緒技術：就像兩位廚師共用廚房設備、或 2 層紙只能算 1 張紙，額外的執行緒提升了資源使用率卻無法倍增效能；也有人提醒不同處理器廠商 SMT 與 Turbo 設計差異甚大，記憶體頻寬、快取與鎖定機制等共享瓶頸同樣非線性。群組意見並建議與其盯著長秒級平均利用率，不如關注短毫秒量級的 p95 延遲 (95 百分位) 及 p99 延遲 (99 百分位) 表現，以及透過真實負載的基準測試來量化系統擴充／縮減時機。
其他觀點補充，可結合 perf 與 ftrace 等工具檢視快取失準、記憶體存取延遲等精細指標；GPU (圖形處理器，Graphics Processing Unit) 的利用率更容易產生誤導，須比對理論 FLOP/s 峰值；stress-ng 雖能呈現線性崩潰前的行為，但以 Memcached 或 Postgres 等實際服務負載測試，往往更貼近生產力需求並揭露高負載下的銳減效能。整體而言，最佳化策略應以應用實際效能與延遲需求為基準，而非單純仰賴 CPU 利用率。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=45110688
在 IT 營運中，常用命令工具如 top 或其他系統監控工具監視網路、記憶體與 CPU (中央處理器) 利用率，以判斷伺服器工作負載是否接近極限。然而實測發現，所謂的「%CPU 利用率」並不是線性指標：當系統回報 50% 利用率時，實際執行工作量往往已達到 60–100% 之間，事實與直覺大相逕庭。
作者在 Ubuntu 系統上使用 Ryzen 9 5900X (12 核心／24 執行緒) 處理器，並啟用 Precision Boost Overdrive (即 Turbo, AMD Turbo Core) 後，以自製腳本結合 stress-ng 進行壓力測試，先讓 24 個執行緒在 1% 至 100% 之間變化，再讓 1 至 24 個執行緒全速運行，並以 Bogo ops (參考 BogoMIPS 基準) 量化每秒執行次數。測試結果顯示，一般 CPU 基準與 64 位元整數運算在回報 50% 利用率時，實際效能已達 65–85%；矩陣運算更在相同回報下跑到 80–100%。主因在於超執行緒技術 (SMT, simultaneous multithreading) 共享實體核心資源，以及 Turbo 加速頻率隨核心數增加而下降等因素，使得「忙碌時脈數／總時脈數」的計算方式導致利用率指標被低估。作者建議以實際應用為基準：先做基準測試找出伺服器最大可接受負載，再以目前流量或請求量做相對比對，取代單純參考 CPU 利用率。
社群討論中，多位專業人士引用廚房與廁紙比喻說明超執行緒技術：就像兩位廚師共用廚房設備、或 2 層紙只能算 1 張紙，額外的執行緒提升了資源使用率卻無法倍增效能；也有人提醒不同處理器廠商 SMT 與 Turbo 設計差異甚大，記憶體頻寬、快取與鎖定機制等共享瓶頸同樣非線性。群組意見並建議與其盯著長秒級平均利用率，不如關注短毫秒量級的 p95 延遲 (95 百分位) 及 p99 延遲 (99 百分位) 表現，以及透過真實負載的基準測試來量化系統擴充／縮減時機。
其他觀點補充，可結合 perf 與 ftrace 等工具檢視快取失準、記憶體存取延遲等精細指標；GPU (圖形處理器，Graphics Processing Unit) 的利用率更容易產生誤導，須比對理論 FLOP/s 峰值；stress-ng 雖能呈現線性崩潰前的行為，但以 Memcached 或 Postgres 等實際服務負載測試，往往更貼近生產力需求並揭露高負載下的銳減效能。整體而言，最佳化策略應以應用實際效能與延遲需求為基準，而非單純仰賴 CPU 利用率。
👥 63 則討論、評論 💬
https://news.ycombinator.com/item?id=45110688
Kernel-hack-drill 與利用 Linux 核心漏洞 CVE-2024-50264 （★ 105 分）
這篇文章由資安研究員撰寫，深入剖析 Linux 核心漏洞 CVE-2024-50264 的利用方式，並介紹作者開發的實驗專案 `kernel-hack-drill` 在漏洞研究中的應用。該漏洞出現在 `AF_VSOCK` 子系統，問題源自 2016 年引入的一個競態條件，當 `connect()` 系統呼叫被 POSIX 訊號中斷時，導致核心在釋放結構後仍繼續使用，觸發 use-after-free (UAF) 式記憶體破壞。由於攻擊者即便不啟用使用者命名空間也能觸發，因而具高度危險性。這個漏洞被認為是最困難被利用的漏洞之一，並獲得 2025 年 Pwnie Award「最佳權限提升利用」獎。
作者最初於 2021 年研究 `AF_VSOCK` 的漏洞，後來在 2024 年再次進行 fuzz 測試時發現錯誤，但由於難度太高暫時擱置。直到其他研究員先公開 CVE-2024-50264 後，他才決定繼續鑽研，不採用原本極為複雜的 BPF JIT、SLUBStick 和 Dirty Pagetable 組合手法，而是尋找更簡化的 exploit 策略。他透過觀察訊號 33（NPTL 保留的特殊即時訊號）能在不終止程序的情況下中斷 `connect()`，發展出穩定觸發漏洞的辦法，進一步藉由 cross-cache 技術讓已釋放的 `virtio_vsock_sock` 覆蓋到其他物件如 `msg_msg`、`pipe_buffer`，形成資訊洩漏與任意位址讀寫 (AARW) 的原語，最後能修改 `struct cred` 以竄改程序身分，達成 root 權限提升。
值得一提的是，作者利用 `kernel-hack-drill` 這個早年為教學所寫的小專案，大幅簡化 exploit 原型測試。這套工具包含可控的 UAF 弱點模組與範例程式，讓研究員能安全複現、驗證記憶體破壞並實驗跨配置攻擊 (cross-cache attack)。作者指出，雖然最新 Ubuntu Kernel 提供 `CONFIG_RANDOM_KMALLOC_CACHES` 與 `CONFIG_SLAB_BUCKETS` 等強化機制，這雖然擋掉一般 heap spray 攻擊，但反而讓 cross-cache 更穩定；若缺乏進一步防禦如 SLAB_VIRTUAL，Linux 核心仍對此類攻擊敞開大門。
在 Hacker News 的討論中，多數人對作者的技術分析表示敬佩，認為能逐步拆解競態漏洞並設計新手法非常不易。有讀者提到，文章篇幅龐大卻一次完整呈現，通常可拆成多篇系列文；也有人指出作者背景來自受制裁的俄羅斯公司，但多數關注仍放在技術本身。值得注意的討論之一是關於「研究員應否同時修補漏洞」的爭議，有人認為安全研究員通常缺乏動力或獎勵去提交修補程式，因為公開 exploit 可能能換取更高額的漏洞獎金。也有人反駁，若能成功開發 exploit，自然也具備修補漏洞的能力，問題在於整體生態誘因而非技術能力的不足。
另外，有讀者將此與 Linux 對 Rust 的採用遲緩連結，認為核心老化的 C 寫法才讓這類競態與記憶體錯誤層出不窮；也有人自嘲「一旦到了低階層級就感覺自己毫無用武之地」，對 exploit 研究員的技巧深感欽佩。雖然整篇文章閱讀難度極高，但社群普遍認為這是展示頂級低階資安研究成果的代表作，結合理論創新、工具改良與實際 PoC，充分體現了漏洞開發與系統防禦之間的拉鋸戰。
👥 12 則討論、評論 💬
https://news.ycombinator.com/item?id=45112996
這篇文章由資安研究員撰寫，深入剖析 Linux 核心漏洞 CVE-2024-50264 的利用方式，並介紹作者開發的實驗專案 `kernel-hack-drill` 在漏洞研究中的應用。該漏洞出現在 `AF_VSOCK` 子系統，問題源自 2016 年引入的一個競態條件，當 `connect()` 系統呼叫被 POSIX 訊號中斷時，導致核心在釋放結構後仍繼續使用，觸發 use-after-free (UAF) 式記憶體破壞。由於攻擊者即便不啟用使用者命名空間也能觸發，因而具高度危險性。這個漏洞被認為是最困難被利用的漏洞之一，並獲得 2025 年 Pwnie Award「最佳權限提升利用」獎。
作者最初於 2021 年研究 `AF_VSOCK` 的漏洞，後來在 2024 年再次進行 fuzz 測試時發現錯誤，但由於難度太高暫時擱置。直到其他研究員先公開 CVE-2024-50264 後，他才決定繼續鑽研，不採用原本極為複雜的 BPF JIT、SLUBStick 和 Dirty Pagetable 組合手法，而是尋找更簡化的 exploit 策略。他透過觀察訊號 33（NPTL 保留的特殊即時訊號）能在不終止程序的情況下中斷 `connect()`，發展出穩定觸發漏洞的辦法，進一步藉由 cross-cache 技術讓已釋放的 `virtio_vsock_sock` 覆蓋到其他物件如 `msg_msg`、`pipe_buffer`，形成資訊洩漏與任意位址讀寫 (AARW) 的原語，最後能修改 `struct cred` 以竄改程序身分，達成 root 權限提升。
值得一提的是，作者利用 `kernel-hack-drill` 這個早年為教學所寫的小專案，大幅簡化 exploit 原型測試。這套工具包含可控的 UAF 弱點模組與範例程式，讓研究員能安全複現、驗證記憶體破壞並實驗跨配置攻擊 (cross-cache attack)。作者指出，雖然最新 Ubuntu Kernel 提供 `CONFIG_RANDOM_KMALLOC_CACHES` 與 `CONFIG_SLAB_BUCKETS` 等強化機制，這雖然擋掉一般 heap spray 攻擊，但反而讓 cross-cache 更穩定；若缺乏進一步防禦如 SLAB_VIRTUAL，Linux 核心仍對此類攻擊敞開大門。
在 Hacker News 的討論中，多數人對作者的技術分析表示敬佩，認為能逐步拆解競態漏洞並設計新手法非常不易。有讀者提到，文章篇幅龐大卻一次完整呈現，通常可拆成多篇系列文；也有人指出作者背景來自受制裁的俄羅斯公司，但多數關注仍放在技術本身。值得注意的討論之一是關於「研究員應否同時修補漏洞」的爭議，有人認為安全研究員通常缺乏動力或獎勵去提交修補程式，因為公開 exploit 可能能換取更高額的漏洞獎金。也有人反駁，若能成功開發 exploit，自然也具備修補漏洞的能力，問題在於整體生態誘因而非技術能力的不足。
另外，有讀者將此與 Linux 對 Rust 的採用遲緩連結，認為核心老化的 C 寫法才讓這類競態與記憶體錯誤層出不窮；也有人自嘲「一旦到了低階層級就感覺自己毫無用武之地」，對 exploit 研究員的技巧深感欽佩。雖然整篇文章閱讀難度極高，但社群普遍認為這是展示頂級低階資安研究成果的代表作，結合理論創新、工具改良與實際 PoC，充分體現了漏洞開發與系統防禦之間的拉鋸戰。
👥 12 則討論、評論 💬
https://news.ycombinator.com/item?id=45112996