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

[Esteban Lorenzano]

and I just fond a lot of other cases where it does not work. 
I think I will rever my change (with pinning) and think a bit further… it still remains the fact that same code in Alien side does not make any check at all… :(

Esteban

> On 08 Dec 2015, at 13:59, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> 
> 
>> On 08 Dec 2015, at 13:47, Esteban Lorenzano <estebanlm at gmail.com <mailto: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/4f071a20/attachment.htm