Linux Kernel Stack Overflow/Linux 内核栈溢出

不同于Linux应用程序的栈能够动态增长,Linux内核栈是固定的,并且比较小,比如Linux 2.6.x内核,在X86 32位架构上一般是4K或8K(在进行内核编译时,Kernel hacking下进行配置,默认8K),而在X86 64位架构上固定为8K。Linux内核会分配一页(4K stack)或两页连续(8K stack)不可交换(non-swappable)内存来作为内核栈使用。Linux 2.4.x内核在X86位架构上,内核栈固定为8K。

当一个进行运行在内核态时(比如通过系统调用),它就将开始使用它自己的内核栈,如果内核栈大小为8K,那么此时的触发的中断处理也将使用这个栈,如果内核栈大小为4K,那么此时的触发的中断处理则将使用单独的内核栈。

由于内核栈大小固定且比较小,很容易出现内核栈溢出的情况,所以不能在内核代码里使用递归调用(除非你非常清楚它递归的层次,但仍建议将递归改为循环,因为谁也不知道将来哪一天递归的层次是否会发生变化),也不建议使用较大或大小未知的栈变量(比如动态数组)等。

由于task_struct和内核栈共用同一块内存区域,所以内核栈溢出最直接的后果就是把task_struct结构体踩坏,在linux下,这个结构体是至关重要的,每一个进程都是由这个task_struct数据结构来定义,它也就是我们通常所说的PCB,它是用来对进程进行控制的唯一手段,也是最有效的手段;但这是kernel 2.4.x的情况,下面代码来之kernel 2.4.37.11:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

union task_union {

    struct task_struct task;

    unsigned long stack[INIT_TASK_SIZE/sizeof(long)];

};

struct task_struct {

    /*

     * offsets of these are hardcoded elsewhere - touch with care

     */

    volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */

    unsigned long flags;    /* per process flags, defined below */

    int sigpending;

    mm_segment_t addr_limit;    /* thread address space:

                        0-0xBFFFFFFF for user-thead

                        0-0xFFFFFFFF for kernel-thread

                     */

    struct exec_domain *exec_domain;

    volatile long need_resched;

    unsigned long ptrace;

    int lock_depth;     /* Lock depth */

...

};

到了kernel 2.6.x之后,和内核栈共用同一块内存区域的不再是task_struct,而是结构体thread_info,下面代码来之kernel 2.6.38.8:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

union thread_union {

    struct thread_info thread_info;

    unsigned long stack[THREAD_SIZE/sizeof(long)];

};

struct thread_info {

    struct task_struct  *task;      /* main task structure */

    struct exec_domain  *exec_domain;   /* execution domain */

    __u32           flags;      /* low level flags */

    __u32           status;     /* thread synchronous flags */

    __u32           cpu;        /* current CPU */

    int         preempt_count;  /* 0 => preemptable,

                           <0 => BUG */

    mm_segment_t        addr_limit;

    struct restart_block    restart_block;

    void __user     *sysenter_return;

#ifdef CONFIG_X86_32

    unsigned long           previous_esp;   /* ESP of the previous stack in

                           case of nested (IRQ) stacks

                        */

    __u8            supervisor_stack[0];

#endif

    int         uaccess_err;

};

不过由于thread_info结构体的第一个字段就是task_struct指针,所以内核栈溢出的话同样会损坏task_struct,因为此时task指针指向一个不可预知的地址,相应的task_struct结构体各个字段数据当然也就都是垃圾数据了。

看图示更直观:

Linux Kernel Stack Overflow/Linux 内核栈溢出_第1张图片


一旦内核栈溢出,间接导致task_struct结构体里的数据异常,那么就会导致系统处于一种不稳定状态(当然,一般情况也就是宕机):

Linux Kernel Stack Overflow/Linux 内核栈溢出_第2张图片


当在查宕机问题时,如果定位到是由于thread_info结构体或task_struct结构体里数据异常导致(比如引起系统宕机的指令是访问task_struct结构体变量的某个字段),那么就要优先考虑是否由内核栈下溢引起宕机。对于栈的保护,Linux内核提供了一系列选项,比如DEBUG_STACKOVERFLOW、CC_STACKPROTECTOR等,但这些都只是辅助手段,要如何定位到更具体的位置呢?内核函数对栈空间的预留和应用层没有什么两样,同样是移动esp或rsp,所以我们可以先找出所有这些预留的地方,看哪个地方预留得最多,也就是该函数占用的栈空间最多,那么就是最有可能引发内核栈溢出的地方。
示例:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

/**

 * kernel_stack.c

 */

#include

#include

#include

#include

#define NUM 256

static int just_copy_half(int *array, int count)

{

    int i;

    int another_array[count];

    for (i = 0; i < count; i ++) {

        another_array[i] = array[i];

    }

    return 0;

}

static int __init kernel_stack_init(void)

{

    int ret = 0;

    int total = 0;

    int array[NUM];

    int i;

    for (i = 0; i < NUM; i ++)

        array[i] = i;

         

    for (i = 0; i < NUM; i ++)

        total += array[i];

         

    just_copy_half(array, NUM/2);

         

    printk("Total: %d\n", total);

    return ret;

}

static void __exit kernel_stack_fini(void)

{

    //Do Nothing

    return;

}

module_init(kernel_stack_init);

module_exit(kernel_stack_fini);

MODULE_LICENSE("GPL");

MODULE_AUTHOR("lenky0401 at gmail dot com");

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

# Makefile

MDIR = $(shell pwd)

ifeq (, $(KSRC))

    KSRC := /usr/src/linux-2.6.36

endif

ifeq (, $(PROJECT_DIR))

    PROJECT_DIR := $(PWD)/../

endif

module := kernel_stack

obj-m := $(module).o

srcs =  $(wildcard, *.c)

$(module)-objs := $(addsuffix .o, $(basename $(srcs)))

EXTRA_CFLAGS += $(FLAG) -I$(PROJECT_DIR)/inc -I${SHAREDHDR} -I$(KERNELHDR) -O2 -D__KERNEL__ -DMODULE $(INCLUDE) -DEXPORT_SYMTAB

TARGET = $(module).ko

all:

    make -C $(KSRC) M=$(MDIR) modules

debug:

    make EXTRA_FLAGS="${EXTRA_CFLAGS} -DDEBUG" -C $(KSRC) M=$(MDIR) modules

clean:

    make -C $(KSRC) M=$(MDIR) clean

install: all

    cp -f $(TARGET) $(INSTALL_DIR)

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

[root@localhost kernel_stack]# ls

kernel_stack.c  Makefile

[root@localhost kernel_stack]# make

make -C /usr/src/linux-2.6.36 M=/home/lenky/modules/kernel_stack modules

make[1]: Entering directory `/usr/src/linux-2.6.36'

  CC [M]  /home/lenky/modules/kernel_stack/kernel_stack.o

  Building modules, stage 2.

  MODPOST 1 modules

  CC      /home/lenky/modules/kernel_stack/kernel_stack.mod.o

  LD [M]  /home/lenky/modules/kernel_stack/kernel_stack.ko

make[1]: Leaving directory `/usr/src/linux-2.6.36'

[root@localhost kernel_stack]# ls

kernel_stack.c   kernel_stack.mod.c  kernel_stack.o  modules.order

kernel_stack.ko  kernel_stack.mod.o  Makefile        Module.symvers

[root@localhost kernel_stack]# objdump --source kernel_stack.ko > kernel_stack.s

[root@localhost kernel_stack]# cat kernel_stack.s | grep sub | grep rsp

  13:   48 29 c4                sub    %rax,%rsp

   3:   48 81 ec 00 04 00 00    sub    $0x400,%rsp

可以看到,一个地方(kernel_stack_init函数)的栈占去$0x400(有几个局部变量是直接使用的寄存器,所以才没有消耗栈),而另外一个地方(just_copy_half函数)的栈占去%rax是个不定值,这就需要继续看对应的汇编来进行分析(因为数组是动态数组),这只是个示例,如果在真实内核代码中有这样的函数,那是相当危险的。更多细节不说,相关汇编代码:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

kernel_stack.ko:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 :

static int just_copy_half(int *array, int count)

{

    int i;

    int another_array[count];

   0:   48 63 c6                movslq %esi,%rax

   3:   55                      push   %rbp

   4:   48 8d 04 85 1e 00 00    lea    0x1e(,%rax,4),%rax

   b:   00

   c:   48 89 e5                mov    %rsp,%rbp

   f:   48 83 e0 f0             and    $0xfffffffffffffff0,%rax

  13:   48 29 c4                sub    %rax,%rsp

  16:   4c 8d 44 24 0f          lea    0xf(%rsp),%r8

  1b:   49 83 e0 f0             and    $0xfffffffffffffff0,%r8

    for (i = 0; i < count; i ++) {

  1f:   85 f6                   test   %esi,%esi

  21:   7e 16                   jle    39

  23:   31 c9                   xor    %ecx,%ecx

  25:   31 d2                   xor    %edx,%edx

        another_array[i] = array[i];

  27:   8b 04 97                mov    (%rdi,%rdx,4),%eax

  2a:   83 c1 01                add    $0x1,%ecx

  2d:   41 89 04 90             mov    %eax,(%r8,%rdx,4)

  31:   48 83 c2 01             add    $0x1,%rdx

  35:   39 f1                   cmp    %esi,%ecx

  37:   75 ee                   jne    27

    }

    return 0;

}

  39:   c9                      leaveq

  3a:   31 c0                   xor    %eax,%eax

  3c:   c3                      retq  

  3d:   00 00                   add    %al,(%rax)

    ...

Disassembly of section .exit.text:

0000000000000000 :

static int __init kernel_stack_init(void)

{

    int ret = 0;

    int total = 0;

    int array[NUM];

    int i;

    for (i = 0; i < NUM; i ++)

        array[i] = i;

         

    for (i = 0; i < NUM; i ++)

        total += array[i];

         

    just_copy_half(array, NUM/2);

         

    printk("Total: %d\n", total);

    return ret;

}

static void __exit kernel_stack_fini(void)

{

    //Do Nothing

    return;

}

   0:   f3 c3                   repz retq

Disassembly of section .init.text:

0000000000000000 :

   0:   53                      push   %rbx

   1:   31 c0                   xor    %eax,%eax

   3:   48 81 ec 00 04 00 00    sub    $0x400,%rsp

   a:   48 89 e7                mov    %rsp,%rdi

   d:   0f 1f 00                nopl   (%rax)

  10:   89 04 87                mov    %eax,(%rdi,%rax,4)

  13:   48 83 c0 01             add    $0x1,%rax

  17:   48 3d 00 01 00 00       cmp    $0x100,%rax

  1d:   75 f1                   jne    10

  1f:   31 db                   xor    %ebx,%ebx

  21:   66 31 c0                xor    %ax,%ax

  24:   03 1c 87                add    (%rdi,%rax,4),%ebx

  27:   48 83 c0 01             add    $0x1,%rax

  2b:   48 3d 00 01 00 00       cmp    $0x100,%rax

  31:   75 f1                   jne    24

  33:   48 89 e7                mov    %rsp,%rdi

  36:   be 80 00 00 00          mov    $0x80,%esi

  3b:   e8 00 00 00 00          callq  40

  40:   89 de                   mov    %ebx,%esi

  42:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi

  49:   31 c0                   xor    %eax,%eax

  4b:   e8 00 00 00 00          callq  50

  50:   48 81 c4 00 04 00 00    add    $0x400,%rsp

  57:   31 c0                   xor    %eax,%eax

  59:   5b                      pop    %rbx

  5a:   c3                      retq  

上面提到Linux 2.6.x内核在X86 32位架构上可以配置内核栈大小(在进行内核编译时,Kernel hacking下进行配置,默认8K,配置之后对应的宏为CONFIG_4KSTACKS),具体生效代码可以看:
LXR / The Linux Cross Reference

1

2

3

4

5

6

#ifdef CONFIG_4KSTACKS

#define THREAD_ORDER    0

#else

#define THREAD_ORDER    1

#endif

#define THREAD_SIZE     (PAGE_SIZE << THREAD_ORDER)

通过CONFIG_4KSTACKS宏来定义THREAD_SIZE大小,但是在2.6.37后的内核代码里都已经找不到这个定义了:
LXR / The Linux Cross Reference
LXR / The Linux Cross Reference
LXR / The Linux Cross Reference
后来一查才知道CONFIG_4KSTACKS已经被移除了:https://lkml.org/lkml/2010/6/29/107,好吧,继续8K内核栈。

你可能感兴趣的:(Linux内核技术,linux,内核,栈溢出,踩栈)