Re: Re: new module to check constant memory for corruption

[Andi Kleen <andi@firstfloor.org>]

> your question: there are no writes in this write protected adress range (e.g. kernel code).

It's actually not true, Linux changes r/o code. But you could
handle that by hooking into the right places.

> my idea is to calculate a checksum (xor is fastest) over this range and check later (periodically) if its unchanged.
> see source code download (5 KB): http://tauruz.homeip.net/ramcheck.tgz
> the code is working fine and the checksum is (as expected) constant (at least for many hours).
> 

So is the goal security or reliability or debugging?

Reliability:
I have doubts it makes sense for that. On most system the code
is only a very small part of the total memory. So you wouldn't
cover most data.

Also if something corrupts the code we likely already detect it
eventually by crashing. Your module would need to panic too in this
case.

Security: If someone can change the code what stops them from changing
the checksum module too?

Also if you use a poor (= fast) checksum it's likely easy to construct
a valid patch that does not change the checksum.

Debugging:
Maybe, but I have never seen a bug where code got corrupted.

The user program technique works reasonably well for finding bad
pointers. Write a program that allocates a lot of memory. Regularly
checksum and recheck all its memory.


-Andi