全部博文(44)
分类: LINUX
2008-09-19 20:06:02
图2. 内核image整体布局
图2显示了内核image的布局,其中深色部分位于内核的虚拟地址空间3G~4G,共有text、data、note三个segment,其中note segment又是包含在text segment中。每个segment包含多个section,后面我们会讲到这些section是如何生成的。在这之前,需要了解链接脚本用到的两个地址:虚拟地址(VMA)和加载地址(LMA)。这里虚拟地址和我们平常说的虚拟地址是一样的,即section[*]在目标文件加载后所在的虚拟地址。例如在一个可执行的ELF文件中,.text section的VMA是0x08048310,即.text section的基地址位于虚拟地址空间的0x08048310处。加载地址指section被加载到内存中的地址,对于应用程序来说它通常和VMA相同,但对于内核来说,LMA是指section被加载到的物理地址。例如内核.text的VMA是0xc1001000,则LMA是0x01001000。很明显,这就是我们所熟知的内核虚拟地址 = 物理地址 + 0xC0000000(3G)的identify mapping关系。
[*]前面提到目标文件的加载是若干segment被加载到内存中的过程,这和section的加载并不冲突。实际上,当我们不指定segment的LMA和VMA时,这个两个值取segment中第一个section的LMA、VMA。加载segment也就是将其包含的各个section加载到内存中的过程。
好了,下面我们来看看内核链接脚本是怎么干的。
除去一些文件包含和宏定义,内核链接脚本以下面内容开始:
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(phys_startup_32)
jiffies = jiffies_64;
PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(7); /* RWE */
note PT_NOTE FLAGS(0); /* ___ */
}
OUTPUT_FORMAT和OUTPUT都是链接脚本的关键字,它们指定了目标文件的格式和所运行平台的架构,这些公式化的东西我们不关心它,具体内容详见参考文献1。ENTRY指定了整个目标文件的入口点(或入口函数),这里phys_startup_32是个地址,从名字我们就可以看出它是startup_32()函数的物理地址,在后面会看到该地址是如何计算得到的。jiffies = jiffes_64的魔术与本文无关,感兴趣的朋友可以参见ULK3的6.2.1.2节。
下面进入正题。PHDRS关键字描述了3个segment:text、data和note,它们分别具有PT_LOAD和PT_NOTE类型,并指定了每个segment的属性。PT_LOAD类型表示该segment是从文件加载入内存的,在这个上下文中文件应该指最后生成的内核image。FLAG关键字指定segment的属性,如注释所示,text segment为可读可执行、data segment为可读可写可执行,note段留到后面再说。至此,PHDRS定义了内核image的大体框架,它包含两个最主要的segment —— text和data,并确定了它们的属性,后面的代码就是向两个segment填充section了。
链接脚本知识:
PHDRS关键字的完整格式如下:
PHDRS
{
name type [ FILEHDR ] [ PHDRS ] [ AT ( address ) ]
[ FLAGS ( flags ) ] ;
}
其中name表示segment的名字,它位于单独的名字空间,不会和后面的section name冲突。type即segment的类型,如上的PT_LOAD,详细列表参见参考文献1。FILEHDR和PHDRS指定是否要包含ELF文件头和ELF程序头。AT指定segment的加载地址,FLAGS指定segment的属性。
在构建了基本的segment后,就可以从输入.o文件中获取感兴趣的section以生成新的section并放入相应的segment。在这里,输入的section称为input section,生成的新section称为output section。除此之外,有一个重要的链接脚本符号“.”需要了解。”.”是个位置计数器,记录着当前位置在目标文件中的虚拟地址(VMA)。”.”是个自动增加的计数器,当一个output section生成后,”.”的值自动加上该output section的长度。我们也可以显式的给”.”赋值以改变当前位置的地址,这在内核链接脚本中被大量使用。一个例子可以很好的描述”.”的作用:
. = 0x100000;
_start_addr = .;
.text : { *(.text) }
_end_addr = . ;
这里我们首先给”.”赋了一个初值,将地址指定到0x100000处,并将该值赋给变量_start_addr,它是.text section的起始地址;接着我们生成了一个.text section,此时”.”自动加上该section的长度,可描述为 . = . + SIZEOF(.text);最后将”.”赋值给_end_addr,记录下.text的结束地址。此时”.”的值变成了 0x100000 + SIZEOF(.text)。有了”.”的帮助,我们可以灵活的控制目标文件中各个section所在的虚拟地址(VMA)。
内核首先构造的是text segment,该segment又由若干个.text.*节构成,除此之外,它还包含了note segment的内容以及只读数据section。下面的代码完成了这些工作:
SECTIONS { . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR; phys_startup_32 = startup_32 - LOAD_OFFSET; .text.head : AT(ADDR(.text.head) - LOAD_OFFSET) { _text = .; /* Text and read-only data */ *(.text.head) } :text = 0x9090 /* read-only */ .text : AT(ADDR(.text) - LOAD_OFFSET) { . = ALIGN(PAGE_SIZE); /* not really needed, already page aligned */ *(.text.page_aligned) TEXT_TEXT SCHED_TEXT LOCK_TEXT KPROBES_TEXT *(.fixup) *(.gnu.warning) _etext = .; /* End of text section */ } :text = 0x9090 NOTES :text :note . = ALIGN(16); /* Exception table */ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { __start___ex_table = .; *(__ex_table) __stop___ex_table = .; } :text = 0x9090 RODATA
首先是SECTIONS关键字,官方的解释是“The SECTIONS command tells the linker how to map input sections into output sections, and how to place the output sections in memory.”,实际上可以把它看成一个描述符,所有的工作要在它的内部完成。就像你在C中定义一个结构体要以struct关键字开头一样。
构造的第一步是为”.”指定初值,之后所有section虚拟地址(VMA)都由该值计算得来(前面我们讲过,生成一个section后”.”的值会自动加上改section的长度)。这里初始值为LOAD_OFFSET + LOAD_PHYSICAL_ADDR,前者是我们熟知的内核虚拟地址空间起始地址0xC0000000,LOAD_PHYSICAL_ADDR是内核image加载的物理地址,由CONFIG_PHYSICAL_START计算得到。该物理地址是可以指定的,你可以在.config文件中找到它,也可以由make menuconfig得到,具体解释参考arch/x86/Kconfig文件的PHYSICAL_START条目。对于一般的x86架构,内核被加载到物理地址0x100000处,故”.”的初值为0xC0100000。接着
phys_startup_32 = startup_32 - LOAD_OFFSET;
计算了内核image的入口地址,这在前面已经提到。
开始构造section了。由于使用的语法是固定的,我们只需要了解一个例子,其余的就可举一反三。以第一个section为例:
.text.head : AT(ADDR(.text.head) - LOAD_OFFSET) { _text = .; /* Text and read-only data */ *(.text.head) } :text = 0x9090
.text.head指定了生成的section的名字,后面的冒号是固定语法。AT关键字前面介绍过,指定该section的加载地址(LMA),它的完整表达是
AT(expression)
括号中expression表达式指定LMA的值。在此例中该表达式由
ADDR(.text.head) - LOAD_OFFSET
计算得到。这里
ADDR(section)
计算section的虚拟地址,故.text.head的加载地址(LMA)是它的物理地址。在大括号内部,_text = .;
定义了一个全局变量,它的值为”.”的当前值,记录了整个text segment的起始地址.。在这里,由于_text变量前还没有任何section被创建,故_text有如下等价关系:
_text = ADDR(.text.head) = . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
*(.text.head)完成了具体的section创建工作,”*”代表所有输入的.o文件,括号中的.text.head指定了链接器感兴趣的section名。
*(text.head)
表示从所有输入文件中抽取名为.text.head的section并填充到目标文件的.text.head section中。
: text
指定了新生成section所在的segment,这里冒号后的text是segment名,可见内核的第一个section被放到了text segment。
= 0x9090
指定section的填充内容。从输入文件中抽取来的section由于代码对齐的缘故,其二进制的存放可能是不连续的,这里指定对section中的空隙用0x9090进行填充。0x90是汇编指令NOP的机器码,故相当于在不连续代码间填充空操作。至此,内核的第一个section就创建好了,它名为.text.head,由输入文件的.text.head section构成(并非所有文件都有.text.head section,链接器只从具有该section的文件中抽取内容),该section的虚拟地址(VMA)由”.”的值确定,加载地址(LMA)为其物理地址,section中不连续区域产生的间隙由0x9090填充,最后该section被放入了内核的text segment中。
通过objdump内核,我们可以看到关于该section的最终内容:
Sections: Idx Name Size VMA LMA File off Algn 0 .text.head 00000375 c1000000 01000000 00001000 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE ………………………………………………………………………………………….. Disassembly of section .text.head: c1000000 <_text>: c1000000:>--f6 86 11 02 00 00 40 >--testb $0x40,0x211(%esi) c1000007:>--75 14 >--jne c100001d <_text+0x1d> c1000009:>--0f 01 15 1a e1 4d 01 >--lgdtl 0x14de11a >--->--->---c100000c: R_386_32>-boot_gdt_descr c1000010:>--b8 18 00 00 00 >--mov $0x18,%eax c1000015:>--8e d8 >--mov %eax,%ds ………………………………………………………………………………………………… c10013d5:>--5b >--pop %ebx c10013d6:>--5e >--pop %esi c10013d7:>--c9 >--leave-- c10013d8:>--c3 >--ret---- c10013d9:>--90 >--nop---- c10013da:>--90 >--nop---- c10013db:>--90 >--nop---- c10013dc:>--90 >--nop---- c10013dd:>--90 >--nop---- c10013de:>--90 >--nop---- c10013df:>--90 >--nop----
其中最后一部分显示了填充0x9090产生的nop指令。
链接脚本知识:
创建一个section的完整格式是:
section [address] [(type)] : [AT(lma)]
{
output-section-command
output-section-command
...
} [>region] [:phdr :phdr ...] [=fillexp]
其中[address]参数在上例中没有提到,它指定了section的虚拟地址(VMA),如果没有指定该参数及region参数,section的虚拟地址由当前”.”的值确定,正如上例我们看到的一样。Region用于将section分配给通过MEMORY关键字创建的内存描述块,内核链接脚本没使用它,本文也不关注,具体内容详见参考文献1的MEMORY command一节。
通过这个例子,我们很容易就可以理解text segment中其它section的创建。例如接下来的第二个.text section,它的创建方法和.text.head类似,唯一不同的是这里多了一句:
. = ALIGN(PAGE_SIZE);
ALIGN(exp)关键字计算当前”.”值对齐到exp边界后的地址,即:
ALIGN(exp) = ( . + exp – 1) & ~(exp – 1);
此处在创建.text section前,将”.”对齐到了页边界,从第一个输入section的名字.text.page_aligned就可以看出,输入section的内容是有对齐要求的。内核使用了TEXT_TEXT等宏将不同类型的输入section进行了封装,展开后可以看到它们都是:
*(section_name)
的形式,和我们前面讲的一样,不再多做介绍。
从上面内容可以看出,输入文件中的section有各种各样的名字,如.text.head、.text.page_aligned、.text.hot等,并不是所有的section名都是标准的,绝大部分是内核使用GCC扩展生成的自定义名。举个例子,我们常见的__init宏,展开后如下:
#define __init __attribute__ ((__section__(“.init.text”)))
这里.init.text是个自定义的section,用__init修饰的函数编译后会被放到名为.init.text section中。
自定义的section极大的发挥了链接脚本的作用,让我们可以对代码中的函数、数据进行归类操作,同时还可以完成一些在程序中不易完成的功能。这很容易理解,如果我们都用GCC内置的section,何必要自定义链接脚本,用默认的不就好了。
链接脚本向我们展示了大量的自定义section,本人水平有限,无法一一弄清每个section的用途,但通过几个常见的典型例子,我们可以了解它们的用法。首先就以text segment中的exception table举例。
此exception table不是用于处理硬件异常的(那是IDT表的工作),但它确实和硬件异常有一点关系,具体来说是和Page Fault有关系。Exception Table的具体机制在内核文档”Exception”中有详细介绍,你可以在/path_to_your_kernel_src/ Documentation/exception.txt中找到它。这里为了说明问题做一点简要介绍。
我们尊敬的Linus大神为了避免内核在访问用户态地址时进行有效性检查带来的开销(我们总是需要这样的检查,虽然大部分情况下结果是成功的),利用了page fault的处理函数来完成这项任务,这样只有在真正访问了一个坏的用户态地址时检查才会发生。或许你会问:此时检查有什么用?一个例子就很容易说明问题,假设我们有一个函数叫is_user_addr_ok(),用于检查传入的用户态地址是否合法。那么,当地址非法时它能干什么?什么都不能干,仅仅是告诉内核:“这是个非法地址,你不要访问”。这样便带来了个问题,让它在90%的时间里告诉内核:“这是个合法地址,去吧!”是件很无聊的事情。既然该函数对非法地址无能为力,我们干脆就什么都不要干,直到内核真访问到一个非法地址时再告诉调用者:“噢,抱歉,您访问到一个非法地址。”不管用哪种方法,调用者遇到非法地址最终结果都是获得一个错误码,但后者明显省下了对合法地址进行检查的开销。让我们来看看如何用自定义section完成这个任务。
如果你顺着copy_from_user()向下找几层,会看到__get_user_asm宏,该宏展开后可读性太差,我们用下面的伪代码来描述它:
1: movb (%from),(%to) /* 这里访问用户态地址,当地址非法时会产生一个page fault*/ 2: /*注意,后面的代码在最终的目标文件中不是跟在标号2后的*/ .section .fixup,"ax" 3: movl $ERROR_CODE,%eax xorb %dl,%dl jmp 2b .section __ex_table,"a" .align 4 .long 1b,3b
上面的伪代码描述了__get_user_asm宏的用途,它将用户态地址from中的内容拷贝到内核地址to。当from是个非法地址时,会产生page fault从而执行内核的do_page_fault(),在进行一系列检查处理后fixup_exception()被调用,该函数会调用search_exception_tables()查找exception table,将EIP设置成对应handler的地址并返回。至此该非法地址造成的错误就交由exception table中的handler处理了。
所有问题的归结到了exception table的建立和错误处理handler的设置。其实上面的伪代码已经告诉我们答案了。首先,标号”1”代表了可能产生page fault的EIP,当page fault产生时这个地址会被记录在struct pt_regs的ip字段中(不知道的看看do_page_fault()的参数);其次,标号”3”是错误处理handler的地址,很明显,它只是返回了一个错误码(EAX是x86的返回值寄存器)。jmp 2b跳到了产生page fault的指令的下一条指令继续执行。这里
.section .fixup,"ax"
创建了名为.fixup的自定义section,并将整个handler放入其中。标号”1”后的代码是位于.text section的,故你看到它们在源代码里写在了一起,但在目标文件中去是分开的,它们在不同的section。
好了,我们已经有了会产生错误的代码地址,也有了错误处理handler的地址,
.section __ex_table,"a"
将它们放到了自定义的__ex_table section中(.long 1b,3b),以如下格式存放:
出错地址,处理函数地址
内核用结构体struct exception_table_entry表示该格式,定义如下:
struct exception_table_entry {
unsigned long insn, fixup;
};
很明显,exception table的格式简单,表项的前4个字节是出错地址,后4个字节是处理函数的地址。下图展示了通过exception table解决一次访问用户态非法地址产生的错误。
怎样,所有的事实都清楚了。当在内核在不同位置调用copy_from_user()时,展开的__get_user_asm宏都会将可能出错的地址和处理函数的地址存入该源文件对应.o文件的__ex_table section中。链接脚本的如下代码:
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { __start___ex_table = .; *(__ex_table) __stop___ex_table = .; } :text = 0x9090
将分散的__ex_table收集起来产生一张完整的exception表,并将表的起始地址和结束地址记录在__start___ex_table和__stop___ex_table两个全局变量中,从而search_exception_tables()函数可以顺利的索引该表。
这种通过自定义section和链接脚本构造表的技巧被大量使用,后面我们还会看到两个例子。在此先告一段落。
前面提到内核image分为三个segment,其中就有note segment,它是包含在text segment中的。NOTE segment被用于不同的vendor在ELF文件中添加一些标识,让运行这些二进制代码的系统确定能否为该ELF提供其所需要的系统调用接口。它对我们了解内核用处不大,详细内容参见参考文献2。
NOTES :text :note
上面代码中,NOTE是一个宏,展开的格式和构建其它section的格式一样,这里”:text:note”表示把生成的section即加入text segment又加入note segment。从objdump的内容可以看到后者包含在前者之中,如下:
LOAD off 0x00001000 vaddr 0xc1000000 paddr 0x01000000 align 2**12 filesz 0x004de000 memsz 0x004de000 flags r-x NOTE off 0x0037b844 vaddr 0xc137a844 paddr 0x0137a844 align 2**2 filesz 0x00000024 memsz 0x00000024 flags ---