[squeak-dev] [UPD] NativeBoost runs on new Cog VMs

Igor Stasenko siguctua at gmail.com
Mon Mar 21 11:42:57 UTC 2011

On 21 March 2011 11:54, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 21.03.2011, at 03:12, Igor Stasenko wrote:
>> On 21 March 2011 02:43, Levente Uzonyi <leves at elte.hu> wrote:
>>> On Sun, 20 Mar 2011, Igor Stasenko wrote:
>>>> Hello,
>>>> i just wanna to inform you that i adopted NativeBoost plugin for
>>>> building with latest Cog vms.
>>> Great.
>>>> To build VM, you should have an image with VMMaker + CMakeVMMaker
>>>> packages installed.
>>>> Then load NBIntaller package and do:
>>>> NBInstaller installCogPlugin
>>>> There are new cmake configurations i added to build VMs with NB plugin
>>>> support.
>>> It's an old question, but I don't remember your answer, so: wouldn't it
>>> be better to add a command line switch for enabling NB? So even if a VM is
>>> compiled with NB, I can still turn it off if I want to.
>> It is disabled by default, when you starting a new image.
>> This allows me to not care if some of the methods were carrying native
>> code saved into an image.
>> For enabling a native code, one should invoke #primitiveEnable first.
>> You can customize a mechanism of enabling it in
>> NativeBoost class>>enableNativeCode
>> and put checking of command-line argument(s) there.
>> And yes, i am against putting extra logic at plugin side :)
>> The reason is simple: if you using it, then you know what you doing,
>> and if you don't - then you safe anyways.
> IMHO it's a good idea to not allow native code execution if the VM sandbox is enabled. Just like e.g. OSProcess checks the SecurityPlugin for this.

Bert, but you cannot state that your deployment are more secure just
because you are passing "right" command-line arguments to VM.
As i said before , if you want security for real, then you should
build own "sandboxed" version of VM, which simply having no way to use
such features.
Otherwise that's just a painting on the water pool.

> - Bert -

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list