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