Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

BTW: write_cr0(read_cr0() | 0x10000)

is a absolute no-go. It's a nice and funny kernel module but it dooms the kernel's security.



For the uninitiated, cr0 is a control register in the x86 family of processors. Bit 16 of that register is (according to wikipedia) WP - Write protect: Determines whether the CPU can write to pages marked read-only.

What this means is that the kernel can no longer see if a user is writing to a read-only location, which is a major part of memory protection. It has major security implications. I don't know whether other parts of the kernel enable or disable this at context switches or at other times.

What this also means is that this kernel module will only work on x86 CPU's. So no rickrolling you ARM boxes or smartphones.


> What this means is that the kernel can no longer see if a user is writing to a read-only location, which is a major part of memory protection.

No, disabling WP in CR0 is only relevant for privileged code. Writes to write protected pages in user mode will still trap. It might mess up some in-kernel COW stuff though.


If we could take CR0 et al manipulations away from module authors, we'd do it long ago. Sigh...


This is why I avoid out-of-tree modules. At least someone had to glance over the in-tree module before I run it on my machine. When you download random kernel modules from the Internet, they're probably from people too lazy to have their code properly reviewed. And if they're too lazy to have their code reviewed, they probably don't feel too bad about disabling all page write protection, either.


Can you name such a module?


Not sure why it's needed, too. It could also restrict the rw/ro toggle to the init_rickroll and exit_rickroll functions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: