RE: where to start?

[Bryan Paxton <evil7@bellsouth.net>]

Exactly, please don't by shy to share your finding/ideas... Just do it
: )  Maybe you could be wrong on what you're doing or the idea you
have, but it could lead to a right idea in the same dept. or possibly
another. On the fly innovation : )


On Sat, 10 Jun 2000, you wrote:
> 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/
> 
> 
> Kernel-audit:  discussion list for security and the linux kernel
> Archive:       http://mail.nl.linux.org/kernel-audit/
-- 
Bryan Paxton

"How should I know if it works? That's what beta testers are for. I
          only coded it."
 -- Linus Torvalds.



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