- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.3] #13102

by StÃ©phane Ducasse

13102 ----- - Cleaning Polymorph overrides. Part two. Stef

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Toon Verwaest

It is much simpler than that! You just need a separate Smalltalk root object to which only the VM has access. It has its own set of classes which are unique pointers. This means that the user-level image never has any pointer to any of the objects inside of this core image. This means that it can never GET access to it either! So they can't tamper with the code in the first place, since they can't see it. The VM just passes code from the user-part of the memory to the verification part of the memory, since the VM has access to both. As simple as that. cheers, Toon On 03/22/2011 02:17 PM, Igor Stasenko wrote: > On 22 March 2011 14:02, Toon Verwaest<toon.verwaest(a)gmail.com> wrote: >> The problem is exactly what you had at hand. Your bytecode WAS valid, but it >> was used in combination with an incompatible class layout. So validation >> here wouldn't solve anything. You always need to validate in a closed world >> to ensure you don't accidentally break everything. Whenever you change >> something, you need to ensure that you revalidate the relevant parts. In >> this case you could for example just have validated that your new class is a >> valid subclass of its superclass; which it was not. >> >> To make the system more secure obviously you would have to check those >> things, but if you add part of the API that circumvents these checks, like >> you were doing by calling "Class new" rather than using the ClassBuilder >> which does do the checks, everything breaks. The only authority that can >> actually ensure that you don't circumvent these checks is the VM. >> >> Obviously you can make sure already in your image that you have enough >> checks everywhere. You just don't have a crashproof mechanism that will >> chain your users down avoiding that they shoot themselves in the foot with >> segfaults. If you put it inside of the VM you -can- provide such a >> mechanism, because you don't execute anything unless you know it's safe. And >> as I said, this piece of code could be a piece of prevalidated Smalltalk >> code that's immutable from the rest of the image. >> > Yep.. and that is possible only after you introduce irreversible > immutability mechanism into VM, > which marking object(s) to be immutable for the rest of their existence. > >> cheers, >> Toon >> >> On 03/22/2011 02:37 PM, Alexandre Bergel wrote: >>>> But why we could not have a byecode validator at the image level that >>>> first make sure that byte code are in sync with the format of the objects. >>>> Why this has to be done in the vm. >>> I agree with Stef. It is not obvious for me why it has to be done at the >>> VM. >>> >>> Alexandre >> >> > >

March 22, 2011

Re: [Pharo-project] [ANN] SqueakNOS update released!

by Javier PimÃ¡s

No, we use them for much low level stuff: to directly access memory regions, which is needed in some cases, and to use callbacks, in the case of handling page faults to reenter the interpreter. You can use any plugin as long as: a) you compile it as internal and b) the plugin doesn't make any syscall or use code from other libraries that make syscalls. I don't know if this is the case of openssl and curl. Regards, Javier. On Tue, Mar 22, 2011 at 3:42 AM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > Hello, Javier. > > Very impressive work. > > What you mean by support for Alien and FFI? > What libraries I can call from SqueakNOS? And how I can build that > libraries? > > Can I use curl plugin or openssl from SqueakNOS somehow? > > Best regards, > Denis > > > 2011/3/21 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > >> For all those who may be intrested, we are glad to announce that we have >> just uploaded an updated version of SqueakNOS to our site. You can find the >> updated download links here<http://squeaknos.blogspot.com/p/download.html> >> . >> >> This release adds the following items to the previous version: (99.9% >> modeled with objects) >> >> - Improved support for ATA devices access >> - Implementation of a model of files and directories >> - Implementation of FAT32 filesystem >> - Support for reading sources from the hard disk >> - Support for X86 paging setup and handling of page faults >> - Implementation of a model of free and used memory >> - Implementation of image snapshotting (based on the paging mechanism) >> - Based on Pharo, but also supporting Squeak and Cuis >> - Added some primitives for communicating between VM and image >> - Support for Alien and FFI >> - Added basic support for writing to serial via VM so that it's possiblo >> to out debug info to the outside world. >> - Added pretty basic ATA benchmarks >> - Added some scripts to automatize work done from the outside world >> - Many code cleanups >> >> Future directions are: >> >> - Support for Cog VM >> - Investigate replacing SqueakNOS plugin with NativeBoost so that we do >> more on the image >> - Offloading memory pages to disk >> - More tests >> - Benchmarks >> >> For the brave ones, remember that you can always generate a SqueakNOS >> image by using the ConfigurationOfSqueakNOS (which is a bit outdated now), >> or by manually loading the packages from monticello. Also to generate a >> SqueakNOS VM download its code from GIT (hosted on sourceforge.net) >> >> Don't forget to visit squeaknos.blogspot.com for news and instructions. >> We hope to be able to write more soon. >> >> Many thank's t all the people who made it possible to understand the code >> and to develop all this. >> >> SqueakNOS' Team >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> > > -- Javier PimÃ¡s Ciudad de Buenos Aires

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Igor Stasenko

On 22 March 2011 14:02, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > The problem is exactly what you had at hand. Your bytecode WAS valid, but it > was used in combination with an incompatible class layout. So validation > here wouldn't solve anything. You always need to validate in a closed world > to ensure you don't accidentally break everything. Whenever you change > something, you need to ensure that you revalidate the relevant parts. In > this case you could for example just have validated that your new class is a > valid subclass of its superclass; which it was not. > > To make the system more secure obviously you would have to check those > things, but if you add part of the API that circumvents these checks, like > you were doing by calling "Class new" rather than using the ClassBuilder > which does do the checks, everything breaks. The only authority that can > actually ensure that you don't circumvent these checks is the VM. > > Obviously you can make sure already in your image that you have enough > checks everywhere. You just don't have a crashproof mechanism that will > chain your users down avoiding that they shoot themselves in the foot with > segfaults. If you put it inside of the VM you -can- provide such a > mechanism, because you don't execute anything unless you know it's safe. And > as I said, this piece of code could be a piece of prevalidated Smalltalk > code that's immutable from the rest of the image. > Yep.. and that is possible only after you introduce irreversible immutability mechanism into VM, which marking object(s) to be immutable for the rest of their existence. > cheers, > Toon > > On 03/22/2011 02:37 PM, Alexandre Bergel wrote: >>> >>> But why we could not have a byecode validator at the image level that >>> first make sure that byte code are in sync with the format of the objects. >>> Why this has to be done in the vm. >> >> I agree with Stef. It is not obvious for me why it has to be done at the >> VM. >> >> Alexandre > > > -- Best regards, Igor Stasenko AKA sig.

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Toon Verwaest

The problem is exactly what you had at hand. Your bytecode WAS valid, but it was used in combination with an incompatible class layout. So validation here wouldn't solve anything. You always need to validate in a closed world to ensure you don't accidentally break everything. Whenever you change something, you need to ensure that you revalidate the relevant parts. In this case you could for example just have validated that your new class is a valid subclass of its superclass; which it was not. To make the system more secure obviously you would have to check those things, but if you add part of the API that circumvents these checks, like you were doing by calling "Class new" rather than using the ClassBuilder which does do the checks, everything breaks. The only authority that can actually ensure that you don't circumvent these checks is the VM. Obviously you can make sure already in your image that you have enough checks everywhere. You just don't have a crashproof mechanism that will chain your users down avoiding that they shoot themselves in the foot with segfaults. If you put it inside of the VM you -can- provide such a mechanism, because you don't execute anything unless you know it's safe. And as I said, this piece of code could be a piece of prevalidated Smalltalk code that's immutable from the rest of the image. cheers, Toon On 03/22/2011 02:37 PM, Alexandre Bergel wrote: >> But why we could not have a byecode validator at the image level that first make sure that byte code are in sync with the format of the objects. >> Why this has to be done in the vm. > > I agree with Stef. It is not obvious for me why it has to be done at the VM. > > Alexandre

March 22, 2011

[Pharo-project] [update 1.3] #13101

by stephane ducasse

13101 ----- - Cleaning Polymorph overrides. Part one

March 22, 2011

Re: [Pharo-project] Filesystem and FS extensions in Pharo book

by Max Leske

Yes, I understand that. My question is if I should create entries for the "old" version since that one is working and has working extensions. Max On 22.03.2011, at 13:37, StÃ©phane Ducasse wrote: > right now we are stuck because we started documenting and understanding FS and coling publihsed a new one and he should merge our changes > > Stef > > On Mar 22, 2011, at 1:20 PM, Max Leske wrote: > >> Hey >> >> I miss Filesystem and its extensions (cURL, zip, git etc.) in the Pharo book. I'd write the entries but I want your oppinion on whether we should wait till the Filesystem rewrite in 1.2 is ready. >> >> My suggestion: >> >> ---- Pharo Tools >> ---- ---- Filesystem >> ---- ---- ---- Filesystem for Pharo 1.1 >> ---- ---- ---- ---- extensions 1 ...n >> ---- ---- ---- Filesystem for Pharo 1.2 >> ---- ---- ---- ---- extensions 1 ...n >> >> Should we even list the "old" versions? The downside to that is that we would have to wait for all the extensions to be updated. >> What do you think? >> >> Max >> >> > >

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by Marcus Denker

On Mar 22, 2011, at 1:35 PM, StÃ©phane Ducasse wrote: > But why we could not have a byecode validator at the image level that first make sure that byte code are in sync with the format of the objects. > Why this has to be done in the vm. > Because you can not gurantee that they are not changed after. Or that the code is changed that does the checking. or... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 22, 2011

Re: [Pharo-project] Filesystem and FS extensions in Pharo book

by StÃ©phane Ducasse

right now we are stuck because we started documenting and understanding FS and coling publihsed a new one and he should merge our changes Stef On Mar 22, 2011, at 1:20 PM, Max Leske wrote: > Hey > > I miss Filesystem and its extensions (cURL, zip, git etc.) in the Pharo book. I'd write the entries but I want your oppinion on whether we should wait till the Filesystem rewrite in 1.2 is ready. > > My suggestion: > > ---- Pharo Tools > ---- ---- Filesystem > ---- ---- ---- Filesystem for Pharo 1.1 > ---- ---- ---- ---- extensions 1 ...n > ---- ---- ---- Filesystem for Pharo 1.2 > ---- ---- ---- ---- extensions 1 ...n > > Should we even list the "old" versions? The downside to that is that we would have to wait for all the extensions to be updated. > What do you think? > > Max > >

March 22, 2011

Re: [Pharo-project] test crashing the cog vm

by StÃ©phane Ducasse

But why we could not have a byecode validator at the image level that first make sure that byte code are in sync with the format of the objects. Why this has to be done in the vm. Stef

March 22, 2011