lkml.org 
[lkml]   [2008]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] 2.6.27: add a kernel hacking option to protect kernel memory between different modules
From
Date
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]
\
 
 \ /
  Last update: 2008-11-03 13:33    [W:0.034 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site