[原创] 写一个块设备驱动

OstrichFly

原帖由 Godbach 于 2008-12-9 22:10 发表
另外一个建议：由于LZ的八章内容是分散的，所以如果能在1楼把各个章节以及对应的位置标出来，也相当于个目录，那样大家参考起来更容易找。

谢谢建议！
有空我更新一下1楼。

OstrichFly

原帖由 2004sz 于 2008-12-11 11:45 发表
OstrichFly  大好人,多谢奉献

谢谢支持！
其实不光人好，还很帅很有品位呢: )

OstrichFly

原帖由 hb12112 于 2008-12-12 15:31 发表
期待中呵！

谢谢支持！

OstrichFly

+---------------------------------------------------+
|                 写一个块设备驱动                  |
+---------------------------------------------------+
| 作者：赵磊                                        |
| email: zhaoleidd@hotmail.com                      |
+---------------------------------------------------+
| 文章版权归原作者所有。                            |
| 大家可以自由转载这篇文章，但原版权信息必须保留。  |
| 如需用于商业用途，请务必与原作者联系，若因未取得  |
| 授权而收起的版权争议，由侵权者自行负责。          |
+---------------------------------------------------+

在本章中我们来讨论一下这个驱动程序的数据安全，
因为最近的一些事情让作者愈发地感觉到数据泄漏对当事人来说是麻烦的。

我们开门见山的解释一下数据安全问题：
内核常常会向用户态传递数据，而作为内核程序的开发者，我们必须意识到不能把包含意料内容之外的数据随便透露给用户态，
因为如果这些数据不巧被别有用心者利用，就会带来不少麻烦。
比如陈冠希就犯了这样的错误。新余市出国考察团也没有在陈冠希身上吸取教训，把单据也不当回事儿。
单据对于考察团而言并不是什么重要的玩意儿，但一旦落到“别有用心”的人手中被加以利用，就不得不当一回事了。
由此我们发现了单据的商业价值。
今后在旅游公司干过的员工拿着手头攒到的大量单据，可能会比KIRA更有前途。
因此公务员确实属于高风险职业，加薪也是情理当中的了。

对于内核而言，其中的数据也是如此。
即使一些数据对内核而言没有价值，但也不能随意地向用户态传递，因为这段内存中可能不巧包含了不能随意让用户获取的数据，
比如用户A使用linux整理他女友的裸照文件，裸照的数据很可能存在于用户A的进程的虚存中，也可能还存在于文件缓存中，
A的进程结束后，系统回收了进程的内存，这时内存中的数据被系统认定为无效数据，但系统并没有清空这段数据。
A打开的文件的缓存也类似，缓存被系统回收后，内存中的数据并没有被清除。
随后用户B使用了我们的块设备驱动程序。驱动程序初始化时需要获取足够的内存以存储块设备中的数据，
系统很可能将用户A使用过的那段包含裸照数据的内存分配给我们的块设备驱动程序。
这时如果用户B老老实实分区、创建文件系统、写入文件，这当然没事，
但如果用户B别有用心的上来就直接去读块设备中的数据，那么他可能很幸运的看到不该看的东西。

因此我们咬牙切齿，嫉妒心促使我们修改这个块设备驱动，我们都没遇到的好事儿，也决不允许用户B遇到。
修改的方法很简单，我们申请内存时使用了__get_free_pages()函数，
这个函数的第一个参数是gfp_mask，原先我们传递的是GFP_KERNEL，表示用于内核中的一般情况。
现在我们只要向gfp_mask中添加__GFP_ZERO标志，以提示需要申请清0后的内存。
这样驱动程序加载后，块设备中数据的初始值全为0，这就避免了上文中提到的安全问题。
详细来说，就是把alloc_diskmem()函数中的
p = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
这一行改成
p = (void *)__get_free_pages(GFP_KERNEL,

安全方面的改动已经完成了，但为了避免读者认为本章偷工减料，我们再多改一些代码。

块设备中每扇区的数据长度为512字节，我们在驱动程序经常遇到与此相关的转换。
为了快速运算，我们经常用到9这个常数，比如：
乘以512就是左移9、除以512就是右移9、除以512的余数就是& ((1ULL<<9) - 1)、
向上对齐到512的倍数就是加上(1<<9) - 1再& ~((1ULL<<9) - 1)。

不过现在我们决定通过定义几个宏来吧这些操作写得好看一些。
先定义：
#define SIMP_BLKDEV_SECTORSHIFT        (9)
#define SIMP_BLKDEV_SECTORSIZE        (1ULL<<SIMP_BLKDEV_SECTORSHIFT)
#define SIMP_BLKDEV_SECTORMASK        (~(SIMP_BLKDEV_SECTORSIZE-1))

然后使用这几个宏来进行扇区相关的转换工作。

详细来说，就是把simp_blkdev_make_request()函数中的：
if ((bio->bi_sector << 9) + bio->bi_size > simp_blkdev_bytes) {
改成
if ((bio->bi_sector << SIMP_BLKDEV_SECTORSHIFT) + bio->bi_size
        > simp_blkdev_bytes) {

dsk_offset = bio->bi_sector << 9;
改成
dsk_offset = bio->bi_sector << SIMP_BLKDEV_SECTORSHIFT;

把simp_blkdev_getgeo()函数中的：
geo->cylinders = simp_blkdev_bytes>>9/geo->heads/geo->sectors;
改成
geo->cylinders = simp_blkdev_bytes >> SIMP_BLKDEV_SECTORSHIFT
        / geo->heads / geo->sectors;

把getparam()函数中的：
simp_blkdev_bytes = (simp_blkdev_bytes + (1<<9) - 1) & ~((1ULL<<9) - 1);
改成
simp_blkdev_bytes = (simp_blkdev_bytes + SIMP_BLKDEV_SECTORSIZE - 1)
        & SIMP_BLKDEV_SECTORMASK;

把simp_blkdev_init()函数中的：
set_capacity(simp_blkdev_disk, simp_blkdev_bytes>>9);
改成
set_capacity(simp_blkdev_disk,
        simp_blkdev_bytes >> SIMP_BLKDEV_SECTORSHIFT);

如果运气不算太背的话，程序应该是能够运行的，让我们试试：
# make
make -C /lib/modules/2.6.18-53.el5/build SUBDIRS=/root/test/simp_blkdev/simp_blkdev_step09 modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-53.el5-i686'
  CC [M]  /root/test/simp_blkdev/simp_blkdev_step09/simp_blkdev.o
  Building modules, stage 2.
  MODPOST
  CC      /root/test/simp_blkdev/simp_blkdev_step09/simp_blkdev.mod.o
  LD [M]  /root/test/simp_blkdev/simp_blkdev_step09/simp_blkdev.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.18-53.el5-i686'
# insmod simp_blkdev.ko
#
看一看驱动程序刚刚加载时里面的数据：
# hexdump /dev/simp_blkdev -vn512
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 0000 0000 0000 0000 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0000 0000 0000 0000 0000 0000 0000 0000
0000090 0000 0000 0000 0000 0000 0000 0000 0000
00000a0 0000 0000 0000 0000 0000 0000 0000 0000
00000b0 0000 0000 0000 0000 0000 0000 0000 0000
00000c0 0000 0000 0000 0000 0000 0000 0000 0000
00000d0 0000 0000 0000 0000 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
0000100 0000 0000 0000 0000 0000 0000 0000 0000
0000110 0000 0000 0000 0000 0000 0000 0000 0000
0000120 0000 0000 0000 0000 0000 0000 0000 0000
0000130 0000 0000 0000 0000 0000 0000 0000 0000
0000140 0000 0000 0000 0000 0000 0000 0000 0000
0000150 0000 0000 0000 0000 0000 0000 0000 0000
0000160 0000 0000 0000 0000 0000 0000 0000 0000
0000170 0000 0000 0000 0000 0000 0000 0000 0000
0000180 0000 0000 0000 0000 0000 0000 0000 0000
0000190 0000 0000 0000 0000 0000 0000 0000 0000
00001a0 0000 0000 0000 0000 0000 0000 0000 0000
00001b0 0000 0000 0000 0000 0000 0000 0000 0000
00001c0 0000 0000 0000 0000 0000 0000 0000 0000
00001d0 0000 0000 0000 0000 0000 0000 0000 0000
00001e0 0000 0000 0000 0000 0000 0000 0000 0000
00001f0 0000 0000 0000 0000 0000 0000 0000 0000
0000200
#
对比一下修改前的效果：
# hexdump /dev/simp_blkdev -vn512
0000000 f300 0800 1200 0000 b804 1200 0000 0500
0000010 501a 6930 1806 246a bf0a 7700 256a bf0b
0000020 1f80 256b bf0b 47a0 266b bf0b 0ff0 246a
0000030 bf0a 1708 ffff 00ff 5028 256b bf0b 00a8
0000040 ffff 00ff 04b8 ffff 00ff 10c8 256b bf0b
0000050 00e8 246a bf0a 0229 ffff 00ff 1339 ffff
0000060 00ff 0059 246a bf0a 1669 ffff 00ff 12a9
0000070 256b bf0b 02c9 ffff 00ff 12d9 246a bf0a
0000080 215a ffff 00ff 302c 256b bf0b 03ac ffff
0000090 00ff 10cc 256b bf0b 03ec 246a bf0a 522d
00000a0 256b bf0b 32bd 2318 266b bf0c 2700 266c
00000b0 bf0c 2730 276c bf0c 1f60 276c bf0d 3580
00000c0 276d bf0d 1bc0 286d bf0d 05e0 286d bf0e
00000d0 04f0 ffff 00ff 07f5 276c bf0d 0186 ffff
00000e0 00ff 1596 276c bf0d 01b6 ffff 00ff 15e6
00000f0 266b bf0c 0708 266b bf0c 0018 ffff 00ff
0000100 0428 ffff 00ff 1038 266c bf0c 0058 ffff
0000110 00ff 3088 ffff 00ff 1219 266c bf0c 0239
0000120 ffff 00ff 1249 276c bf0d 0689 276c bf0d
0000130 02b9 266b bf0c 031c ffff 00ff 103c 266c
0000140 bf0c 035c 276c bf0d 039c ffff 00ff 20ac
0000150 276d bf0d 03dc 286d bf0d 03ec 266b bf0c
0000160 022d 266c bf0c 223d 276c bf0d 12ad 276d
0000170 bf0d 12cd 286d bf0e 02fd 2b18 286d bf0e
0000180 4400 296e bf0e 1450 296e bf0f 4470 2a6e
0000190 bf0f 14c0 2a6f bf0f 04e0 2a6f bf10 04f0
00001a0 ffff 00ff 2005 286d bf0e 1035 ffff 00ff
00001b0 5055 296e bf0f 0ab5 ffff 00ff 30c5 286d
00001c0 bf0e 1006 ffff 00ff 1426 286d bf0e 0946
00001d0 ffff 00ff 1056 296e bf0f 0176 ffff 00ff
00001e0 1186 296e bf0f 14a6 2a6e bf0f 05c6 ffff
00001f0 00ff 16d6 2a6f bf10 05f6 286d bf0e 0007
0000200
#

本章到此结束，读者是不是感觉我们的教程越来越简单了？

<未完，待续>

Godbach

LZ辛苦。

myem007

虽然没看懂，但是还是有支持下楼主！

scofield1025

非常感谢楼主的辛勤工作！ 强烈支持！

fishswimming

原帖由 OstrichFly 于 2008-12-3 22:20 发表
+---------------------------------------------------+
|                 写一个块设备驱动                  |
+---------------------------------------------------+
| 作者：赵磊                   ...

"我们的块设备驱动程序需要从伙伴系统中获得所需的内存。
目前的做法是每次获得1个页面，也就是分配页面时，把2的n次幂中的n指定为0。
这样做的好处是只要系统中存在空闲的页面，不管空闲的页面是否连续，分配总是能成功。
但坏处是增加了造就页面碎片的几率。
当系统中没有单独的空闲页面时，伙伴系统就不得不把原先连续的空闲页面拆开，再把其中的1个页面返回给我们的程序。"

为什么说每一次都申请单页会增加页面碎片？
比如我要分4次，每次申请1个单页，假如在第一次申请时候buddy系统order为0，1，2的连续空闲页面链表都是空的，那么只能拆开一个长度为8页的连续页面，但根据buddy系统的算法，这个8页的连续页面在返回一个页面后，被拆成了1，2，4，那我后面3次申请单页不正好是用掉了前面的1，2，剩下一个长度为4页的连续页面，这不是跟一次性的申请4个页面效果一样吗？

当然申请单页是先从cpu的单页缓存中分配的，我只是说这么个意思，还望楼主解答一下迷惑

hb12112

原帖由 OstrichFly 于 2008-12-12 21:08 发表
+---------------------------------------------------+
|                 写一个块设备驱动                  |
+---------------------------------------------------+
| 作者：赵磊                   ...

楼主好厉害呵，是感觉没之前那么大难度，不过数据安全确实是很容易忽略的问题。

lonelyair

受教，期待中