內(nèi)核相關(guān)問(wèn)題：kill init和內(nèi)核結(jié)構(gòu)的釋放

如果在命令行執(zhí)行kill -9 1，那么結(jié)果是沒(méi)有反應(yīng)，連個(gè)提示都沒(méi)有，實(shí)際上init進(jìn)程是殺不死的，到底為何呢？kill指令實(shí)際上是發(fā)信號(hào)，如果一個(gè)進(jìn)程對(duì)一個(gè)信號(hào)沒(méi)有反應(yīng)那么 原因可能有以下三點(diǎn)：1.該進(jìn)程屏蔽了此信號(hào)；2.該進(jìn)程是內(nèi)核線程，手動(dòng)屏蔽了此信號(hào)；3.內(nèi)核忽略了此信號(hào).我們看看init進(jìn)程，它不是內(nèi)核線程 （實(shí)際上在rest_init之初的init是內(nèi)核線程，只是它馬上exec到用戶空間了），而且SIGKILL（9）是用戶線程所不能忽略和屏蔽的，因 此只有第三種可能，內(nèi)核忽略了此信號(hào)，找找代碼，看看下面的函數(shù)就得到了確切的答案。
因此我們知道內(nèi)核只是通過(guò)進(jìn)程的pid來(lái)識(shí)別init進(jìn)程的，如果我們找到init，然后修改它的pid，使之不再為1，是否就可以殺死init進(jìn)程了呢？理論是這樣，難道真的是這么簡(jiǎn)單嗎？于是我寫(xiě)下以下的模塊：
結(jié)果如何呢？當(dāng)然是系統(tǒng)崩潰，linux臨死前coredump，調(diào)用堆棧中有choose_new_parent函數(shù)，找到choose_new_parent函數(shù)看了一下：
那里為何出錯(cuò)呢？實(shí)際上SIGKILL信號(hào)真的發(fā)給了init，然后init就do_exit了，當(dāng)中調(diào)用了以下函數(shù)：參數(shù)的father就是init本身，該函數(shù)過(guò)繼了init的孩子們給一個(gè)新的父親。
因此init進(jìn)程不可殺并不是用戶空間的策 略，而是內(nèi)核的機(jī)制，是操作系統(tǒng)的一部分，操作系統(tǒng)用這個(gè)機(jī)制實(shí)現(xiàn)了很多事情，比如僵尸進(jìn)程管理回收問(wèn)題，多用戶安全問(wèn)題等等，不要指望殺死init了， 即使通過(guò)rootkit做到了，試問(wèn)有意義嗎？就是個(gè)兒戲罷了，沒(méi)有實(shí)用性的。
?? 下面談?wù)剝?nèi)核野指針問(wèn)題，這其實(shí)是一個(gè)爭(zhēng)論的話題，爭(zhēng)論主題就是要將不用的指針清零還是采用懶惰策略，待下次使用的時(shí)候再清零。前者更安全，后者更高效， 兩全不得其美，必選其一。如果說(shuō)發(fā)生了內(nèi)核錯(cuò)誤，我的期望是馬上出錯(cuò)馬上崩潰，不然等到以后出錯(cuò)的時(shí)間就是不確定的了，那會(huì)很不安全，同樣給調(diào)試帶來(lái)困 難，安全性永遠(yuǎn)比性能重要。
?? 我采用了一個(gè)很極端的例子，在一個(gè)進(jìn)程執(zhí)行的時(shí)候釋放掉其task_struct，為了使事情簡(jiǎn)單，我的進(jìn)程如下：
編譯后運(yùn)行，ps后它的pid是2732，然后寫(xiě)如下模塊：

加 載模塊后，只要不要?jiǎng)渔I盤(pán)，一點(diǎn)問(wèn)題沒(méi)有，程序依舊完好地運(yùn)行，內(nèi)核沒(méi)有崩潰，但是一旦敲入ps，內(nèi)核立馬崩潰，讓我們來(lái)看看這是為什么。簡(jiǎn)單起見(jiàn)，我用 2.6.9內(nèi)核分析。free_task實(shí)際調(diào)用kmem_cache_free(task_struct_cachep, (task))，而后者就是：
僅此而已，操作task_struct的字段了嗎？沒(méi)有，實(shí)際上 task_struct還是那個(gè)task_struct，一點(diǎn)沒(méi)變，內(nèi)核要想取該task_struct的某個(gè)字段，照取不誤，還是原來(lái)的地址（內(nèi)核的前 896m與物理內(nèi)存一一對(duì)應(yīng)），只是操作了slab的指針。因此進(jìn)程依舊完好運(yùn)行，那為何一旦ps就崩潰了呢？或者ls也崩潰。我們知道，你執(zhí)行ps或 ls以及任何一個(gè)命令的時(shí)候，shell都要fork出一個(gè)新進(jìn)程，而fork要分配一個(gè)task_struct，該task_struct當(dāng)然在 slab分配，我們看看分配代碼：
看看這個(gè)--ac->avail，再對(duì) 比一下前面釋放時(shí)的ac->avail++，這里最新分配的task_struct就是最新被釋放的task_struct，而這個(gè) task_struct就是那個(gè)我的模塊中被變態(tài)釋放的task_struct了，于是新進(jìn)程一產(chǎn)生，原來(lái)的被釋放的進(jìn)程的task_struct的所有 字段幾乎都要被重置，如果我敲入了ps，那么那個(gè)while循環(huán)進(jìn)程的task_struct將和ps的task_struct一樣，因此亂套崩潰在情理 之中，為何亂套？最簡(jiǎn)單的例子，內(nèi)核要調(diào)度while，切出while循環(huán)，但是他們的task_struct一樣，如果你是內(nèi)核你該咋辦，絕對(duì)崩潰，要 你放下一個(gè)桔子拿起另一個(gè)桔子，而這兩個(gè)桔子是一個(gè)桔子，你難道不崩潰嗎？呵呵。
?? 因此，我認(rèn)為因該在slab對(duì)象初始化時(shí)只初始化公共部分，只要釋放一個(gè)slab對(duì)象到slab中，那么就把非公共部分清零，這樣才安全，把一切清零，不 要什么工公共部分更安全，當(dāng)然這樣slab的ctor構(gòu)造函數(shù)也就沒(méi)有必要了，不過(guò)這樣的效率會(huì)小低一些，僅僅小低一些。還是為了簡(jiǎn)單，我寫(xiě)下如下模塊， 釋放后隨即將整個(gè)結(jié)構(gòu)清零，不保留任何公共部分：

還 是以上面的while循環(huán)作試驗(yàn)，加載模塊后，內(nèi)核立即崩潰，達(dá)到了目的。但是內(nèi)核是怎么崩潰的呢？很簡(jiǎn)單，典型的有兩個(gè)時(shí)機(jī)，一個(gè)是時(shí)鐘中斷，一個(gè)是調(diào) 度，當(dāng)然還有別的很多，只是這兩個(gè)更具有典型性，在這兩個(gè)時(shí)機(jī)場(chǎng)景的處理時(shí)候會(huì)用到current，而它就是被釋放那的task_struct，字段全是 0，這樣很容易就崩潰了，可能訪問(wèn)了0指針也就是空指針，也可能是別的。在應(yīng)用程序設(shè)計(jì)時(shí)，我們大談特談野指針的危害，內(nèi)核中也要關(guān)注它，不過(guò)不必像用戶 空間那么過(guò)分關(guān)注它，畢竟內(nèi)核中做的事情應(yīng)該形成一種約定，這樣就不用浪費(fèi)資源去驗(yàn)證這驗(yàn)證那了，內(nèi)核做的事情要少而有效，最重要的是保證安全。
task_struct來(lái)自slab，而slab有ctor構(gòu)造函數(shù)和dtor析構(gòu)函數(shù)，dtor我們想想實(shí)際上是沒(méi)有什么用的，于是在最新的內(nèi)核中就去掉了，不再為slab對(duì)象提供析構(gòu)函數(shù)了（參考slub）。
附：2.6內(nèi)核模塊的編譯
1.寫(xiě)好模塊c文件，文件名為：XX.c；
2.寫(xiě)Makefile文件，內(nèi)容：obj-m += XX.o
3.make -C /lib/modules/`uanem -r`/build/ SUBDIRS=$PWD modules