[Vm-dev] Robust FFI with Memory Protection Keys

[tim Rowledge]

> On 06-08-2018, at 10:42 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>> On Aug 6, 2018, at 10:32 AM, tim Rowledge <tim at rowledge.org> wrote:
>> 
>> 
>> Surely the really safe way to do FFI type stuff is to have a separate memory space? The trick is how one achieves that.
>> 
>> I can think of a few ways to do that, some of which might even work...
>> - remapping (temporarily) the MMU entries to make only the directly involved FFI data area(s) visible
>> - similar but perhaps just making everywhere else read-only
>> - actually have a separate memory space that is shared to the vm
>> - a completely separate process
>> - hell, a completely separate computer!
> 
> While nice in theory this approach is useless in practice.  Many APIs we want to use are fundamentally about resources shared on some context (process, thread, API instance, etc) and involve sharing between the Smalltalk system and the external library.  Given that the relevant context is typically not shareable across different memory spaces then the approach is not generally useful.
> 

I get the problems. The interesting thing is that the problem is not unique to us, not by a long way. That means that we may have a chance of it being sorted (for certain definitions) as part of making OSs more secure. 
The biggest cost I see is the likelihood of it involving copying data to 'secured' locations where the FFI stuff can see it and the OS can manage it. But then we have the pinning stuff that can move an object to a particular space (IIRC) so maybe that wouldn't be too terrible a cost?
And how about Alien? Is there no way of having the alien data be 'secured' (for certain definitions etc etc)?
Sure, anything that requires copying data around is annoying and time consuming. But it's likely less annoying than having your image eaten by monsters from another dimension (aka buffer overflow bugs et al.) and certainly less time consuming than crashing, restarting and rebuilding.
For stuff that is really internal to the context of the running VM, sure; pain, not likely to work, stupid idea. And for anything really short-lived, way too slow.
Ah, if only MMUs could be told 'lock everything except this range, and this range, and that one' and do it adequately fast. ARM actually tried that for the 610 for the Newton, many years ago. I don't think it would fly nowadays.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Bad command or file name.  Go stand in the corner.