开发者

How the user process can access the character device loaded by my module

开发者 https://www.devze.com 2023-04-10 10:22 出处:网络
I am trying to load into the kernel a system-call dynamically (without restarting the kernel and compailing it) in an attempt to (once in kernel mode) write to user process\'s memory.

I am trying to load into the kernel a system-call dynamically (without restarting the kernel and compailing it) in an attempt to (once in kernel mode) write to user process's memory.

(I know there is a way to do this with the ptrace interface but it is not an option.)

I know the only way to do this is to load a module. In order to allow the user communicating with it, i was told to use a character device (which is supposed to be in /dev/, right?). 开发者_开发问答I loaded one successfully. My problem is that i don't know how the user process access it without an system call. (i was told to use ioctl) Could anyone show how a user process can call ioctl for example that was loaded by my module?

Thanks, Shai


For the answer below, I have assumed you to be developing a Linux module. Upon rereading your question, I see I could have misinterpreted the problem.


There are several mechanisms for communicating with a kernel driver:

  • a /proc entry (aka procfs)
  • ioctl through the device interface
  • directly through the device interface

The most common technique is the last which uses read() and/or write() system calls to cause driver action. While these system calls ordinarily pass pure data, there is nothing stopping a particular driver from instead passing metadata through the i/o interface.

On the other hand, if the driver already has a useful pure data discipline for which read() and write() are not good for metadata, then the ioctl() system call is a kind of general purpose Swiss army knife for doing all kinds of things related to a file, such as loading or unloading a magnetic tape, ejecting a DVD, finding a network card's Ethernet address, or finding out how many disk drive errors have occurred. There have been so many ioctl operation codes defined, you can probably find a reasonable one to reuse for your purposes. A big disadvantage of the ioctl interface is that it is best suited for use by a custom program, so it would be awkward or difficult to transfer data through an ioctl connected to a pipeline of standard programs.

The /proc interface combines the best of the previous two techniques: it is amenable to using stdin/stdout conventions with standard utility programs, but it also provides an interface to a device driver which is independent of any i/o through the regular driver mechanism. For example, try cat /proc/net/tcp on your Linux system. It shows the status of all TCP connections.

A good article on implementing the procfs feature is at create_proc_entry(). Implementing an ioctl is well covered here. The metadata approach is as easy to code as any other device driver, though it might present conceptual hurdles for an experienced implementer.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号