"There are a number of different approaches, but the most obvious is to simply modify the page table entry associated with the virtual address the attacker is attempting to modify. To do this, a review of the code of set_pte_vaddr and the exported swapper_pg_dir symbol would be of use. If you actually knew as much as you think you know, I wouldn't have to generate these scenarios for you."
This is what I meant when I wrote in my first post:
"Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable. There are even (usually un-exported but obtainable via System.map or /proc/kallsyms) kernel functions that will do it for you. Using module interface is much more practical to achieve the result described in the article."
Or are you claiming that you know of a "trick" to change page tables permissions by using io on /dev/mem (without mmap)?
I do not think /dev/mem has much longer to live. The drivers (Xorg) are encouraged to use /sys/.../resource files to map what they need and the need for /dev/mem will be eventually gone.
Posted Apr 23, 2009 12:52 UTC (Thu) by spender (subscriber, #23067)
[Link]
You keep revising what you "meant" to say (forgetting the self-sufficient sentences that are just factually wrong, which no ex post facto revising can fix), and again your revisions are completely wrong.
You say "Of course if module interface is available, one can load a malicious code that can set arbitrary memory as both writable and executable."
Wrong again; module support isn't necessary to set arbitrary memory as both writable and executable. And yes, it can be done purely with read() and write() on /dev/mem as I've already said. You can call it a "trick" if you like, but if you did the reading I suggested it would be simply "textbook behavior."
Since you're clearly unwilling to educate yourself, there's no point really in wasting any more time with this.