Re: [PATCH] 2.6.27: add a kernel hacking option to protect kernel memory between different modules

[Valdis . Kletnieks]

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. ;)

Attachment: pgp00000.pgp
Description: PGP signature