[Vm-dev] Stupidifying FFI/library loading mechanism

Igor Stasenko siguctua at gmail.com
Fri May 27 14:01:29 UTC 2011

On 27 May 2011 14:07, Andreas Raab <andreas.raab at gmx.de> wrote:
> On 5/27/2011 13:51, Igor Stasenko wrote:
>> On 27 May 2011 13:25, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>> On 5/27/2011 13:01, Igor Stasenko wrote:
>>>> On 27 May 2011 12:52, Andreas Raab<andreas.raab at gmx.de>    wrote:
>>>>> Then perhaps you can clarify what you mean by "I think we should trash
>>>>> too
>>>>> clever intrinsic library lookup mechanism and provide a simple
>>>>> primitive,
>>>>> which attempts to load a library by given file name&    path ". To me,
>>>>> this
>>>>> sounded as if you want to deliberately abandon implicit search paths on
>>>>> the
>>>>> platforms. If not, then I don't understand what is different compared
>>>>> with
>>>>> today (other than having better failure information with which I
>>>>> agree).
>>>> Clarification:
>>>> if search is implicitly managed by platform, then there's no problem.
>>>> (and actually you cannot trash this logic since it sits in platform
>>>> functions, and VM have to use these functions anyway).
>>>> But VM should not add its own implicit logic in addition to what
>>>> provided by platform.
>>> It seems to me that a good way to address the implicit logic is simply by
>>> by
>>> exposing (a list of) search paths to the image. In which case you can set
>>> the search paths to be as wide, or as narrow, as you'd like and the VM
>>> can
>>> list what additional search paths it would use by default, thus making
>>> this
>>> both forwards and backwards compatible.
>> Indeed.
>> In this way it is language side, are the only who responsible for
>> finding a library,
>> while VM could provide a hints , like default search paths, which are
>> most appropriate for current platform.
>> So, if we agreed on that, lets sketch the plan what we need to provide:
>> - extended error handling
>> - explicit module loading mechanism
>> - providing hints for library search by VM
> Almost :-) I really can't see a reason for requiring explicit module
> loading. Amongst other things it bloats applications (which will attempt to
> preload all libraries they might *possibly* need instead of those they
> *actually* need) and slow down system startup (for the same reason) or
> otherwise require people to write lots of either repeated code (as an
> example, just look at how many senders of Socket initializeNetwork there are
> all of which should be removed) or equally pointless extra primitive/ffi
> failure code. I can really see no good reason for requiring explicit loading
> other than ensure some library is available and that can be done with better
> error reporting.

No need for repetitious code :) It will require changes in
#primitiveFailed, or #primitiveFailedFor: errorCode on image side.
And of course it makes sense to introduce this only for VMs which can
use primitive error codes.

A primitiveFailed method could be changed to see if primitive failed
because module not yet loaded
and then it will try loading it and retry the primitive.
So, for most users of primitives it will behave as today: the failure
will be handled implicitly,
and seamlessly, except that implicit code are in image not in VM!

As for explicit module loading at image startup: it has own uses.
If you like to run in sandboxed mode, you must ensure that no other
modules could be loaded except those, which you know
that they are secure and should be there.
So, during startup you will load modules which you will use, and then
disable loading module mechanism for the rest of the session.
In that way a primitives which attempting to use non-registered
modules will fail.
And then a error handler in #primitiveFail, if it attempt to load such
module, it will receive an error: new module can't be loaded because
module loading mechanism is disabled.

And that's why i proposed to use explicit mechanism even for internal
modules, because some internal modules could contain
caveats which malicious code could exploit to destroy your sand castle.
And designers of sandboxed images could choose to prevent loading such
modules, because it could compromise the security.

So, it is also a future proof, because today we ship VMs with one set
of default internal modules, but tomorrow we may include some more.
But developers of sandbox mode images don't need to care of these new
additions and can feel confident, that their stuff will continue
working on new VM
as before, without compromising their security model.
(unless, of course there will be changes in existing plugins which may
open new security holes ;)

> Cheers,
>  - Andreas

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list