宋寶華：為了不忘卻的紀念，評Linux 5.13內核
[導讀]Linux5.14于14小時之前發(fā)布了，而我5.13的總結還沒有寫出，我早覺得有寫一點東西的必要了，這雖然于搬磚的碼農毫不相干，但在追求進步的工程師那里，卻大抵只能如此而已。為了不忘卻的紀念，我們列出5.13內核的數個激動人心的新特性：AppleM1的初始MisccgroupLa...
Linux 5.14于14小時之前發(fā)布了，而我5.13的總結還沒有寫出，我早覺得有寫一點東西的必要了，這雖然于搬磚的碼農毫不相干，但在追求進步的工程師那里，卻大抵只能如此而已。為了不忘卻的紀念，我們列出5.13內核的數個激動人心的新特性：
Apple M1的初始支持
5.13最爆炸性的新聞無非是初始的Apple M1支持，但是然并卵，實用性幾乎為0。因為，已經合入的patch非常類似于SoC bringup的初級階段：
Misc cgroup眾所周知，cgroup具備一個強大的控制CPU、內存、I/O等資源在不同的任務群間進行分配的能力。比如，你通過下面的命令，限制A這個群的CFS調度類進程，最多只能耗費20%的CPU：這個世界上的絕大多數資源都是可以進行抽象的，比如屬于cpuacct、cpu、memory、blkio、net_cls什么的，但是，總有一些不同于常人的人，他們既不是男人，也不是女人，而是“妖如果有了仁慈的心”的人。Linux內核的驅動子系統多達100多個，但是還是有極個別驅動不屬于這100多類中的任何一類，于是在drivers下面有個misc：現在內核碰到了類似的問題，它的資源要進行配額控制，但是不屬于通用的類型，而是：
?Landlock安全模塊曾經有一個真誠的patch擺在我面前，但是我沒有珍惜，發(fā)了V1被人懟了后就放棄了，等到失去的時候才后悔莫及，塵世間最痛苦的事莫過于此，如果上天可以給我一個機會再來一次的話，我會對那個patch說我要繼續(xù)迭代發(fā)！如果非要在這個迭代的次數上加上一個期限，我希望是一百遍。5.13內核，最勵志的事情無疑是，"Landlock" Lands In Linux 5.13 ！在迭代了超過5年之后，安全組件landlock終于合入了Linux內核，這份始于2016年的愛情，終于有了一個美好的結局。為此，Linux內核doc的維護者，LDD3的作者之一Jonathan Corbet發(fā)文指出：Kernel development is not for people who lack persistence; changes can take a number of revisions and a lot of time to make it into a mainline release。文章鏈接：https://lwn.net/Articles/859908/所以，沒有耐力、不能持之以恒,想一夜暴富的人，真地不適合做kernel開發(fā)。Landlock LSM主要給非特權進程提供安全沙盒的能力，比如你可以對一個普通進程，施加自定義的文件系統訪問控制策略。它的操作原理是，先創(chuàng)建一個規(guī)則集ruleset，比如，如下的ruleset就是涉及到文件的讀、寫、執(zhí)、讀DIR、寫DIR等：ruleset對用戶以文件描述符fd的形式存在，再次證明了“一切都是文件”。接下來，我們可以透過這個fd，向這個ruleset里面添加rule，比如我們添加一個/usr目錄的“讀”規(guī)則，這樣進程就不能寫/usr了：我們把這個ruleset施加起來讓它生效：想要體驗的童鞋可以用這個例子啟動你的進程，它設置好ruleset后，會去call exec啟動命令行參數指定的程序：https://github.com/landlock-lsm/linux/blob/landlock-v34/samples/landlock/sandboxer.cLL_FS_RO環(huán)境變量是可讀文件的列表，LL_FS_RW環(huán)境變量是可讀寫文件的列表，運行方法：
童鞋們看明白了嗎？我用sandboxer去啟動cat，2個文件都是成功的。但是，去啟動echo，/home/baohua/1/1是不允許寫的，但是/home/baohua/2/1是可以寫的。實際上，/home/baohua/1/1和/home/baohua/2/1并沒有絲毫的不同。landlock在發(fā)揮作用了！
系統調用的堆棧隨機化這是一項安全增強，它允許對系統調用發(fā)生時，內核使用的堆棧添加一個隨機偏移。這給基于stack的攻擊增加了難度，因為stack攻擊通常要求stack有個固定的layout。現在每次系統調用，stack的layout都變化的話，黑客就比較捉摸不定了。比如ARM64主要修改了invoke_syscall()這個函數：這個東西聽起來很高大上，但是它的原理可能簡單地你想哭，NO BB! show me the code：它實際上就是每次系統調用把offset隨機化一下，然后通過__builtin_alloca()從stack里面分配一些stack空間，于是導致stack的位置移動。我們可以寫個非常簡單的應用程序來驗證原理：然后編譯
printk無鎖ringbuffer的進一步優(yōu)化鎖什么，不鎖什么，鎖大還是鎖小，從來都是一個問題。宮鎖心玉、宮鎖珠簾、宮鎖沉香、宮鎖連城、宮鎖printk......內核工程師，可能真地被printk寵壞了，printk的優(yōu)勢是在Linux的任意CPU、任意線程、任意中斷（甚至包括NMI）都可以調用，呼之即來揮之即去。你有沒有想過，printk的實現里面可能有很大的鎖代價的？你怎么保證一個人在打印”abc”，另外一個人再打印”def”，它不把2個人的打印串擾呢？如何避免各種死鎖的可能性？很多操作系統為了避免這種代價，干脆禁止了一些上下文對類似print函數的調用，比如VxWorks的中斷服務程序是不能調用printf()的。所以Linux的printk是一個極端復雜的存在。John Ogness
這樣就導致了printk依賴一個臨時的所謂safe buffer。這種safe buffer的理念，也被用來避免printk自己遞歸（printk的實現調用printk）引起的死鎖。在遞歸的printk里面，內容也如NMI那樣寫入safe buffer，之后在安全的上下文才把這個buffer的內容flush出去。這種思路，其實也是數據結構分化以避免全局鎖的思路，比如太平天國洪秀全暫時沒有辦法奪取北京城，就先在南京城占山為王，然后伺機再取北京。北京城1個數據結構，南京城是另1個。printk的logbuf有各種NMI、遞歸的坑的，前面基本就是在想辦法繞坑。繞坑的話，進取心實在有限，比如天王后面放棄了007，選擇了躺平，天國最后完蛋了。但是內核的進取心很大，在5.10中，內核提交了一個lockless的ringbuffer，可安全地用于一切上下文，避免了死鎖，也為避免NMI等場景對臨時的per-CPU?safe buffer依賴的去除提供了可能性，應該是更加接近printk需求的本質。注意，5.10內核printk的這個lockless ringbuffer支持多個讀者、多個寫者安全的，它本身的實現比較復雜，更多涉及數據結構的知識，具體的細節(jié)可以參考這個commit（大約2000行代碼）：但是5.10仍然有少量代碼路徑依賴?logbuf_lock，比如kmsg_dump、syslog?、格式化消息用的臨時buffer等（畢竟5.10之前的代碼用logbuf_lock用地比較奔放）。5.13中，內核進一步移除了?logbuf_lock，從而基本接近了lockless的printk。移除的方法是要么直接刪沒必要的?logbuf_lock調用，要么用一個特定的更小鎖來替換。比如，之前syslog里面的 syslog_seq, syslog_partial, syslog_time ，clear_seq 是靠?logbuf_lock保護的，現在重新引入一個它自己的鎖syslog_lock：這種思路其實就是分而治之，逐步細化瓦解。就像以前內核有個BKL，后面它的使用場景，被一個個更小的鎖細化代替，直至最后BKL被徹底消滅一樣。
BPF可調用內核函數技術上來講BPF程序載入內核的時候，內核會執(zhí)行嚴格的檢查，內核和BPF程序能實際互動的范圍非常有限，主要是內核調用BPF而不是反過來。Linux 5.13內核則允許特定program type的BPF程序直接調用特定的內核函數，為確保調用的安全，目前內核僅僅授權了?tcp_slow_start()?、tcp_cong_avoid_ai()等這種TCP擁塞控制相關的函數（tcp-cc helper）供BPF擁塞控制程序直接調用，這樣BPF擁塞控制程序不需要把這些函數再copy-paste一遍。內核net/ipv4/bpf_tcp_ca.c的代碼顯示了這個verify的過程，需要在相應的bpf_verifier_ops中添加check_kfunc_call()成員函數：check_kfunc_call()的成立條件就是特定函數必須是在bpf_tcp_ca_kfunc_ids集合里面的白名單函數，比如：這個時候，哥在想，如果我把kprobe這種program type的BPF的check_kfunc_call()永遠返回真，我不是可以在kprobe的BPF中為所欲為？比如我可以嘗試在任何kprobe點對應的BPF程序上，調用barrysong_hack_print()這個函數？目前還沒有嘗試，想做實驗的童鞋，可以仿照這個commit中的例子完成，這是一個測試案例：
公共的IO PAGE Fault支持這個特性主要用于用戶空間的DMA，特別適用于SVA的場景，Shared Virtual Addressing (SVA)。在SVA模式下，設備的IOMMU采用和CPU的MMU共享的頁表，從而讓進程地址空間對設備可見。圖片來源:https://events19.linuxfoundation.cn/wp-content/uploads/2017/11/Shared-Virtual-Addressing_Yisheng-Xie-_-Bob-Liu.pdf5.13內核中，ARM?SMMU和UACCE?(Unified/User-space-access-intended Accelerator Framework)?合入了共享SVA的支持，并將相關IO Page Fault（IOPF）的代碼提煉成了通用的drivers/iommu/io-pgfault.c代碼。我們都知道，Linux的內存管理重度近乎強迫癥式地依賴CPU的page fault，比如demanding page, swap，CoW等，內存都是在page fault發(fā)生后申請內卷進來的。現在，設備也共享了進程的內存，這樣設備訪問這些頁面的時候，仍然可能產生類似CPU的page fault幫忙把進程缺少的頁面申請出來。不過設備是先發(fā)一個中斷，然后內核在中斷服務程序里面調用handle_mm_fault()來處理缺頁，這樣設備產生的IOPF同樣可以幫忙demanding page（比如設備DMA寫malloc()后還沒獲得的內存）。似乎設備變地非常類似進程里面的一個線程，不過我們仔細一想，這里仍然有一個邏輯講不通，如果我們把線程和Device并列：當線程寫空指針，CPU會收到同步的Page Fault（在*p=10的指令卡住，并最終給進程產生segment fault）；但是進程啟動設備在用戶態(tài)去做DMA，設備寫無效的地址，顯然也會收到IOPF，但是我們卻沒辦法定位到對應的代碼行。在加上中斷啥時候進ISR的問題，這種IOPF行為總體對進程而言異步的。比如：
另外這個時候，內核應該給進程發(fā)什么信號也是個問題？CPU碰到這種情況，顯然就是發(fā)SIGSEGV；設備這里，IOPF的中斷服務程序，目前似乎是沒有發(fā)，理想情況下，是不是至少也應該發(fā)一個類似SIGBUS或者什么信號，不過無論如何，進程也無法同步檢測到哪里的代碼出了問題，更加不要說支持ASAN（Address Sanitizer）這種內存越界檢查技術了。我們期待后續(xù)內存繼續(xù)對這個問題給出一個明確的說法，也期待更多的童鞋發(fā)patch來讓內核能自圓其說。時光永是流逝,街市依舊太平。內核的每個新版本發(fā)布，之于搬磚的碼農，已泛不起任何的漣漪。但是，鐘愛內核的人們，仍然在孜孜不倦地追隨。
- Apple M1的初始
- Misc cgroup
- Landlock安全模塊
- 系統調用的堆棧隨機化
- printk無鎖ringbuffer的進一步優(yōu)化
- BPF可調用內核函數
- 公共的IO PAGE Fault支持
Apple M1的初始支持
5.13最爆炸性的新聞無非是初始的Apple M1支持，但是然并卵，實用性幾乎為0。因為，已經合入的patch非常類似于SoC bringup的初級階段：
- 帶earlycon支持的UART (samsung-style) 串口驅動
- Apple中斷控制器，支持中斷、中斷親和(affinity )和IPI (跨CPU中斷)
- SMP (通過標準spin-table來支持）
- 基于simplefb的framebuffer驅動
- Mac Mini的設備樹
Misc cgroup眾所周知，cgroup具備一個強大的控制CPU、內存、I/O等資源在不同的任務群間進行分配的能力。比如，你通過下面的命令，限制A這個群的CFS調度類進程，最多只能耗費20%的CPU：這個世界上的絕大多數資源都是可以進行抽象的，比如屬于cpuacct、cpu、memory、blkio、net_cls什么的，但是，總有一些不同于常人的人，他們既不是男人，也不是女人，而是“妖如果有了仁慈的心”的人。Linux內核的驅動子系統多達100多個，但是還是有極個別驅動不屬于這100多類中的任何一類，于是在drivers下面有個misc：現在內核碰到了類似的問題，它的資源要進行配額控制，但是不屬于通用的類型，而是：
- Secure?Encrypted Virtualization (SEV) ASIDs
- SEV - Encrypted State (SEV-ES)?ASIDs
- misc.capacity描述資源的能力（只讀），比如：
$ cat misc.capacityres_a 50res_b 10- 透過misc.current描述當前資源的占用（只讀），比如：
$ cat misc.currentres_a 3res_b 0- 透過misc.max設置這個cgroup最多只能使用多少資源（可讀可寫），比如：
# echo res_a 1 > misc.max同志們，有了這個misc cgroup的支持，以后咱們的阿貓阿狗資源限制，也可以往里面塞了。它相當于開了一道門。?Landlock安全模塊曾經有一個真誠的patch擺在我面前，但是我沒有珍惜，發(fā)了V1被人懟了后就放棄了，等到失去的時候才后悔莫及，塵世間最痛苦的事莫過于此，如果上天可以給我一個機會再來一次的話，我會對那個patch說我要繼續(xù)迭代發(fā)！如果非要在這個迭代的次數上加上一個期限，我希望是一百遍。5.13內核，最勵志的事情無疑是，"Landlock" Lands In Linux 5.13 ！在迭代了超過5年之后，安全組件landlock終于合入了Linux內核，這份始于2016年的愛情，終于有了一個美好的結局。為此，Linux內核doc的維護者，LDD3的作者之一Jonathan Corbet發(fā)文指出：Kernel development is not for people who lack persistence; changes can take a number of revisions and a lot of time to make it into a mainline release。文章鏈接：https://lwn.net/Articles/859908/所以，沒有耐力、不能持之以恒,想一夜暴富的人，真地不適合做kernel開發(fā)。Landlock LSM主要給非特權進程提供安全沙盒的能力，比如你可以對一個普通進程，施加自定義的文件系統訪問控制策略。它的操作原理是，先創(chuàng)建一個規(guī)則集ruleset，比如，如下的ruleset就是涉及到文件的讀、寫、執(zhí)、讀DIR、寫DIR等：ruleset對用戶以文件描述符fd的形式存在，再次證明了“一切都是文件”。接下來，我們可以透過這個fd，向這個ruleset里面添加rule，比如我們添加一個/usr目錄的“讀”規(guī)則，這樣進程就不能寫/usr了：我們把這個ruleset施加起來讓它生效：想要體驗的童鞋可以用這個例子啟動你的進程，它設置好ruleset后，會去call exec啟動命令行參數指定的程序：https://github.com/landlock-lsm/linux/blob/landlock-v34/samples/landlock/sandboxer.cLL_FS_RO環(huán)境變量是可讀文件的列表，LL_FS_RW環(huán)境變量是可讀寫文件的列表，運行方法：
LL_FS_RO=”只讀路徑”?\LL_FS_RW=”可寫路徑”?\sandboxer??./a.outa.out是你的想要安全沙盒的程序。在下已經一睹為快，在/home/baohua下面創(chuàng)建2個目錄1,2，然后創(chuàng)建/home/baohua/1/1和/home/baohua/2/1這2個文件，限制第一個目錄只讀：童鞋們看明白了嗎？我用sandboxer去啟動cat，2個文件都是成功的。但是，去啟動echo，/home/baohua/1/1是不允許寫的，但是/home/baohua/2/1是可以寫的。實際上，/home/baohua/1/1和/home/baohua/2/1并沒有絲毫的不同。landlock在發(fā)揮作用了！
系統調用的堆棧隨機化這是一項安全增強，它允許對系統調用發(fā)生時，內核使用的堆棧添加一個隨機偏移。這給基于stack的攻擊增加了難度，因為stack攻擊通常要求stack有個固定的layout。現在每次系統調用，stack的layout都變化的話，黑客就比較捉摸不定了。比如ARM64主要修改了invoke_syscall()這個函數：這個東西聽起來很高大上，但是它的原理可能簡單地你想哭，NO BB! show me the code：它實際上就是每次系統調用把offset隨機化一下，然后通過__builtin_alloca()從stack里面分配一些stack空間，于是導致stack的位置移動。我們可以寫個非常簡單的應用程序來驗證原理：然后編譯
gcc 1.c -fno-stack-protector -O0運行：親愛的，你有沒有發(fā)現，10次函數調用的時候，每次stack臨時變量的位置都不一樣?。。?/span>printk無鎖ringbuffer的進一步優(yōu)化鎖什么，不鎖什么，鎖大還是鎖小，從來都是一個問題。宮鎖心玉、宮鎖珠簾、宮鎖沉香、宮鎖連城、宮鎖printk......內核工程師，可能真地被printk寵壞了，printk的優(yōu)勢是在Linux的任意CPU、任意線程、任意中斷（甚至包括NMI）都可以調用，呼之即來揮之即去。你有沒有想過，printk的實現里面可能有很大的鎖代價的？你怎么保證一個人在打印”abc”，另外一個人再打印”def”，它不把2個人的打印串擾呢？如何避免各種死鎖的可能性？很多操作系統為了避免這種代價，干脆禁止了一些上下文對類似print函數的調用，比如VxWorks的中斷服務程序是不能調用printf()的。所以Linux的printk是一個極端復雜的存在。John Ogness
- console_lock?semaphore：用于在console打印
- logbuf_lock spinlock：用于寫環(huán)形緩沖區(qū)logbuf
這樣就導致了printk依賴一個臨時的所謂safe buffer。這種safe buffer的理念，也被用來避免printk自己遞歸（printk的實現調用printk）引起的死鎖。在遞歸的printk里面，內容也如NMI那樣寫入safe buffer，之后在安全的上下文才把這個buffer的內容flush出去。這種思路，其實也是數據結構分化以避免全局鎖的思路，比如太平天國洪秀全暫時沒有辦法奪取北京城，就先在南京城占山為王，然后伺機再取北京。北京城1個數據結構，南京城是另1個。printk的logbuf有各種NMI、遞歸的坑的，前面基本就是在想辦法繞坑。繞坑的話，進取心實在有限，比如天王后面放棄了007，選擇了躺平，天國最后完蛋了。但是內核的進取心很大，在5.10中，內核提交了一個lockless的ringbuffer，可安全地用于一切上下文，避免了死鎖，也為避免NMI等場景對臨時的per-CPU?safe buffer依賴的去除提供了可能性，應該是更加接近printk需求的本質。注意，5.10內核printk的這個lockless ringbuffer支持多個讀者、多個寫者安全的，它本身的實現比較復雜，更多涉及數據結構的知識，具體的細節(jié)可以參考這個commit（大約2000行代碼）：但是5.10仍然有少量代碼路徑依賴?logbuf_lock，比如kmsg_dump、syslog?、格式化消息用的臨時buffer等（畢竟5.10之前的代碼用logbuf_lock用地比較奔放）。5.13中，內核進一步移除了?logbuf_lock，從而基本接近了lockless的printk。移除的方法是要么直接刪沒必要的?logbuf_lock調用，要么用一個特定的更小鎖來替換。比如，之前syslog里面的 syslog_seq, syslog_partial, syslog_time ，clear_seq 是靠?logbuf_lock保護的，現在重新引入一個它自己的鎖syslog_lock：這種思路其實就是分而治之，逐步細化瓦解。就像以前內核有個BKL，后面它的使用場景，被一個個更小的鎖細化代替，直至最后BKL被徹底消滅一樣。
BPF可調用內核函數技術上來講BPF程序載入內核的時候，內核會執(zhí)行嚴格的檢查，內核和BPF程序能實際互動的范圍非常有限，主要是內核調用BPF而不是反過來。Linux 5.13內核則允許特定program type的BPF程序直接調用特定的內核函數，為確保調用的安全，目前內核僅僅授權了?tcp_slow_start()?、tcp_cong_avoid_ai()等這種TCP擁塞控制相關的函數（tcp-cc helper）供BPF擁塞控制程序直接調用，這樣BPF擁塞控制程序不需要把這些函數再copy-paste一遍。內核net/ipv4/bpf_tcp_ca.c的代碼顯示了這個verify的過程，需要在相應的bpf_verifier_ops中添加check_kfunc_call()成員函數：check_kfunc_call()的成立條件就是特定函數必須是在bpf_tcp_ca_kfunc_ids集合里面的白名單函數，比如：這個時候，哥在想，如果我把kprobe這種program type的BPF的check_kfunc_call()永遠返回真，我不是可以在kprobe的BPF中為所欲為？比如我可以嘗試在任何kprobe點對應的BPF程序上，調用barrysong_hack_print()這個函數？目前還沒有嘗試，想做實驗的童鞋，可以仿照這個commit中的例子完成，這是一個測試案例：
公共的IO PAGE Fault支持這個特性主要用于用戶空間的DMA，特別適用于SVA的場景，Shared Virtual Addressing (SVA)。在SVA模式下，設備的IOMMU采用和CPU的MMU共享的頁表，從而讓進程地址空間對設備可見。圖片來源:https://events19.linuxfoundation.cn/wp-content/uploads/2017/11/Shared-Virtual-Addressing_Yisheng-Xie-_-Bob-Liu.pdf5.13內核中，ARM?SMMU和UACCE?(Unified/User-space-access-intended Accelerator Framework)?合入了共享SVA的支持，并將相關IO Page Fault（IOPF）的代碼提煉成了通用的drivers/iommu/io-pgfault.c代碼。我們都知道，Linux的內存管理重度近乎強迫癥式地依賴CPU的page fault，比如demanding page, swap，CoW等，內存都是在page fault發(fā)生后申請內卷進來的。現在，設備也共享了進程的內存，這樣設備訪問這些頁面的時候，仍然可能產生類似CPU的page fault幫忙把進程缺少的頁面申請出來。不過設備是先發(fā)一個中斷，然后內核在中斷服務程序里面調用handle_mm_fault()來處理缺頁，這樣設備產生的IOPF同樣可以幫忙demanding page（比如設備DMA寫malloc()后還沒獲得的內存）。似乎設備變地非常類似進程里面的一個線程，不過我們仔細一想，這里仍然有一個邏輯講不通，如果我們把線程和Device并列：當線程寫空指針，CPU會收到同步的Page Fault（在*p=10的指令卡住，并最終給進程產生segment fault）；但是進程啟動設備在用戶態(tài)去做DMA，設備寫無效的地址，顯然也會收到IOPF，但是我們卻沒辦法定位到對應的代碼行。在加上中斷啥時候進ISR的問題，這種IOPF行為總體對進程而言異步的。比如：
p = malloc(1M);device_write(p, 2M);其實寫前1MB都沒有問題，但是到1MB后，其實就是非法地址了，設備啥時候寫完1MB，這個完全是異步的。另外這個時候，內核應該給進程發(fā)什么信號也是個問題？CPU碰到這種情況，顯然就是發(fā)SIGSEGV；設備這里，IOPF的中斷服務程序，目前似乎是沒有發(fā)，理想情況下，是不是至少也應該發(fā)一個類似SIGBUS或者什么信號，不過無論如何，進程也無法同步檢測到哪里的代碼出了問題，更加不要說支持ASAN（Address Sanitizer）這種內存越界檢查技術了。我們期待后續(xù)內存繼續(xù)對這個問題給出一個明確的說法，也期待更多的童鞋發(fā)patch來讓內核能自圓其說。時光永是流逝,街市依舊太平。內核的每個新版本發(fā)布，之于搬磚的碼農，已泛不起任何的漣漪。但是，鐘愛內核的人們，仍然在孜孜不倦地追隨。
下載文檔
