[Vm-dev] Re: FFI memory access error and pinned

Esteban Lorenzano estebanlm at gmail.com
Tue Dec 8 12:59:24 UTC 2015


> On 08 Dec 2015, at 13:47, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> 
> Hi,
> 
> Some days ago I submitted a small change at ThreadedFFIPlugin>>#ffiAddressOf: rcvr startingAt: byteOffset size: byteSize
> 
> to restore a security level: 
> 
> 		"don't you dare to read from object memory (unless is pinned)!"
> 		(addr = 0 or: [(interpreterProxy isInMemory: addr) or: [(interpreterProxy isPinned: rcvr) not]])
> 			ifTrue:[^interpreterProxy primitiveFail].
> 
> if you remember, before (at the origin) that method was validating #isInMemory, but I took it out because it was making some test failing and because if found it incorrect. 
> Then, after talk with Eliot (and after I took some vacations in the middle), he suggested that internal object should be pinned, so I submitted the change you can see.
> 
> Now, the problem is now the test FFIPluginTests>>#testPointers fails because it returns a structure and we try to access its fields. 
> 
> Problem is solved if I edit the tests to add a pin:
> 
> FFIPluginTests>>#testPointers
> 	"Test passing and returning of pointers to structs"
> 	| pt1 pt2 pt3 |
> 	pt1 := FFITestPoint4 new.
> 	pt1 x: 1. pt1 y: 2. pt1 z: 3. pt1 w: 4.
> 	pt2 := FFITestPoint4 new.
> 	pt2 x: 5. pt2 y: 6. pt2 z: 7. pt2 w: 8.
> 	pt3 := FFITestLibrary ffiTestPointers: pt1 with: pt2.
> 	pt3 getHandle pin. “HERE THE CHANGE"
> 	self assert: pt3 x = 6.
> 	self assert: pt3 y = 8.
> 	self assert: pt3 z = 10.
> 	self assert: pt3 w = 12.

mmm… that change will not work on non-spur images :(

> 
> I will submit the change, but now I wonder (again) if forcing a pin is correct. 
> Of course, pinning it is safe because it prevents errors if object is moved… but well, I wonder :)
> 
> Esteban
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151208/9ea7e1d2/attachment.htm


More information about the Vm-dev mailing list