Odd .....

Matthew Carpenter matt
Mon Jun 19 08:22:16 PDT 2006


On Friday 16 June 2006 14:47, Ben Duncan wrote:
> Actually, It's a "way to beat the system" that lead me down this path.
> My MVISAM has to somehow use DYNAMIC allocations for NODE stuff for
> variable length keys in the key pair portion of a NODE structure.
>
> SO, I cheat, I define my node as a 36 byte structure, last
> 4 bytes being a char Key_Pair [4] and "voile", malloc
> a structure using 2048 (or whatever the NODE page size is defined).
>
> This allows me to eventually, go back and tune dynamically, using
> different node sizes (of course there has to be a "re-build" of the
> database file to accomplish this). And all this cna be contained
> in Super Block information.

You crazier than I am, and that's sayin' somethin.  :)  (respectfully stated)

> Anyway, I was trying to figure out if there is a way to prevent
> someone from going beyond my malloc'd NODE size when adding
> key value items.

There are several approaches to bounds checking, as several others have 
listed.  Some will not cover what you are talking about, however.  A good 
deal of heap buffer protection is geared towards detecting a buffer overflow. 
These protections will create a cookie, or a "canary" which sits at the end of 
a buffer.  Validation then takes place to make sure the canary is still 
there, or the cookie (which is dynamically generated) is still valid.  Simply 
pointing past a buffer and writing into it doesn't trigger these mechanisms 
since you are likely not changing the cookie or canary.
>
> Don't want some nube hacking my C code and them not knowing WHAT I
> am doing, or what THEY are doing either, now do we ?

I would recommend best practices, as the technical solutions add both latency 
and a false sense of security.  
* Limit the code-points where the data is directly accessed.  
* Document the crap out of the "correct" process for accessing the data
* Check boundaries in that section of code that directly touches the memory 
structures
* Fuzz your applications to find holes you didn't know about.
* Peer code review, or at least *some* kind of code review :)

Some Linux distros already do stack-protection and heap-protection.  However, 
these techniques have their own weaknesses and ambiguities.  Nothing can 
fully overcome mistakes in code.

Hope that helps,
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.linux-sxs.org/pipermail/linux-users/attachments/20060619/c7a4bed5/attachment.pgp 



More information about the Linux-users mailing list