关于linux内核空间保护的问题
来源: 互联网 发布时间:2015-11-22
本文导语: 在网上看到一篇文章,择选如下: “看了LINUX代码,感觉其对内核内存的保护做得不是很好,还有感觉大家有些地方理解不对(主要是LINUX的代码看起来的样子和实际的样子不太一样),所以谈谈我对LINUX系统内核空间的保...
在网上看到一篇文章,择选如下:
“看了LINUX代码,感觉其对内核内存的保护做得不是很好,还有感觉大家有些地方理解不对(主要是LINUX的代码看起来的样子和实际的样子不太一样),所以谈谈我对LINUX系统内核空间的保护和用户空间与系统空间数据传递的代码看法.注意我说的都是I386体系结构,别的体系结构可以看相应的代码,不敢保证结果是否是如我所说.
LINUX建立进程的时候建立了两套段描述符,在文件Segment.h有说明.
#ifndef _ASM_SEGMENT_H
#define _ASM_SEGMENT_H
#define __KERNEL_CS 0x10
#define __KERNEL_DS 0x18
#define __USER_CS 0x23
#define __USER_DS 0x2B
#endif
一个用于内核代码,一个用于用户代码.运行内核代码的时候用内核的段描述符号就可以直接访问用户空间,但运行用户代码的时候用户段描述符不能访问内核空间,这是用的保护模式一些机制,具体代码不再介绍.不懂的就得看看介绍保护模式的一些书籍了.
在用户代码调用系统函数的时候,程序进入了系统内核代码,描述符也已经切换到了内核的描述符,这时可以直接访问用户空间或者内核空间,两者的参数数据传递也很简单,可以直接拷贝等。但看了LINUX代码的都知道,系统函数代码里面的用户空间与内核空间参数传递是没有这么直接拷贝的,那是为什么呢?大家想一想,用户调用的一些指针参数等,可以指向内核空间,如果不加以检测直接拷贝,那么用户空间代码就可以通过系统调用读写内核空间了,这显然是不准许的。所以内核代码里面就采用了统一的一些函数:
copy_from_user/copy_to_user和__generic_copy_from_user/__gerneric_copy_to_user等
,而在这些函数里面实现用户调用传递的指针合法性检测,用户参数提供的指针等不能指向系统空间,这样编写内核代码的时候只要调用这些函数就能实现了对内核空间的保护,编写也比较方便。这就提醒大家自己编写内核代码的时候,千万不要图方便直接用户空间与内核空间的参数拷贝,其实那些COPY函数并不是说用户空间与内核空间要怎么切换才能拷贝,这点我看很多人都没有真正的理解。”
想问的是:
“大家想一想,用户调用的一些指针参数等,可以指向内核空间,如果不加以检测直接拷贝,那么用户空间代码就可以通过系统调用读写内核空间了,这显然是不准许的。所以内核代码里面就采用了统一的一些函数: ”------即便能阻止用户空间通过一次指针访问内核空间,那么怎么能够防止通过二次、三次指针访问内核空间?
“看了LINUX代码,感觉其对内核内存的保护做得不是很好,还有感觉大家有些地方理解不对(主要是LINUX的代码看起来的样子和实际的样子不太一样),所以谈谈我对LINUX系统内核空间的保护和用户空间与系统空间数据传递的代码看法.注意我说的都是I386体系结构,别的体系结构可以看相应的代码,不敢保证结果是否是如我所说.
LINUX建立进程的时候建立了两套段描述符,在文件Segment.h有说明.
#ifndef _ASM_SEGMENT_H
#define _ASM_SEGMENT_H
#define __KERNEL_CS 0x10
#define __KERNEL_DS 0x18
#define __USER_CS 0x23
#define __USER_DS 0x2B
#endif
一个用于内核代码,一个用于用户代码.运行内核代码的时候用内核的段描述符号就可以直接访问用户空间,但运行用户代码的时候用户段描述符不能访问内核空间,这是用的保护模式一些机制,具体代码不再介绍.不懂的就得看看介绍保护模式的一些书籍了.
在用户代码调用系统函数的时候,程序进入了系统内核代码,描述符也已经切换到了内核的描述符,这时可以直接访问用户空间或者内核空间,两者的参数数据传递也很简单,可以直接拷贝等。但看了LINUX代码的都知道,系统函数代码里面的用户空间与内核空间参数传递是没有这么直接拷贝的,那是为什么呢?大家想一想,用户调用的一些指针参数等,可以指向内核空间,如果不加以检测直接拷贝,那么用户空间代码就可以通过系统调用读写内核空间了,这显然是不准许的。所以内核代码里面就采用了统一的一些函数:
copy_from_user/copy_to_user和__generic_copy_from_user/__gerneric_copy_to_user等
,而在这些函数里面实现用户调用传递的指针合法性检测,用户参数提供的指针等不能指向系统空间,这样编写内核代码的时候只要调用这些函数就能实现了对内核空间的保护,编写也比较方便。这就提醒大家自己编写内核代码的时候,千万不要图方便直接用户空间与内核空间的参数拷贝,其实那些COPY函数并不是说用户空间与内核空间要怎么切换才能拷贝,这点我看很多人都没有真正的理解。”
想问的是:
“大家想一想,用户调用的一些指针参数等,可以指向内核空间,如果不加以检测直接拷贝,那么用户空间代码就可以通过系统调用读写内核空间了,这显然是不准许的。所以内核代码里面就采用了统一的一些函数: ”------即便能阻止用户空间通过一次指针访问内核空间,那么怎么能够防止通过二次、三次指针访问内核空间?
|
举一个例子来说明:
用户态程序通过系统调用A进入内核,其中有两个参数,第一个是应用程序的全局指针变量B,指向它的一个数组空间,第二个是另一指针变量C,其值等于0xC0000020,这个系统调用的要求就是将B指向的空间的数据拷贝到C指向的空间,在应用层发出系统调用时,由于程序还未访问C指向的内存区,所以不会触发异常(C指向的内存区就是内核空间,因为它是大于0xC0000000的,也就是3G至4G的地址空间),进入系统调用时,此时为内核态,可以访问任何一个已被页表映射的地址,也就是包括内核态与用户态下的所有地址空间,如果相应的服务程序不对这两个参数进行合法性检查,就会将进程空间中的内容(B指向的空间)拷贝到内核空间(C指向的空间),这样就破坏了内核,也就是说达到了用户空间的函数去破坏内核空间的功能,这是操作系统设计所不允许的,所以在内核中的函数(包括驱动模块),绝不允许直接将用户空间传进来的指针直接操作,而必需进行合法性检查,也就是用copy_from_user/copy_to_user这些函数进行数据拷贝,只有当用户态传下来的参数是安全的(也就是它指向的空间一定是进程用户态空间),才能对其进行操作,这样才能保证用户态不破坏内核空间,当然,你要是在驱动模块中故意不使用这种方法,那是你的自由了,系统被破坏也就成了可能发生的事了!!!!当系统调用退出内核态进入用户空间时,进程再利用指针访问0xC0000000以上的内容,CPU立即触发异常,原因是上一回复中所说,这里不再详述。
还有一点要说的是:
在用户代码调用系统函数的时候,程序进入了系统内核代码,描述符也已经切换到了内核的描述符
这一句话不够精确,通过系统调用进入内核,此时的页目录与页表没有变化,CPU的权限发生了变化,堆栈段与堆栈指针发生了变化,其它的未发生变化
用户态程序通过系统调用A进入内核,其中有两个参数,第一个是应用程序的全局指针变量B,指向它的一个数组空间,第二个是另一指针变量C,其值等于0xC0000020,这个系统调用的要求就是将B指向的空间的数据拷贝到C指向的空间,在应用层发出系统调用时,由于程序还未访问C指向的内存区,所以不会触发异常(C指向的内存区就是内核空间,因为它是大于0xC0000000的,也就是3G至4G的地址空间),进入系统调用时,此时为内核态,可以访问任何一个已被页表映射的地址,也就是包括内核态与用户态下的所有地址空间,如果相应的服务程序不对这两个参数进行合法性检查,就会将进程空间中的内容(B指向的空间)拷贝到内核空间(C指向的空间),这样就破坏了内核,也就是说达到了用户空间的函数去破坏内核空间的功能,这是操作系统设计所不允许的,所以在内核中的函数(包括驱动模块),绝不允许直接将用户空间传进来的指针直接操作,而必需进行合法性检查,也就是用copy_from_user/copy_to_user这些函数进行数据拷贝,只有当用户态传下来的参数是安全的(也就是它指向的空间一定是进程用户态空间),才能对其进行操作,这样才能保证用户态不破坏内核空间,当然,你要是在驱动模块中故意不使用这种方法,那是你的自由了,系统被破坏也就成了可能发生的事了!!!!当系统调用退出内核态进入用户空间时,进程再利用指针访问0xC0000000以上的内容,CPU立即触发异常,原因是上一回复中所说,这里不再详述。
还有一点要说的是:
在用户代码调用系统函数的时候,程序进入了系统内核代码,描述符也已经切换到了内核的描述符
这一句话不够精确,通过系统调用进入内核,此时的页目录与页表没有变化,CPU的权限发生了变化,堆栈段与堆栈指针发生了变化,其它的未发生变化
|
DMA是设备访问内存,不是CPU访问内存,所以不存在“页保护异常”,也不存在访问级别,不通过MMU单元,而且访问的是物理地址,不经过段页式变换,LINUX将低于16M的一段地址空间保留未用(好像是15M至16M,具体记不得了),也就是让这段空间不存放任何内容,专门空出让DMA来访问,换句话说,DMA仅能访问这一段未使用的地址空间(硬件标准就是这样的,DMA是低于16M地址的),也就是说不会破坏掉内核区的其它内容,而对DMA的设置是通过设置外设寄存器来实现的,而对外设寄存器的访问依然要在内核态下完成(当然,用户态可以通过iopl这样的方式访问外设寄存器,这里暂不说),而且每申请一段DMA区地址,都需要向内核申请并登记,以便各种外设不冲突
如果非得要DMA去破坏内核,你就需要重做硬件,让硬件有通过DMA访问任何内存地址范围的能力,这就涉及到南桥芯片,主板,系统总线方面的内容了
如果非得要DMA去破坏内核,你就需要重做硬件,让硬件有通过DMA访问任何内存地址范围的能力,这就涉及到南桥芯片,主板,系统总线方面的内容了
|
看来LZ对LINUX的内存管理还不太清楚,才会有如此担心的!!!!
当用户通过系统调用进入内核空间时,使用的依然是当前进程所使用的页目录与页表,只是CPU工作的权限被提升为0级,所以内核态下CPU可以访问任何已被页表映射的空间,而用户态下的CPU是工作在3级,它只能访问权限被设为3级的页表所映射的页,若一不小心访问了权限被设为0-2级的页表所指向的内存区,CPU就会触发页保护异常,接着出现C程序员常见的“段错误”,所以无论你是1次,或是2次,N次访问没有权限的内存,都会以失败而告终
在X86下的LINUX,基本上将CPU的段式变换给置空了,也就是让它形同虚设,若光靠段式保护,完全可以在用户态下去破坏内核的东东,所以内存保护的最后一道防线就是“页保护”,这是不可逾越的
当用户通过系统调用进入内核空间时,使用的依然是当前进程所使用的页目录与页表,只是CPU工作的权限被提升为0级,所以内核态下CPU可以访问任何已被页表映射的空间,而用户态下的CPU是工作在3级,它只能访问权限被设为3级的页表所映射的页,若一不小心访问了权限被设为0-2级的页表所指向的内存区,CPU就会触发页保护异常,接着出现C程序员常见的“段错误”,所以无论你是1次,或是2次,N次访问没有权限的内存,都会以失败而告终
在X86下的LINUX,基本上将CPU的段式变换给置空了,也就是让它形同虚设,若光靠段式保护,完全可以在用户态下去破坏内核的东东,所以内存保护的最后一道防线就是“页保护”,这是不可逾越的