Subject: Re: compartmentalization of kernel memory
To: None <tech-kern@netbsd.org>
From: Matthew Mondor <mmondor@gobot.ca>
List: tech-kern
Date: 04/08/2003 13:26:02
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.

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