safety model in D

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Nov 4 07:33:32 PST 2009


Don wrote:
> Andrei Alexandrescu wrote:
>> Don wrote:
>>> Andrei Alexandrescu wrote:
> 
>> module(safe) is not a comment. We need three types of modules because 
>> of the interaction between what the module declares and what the 
>> command line wants.
>>
>> Let's assume the default, no-flag build allows unsafe code, like right 
>> now. Then, module(safe) means that the module volunteers itself for 
>> tighter checking, and module(system) is same as module unadorned.
>>
>> But then if the user compiles with -safe, module(safe) is the same as 
>> module unadorned, and module(system) allows for unchecked operations 
>> in that particular module. I was uncomfortable with this, but Walter 
>> convinced me that D's charter is not to allow sandbox compilation and 
>> execution of malicious code. If you have the sources, you may as well 
>> take a look at their module declarations if you have some worry.
>>
>> Regardless on the result of the debate regarding the default 
>> compilation mode, if the change of that default mode is allowed in the 
>> command line, then we need both module(safe) and module(system).
> 
> When would it be MANDATORY for a module to be compiled in safe mode?

module(safe) entails safe mode, come hell or high water.

> If module(safe) implies bound-checking *cannot* be turned off for that 
> module, would any standard library modules be module(safe)?

I think most or all of the standard library is trusted. But don't forget 
that std is a bad example of a typical library or program because std 
interfaces programs with the OS.

>>> This actually seems pretty similar to public/private.
>>> I see three types of modules:
>>>
>>> module  : the default, should compile in -safe mode.
>>> module(system) : Modules which need to do nasty stuff inside, but for 
>>> which all the public functions are safe.
>>> module(sysinternal/restricted/...): Modules which exist only to 
>>> support system modules. This will include most APIs to C libraries.
>>>
>>> Modules in the outer ring need to be prevented from calling ones in 
>>> the inner ring.
>>
>> Well I wouldn't want to go any dirtier than "system", so my "system" 
>> would be your "sysinternal". I'd like to milden "system" a bit like in 
>> e.g. "trusted", which would be your "system".
> 
> Yeah, the names don't matter. The thing is, modules in the inner ring 
> are extremely rare. I'd hope there'd be just a few in druntime, and no 
> public ones at all in Phobos.

That sounds plausible.


Andrei



More information about the Digitalmars-d mailing list