Squeak-e February 2003

squeak-e@lists.squeakfoundation.org

17 participants
29 discussions

RE: [Squeak-e] Programming the VM
by Stephen Pair 03 Feb '03

03 Feb '03

>> SqueakVM specialists: how hard is it to add an extra > reference to all >> objects? On Squeak level? On VM level? > > I would like to hear a little more about what this 'machine' actually > is. Is it a lexical closure? Would all objects need to have this > 'machine' reference? > > Squeak object headers are of variable size. there are 3 different > sizes so it uses 2 bits in the baseHeader to define the > header size. 1 > word, 2 words, or 3 words are the possibilities, and the fourth value > is for dead objects, I believe. Stephen added an extra word for his > LOOM impl, and basically all the code that reads or writes > the headers > would need to be changed to deal with it. You are correct about header sizes and bit usages. Coaxing squeak into having extra headers is straightforward, but time consuming. You'll have an additional challenge by adding a pointer field (because you'll need GC to trace it). I'd also recommend that you bone up on the InterpreterSimulator and use SystemTracer2 (on SqueakMap) for making your new images and testing your new interpreter. The InterpreterSimulator is an invaluable debugging tool. Since it is a pointer field, I'd probably explore adding the word *below* the base header because that will be the least impact on GC...however, it's also something that I've never attempted. I have added non-pointer headers to every object above the base header and I've added the ability to insert a "state manager" between an object and its class (path of least resistance). If you added a pointer field above the base header, you're going to have to do some very tricky things with GC to get it to traverse that field (similar to the way GC currently deals with the class header). In an ideal world, I'd move the class header below the base header, but this probably wasn't done because not every object has a class header and testing that fact on every inst var access would probably be expensive. If you eliminated compact classes, then it would make sense to move the class header below the base header (note, I have not done that in my Chango VM even though I did eliminate compact classes). If absolutely every object is going to have this pointer and it is a pointer, I would start with a design that puts this pointer after the base header. If only some of the objects in the image will have this pointer, you might try a similar hack that I did which inserts your object between an object and its class. Finally, you can put a pointer above the header, but it's going to make for some ugly looking code in GC. - Stephen

1 0

Re: [Squeak-e] Programming the VM
by Mark S. Miller 03 Feb '03

03 Feb '03

At 01:03 AM 2/3/2003 Monday, Avi Bryant wrote: >Seaside requires access to the entire context stack, but opaquely - it >just needs to copy it, not to look at or change it. To put it another >way, it needs access not to its caller's frame but to its own >continuation, which seems reasonable to me from a security point of view >(there was a brief mention earlier of a secured Scheme - did this still >have call/cc?). It's called W7 and is documented at http://mumble.net/jar/pubs/secureos/ . It's great. I strongly recommend reading it. It did have call/cc with indefinite extent continuations, which isn't technically incompatible with capability security. But indefinite extent continuations make it too hard to program defensively. Every caller has to worry that any callee may return to it multiple times. Jonathan Rees, who did W7, now agrees that default indefinite extent continuations are a disaster in the context of general caller/callee mutual suspicion. See http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html for some related points. Btw, call/cc with dynamic extent continuations are fine, as with Smalltalk's traditional "[:result | ^result]" . It sounds like there's a genuine conflict here with Seaside, which we need to understand better. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

2 1

[goodie] SqueakElib released to squeak map
by Robert Withers 03 Feb '03

03 Feb '03

http://swiki.squeakfoundation.org/squeak-e/3 sorry, no docs. enjoy! ps. you have to have the asn-encoding-dsa.cs changeset, loaded

1 1

Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 03 Feb '03

03 Feb '03

Hi Anthony, I just reread your paper, and enjoyed it tremendously once again. Sorry for the delay on the comments. All unattributed ">"-style quotes are taken from Anthony Hannan's "Capabilities and Class Extensions for Secure but Extensible, Shared Smalltalk", version dated January 2003, at http://housechk.com/~tony/SharedSmalltalk.htm . At the beginning of 2.1, typo: >allows you to associated resources 2.2: >If you have to give out stronger capability objects, make sure the client is >trustworthy, since it may pass the capability along to other objects. It is >possible to create smart capabilities that confirm the sender at runtime, >but this requires maintaining an access control list that is usually more >trouble than handing the capabilities out correctly in the first place. [likewise, but out of order] >In extreme cases, where you need to give a stronger capability to an >untrusted client, you can have the capability check who the sender or user >is as mentioned earlier. You can have it wrap all results in new >capabilities that also check who the sender/user is, and so on. This >provides end-to-end security without trusting client objects, albeit with >extra overhead. What problem do these "smart capabilities" solve that isn't better solved using pure capabilities? What do you mean by "confirm the sender"? What information would you examine, and what notion of sender would you compare it against? These "smart capabilities" looks to me like a mixture of capability and ACL notions. Among other things, it means that a sender effectively has extra authority because of his identity, rather than just the authority he chooses to use. This leads to confused deputy problems. In terms of Figures 3 and 4 of Capability Myths Demolished http://zesty.ca/capmyths/usenix.pdf , you have arrows pointed both ways. I think this may be approximately what Li Gong's ICAP http://citeseer.nj.nec.com/gong89secure.html tried to do. The next paragraph beginning with >A fundamental difference is just great. I don't remember seeing it explained this way before. 2.4: >We can automatically determine if an object's instance variables can be >transferred with the object or if a proxy should be transferred instead. If >one of the object's instance variables is truly private, i.e. no methods >give it out, then only a proxy to the object should be given out. Otherwise, >it is ok to transfer the object and its instance variable, since it is >willing to give out its instance variables anyway. This corresponds in E to the distinction between PassByCopy and PassByProxy. E objects are by default PassByProxy. Since your paper mostly avoids distribution issues, the following is probably a digression: <digression> In E, to declare an object PassByCopy it must satisfy three conditions: * OpenState -- all its instance variables must be accessible through its interface in a standard way. I think this maps exactly to what you're saying. * OpenSource -- the object must make its source available through a standard request on its interface. * Frozen -- the instance variables must be immutable. (It would be adequate to check that they aren't assigned to.) OpenState and OpenSource together are called Transparent. It ensures that all the information needed to instantiate a copy is available through the public interface. An effect of declaring an object PassByCopy is to make it Selfless. Objects are Selfish by default. "x == y" between two Selfish objects in E means what it means in Squeak: compare the object's creation identity, ie, their selfs. Selfless objects have no self. "x == y" among two PassByCopy objects recursively compares (with cycle breaking) their source and state. Frozen and Selfless together means that PassByCopy objects can be copied freely, and not coordinated afterwards, and nevertheless they are all still manifestations of the same object. All the copies are still ==. If your copied objects aren't Selfless, you probably need some kind of per-connection interning table for each object copied over that connection, in order to make sure that a second passing looks up the already constructed copy on the other side. If your copied objects aren't Frozen, then you'll need to coordinate distribute state, which is tricky http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html http://www.eros-os.org/pipermail/e-lang/2002-April/006357.html . </digression> 3: >Since common classes are the same across users we will model them as >actually being identical objects that are replicated but kept in sync [2]. >This allows them to be changed together if need be by an authorized user. Aren't the common classes common across the universe? Who would have enough authority to change these? I think I'm missing something. 3.1: I love your description of users and portals. I think it's exactly right. typo: >he may create an chat 3.2: Are you proposing that each pool dictionary be replicated across all users? If so, then these must contain no authority as you've heard me harp on. If you're not replicating them, but instead allowing each machine to have its own name->variable bindings for each pool, then a shared class + separate pool bindings = a new level of instantiation. I think I'd be happy with either direction as long as they're taken to their logical extreme. 3.4: Really really cool. But, since you wish to prevent the class extension from overriding the common class it's extending, what happens if the common class later defines a method for one of the messages defined by some extension? The common class doesn't know enough to refuse to do that. Once it's done, then the extension in effect defines an override. I don't know what to do about that, as I also think that overrides by extensions should be disallowed. 3.5: >A user may also add a subclass to any class. If the superclass is read-only >then the subclass can not access the superclass's instance variables or >pool, only its own instance variables and pool. If the superclass sends a message to self, does the subclass receive it, as one would naively expect? 3.6: >Finally, if the message name is found in more than one class interface, >then those classes are presented to the user for him to choose. In this case, the choice should be represented by making the selector in the source explicit (eg, your later "collection.do"). Otherwise, the source text is not the complete source. >It also makes detached class extensions possible. Intriguing. How do you mean? I think this one's important to understand. ********************** I'm holding off on some further comments while I see if I can nag Dean (cc'ed above) into finding and posting the Joule Type Extension paper he wrote many moons ago. Dean, nag nag. ;) ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

reply-to addressing is going to the sender rather than the list
by Robert Withers 02 Feb '03

02 Feb '03

Cees, Could you modify the way the list sets the reply-to field? or is it something I need to setup in my mail client? thanks, rob

2 1

Re: Comments on Lex's "Object as Capabilities in Squeak"
by Mark S. Miller 02 Feb '03

02 Feb '03

Answering out of order. At 12:26 AM 1/31/2003 Friday, Lex Spoon wrote: >Your notion of 4 levels of effort is a great basis of discussion. In >fact, I believe Islands works at level 4, though it is more awkward for >such thigns than E. I'll attach my solution to the little-money problem >at the end of the message. Still, as you guessed, the goal of the >project was more for level 1 or maybe level 2 (eg, retracting sound >access from annoying squeaklets), with hopes of making a basis for level >4. As I count it, everyone would like to reach for level 4. So let's proceed with that as a shared goal, being willing to pay the incompatibility price along the way, so that we can see how big that price is at the end of the day, and how we feel about it. >There is a big engineering effort to get away from dynamic binding of >class names yet still have limited access to classes. Happily, though, >the independent modules efforts for Squeak seem to be solving this exact >issue along with their other goals. Where can I read about this? >The more general dynamic global variables are annoying, but the one case >of World is hard to do away with in Squeak. World refers to the current >morphic rendering unit. Currently it is an entire desktop, though in a >Squeaklet it would be more like one page or one subwindow. This demonstrates already that it was a mistake to make it global -- it needs to be bound to a different object when it appears in a Squeaklet. >Plus, there is a tricky >*conceptual* issue with getting rid of the variable. It's just really >convenient to have the world floating in the ether, and it would suck if >Squeak code became significantly harder to write. I think the real problem is that Squeak currently has a very rigid notion of lexically nested levels of instantiation: Global Class/Factory Instance Method (activation frame) Block Block ... At the bottom of the hierarchy, one can add more levels freely. What is needed to address many of the problems that are coming up is the ability to add more levels between Global and Class/Factory. I suspect "World" should appear in one of these. The Java ClassLoader mechanism adds exactly one additional level, which postpones the pain but doesn't cure the disease. Let's call this the "loader scope". E and W7 have arbitrary and uniform lexical nesting to whatever depth or height is desired. What would it mean for Squeak-E if a full class definition could appear in a method, just as a block-closure definition does now? Hell, even Java does proper lexically nested class definitions. Imagine perhaps a single-class-browser embedded in the method text, making the method editor pane into a compound document editor. >Code uses World all over the place: there are 98 direct accesses to the >variable, and 119 senders of #currentWorld. How do I make such queries in my image? >On another topic, you say that level-1 success, where you have >completely isolated applets, is useless. That is not actually true in >Squeak. The most important goal of Squeak is to allow a new way of >composing electronic documents. Level-1 success means Squeak documents >can be exchanged safely, which is a huge step forward for Squeak. "Useless" was harsh. Applets are certainly useless compared to their billing. But for interactive diagrams in documents, they should be great. I've been puzzled that there are so few even of these. >Then, instead of writing >> >> x := ObjectInspector instVatOf: obj at: i >> >> you'd write: >> >> x := (ObjectInspector new: obj) at: i Oops, my second line should have said "instVarAt:" rather than "at:". >I believe this is implemented. However, the instance methods just call >the class methods. :) I guess you'd actually want to use something >other than this exact message sequence to *create* an ObjectInspector >instance, though, in order to defeat using "myObjectInspector class" to >create arbitrary new ObjectInspectors. Yes. Which brings up the question, should Squeak-E objects respond to #class at all? #class is a query about an object's implementation, which is none of its client's business. In E, objects instead respond to __getAllegedType, which returns an immutable object (should only be read-only) which describes the API the original object responds to. In other words, the query-only interface-information-only abstraction of messages like "allMethodsInCategory:" -- enumerating not the methods, but the names or signatures or something of the methods. In any case, if Squeak-E classes are factories that may themselves have authority (having gotten it from an enclosing lexical scope perhaps), then it's important that one not be able to access an object's factory by default from the object. See http://zesty.ca/e-archive/ . >Anyway, I never made a serious pass at secure debugging, and it seems >like a low priority. It seems very complicated -- e.g., the debugger >itself may have to worry about being corrupted by the code it is >debugging! While I think it's important long term, I've postponed it for E as well. When the time comes, KeyKOS and EROS are the places to look for a full reconciliation of the tensions between security and debugging. But transposing their solution to a language context may require some research. >Currently, literals in Squeak change all too often; >specifically, I have a literal change about once a year, and it sucks >when it happens. :) Making literals immutable along with read-only is >a terrific thing. The only time they are mutated in Islands, is when >they are instantiated by the compiler when a method is compiled. The literal itself is changed? I think I'm confused. This would seem to be very bad. I'm reminded of those old Fortran stories where an assignment could make all literal "5"s in a program have the value 3. >(Implementation note: I never made an island-creating capability for >Islands, and I never implemented a thisIsland facility for grabbing the >island you are running in. It seems like these would be very easy, >however.) What's the API of an island? If I hold a capability to an island, do I thereby have any authority beyond querying? If so, you should not provide a thisIsland that anyone can say. >> This section refers to "methods that are marked as privileged". Even after >> reading the later section that explains this, I didn't feel like I >> understood how this marking happens, or how the authority to do this marking >> is controlled. > >You mark it by sending messages to the real, low-level class object, the >same class object that the VM uses. Thus it is as privilaged as it can >be. Cool. >I really hope that Islands reaches the 4th level of success that you >talk about, in which case normal users never need to write privilaged >methods. Who needs to define primitives, or access variables from the >system's most privilaged island, or touch thisContext? Logically no >one, and hopefully this works out in practice. Actually, thisContext or something like it may be fine, as open access to *this* stack frame, so long as the parent pointer is no longer open access to the parent frame, but instead at most an opaque continuation. >> Can the same dynamic-variable-using instance be invoked from different >> processes (causing different bindings of the same use-occurrence of the same >> variable), or are dynamic-variable-using instance partitioned among the >> processes that can invoke them. Unfortunately, I suspect it's the first, but >> I'll wait to find out before arguing against it. > >It's possible for it to be the first. For example, if a squeaklet forks >a thread, then the thread will surely be given the same island and thus >the same bindings. I think I'm concerned about the opposite problem. If you have per-process variables, and objects are disjointly partitioned among processes, so that each object "lives" in only one process, and only gets invoked by that process, then the process scope becomes like an outer lexical scope. On object creation, the process scope is determined according to which process the object is created "in". OTOH, if the same object can be reached by multiple processes, then per-process-scoped variables must be disqualified for many of the same reasons that dynamic scoping is a bad idea. More later... ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 1

What is E and squeak-e?
by shane＠shaneroberts.com 01 Feb '03

01 Feb '03

I am interested in new operating system technologies and new approaches to software systems. I have been looking at Forth, Plan9, Java, Python, Inferno, Hurd, and other systems. Now I am reviewing Squeak and Smalltalk. I joined the Squeak-E list because I saw a mention of capabilities as a security approach for Squeak or Smalltalk. Can someone give me a little background on how this list appeared and what the topic is? Thanks, Shane email: shane(a)shaneroberts.com

2 5

Market economies
by Robert Withers 01 Feb '03

01 Feb '03

folks, I have an outrageous idea. I'm wondering what you think of it. The real value of squeak is the community. Since we are considering the possibilities of opening a hole can of worms, here, why don't we turn it up a notch. Let's form a corporation and issue preferred stock to a bunch of people. I am thinking the entire squeak and E communities should own stock. We'll want to distribute it commensurate to 'contribution' somehow, but there is really no fair way, is there? So we'll have a vote. And whatever the results, we'll abide by them. I don't know how the vote will work, but maybe each person has 100 shares to distribute and they distribute them to specific people or organizations. Whatever they want to do with it, they can. Perhaps it would be easier to just decide amongst ourselves, I don't know. Then we build a system that can reliable trade that stock, with security. then we look for ways to inject real money into the system. the only way for the stock to ever be worth money is if we build the system to support it the code we write, will be open-source, under our open source license. We could give Apple some of the stock to buy their license from them. :) the value will be in the system we build with the code, not the code itself. so? is it crazy enough to work? It's like an experiment. Do you want to try it, just for the hell of it? It might be possible to get funding to create such a system and track it's growth and evolution. regards, rob

2 2

Re: [e-lang] Re: Comments on Lex's "Object as Capabilities in Squeak"
by Robert Withers 01 Feb '03

01 Feb '03

On Friday, January 31, 2003, at 05:00 AM, Lex Spoon wrote: > Robert Withers <rwithers12(a)attbi.com> wrote: > >> How would it be different? Where would it hurt? I can imagine that >> it >> would be a beautiful engine, asynchronously sending messages and >> making >> sure things synchronize later. Events from the external system would >> just be another message send into the image. You wouldn't need an >> idle >> loop. You could schedule the message sends based on cost feedback. I >> don't have as good a feel for what SafeSqueak would feel like, though. >> >> Well, it wouldn't take a community commitment, of course, but it would >> require some core group of enthusiasts. I think they are out there. >> :-) > > > SafeSqueak would also demonstrate to the Smalltalk community that such > a > wonderful way to do in-language security is available. Honestly, one > reason I got into this is that it drives me crazy whenever someone says > "we need security, so lets add passwords" or "we need security, so lets > start using cryptographic signatures". If I start telling them about > capabilities, they currently just say "that's only theore. It's > spinning my head, and I already understand and can use these other > methods, anyway. Security = passwords. nya nya nya i can't here you". A perfect application of revoking the audible capability to the poor little non-squeaklet. Feed the annoyance some bytecodes and perhaps he'll pipe down. Java, JMS, J2EE, JTS, XML, XTS, XSL, SOAP, RMI, CLR, ML, Ocaml... whatever. If there's no market for secure Smalltalk, so we just have to create our own. > > Yarg!! yeah, Lex. Let it be known. > If we start saying "Well, SafeSmalltalk does it this way", and > even better "SafeSmalltalk automatically prevents the security hole you > just got in your Java program", then these discussions will go a lot > more nicely. such perfect restrained sarcasm and disdain for the opponent. I love it! :) > Further, the world will start getting populated with more > secure software. The most aggravating part of the computing industry > is > that people keep doing stupid things out of ignorance. There's little > respect far what has been studied already. One of the chief designers > actually stood up at OOPSLA in front of 1000+ people a few years ago > and > said he didn't see much point to having closures in his language. Which nincompoop was that? Squeakers are the smartest group of people I have ever had the pleasure of working with. Come join the new list and let's see what ferments, or rather foments. Thanks for your fantastic posts these past few days. I have really enjoyed reading them. cheers, rob ps. Let's transition the discussion to squeak-e. We should leave the other 900 squeakers alone, at this point ;-)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e February 2003