On Thu, 8 May 2003, Kamal R Prasad wrote:

> On Mon, 7 Apr 2003, Kamal R Prasad wrote:
>
> >First off, please leav a blank line between quoted text and where you
> >start your response. Otherwise it's rather hard to see where the quote
> >stops and your answer starts.
>
> pardon me on this one. I am having some problems with my email reader.

No problem.

> > Second, how much will that help? Yeah, for the first bad write you can
> > say, you're writing to memory that should have been a FOO, but once the
> > first write happens, you can't say much.
> > I mean that's the whole problem we have now; we can't identify that first
> > bad write. We only know something's wrong when the kernel dies and memory
> > all looks like garbage. Since there can be multiple bad writes in a row,
> > how can you say what this will tell you?
>
> exceptions are not trigerred on the first (bad) write -true. further, if
> the exception handler is in the same address space as the kernel, it may
> not be able to function properly once the entire address space is
> suspect/messed up.
> The only way out (to improving stability) is to inhibit bad memory access
> through some means.
> we can create bounds on the addresses that a particular module inside the
> kernel is
> allowed to access. This is possible if modules within the kernel (eg:-
> device drivers/networking stack etc) malloc() and use only data structures
> specific to them ie they will not have to access data structures malloc
> ()'ed by other modules. In practice, this may not be possible because they
> may have to access some generic data structures too -but we can isolate
> such accesses. (if we can move drivers from kernel-space to user-space that
> would also have sufficed- because a a bad pointer access in a user-space
> driver will not bring the whole system down.)

Drivers in userland is slow. You'd end up adding two or more context
switches per driver use.

The big problem with the "malloc in an area" stuff you're talking about is
that it's a cooperative thing, yet we're talking about an uncooperative
problem. :-)

There are other things you can do too. Like use the pool allocators and
add a generic routine to see if a given pointer is in a given pool. Or
keep two copies of the pointers your driver mallocs, and compare them.

Take care,

Bill