Linux内核空间保护和空间数据传递分析

最新推荐文章于 2024-07-07 08:53:25 发布

小牡蛎

最新推荐文章于 2024-07-07 08:53:25 发布

阅读量800

点赞数

分类专栏： Linux系统文章标签：内核

Linux系统专栏收录该内容

23 篇文章 0 订阅

订阅专栏

转载一

原文：http://www.linuxidc.com/Linux/2012-08/68271.htm 点击打开链接

一定要注意的是不能直接访问用户空间数据，内核代码可以通过特殊的函数来访问用户空间数据，copy_to_user copy_from_user这两个函数就是内核代码访问用户空间数据的函数，但是内核不能直接通过像是memcpy函数来直接操作用户空间数据。

按照linux设备驱动书本上的说法，我的理解，三个原因描述如下。

其一，驱动程序架构不同或者内核的配置不同，用户空间数据指针可能运行在内核模式下根本就是无效的，可能没有那个虚拟地址映射到的物理地址，也有可能直接指向一些随机数。

其二，用户空间的内存数据是分页的，运行在内核模式下的用户空间指针可能直接就不在内存上，而是在swap交换的其他存储设备上，这样就会发生页面错误。页面错误是内核所不允许的，会导致该进程死亡。

其三，内核代码访问用户内存指针，就给内核开了后门，用户程序可以利用这一点来任意的访问操作全部地址空间，这样内核就没有安全性可言了。

转载二

原文：http://www.west263.com/info/html/wangzhanyunying/jianzhanjingyan/20080417/69783.html 点击打开链接

看了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函数并不是说用户空间和内核空间要怎么转换才能拷贝，这点我看很多人都没有真正的理解。

我们再仔细看看那些COPY函数是怎么实现的内核空间保护呢。原来是在每个进程的进程数据结构里面保存了一个用户空间范围， current- >addr_limit，因为内核空间在用户空间上面，所以只要简单检测用户传递参数访问的空间是不是小于等于这个范围就是了。下面是相关的几个文档的相关内容。

　　　

            文档 uaccess：　　　　

            　#define MAKE_MM_SEG(s) ((mm_segment_t) { (s) })

            　#define KERNEL_DS MAKE_MM_SEG(0xFFFFFFFF)

            　#define USER_DS MAKE_MM_SEG(PAGE_OFFSET)

            　#define get_ds() (KERNEL_DS)

            // 取得内核空间范围

            　#define get_fs() (current->addr_limit)

            　// 取得用户空间范围

            　#define set_fs(x) (current->addr_limit = (x))

            　// 配置用户空间范围

            文档 processor.h ：

            　typedef struct {

            　unsigned long seg;

            　} mm_segment_t;

            　文档 page。h ：

            　include 　　　　　　　

            　#define __PAGE_OFFSET (PAGE_OFFSET_RAW)

            　#define PAGE_OFFSET ((unsigned long)__PAGE_OFFSET)

            　文档page_offset。h：

            　#include

            　#ifdef CONFIG_1GB

            　#define PAGE_OFFSET_RAW 0xC0000000

            　#elif defined(CONFIG_2GB)

            　#define PAGE_OFFSET_RAW 0x80000000

            　#elif defined(CONFIG_3GB)

            　#define PAGE_OFFSET_RAW 0x40000000

            #endif

            　// 这个显然能够配置用户空间和系统空间大小

大家看那get_ds()、get_fs()、set_fs()等函数可能不是您刚看到时想的那么一回事吧？他们看来好象是访问或配置段，其实只是访问或配置一个进程变量罢了。

您看那些COPY函数使得传递的一些参数只能是指向用户空间，那么内核代码对系统一些函数的调用怎么办呢，因为那时的参数都在内核空间里面呀。您仔细看看上面不是有个set_fs(x)调用吗，那就是配置这个用户空间限制的调用，只要临时配置用户空间限制为内核空间的范围，调用完了过后恢复就是了。您再看下面代码就对那几个set_fs()的作用清楚了吧。

<span style="font-size:14px;">->filename is in our kernel space
unsigned long old_fs_value = get_fs();
set_fs(get_ds()); /* after this we can access the user space data */
open(filename, O_CREAT|O_RDWR|o_EXCL, 0640);
set_fs(old_fs_value); /* restore fs... */</span>

好了，原理讲完了，代码大家也看明白了，我们再看看这种编程好不好呢？其实这种编程显然不好。缺点如下：

1、还没有形成统一的保护方式，对内核空间的保护不好。内核代码编程不注意的话就可能使得用户程式突破内核空间的保护。这点编写内核代码的同志一定得注意用户空间和系统空间的拷贝一定得用那些COPY函数，不要自己简单的直接拷贝。

2、内核代码对系统函数调用时配置用户空间限制不好。这点假如配置了哪个进程的用户空间限制还没有配置回去的时候假如进程用户代码得到运行(应该不太可能吧)那么就突破了内核空间限制。更有假如内核代码不注意忘了恢复用户空间限制那么也使得内核空间保护失效。

其实有好的办法，实现也很简单。就是用一个内核全局变量保存用户空间范围，这个启动的时候根据配置计算好，内核调用的时候能够很方便的引用这个变量对用户代码的调用参数实现检测，用另一个内核全局变量来区分程式是在内核态还是用户态运行，假如在内核态再调用系统函数就能够不用检测系统调用的参数是在内核空间还是用户空间。这样就能够避免修改那个全局变量的麻烦。