How to access(if possible) kernel space from user space?

How exactly is user memory and kernels memory differentiated inside the Linux kernel(in terms of giving security to kernel space)?

What are the different ways I can write in kernel address space from user space?

One way I know is through a system call. There are multiple system calls we can use, but at the end they are all system calls. Even in system calls, we send a data to kernel space, where it(driver or respective module) calls functions like copy_from_user() to copy data from user space to kernel space. Here we exactly are not writing into address space. we are just passing a user pointer which contains the data that needs to be copied into the kernel buffers.

My question is there any way we can access a physical address that is present in the kernel space and perform operations on it?

Second, Apart from system calls are there any other ways I can write into kernel space from an user application?

I referred to this link from stackoverflow. But I think my question is not answered there and is from different perspective. Hence I thought of asking a different question.

Please share your knowledge... Thanks.

Solution 1:

What are the different ways I can write in kernel address space from user space?

I'm not sure if there're other methods, but you can access physical memory using /dev/mem & system call mmap().

/dev/mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system. Byte addresses in mem are interpreted as physical memory addresses.

more on /dev/mem: http://linux.about.com/library/cmd/blcmdl4_mem.htm

more on mmap(): http://linux.die.net/man/2/mmap

You can use the mmap() to map a section of /dev/mem and use in your user program. A brief example code:

#define MAPPED_SIZE //place the size here
#define DDR_RAM_PHYS  //place the physical address here

int _fdmem;
int *map = NULL;
const char memDevice[] = "/dev/mem";

/* open /dev/mem and error checking */
_fdmem = open( memDevice, O_RDWR | O_SYNC );

if (_fdmem < 0){
printf("Failed to open the /dev/mem !\n");
return 0;
}
else{
printf("open /dev/mem successfully !\n");
}

/* mmap() the opened /dev/mem */
map= (int *)(mmap(0,MAPPED_SIZE,PROT_READ|PROT_WRITE,MAP_SHARED,_fdmem,DDR_RAM_PHYS));

/* use 'map' pointer to access the mapped area! */
for (i=0,i<100;i++)
printf("content: 0x%x\n",*(map+i));

/* unmap the area & error checking */
if (munmap(map,MAPPED_SIZE)==-1){
perror("Error un-mmapping the file");
}

/* close the character device */
close(_fdmem);

However, please make sure the area you are mapping is not used, for example by the kernel, or it will make your system crash/hang, and you will be forced to reboot using hardware power button.

Hope it helps.

Solution 2:

How exactly is user memory and kernels memory differentiated inside the Linux kernel(in terms of giving security to kernel space)?

Not sure if I understood your question.

To the kernel there isn't much difference technically, it's just memory. Why? Because the kernel, which is running in the most privileged CPU mode, can access all memory.

What are the different ways I can write in kernel address space from user space?

Unless there's a security hole in the kernel or kernel mode device drivers, you can't do that, at least not directly. The kernel (or one of its drivers) may, however, copy data from the user mode application's memory to the kernel memory.

... is there any way we can access a physical address that is present in the kernel space and perform operations on it?

Same thing, you should not be able to access memory using physical addresses if there's virtual to physical address translation present. Even the kernel itself cannot avoid this translation once it's enabled. It has to create appropriate virtual to physical address mappings in the page tables to access memory at arbitrary physical addresses.

Apart from system calls are there any other ways I can write into kernel space from an user application?

You can also force the CPU to switch to the kernel code by triggering an exception (e.g. division by 0, page fault, general protection fault, etc). The kernel is the first one to handle exceptions. The kernel will change its memory as needed in response to an exception. It may load data from somewhere (e.g. disk) on a page fault.