RE: where to start?

[Dave Jones <dave@denial.force9.co.uk>]

On Sat, 10 Jun 2000, Mathijs Mohlmann wrote:

> Which brings me to my next question. How far should we go? 
> Imagine a function that just can't take a null pointer as
> argument. Every caller checks to make sure that no null 
> pointer is passed. Should we introduce in extra sanity check
> in that function to make absolutly sure? If we do that we
> prevent a lot of future bugs from happening. On the other 
> hand we can forget about mainstream kernel inclusion.

What you have to be aware of, is that some of the functions
allow NULL inputs and perform in slightly different ways.
As code gets more documented, this will become easier.

As an example, I recently made a patch that added a check
to kmalloc() for 0 byte allocations. When I booted the
kernel, I got messages every second from select()
allocating 0 bytes.  What I didn't know is that it's
perfectly valid (though aparently non-sensical) for
kmalloc to allocate 0 bytes. It actually returns a ptr
to a mem area where you can store 0 bytes :)

I think this was a perfect case of someone who didn't
really know what he was doing having what he thought
was a good idea.  Sometimes this pays off, but not
always, but don't be afraid to share results.
I think the important thing is that even if your
findings turn out to be wrong (as mine were in this
case), that the code is checked.


For the curious, a patch to find out who called a function
with 'invalid' arguments looks like this..

+   if (size==0) {
+       printk("DEBUG: kmalloc() called with size==0 !! caller=%p\n",
+           __builtin_return_address(0));
+   }

This will print out a hex address for the caller.
You can look up the nearest match in System.map to
find the function name.


regards,

-- 
Dave.


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/