Don wrote:
> Andrei Alexandrescu wrote:
>> 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
>>>>
>>>> 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.
>
> I think it's not so atypical. Database, graphics, anything which calls a
> C library will be the same.

I still think the standard library is different because it's part of the
computing base offered by the language. A clearer example is Java, which
has things in its standard library that cannot be done in Java. But I
agree there will be other libraries that need to interface with C.

> For an app, I'd imagine you'd have a policy of either always compiling
> with -safe, or ignoring it.

I'd say for an app you'd have a policy of marking most modules as safe.
That makes it irrelevant what compiler switch is used and puts the onus
in the right place: the module.

> If you've got a general-purpose library, you have to assume some of your
> users will be compiling with -safe. So you have to make all your library
> modules safe, regardless of how they are marked. (Similarly, -w is NOT
> optional for library developers).

If you've got a general-purpose library, you try what any D codebase
should try: make most of your modules safe and as few as possible system.

> That doesn't leave very much.
> I'm not seeing the use case for module(safe).

I think you ascribe to -safe what module(safe) should do. My point is
that -safe is inferior, just some low-level means of choosing a default
absent other declaration. The "good" way to go about it is to think your

Andrei

Jesse Phillips wrote:
> Andrei Alexandrescu Wrote:
>
>> Jesse Phillips wrote:
>>> On Tue, 03 Nov 2009 23:13:14 -0600, Andrei Alexandrescu wrote:
>>>
>>>>> I think the only real option is to have the importer decide if it is
>>>>> trusted.
>>>> That can't work. I can't say that stdc.stdlib is trusted no matter how
>>>> hard I try. I mean free is there!
>>> I would like to disagree here.
>>>
>>> void free(void *ptr);
>>>
>>> free() takes a pointer. There is no way for the coder to get a pointer in
>>> SafeD, compiler won't let them, so the function is unusable by a "safe"
>>> module even if the function is imported.
>> Pointers should be available to SafeD, just not certain operations with
>> them.
>>
>> Andrei
>
> I must have been confused by the statement:
>
> "As long as these pointers are not exposed to the client, such an implementation might be certified to be SafeD compatible1 ."
>
> Found on the article for SafeD. I realize things may change, just sounded like pointers were not ever an option.

Yes, sorry for not mentioning that. It was Walter's idea to allow
restricted use of pointers in SafeD. Initially we were thinking of
banning pointers altogether.

Andrei

Andrei Alexandrescu wrote:
> jpf wrote:
>> You may want to have a look at the CoreCLR security model (that's used
>> by silverlight / moonlight). It's quite similar to what you've proposed.
>> http://www.mono-project.com/Moonlight2CoreCLR#Security_levels
>
> I don't have much time right now, but here's what a cursory look reveals:
>
> ====================
>  Security levels
>
> The CoreCLR security model divide all code into three distinct levels:
> transparent, safe-critical and critical. This model is much simpler to
> understand (and implement) than CAS (e.g. no stack-walk). Only a few
> rules can describe much of it.
> ====================
>
> The keywords "security" and "stack-walk" give it away that this is a
> matter of software security, not language safety. These are quite
> different.

What i wanted to refer to are the levels "Transparent", "Critical" and
"Safe Critical", which work exactly as "safe", "system" and "Yeah, I do
unsafe stuff inside, but safe modules can call me no problem". The
implementation and use case might be different, but the meaning is the
same. There's nothing unique in the .net implementation, I just though
you may want to have a look at how others solved a similiar problem.

Andrei Alexandrescu wrote:
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> module(safe) susie;
>
> This means susie commits to extra checks and therefore only a subset of D.
>
> module hobbes;
>
> This means hobbes abides to whatever the default safety setting is.
>
> The default safety setting is up to the compiler. In dmd by default it
> is "system", and can be overridden with "-safe".
>
> Sketch of the safe rules:
>
> \begin{itemize*}
> \item No @cast@ from a pointer type to an integral type and vice versa
> \item No @cast@ between unrelated pointer types
> \item Bounds checks on all array accesses
> \item  No  unions  that  include  a reference  type  (array,  @class@,
>   pointer, or @struct@ including such a type)
> \item No pointer arithmetic
> \item No escape of a pointer  or reference to a local variable outside
>   its scope
> \item Cross-module function calls must only go to other @safe@ modules
> \end{itemize*}
>
> So these are my thoughts so far. There is one problem though related to
> the last \item - there's no way for a module to specify "trusted",
> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
> no problem". Many modules in std fit that mold.
>
> How can we address that? Again, I'm looking for a simple, robust,
> extensible design that doesn't lock our options.
>
>
> Thanks,
>
> Andrei

Not sure if this is the right topic to say this but maybe D needs monads
to allow more functions to be marked as pure. Then functional could be
added to the list of paradigms D supports and will also be safer.

Tim Matthews wrote:
> Andrei Alexandrescu wrote:
>> SafeD is, unfortunately, not finished at the moment. I want to leave
>> in place a stub that won't lock our options. Here's what we currently
>> have:
>>
>> module(system) calvin;
>>
>> This means calvin can do unsafe things.
>>
>> module(safe) susie;
>>
>> This means susie commits to extra checks and therefore only a subset
>> of D.
>>
>> module hobbes;
>>
>> This means hobbes abides to whatever the default safety setting is.
>>
>> The default safety setting is up to the compiler. In dmd by default it
>> is "system", and can be overridden with "-safe".
>>
>> Sketch of the safe rules:
>>
>> \begin{itemize*}
>> \item No @cast@ from a pointer type to an integral type and vice versa
>> \item No @cast@ between unrelated pointer types
>> \item Bounds checks on all array accesses
>> \item  No  unions  that  include  a reference  type  (array,  @class@,
>>   pointer, or @struct@ including such a type)
>> \item No pointer arithmetic
>> \item No escape of a pointer  or reference to a local variable outside
>>   its scope
>> \item Cross-module function calls must only go to other @safe@ modules
>> \end{itemize*}
>>
>> So these are my thoughts so far. There is one problem though related
>> to the last \item - there's no way for a module to specify "trusted",
>> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
>> no problem". Many modules in std fit that mold.
>>
>> How can we address that? Again, I'm looking for a simple, robust,
>> extensible design that doesn't lock our options.
>>
>>
>> Thanks,
>>
>> Andrei
>
> Not sure if this is the right topic to say this but maybe D needs monads
> to allow more functions to be marked as pure. Then functional could be
> added to the list of paradigms D supports and will also be safer.

Would be great if you found the time to write and discuss a DIP.

Andrei

Andrei Alexandrescu wrote:
> SafeD is, unfortunately, not finished at the moment. I want to leave
> in place a stub that won't lock our options. Here's what we currently
> have:

Is the whole SafeD thing trying to do something similar to Microsoft's
"managed/unmanaged" code thing? I don't know much about it, but I had
relegated the managed/unmanaged thing to being C++-like (unmanaged) or
Java-like (managed). "Sandboxing", in short.

Next ›   Last »
1 2 3 4 5