[ANN] malloc'd ByteArrays

[Brian Rice]

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

On Dec 13, 2005, at 9:10 AM, Todd Fleming wrote:
> Brian Rice wrote:
>> 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?
> I have an idea, but it depends on one thing: is there a way to  
> limit slot, method, and primative access so that only approved  
> methods can read, write, or call them?  I guess this is what  
> Subjective Dispatch will help with.

Right now, there's no way to limit access. Even subjective dispatch  
can be bypassed - it simply makes it easier to use other security  
mechanisms while appearing transparent to the user.

The critical thing would be a security auditor, probably built into  
the compiler or a compiler variant. This is a big project, and I  
don't have anything set up for this yet, just a bunch of vague ideas  
I've collected over time.

> If so, we could limit the primitives that malloc, free, read, and  
> write memory so that they only may be called by the wrapper  
> methods.  The wrapper methods would provide a public way to get the  
> pointer value (for plugins), but wouldn't provide a way to set the  
> pointer value.  The wrapper methods would check bounds before  
> calling the primitives.

Right, that's a good start, much like E capabilities, and the  
possibility of this has been an influence on Slate's coding style and  
organization. Still, I haven't spent enough time figuring out the  
details. Perhaps Kevin Reid can weigh in on this, being most familiar  
with E and Common Lisp / Slate.

> There is a similar hole in the Cairo wrapper that needs plugging; I  
> don't know how to prevent the user from modifying the wrapper's  
> pointer values.  This could cause Cairo to clobber arbitrary memory.

Well, the situation is that an attack on the Slate system depends on  
re-compiling sources right now. I think that as long as we can limit  
possible avenues of attack to that, then we're ok.

BTW, you are right about ExternalLibrary's holding pointers being a  
problem, since we are passing function pointers around in mutable  
arrays (not that immutability would help much, since we can call the  
API with other arrays). You are also right about the arbitrary limits  
being a design problem for Slate. So here's my proposition after some  
thought: Why not use the malloc module to drive the tables, and use  
realloc() for re-sizing?

It's still an idea just forming, but it seems that we could remove  
our static limits by re-organizing the VM C sources around it.

>> 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. ;)
>
> Oooh, nice!

It's still annoying that I have to load a module to get these,  
considering that the ExternalLibrary and malloc interfaces could  
benefit from them. So I may wind up duplicating or migrating that  
code into the VM... we'll see.

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

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

iD8DBQFDnxh4PVkAvLW1zf4RAiimAJ9IsV9RqWH/khgnq8dIkLLBHAeBOACgqvoM
JM1Ps320YRMGzOZ3NrXmcbg=
=5ngp
-----END PGP SIGNATURE-----