On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff <gleb...@freebsd.org> wrote:

> On Thu, Nov 28, 2013 at 03:13:53PM +0000, jb wrote:
> j> > But I don't understand why you find ksize()/malloc_usable_size()
> dangerous.
> j> > ...
> j>
> j> The original crime is commited when *usable size* (an implementation
> detail)
> j> is exported (leaked) to the caller.
> j> To be blunt, when a caller requests memory of certain size, and its
> request is
> j> satisfied, then it is not its business to learn details beyond that
> (and they
> j> should not be offered as well).
> j> The API should be sanitized, in kernel and user space.
> j> Otherwise, all kind of charlatans will try to play hair-raising games
> with it.
> j> If the caller wants to track the *requested size* programmatically, it
> is its
> j> business to do it and it can be done very easily.
> +1
> This is kind of APIs that just shouldn't exist.
> --
> Totus tuus, Glebius.

Then again:  Using the "overflow" memory is only going to bite them if the
API lies : If the return value is exactly "the size of the block you got
allocated and can safely use until you free it", using it will per
definition be safe.  If the allocator later changes to, say, always
allocate exact byte ranges, or to allocating blocks but having the option
to fragment them later - then the return value would have to shrink to
match, and any program using it would still DTRT.

I'm completely ambivalent about adding it, though - it's not something I
need, it's more stuff that needs to be handled if you change/rewrite the
allocator, and it's not my decision.

Daniel Nebdal
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to