[ANN] malloc'd ByteArrays

[Brian Rice]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Dec 12, 2005, at 8:24 PM, Todd Fleming wrote:
> Brian Rice wrote:
>> I don't want to give the Image a pointer for safety reasons, and  
>> also  because it's a pain to have to deal primarily with 32-bit or  
>> 64-bit  pointers in tagged-pointer space. There's also two words  
>> of header  overhead for every such value in the image.
>
> ExternalLibrary already exposes raw pointers (stored in byte  
> arrays); it's up to libraries such as cairo.slate to encapsulate  
> them.  In this case, memoryarea.slate would encapsulate the raw  
> pointer values and external interface libraries such as cairo.slate  
> should be the only ones to use those values directly.  2 words of  
> overhead doesn't seem that bad; malloc.c has 2 words of overhead  
> per block anyway.

ExternalLibrary doesn't give you direct access to manually-allocated  
memory, however, so the fact that a pointer is returned is  
immaterial. I guess what I'm saying is that I object to the  
possibility of derefencing arbitrary parts of a malloc()'d area or  
areas outside what's been allocated.

So, this does not remove the limit on malloc()'d areas in my mind,  
since part of the point of these handles is to make sure that the  
Image doesn't cause an invalid memory access, or worse, overwrite  
other places in the valid heap area, and crash the whole system. I  
don't see how your proposal lets me remove those arrays without  
security repercussions.

Remember that I'm not just thinking of your code, but of your code's  
security against other code. What protects the system from side  
effects that alter a direct-pointer handle and accessing arbitrary  
memory? A malloc plugin is NOT a trivial security issue. The entire  
thing is written to avoid buffer overflows. Do you have suggestions  
to keep the VM safe from image-side code and yet allow unlimited  
malloc() usage?

> Brian Rice wrote:
>> Ideas? Suggestions? Do you have a patch I can apply? :)
>
> It would be easy on me if there was a function to retrieve the  
> pointer value as a byte array, since ExternalLibrary expects it.

Yep, that's what I was going to offer. The only reason for my delay  
was the lack of an idiom that appealed to me, and the fact that I  
spent most of this time debugging it. I still don't have an idiom for  
that; here is the first that occurs to me:

MemoryArea addressAt: index

You'll notice that I had also added bytesPerWord and Platform  
endianness primitives to the platform plugin, entirely with this in  
mind. Give me some credit. ;)

> If you're interested, I could code up something similar to what you  
> did as a plugin tomorrow night as an alternative (seems easier than  
> primitives).  It would use the approach that I'm promoting (direct  
> pointers, no quantity limits).

I don't want it to be in a plugin, since the ExternalLibrary  
primitives are also in the VM, and this is an ANSI C feature anyway.  
I'll code this up myself.

I absolutely refuse to admit code that just deals in direct pointers  
without VM checks, on the grounds that the ability to crash the VM in  
a million different ways is not something I want to introduce. If you  
can present a way to do this that does not introduce big security  
concerns, I'd love to hear it, but all I'm hearing right now is your  
impatience and limited perspective on what's at stake here clouding  
your judgement.

Aside: I simply posted this extension looking for feedback on the  
remaining bugs. I got no feedback on that and instead got a lot of  
impatient niggling over the feature that's trivial; I find that  
unpleasant. Just try to be more patient, okay? It won't kill this  
project if it takes another couple of days to make the FFI more  
powerful. :)

- --
- -Brian
http://tunes.org/~water/brice.vcf

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDnlntPVkAvLW1zf4RAti3AJ9jxXHS3esw3oXgviG4TYDAi25nhACdHZii
t2xqLwpcchkMQ+uOxNdiznk=
=IjMv
-----END PGP SIGNATURE-----