The details on loading rootkits via /dev/mem

"Thus it will surely segfault." -- Are you 100% sure about that?
Let's ignore for starters that the process doesn't segfault, the kernel OOPSes and the process is terminated with SIGKILL.
In fact, in reference to your assumption that the syscall table is read-only on x86, you're being fooled by the fact that it exists in the ".rodata" section of the kernel. The .rodata section isn't read-only at all, unless CONFIG_DEBUG_RODATA is enabled. Maybe it's the case that on your distro, that option happens to be enabled in the kernel. I just took a look at the kernel config for the latest Debian kernel. CONFIG_DEBUG_RODATA is disabled. It seems to be enabled however on RHEL/CentOS kernels. I haven't bothered to examine others.

Mr. Lineberry mentions that his technique doesn't work against RHEL, which is why he had to compile a custom kernel to demonstrate it. Note that I'm not praising Mr. Lineberry or his technique at all -- in fact his work is essentially plagiarized and provides nothing new (remove subtracting 0xc0000000 from virtual addresses and you have the exact same rootkit published in Phrack in 2001).

But you weren't purely talking about Mr. Lineberry's technique, as you made the blanket statement:
"To use /dev/mem or /dev/kmem, one has to find a way to change writable memory (which will be data and not executable code) in such a way that it will cause kernel to run a desirable code with predictable results. While the kernel lacks data constraints checks in most places (usually assuming that safe and verified code runs), it is not an easy task. At least not as easy as the authors make it sound."

This is just completely false and nonsensical. If for a given virtual address in kernelspace, it happens to be marked as read-only (so CONFIG_DEBUG_RODATA is enabled), it does not at all follow that it's impossible to write to the memory or that the attacker is stuck with only writing to "data and not executable code" so as to "cause [the] kernel to run a desirable code with predictable results". 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.

As for mmap checking and your definition of a "long time" I would simply refer you to my first post in this thread, which you must have glossed over.

In summary: do what I suggested initially and read the Intel manuals. Really. Or keep writing posts on the subject: I know of at least one rootkit author who's getting a kick out of them.

-Brad