I think Linux uses something similar to at least some of what you
describe....

 --- Matthew Mondor <mmondor@gobot.ca> wrote: > 
> Hmm since kernel space runs under the same MMU context I also see
> that
> self-memory protection can become tricky... There is a system which I
> used when writing Xisop (a microkernel which does not support MMU and
> can run on a plain motorola 68000) which allowed to perform some
> basic
> sanity checking on key system structures which are generally
> referenced
> by address/pointer...
> 
> It uses a magic "cookie" which each special system structures which
> can
> be accessed using pointers have. This only consists of a unique
> number
> which is initialized when such an object is created/allocated, and
> set
> to zero when it is destroyed/freed. This allowed some critical code
> sections
> (i.e. message queuing to a port by port address and message address)
> to
> first verify if the pointer is non-null (it also would be possible to
> perform boundary checking there), and then make sure that the cookie
> corresponds to the expected value.

I think Linux also uses a similar technique in protecting data
structures: either the end or beginning (or both) ends of a structure
are  marked by values when debugging options are selected. In this way,
I think they can detect when such structures have been corrupted by
errant pointers (but not the exact moment this occured obviously).
Seems like a useful practise if they in fact do it: would such a
feature be an aid in debugging the NetBSD kernel?

> 
> Another aspect was that for instance the system had to never attempt
> to
> reply to a message via a message port which may not belong to the
> expected
> task (as the task may have died and it's memory recycled to allocate
> another
> task, same for ports)... Then for instance each task has a unique
> identifyer
> which is only generated by bumping a global counter and assigning
> it's
> new value to the object in question, making sure to prevent race
> conditions,
> and it allows to first verify port address validity using the
> previously
> mentionned technique, and then make sure that the port taskid
> corresponds
> to the unique task id... and then only attempt to queue the message.
> 
> Using such simple methods did not significantly slow down the code,
> neither
> did it make it grow too much, and it works within the same MMU
> context...
> When an object validity is questionned a debugging message can be
> output
> without the operation actually being performed thus reducing memory
> corruption
> 
> I'm not sure if this consists of what is needed, but I thought it
> would be
> worth describing the idea... So to use those an headerfile was
> created with
> various macros and unique cookie definitions to validate/unvalidate
> objects,
> associate an object to another and verify object association
> integrity,
> as simple as that... Not that it can fix everything, but it helped to
> make
> more stable a kernel which was inherently missing hardware assisted
> protection.
> 
> Matt
>  

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca