Messages in this thread | | | Subject | Re: [PATCH] 2.6.27: add a kernel hacking option to protect kernel memory between different modules | From | Valdis.Kletnieks@vt ... | Date | Mon, 03 Nov 2008 07:29:39 -0500 |
| |
On Sun, 02 Nov 2008 22:15:11 +0800, Pengfei Hu said:
> efficiency and simplicity. But now more and more embed application use > linux. In the traditional embed system, all the task run in kernel and > share the memory. Using kernel thread can immigrate these application > easily. So there will be many task run in the kernel.
So the target is embedded systems doing all sorts of stupid-crazy kernel thread tricks...
> + Change page table's present flag to prevent other module's accidental > + access. This results in a large slowdown and waste more memory, but > + helps to find certain types of memory corruptions.
And your solution is to create a large slowdown, which will just make them look for ways to make it go faster... perhaps including even *more* stupid-crazy kernel thread tricks?
Can you point at any bugs/failure modes that this patch would detect, but would *not* be found by any of the already-existing memory debugging tools?
Is it at all sane to expect that a reasonable setting can be done for things like slab and vmalloc? What happens when multiple modules allocate out of the same slab, or even worse, get vmalloc/kmalloc for *different* things on the same physical page? It seems that unless you can separate memory allocations by module, this isn't going to provide a lot of help in finding memory allocation/usage issues.
And I won't even *start* on all the data structures in the kernel that are shared across modules - do a 'cat /proc/slabinfo' or equivalent, and ask yourself how many of those you could tag as "private to module A", or "read/write by B, read-only by C, no-access by others".
You *really* don't want to re-invent the IBM MVS-style "GETMAIN/FREEMAIN SP=nnn" mess. Trust me on this one. ;)
[unhandled content-type:application/pgp-signature] | |