java開發系統核心：讓核心從嚴重錯誤中恢複

標籤：top   idt   方式   控制器   資料存放區   儲存   描述   運行   簡單   

更詳細的講解和代碼調試示範過程，請參看視頻
用java開發C語言編譯器

更詳細的講解和代碼調試示範過程，請參看視頻
如何進入google,演算法面試技能全面提升指南

如果你對機器學習感興趣，請參看一下連結：
機器學習：神經網路導論

更詳細的講解和代碼調試示範過程，請參看視頻
Linux kernel Hacker, 從零構建自己的核心

微軟早期的DOS系統，存在一個嚴重的問題是，如果應用程式運行出現問題，它會導致整個系統完全奔潰掉，我們當前的系統核心也存在這一的問題，例如開啟api_call.asm,其內容如下：

[SECTION .s32]
BITS 32
call main
retf

api_putchar:
mov edx, 1
mov al, [www.vboyule66.cn esp + 4]
int 02Dh
ret

%include "app.asm"
call main 時CPU控制權會提交給應用程式，執行應用程式的代碼，應用程式執行完畢後，返回到call main語句的下一條指令繼續執行，call main 的下一條語句是retf, 它的作用是從堆棧上得到核心代碼的全域描述符，把該描述符在描述符表中的下標賦值給寄存器cs, 同時把核心要執行語句的地址從堆棧上取得，並賦值給寄存器ip, 這樣CPU的控制器會重新交還給核心，假設我們對上面代碼做一個修改如下：

[SECTION .s32]
BITS 32
call main
pop eax ;故意讓返回地址出錯造成異常保護中斷
retf
我們在執行retf語句時，把儲存在堆棧上的核心要執行的語句地址彈出，這樣要返回的核心地址就會遭遇破壞，當執行retf語句後，ip指標會執行記憶體的任意一個無法確定的地方，於是CPU在接下來的執行中就會遇到錯誤，上面代碼修改後運行起來，情況如下：
這裡寫圖片描述

由於ip指標指向了無效地址，致使CPU執行了無效指令進而導致系統的整體奔潰，接下來我們看看如何處理讓系統從這種嚴重錯誤中恢複回來，這樣就可以防止應用程式執行惡意代碼而對系統造成傷害。

當CPU在執行指令出現錯誤時，例如遇到了無效指令，那麼CPU會出發0Dh號中斷，讓該中斷來處理當前所出現的異常局面，如果該中斷無法處理，那麼CPU就會停止運行，於是就出現了上面的情況。為了讓系統能從錯誤中恢複，我們需要實現0Dh號中斷，在中斷中，我們直接結束掉當前正在啟動並執行應用程式，直接把CPU的控制全交還給核心。

我們現在kernel.asm中註冊0Dh號中斷，代碼修改如下：

LABEL_IDT:
%rep 13
Gate SelectorCode32, SpuriousHandler,0, DA_386IGate
%endrep

.0Dh:
Gate SelectorCode32, www.yszxylpt.com exceptionHandler,0, DA_386IGate

%rep 18
Gate SelectorCode32, www.boayulevip.cn SpuriousHandler,0, DA_386IGate
%endrep
上面代碼在中斷描述符表中註冊了一個0Dh號中斷，當中斷髮送時，CPU會調用exceptionHandler函數。我們看看該函數的實現，同樣也是在kernel.asm中：

_exceptionHandler:
exceptionHandler equ _exceptionHandler - $$
cli
;把記憶體段切換到核心
mov ax, SelectorVram
mov ds, ax
mov es, ax
mov ax, www.vboyl130.cn SelectorStack ;切換到核心堆棧段
mov ss, ax

mov ecx, [0xfe4];擷取核心堆棧指標
add ecx, -8
mov [ecx+4], ss ;儲存中斷時的堆棧段
mov [ecx], esp ;儲存中斷時堆棧指標

mov esp, ecx ;切換核心指標

call intHandlerForException

.kill: ;通過把CPU交給核心的方式直接殺掉應用程式
mov esp, [0xfe4]
sti
popad
ret
中斷運行時，先把核心專有記憶體段的描述符賦值給寄存器ds,es,這樣代碼運行時可以直接讀寫核心的資料，同時把核心的堆棧描述符賦值給寄存器ss,這樣代碼運行時使用的堆棧就是核心的專有堆棧。然後把錯誤發生時的應用程式使用的堆棧段描述符和堆棧指標存入核心堆棧，接著調用函數intHandlerForException進行錯誤處理，該函數實現在核心的C語言部分，也就是在write_vga_desktop.c中，我們看看此函數的實現：

void intHandlerForException(int *esp) {
g_Console.cur_x = 8;
cons_putstr("INT 0D ");
g_Console.cur_x = 8;
g_Console.cur_y += 16;
cons_putstr("General Protected Exception");
g_Console.cur_y += 16;
g_Console.cur_x = 8;
return 1;
它的做法很簡單，只是在控制台上列印出兩行字串，分別是”INT OD”,和”General Protected Exception”，然後就返回了。回到中斷實現部分，也就是.kill對應的代碼，在核心把控制權交給應用程式時，會把它當時的堆棧指標儲存到記憶體[0xfe4]處，核心時通過start_app把控制權交給應用程式的，我們再看看start_app的代碼：

start_app: ;void start_app(int eip, int cs,int esp, int ds)
cli
pushad
...
mov [0xfe4], esp
...
大家看，start_app在執行時，通過指令把當時所有通用寄存器的資料存放區到堆棧上，同時把esp指標的值，也就是當時的核心堆棧指標儲存到記憶體0xfe4這個地方，因此.kill 的指令 mov esp [0xfe4]實際上就是對上面指令mov [0xfe4], esp 的逆操作，同時popad也是對上面指令pushad的逆操作。我們再看看start_app是如何被調用的，在write_vga_desktop.c中：

void cmd_hlt() {
....
start_app(0, 11*8,64*1024, 12*8);

char *pApp = (char*)(q + 0x100);
showString(shtctl, sht_back, 0, 179, COL8_FFFFFF, pApp);

memman_free_4k(memman, buffer.pBuffer, buffer.length);
memman_free_4k(memman, q, 64 * 1024);
start_app是在cmd_hlt中被調用的，我們知道c語言在調用子函數時，會把調用子函數後要執行的下一條指令的地址壓入堆棧，因此當上面代碼在調用start_app函數時，下一條指令，也就是char *pApp=(char*)這條語句的地址會被壓入到堆棧上。

當.kill處的代碼執行完語句popad後，此時堆棧上儲存的恰好就是語句char *pApp=(char*)的地址，於是當我們執行指令ret的時候，該語句的地址會賦值給ip寄存器，這樣CPU就會直接從char *pApp=(char*)這條語句開始執行，這就類似與應用程式正常執行完畢後，CPU控制權正常返還給核心的情況是一樣的。

這樣，當應用程式執行出現嚴重錯誤時，CPU觸發0Dh號異常處理中斷，在該中斷中，代碼會把CPU控制權直接交還給核心，著就相當於把出現異常的應用程式毀屍滅跡，核心就好像什麼事都沒發生過一樣，繼續按照老樣子運行，上面代碼修改後，執行錯誤的應用程式後，情況如下：

這裡寫圖片描述

由此可見，當錯誤發生時0Dh號中斷確實被調用了，兩行字串被顯示到控制台，然後核心可以正常繼續運行而不會像前面的例子一樣，整個系統會奔潰掉。

更詳實的講解和代碼示範，請參看視頻。

java開發系統核心：讓核心從嚴重錯誤中恢複