immutability

Has anyone looked at, proposed, implemented object immutability?
Obviously, it would require a VM change.

It would make database proxy objects a bit easier, because they could be
marked immutable to throw an exception during the first write, so they could
be marked dirty (and then mutable) to write back before finalization.

I know VWST has something like this, and I think GemStone does as well.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Randal L. Schwartz wrote:
> Has anyone looked at, proposed, implemented object immutability?
> Obviously, it would require a VM change.
>
> It would make database proxy objects a bit easier, because they could be
> marked immutable to throw an exception during the first write, so they could
> be marked dirty (and then mutable) to write back before finalization.
>
> I know VWST has something like this, and I think GemStone does as well.

Googling a bit shows "sourcery" telling the comp.lang.smalltalk that
Chronos (http://www.chronos-st.org/) does. Or did. Back in 2005, at any
rate:

"An example of the Immutable Object Design Pattern implemented in
Smalltalk can be seen in the Chronos Date/Time Library
(http://www.chronos-st.org). After installing Chronos, see the class
comment of the class Immutable."

frank

-Ralph

El mié, 17-03-2010 a las 07:26 -0700, Randal L. Schwartz escribió:
> Has anyone looked at, proposed, implemented object immutability?
> Obviously, it would require a VM change.
>
> It would make database proxy objects a bit easier, because they could be
> marked immutable to throw an exception during the first write, so they could
> be marked dirty (and then mutable) to write back before finalization.
>
> I know VWST has something like this, and I think GemStone does as well.
>

WriteBarrier?

--
Miguel Cobá
http://miguel.leugim.com.mx

I think on the technical merits of what Randal's talking about, I'm misinformed. 

On Thu, Mar 18, 2010 at 3:26 AM, Randal L. Schwartz
<[hidden email]> wrote:
>
> Has anyone looked at, proposed, implemented object immutability?
> Obviously, it would require a VM change.

It doesn't really need a VM change. I'll be implementing immutability
in SecureSqueak, and most (or all?) literals in a CompiledMethod will
be made immutable.

The pattern I use is that setters in immutable objects are implemented
like this:

MyObject>>someValue: x
    baked ifFalse: [ someValue := x ]
        ifTrue: [ throw an error or something. ].

"baked" is an instance variable.

And then:

MyObject>>initialize
    | result |
    result := super initialize.
    baked isNil ifFalse: [ ^ error of some sort. ].
    baked := false.
    ^ result.

MyObject>>bake
    baked := true. " i.e. not nil."

In SecureSqueak, direct invasive object access using basicAt:put:,
at:put: and so forth will be disallowed.

Gulik.

--
http://gulik.pbwiki.com/

>>>>> "Michael" == Michael van der Gulik <[hidden email]> writes:

Michael> In SecureSqueak, direct invasive object access using basicAt:put:,
Michael> at:put: and so forth will be disallowed.

And that would require a VM change.

Otherwise, I can just create a method that does the primitive.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

> In SecureSqueak, direct invasive object access using basicAt:put:,
> at:put: and so forth will be disallowed.

I've always wondered what good this would do, blocking particular
kinds of object-access api's.  Couldn't an attacker easily just
(mis)use whatever legal-api to wreak havoc anyway?

On Thu, Mar 18, 2010 at 2:23 PM, Chris Muller <[hidden email]> wrote:
>> In SecureSqueak, direct invasive object access using basicAt:put:,
>> at:put: and so forth will be disallowed.
>
> I've always wondered what good this would do, blocking particular
> kinds of object-access api's.  Couldn't an attacker easily just
> (mis)use whatever legal-api to wreak havoc anyway?

No.

The goal of SecureSqueak is to provide an image that can run foreign
untrusted code in a way that doesn't affect the running of the rest of
the image, VM or operating system. I won't be providing attackers with
any APIs or objects that let them wreck havoc.

Java, for the most part, already does this. The only security feature
Java doesn't implement is the ability to control excessive memory or
CPU use.

Gulik.

--
http://gulik.pbwiki.com/

Yes, I have always found your project interesting, even if I don't
understand it.  For immutability I understand that blocking
basicAt:put:, instVarAt:put:, the Compiler, etc., might help for
secure immutability from attackers, but can you support object
serialization?  Beyond that, I was curious about is whether
SecureSqueak addresses how to prevent an attacker from using any
object as a confused deputy.  Or from changing someone's name from
Peter to Paul, etc.  Does SecureSqueak employ capabilities to address
these issues?

On Wed, Mar 17, 2010 at 9:03 PM, Michael van der Gulik
<[hidden email]> wrote:

Randal L. Schwartz wrote:
>>>>>> "Michael" == Michael van der Gulik <[hidden email]> writes:
>
> Michael> In SecureSqueak, direct invasive object access using basicAt:put:,
> Michael> at:put: and so forth will be disallowed.
>
> And that would require a VM change.
>
> Otherwise, I can just create a method that does the primitive.

So #basicAt:put: etc. is the reason why, as Ralph put it, immutability
is a _language_ feature and not simply part of a library?

Or, to put it another way, if we want to _guarantee_ immutability we
can't rely on ProtoObject/Object defining immutability because
subclasses could override that behaviour? (Which would be breaking the
programming-by-convention rule for immutability.)

frank

I dont undestand, why people think that its impossible to build a
secure smalltalk system.
Is smalltalk language not turing complete?
Otherwise, if its possible to build a secure system using other
language, why its impossible to do in smalltalk?

Isn't stating that 'we can build easily anything in smalltalk', goes
into controversy with 'we can't build a secure system in smalltalk'?


On 18 March 2010 11:47, Frank Shearar <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

I studied the immutability bit, from the newspeak VM.

And i think that can be very easy to implement, i would like to perform the change in VMMaker.
But, i work on pharo, and the pharo image have a small difference about VMMaker.
Then if that  small difference can be fixed and we have the same version of VMMaker for the two environments all my work can be usable on squeak.






On Mar 18, 2010, at 11:02 AM, Igor Stasenko wrote:

>>> And that would require a VM change.

Regard
Jean Baptiste Arnaud
[hidden email]