內(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)核線(xiàn)程，手動(dòng)屏蔽了此信號(hào)；3.內(nèi)核忽略了此信號(hào).我們看看init進(jìn)程，它不是內(nèi)核線(xiàn)程（實(shí)際上在rest_init之初的init是內(nèi)核線(xiàn)程，只是它馬上exec到用戶(hù)空間了），而且SIGKILL（9）是用戶(hù)線(xiàn)程所不能忽略和屏蔽的，因此只有第三種可能，內(nèi)核忽略了此信號(hào)，找找代碼，看看下面的函數(shù)就得到了確切的答案。

int?get_signal_to_deliver(siginfo_t?*info,?struct?k_sigaction?*return_ka,?struct?pt_regs?*regs,?void?*cookie)

{

...

?????????spin_lock_irq(¤t->sighand->siglock);

?????????for?(;;)?{

...

?????????????????if?(current->pid?==?1)//由pid判斷是否傳送信號(hào)，執(zhí)行到此，信號(hào)只可能是SIGKILL或STOP之類(lèi)的巨猛信號(hào)了，如果是init進(jìn)程那么忽略，不向它傳送

?????????????????????????continue;

...

?????????????????do_group_exit(signr);?????????????

?????????}

?????????spin_unlock_irq(¤t->sighand->siglock);

?????????return?signr;

}

因此我們知道內(nèi)核只是通過(guò)進(jìn)程的pid來(lái)識(shí)別init進(jìn)程的，如果我們找到init，然后修改它的pid，使之不再為1，是否就可以殺死init進(jìn)程了呢？理論是這樣，難道真的是這么簡(jiǎn)單嗎？于是我寫(xiě)下以下的模塊：

#include?

static?__init?int?test_init(void)

{

????task_t?*task=find_task_by_pid(1);??//找到1號(hào)進(jìn)程的task_struct結(jié)構(gòu)指針?????

????????task->pid?=?3314;??//將init的pid改為一個(gè)沒(méi)有使用的pid

????????force_sig(SIGKILL,task);??//然后殺死它，就是殺死init進(jìn)程

????????return?0;

}

static?__exit?void?test_exit(void)

{

????return?;

}

module_init(test_init);

module_exit(test_exit);

MODULE_LICENSE("Dual?BSD/GPL");

MODULE_AUTHOR("Zhaoya");

MODULE_DESCRIPTION("kill?init");

MODULE_VERSION("Ver?0.1");

結(jié)果如何呢？當(dāng)然是系統(tǒng)崩潰，linux臨死前coredump，調(diào)用堆棧中有choose_new_parent函數(shù)，找到choose_new_parent函數(shù)看了一下：

static?inline?void?choose_new_parent(task_t?*p,?task_t?*reaper,?task_t?*child_reaper)

{

?????????BUG_ON(p?==?reaper?||?reaper->state?>=?TASK_ZOMBIE);

?????????p->real_parent?=?reaper;

?????????if?(p->parent?==?p->real_parent)??//這里出錯(cuò)，p是init的孩子，p->parent當(dāng)然是init，而reaper也是init，所以if為真，BUG乎！

?????????????????BUG();

}

那里為何出錯(cuò)呢？實(shí)際上SIGKILL信號(hào)真的發(fā)給了init，然后init就do_exit了，當(dāng)中調(diào)用了以下函數(shù)：參數(shù)的father就是init本身，該函數(shù)過(guò)繼了init的孩子們給一個(gè)新的父親。

static?inline?void?forget_original_parent(struct?task_struct?*?father,?struct?list_head?*to_release)

{

?????????struct?task_struct?*p,?*reaper?=?father;

?????????struct?list_head?*_p,?*_n;

?????????do?{

?????????????????reaper?=?next_thread(reaper);

?????????????????if?(reaper?==?father)?{

?????????????????????????reaper?=?child_reaper;//child_reaper在初始化時(shí)設(shè)置為init進(jìn)程，于是到此為止father和reaper是一樣的。

?????????????????????????break;

?????????????????}

?????????}?while?(reaper->state?>=?TASK_ZOMBIE);

?????????list_for_each_safe(_p,?_n,?&father->children)?{

?????????????????int?ptrace;

?????????????????p?=?list_entry(_p,struct?task_struct,sibling);

?????????????????ptrace?=?p->ptrace;

?????????????????BUG_ON(father?!=?p->real_parent?&&?!ptrace);

?????????????????if?(father?==?p->real_parent)?{

?????????????????????????choose_new_parent(p,?reaper,?child_reaper);//到了此點(diǎn)。

?????????????????????????reparent_thread(p,?father,?0);

?????????????????}?else?{

...

}

因此init進(jìn)程不可殺并不是用戶(hù)空間的策略，而是內(nèi)核的機(jī)制，是操作系統(tǒng)的一部分，操作系統(tǒng)用這個(gè)機(jī)制實(shí)現(xiàn)了很多事情，比如僵尸進(jìn)程管理回收問(wèn)題，多用戶(hù)安全問(wèn)題等等，不要指望殺死init了，即使通過(guò)rootkit做到了，試問(wèn)有意義嗎？就是個(gè)兒戲罷了，沒(méi)有實(shí)用性的。
?? 下面談?wù)剝?nèi)核野指針問(wèn)題，這其實(shí)是一個(gè)爭(zhēng)論的話(huà)題，爭(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)程如下：

int?main()

{

????while(1){}

}

編譯后運(yùn)行，ps后它的pid是2732，然后寫(xiě)如下模塊：

#include?

static?__init?int?test_init(void)

{

????task_t?*task=find_task_by_pid(2732);??

????free_task(task);

????return?0;

}

static?__exit?void?test_exit(void)

{

?????????return?;

}

module_init(test_init);

module_exit(test_exit);

MODULE_LICENSE("Dual?BSD/GPL");

MODULE_AUTHOR("Zhaoya");

MODULE_DESCRIPTION("free?task");

MODULE_VERSION("Ver?0.1");

加載模塊后，只要不要?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))，而后者就是：

static?inline?void?__cache_free?(kmem_cache_t?*cachep,?void*?objp)

{

?????????struct?array_cache?*ac?=?ac_data(cachep);

?????????check_irq_off();

?????????objp?=?cache_free_debugcheck(cachep,?objp,?__builtin_return_address(0));

?????????if?(likely(ac->avail?limit))?{

?????????????????STATS_INC_FREEHIT(cachep);

?????????????????ac_entry(ac)[ac->avail++]?=?objp;

?????????????????return;

?????????}?else?{

?????????????????STATS_INC_FREEMISS(cachep);

?????????????????cache_flusharray(cachep,?ac);

?????????????????ac_entry(ac)[ac->avail++]?=?objp;

?????????}

}

僅此而已，操作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分配，我們看看分配代碼：

static?inline?void?*?__cache_alloc?(kmem_cache_t?*cachep,?int?flags)

{

?????????unsigned?long?save_flags;

?????????void*?objp;

?????????struct?array_cache?*ac;

?????????cache_alloc_debugcheck_before(cachep,?flags);

?????????local_irq_save(save_flags);

?????????ac?=?ac_data(cachep);

?????????if?(likely(ac->avail))?{

?????????????????STATS_INC_ALLOCHIT(cachep);

?????????????????ac->touched?=?1;

?????????????????objp?=?ac_entry(ac)[--ac->avail];

?????????}?else?{

?????????????????STATS_INC_ALLOCMISS(cachep);

?????????????????objp?=?cache_alloc_refill(cachep,?flags);

?????????}

?????????local_irq_restore(save_flags);

?????????objp?=?cache_alloc_debugcheck_after(cachep,?flags,?objp,?__builtin_return_address(0));

?????????return?objp;

}

看看這個(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)清零，不保留任何公共部分：

#include?

static?__init?int?test_init(void)

{

????task_t?*task=find_task_by_pid(1824);??

????free_task(task);

????memset(task,0,sizeof(task_t));??//將task_struct清零，實(shí)際上就是將其內(nèi)部的字段清零，包括指針變量，由此消除了野指針

????return?0;

}

static?__exit?void?test_exit(void)

{

?????????return?;

}

module_init(test_init);

module_exit(test_exit);

MODULE_LICENSE("Dual?BSD/GPL");

MODULE_AUTHOR("Zhaoya");

MODULE_DESCRIPTION("zero?task");

MODULE_VERSION("Ver?0.1");

還是以上面的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ò)不必像用戶(hù) 空間那么過(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

閱讀全文

評(píng)論

91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲日韩欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

搜索歷史

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

評(píng)論