都知道的copy_from_user
2024-10-10 10:29:37
Q:一直知道内核和用户态的数据交互前都需要 校验地址的合法性,一般都用copy_from/to_user完成数据拷贝,那么为什么要这样呢??
A:看了一些blog以及Stack Overflow 主要说的是安全性:
Linux Kernel: How does copy_to_user work?
“Why can't you just call, say, memcpy? Two reasons.
“Why can't you just call, say, memcpy? Two reasons.
One, the kernel is capable of writing to any memory. User process's can't. copy_to_user needs to check dst to ensure it is accessible and writable by the current process.
Two, depending on the architecture, you can't simply copy data from kernel to user-space. You might need to do some special setup first, invalidate certain caches, or use special operations.
而内核可以访问任意内存。copy_to_user需要 通过当前进程来 检查目标的可写权限 (而用户 进程无法检查内核空间目标地址的 写权限 )
同时:检查指针所指的内存是否有效
设想一下:我们在写file_opeteration的write函数时:write(struct file *filp, const char __user *buf, size_t len, loff_t *ppos)/read(struct file *filp, const char __user *buf, size_t len, loff_t *ppos)
1、buf地址不合法
2、buf地址合法,内核还没有给它映射物理地址
3、如果buf是个一个内核地址, read的时候不就是内核到内核的拷贝么??
所以为了解决上述问题就有了copy_xx_user-----------
- 地址检查,不合法返回
- copy_xx_user 使用精心布置的访存汇编实现,并指这个汇编指令所在的地址全部登记起来(称为extable表)。出现2时------>会发生缺页异常,进入内核do_page_fault流程;然后检查出错的PC地址是不是早已在extable登记好的,如果是,同表示该缺页异常是copy_from_user/copy_to_user函数产生的。最后才检查该地址是否为该进程的合法地址,如果是则分配物理页并处理,否则就是非法地址,把进程给杀死(发送sigsegv信号)
顺便有几个疑问??参考:https://www.cnblogs.com/alantu2018/p/8527077.html http://www.mysixue.com/?p=114#33 这些blog写的详细
1、为什么会产生page fault?
2、发生缺页的上下文是否可以位于内核态
2、发生缺页的上下文是否可以位于内核态
有可能在内核态,但这种情况下,发生缺页的地址只能位于用户态地址空间,而且也只能为exceptions table中预先定义好的异常,如果exceptions table中没有预先定义的处理,或者缺页的地址位于内核态地址空间,则表示错误,进入oops流程。通常属于异常,会导致oops。、、-----copy_xx_user干的就是这事
/*
* If we're in an interrupt, have no user context or are running
* in an atomic region then we must not take the fault:
*/
if (unlikely(in_atomic() || !mm)) {mm 为空表示内核线程
bad_area_nosemaphore(regs, error_code, address);
return;
}
3、发生缺页的地址是否可以位于内核态地址空间----
有可能,发生缺页的内核态地址仅可能位于vmalloc区;在使用Vmalloc分配物理内存时,确实进行了映射,创建了页表项。
但是,其修改的仅为内核的主内核页表,并没有更新相关进程的页表;进程访问时,相关进程的页表中并没有Vmalloc分配内存相应的页表项,所以会触发page fault
//该分支表明发生缺页时是发生在访问内核空间时
if (unlikely(address >= TASK_SIZE)) {
//表示 代码是在内核态访问内核态不存在 的地址,转到vmalloc_fault处理分支,可能是访问了不连续的内核页面
if (!(error_code & 5))
goto vmalloc_fault;
//做相应出错处理
goto bad_area_nosemaphore;
}
关于内存管理文章见连接:
https://files.cnblogs.com/files/codestack/fp%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86.zip
1、内核页表中的内容为所有进程共享,每个进程都有自己的“进程页表”,“进程页表”中映射的线性地址包括两部分:
用户态
内核态
其中,内核态地址对应的相关页表项,对于所有进程来说都是相同的(因为内核空间对所有进程来说都是共享的),而这部分页表内容其实就来源于“内核页表”,即每个进程的“进程页表”中内核态地址相关的页表项都是“内核页表”的一个拷贝。
2、“内核页表”由内核自己维护并更新,在vmalloc区发生page fault时,将“内核页表”同步到“进程页表”中。以32位系统为例,内核页表主要包含两部分:
线性映射区
vmalloc区
其中,线性映射区即通过TASK_SIZE偏移进行映射的区域,对32系统来说就是0-896M这部分区域,映射对应的虚拟地址区域为TASK_SIZE-TASK_SIZE+896M。这部分区域在内核初始化时就已经完成映射,并创建好相应的页表,即这部分虚拟内存区域不会发生page fault。
vmalloc区,为896M-896M+128M,这部分区域用于映射高端内存,有三种映射方式:vmalloc、固定、临时,这里就不像述了。。
以vmalloc为例(最常使用),这部分区域对应的线性地址在内核使用vmalloc分配内存时,其实就已经分配了相应的物理内存,并做了相应的映射,建立了相应的页表项,但相关页表项仅写入了“内核页表”,并没有实时更新到“进程页表中”,内核在这里使用了“延迟更新”的策略,将“进程页表”真正更新推迟到第一次访问相关线性地址,发生page fault时,此时在page fault的处理流程中进行“进程页表”的更新:
最新文章
- SQL变量、Substring、charindex、case函数、去除重复
- Find the Duplicate Number
- jenkins2 javahelloworld
- maven_创建quickstart模板时异常
- JavaScript 获取客户端计算机硬件及系统信息
- iOS+JSPatch在线修改app功能-b
- Nuage SDN
- jquery ajax(5)form表单序列化
- 关于获得本机Mac Address的方法
- SQL Server 动态行转列(轉載)
- Memcached源代码分析 - Memcached源代码分析之消息回应(3)
- REST风格的服务
- SpringMVC 的重定向时,参数非法问题
- [转载]使用QTP测试Windows对象
- js获取html元素在可视区域的位置
- 从零开始学习cocoStudio(1)--cocoStudio是什么?
- Introducing GitFlow
- linux 设置用户自动登出时间
- springboot中url地址重写(urlwrite)
- 使用html+css+js实现魔性的舞蹈