test crashing the cog vm
Locked
123
123
 
|
Hi,
Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. How to reproduce: - download the following image http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip - execute the following code in the workspace (already provided in the image) cls := Class new superclass: MooseElement; yourself. cls compileSilently: 'mooseName ^ 1/0'. element := cls new. - I used all of the followings and they all crashed: https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/artifact/cog/build/Cog.zip https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2/artifact/cog/build/StackVM.zip http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz The strange thing is that the crash only happens when we subclass MooseElement, but not another class. Could someone take a look? Cheers, Doru -- www.tudorgirba.com "Every thing should have the right to be different." |
|
|
This does crash whenever you subclass a class which has instance
variables and you try to access those instance variables. The problem is that you don't properly initialize your class, leaving you with a Class that has a wrong format. For example: cls := Class new superclass: Class; yourself. cls format returns 2. 2 basically means it's an object with pointers but with 0 instance variables. If you instantiate the 'cls' I just made it also crashes. Why? Well, class has an initialize method that is compiled to write to the fields of the new instance. It puts an empty method dictionary into the class you create as an instance of my cls. This segfaults because you are writing outside of memory. So just make sure you properly create classes, with a proper format! This test should crash all VMs btw... at least at some point. Since you are writing in random memory it might take longer to notice it in some cases; especially when padded memory is owned by the garbage collector :) cheers, Toon On 03/21/2011 10:24 AM, Tudor Girba wrote: > Hi, > > Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. > > How to reproduce: > > - download the following image > http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip > > - execute the following code in the workspace (already provided in the image) > cls := Class new superclass: MooseElement; yourself. > cls compileSilently: 'mooseName ^ 1/0'. > element := cls new. > > - I used all of the followings and they all crashed: > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/artifact/cog/build/Cog.zip > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2/artifact/cog/build/StackVM.zip > http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz > http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz > > > The strange thing is that the crash only happens when we subclass MooseElement, but not another class. > > Could someone take a look? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > > |
|
|
Thanks, Toon!
I changed the code to explicitly set the format, and it seems to fix the problem: cls := Class new superclass: MooseElement; setFormat: MooseElement format; yourself. cls compileSilently: 'mooseName ^ 1/0'. element := cls new. Is this correct? Cheers, Doru On 21 Mar 2011, at 10:57, Toon Verwaest wrote: > This does crash whenever you subclass a class which has instance variables and you try to access those instance variables. The problem is that you don't properly initialize your class, leaving you with a Class that has a wrong format. For example: > > cls := Class new superclass: Class; yourself. > cls format > > returns 2. 2 basically means it's an object with pointers but with 0 instance variables. If you instantiate the 'cls' I just made it also crashes. Why? Well, class has an initialize method that is compiled to write to the fields of the new instance. It puts an empty method dictionary into the class you create as an instance of my cls. This segfaults because you are writing outside of memory. > > So just make sure you properly create classes, with a proper format! > > This test should crash all VMs btw... at least at some point. Since you are writing in random memory it might take longer to notice it in some cases; especially when padded memory is owned by the garbage collector :) > > cheers, > Toon > > On 03/21/2011 10:24 AM, Tudor Girba wrote: >> Hi, >> >> Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. >> >> How to reproduce: >> >> - download the following image >> http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip >> >> - execute the following code in the workspace (already provided in the image) >> cls := Class new superclass: MooseElement; yourself. >> cls compileSilently: 'mooseName ^ 1/0'. >> element := cls new. >> >> - I used all of the followings and they all crashed: >> https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/artifact/cog/build/Cog.zip >> https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2/artifact/cog/build/StackVM.zip >> http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz >> http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz >> >> >> The strange thing is that the crash only happens when we subclass MooseElement, but not another class. >> >> Could someone take a look? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Every thing should have the right to be different." >> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow." |
|
|
If this is all you are doing then yes, that is correct. If you expect
the format to be different in the new subclass you will have to recalculate it, but since you aren't doing that in this example, this is fine. cheers, Toon On 03/21/2011 11:29 AM, Tudor Girba wrote: > Thanks, Toon! > > I changed the code to explicitly set the format, and it seems to fix the problem: > > cls := Class new superclass: MooseElement; > setFormat: MooseElement format; > yourself. > cls compileSilently: 'mooseName ^ 1/0'. > element := cls new. > > Is this correct? > > Cheers, > Doru > > > On 21 Mar 2011, at 10:57, Toon Verwaest wrote: > >> This does crash whenever you subclass a class which has instance variables and you try to access those instance variables. The problem is that you don't properly initialize your class, leaving you with a Class that has a wrong format. For example: >> >> cls := Class new superclass: Class; yourself. >> cls format >> >> returns 2. 2 basically means it's an object with pointers but with 0 instance variables. If you instantiate the 'cls' I just made it also crashes. Why? Well, class has an initialize method that is compiled to write to the fields of the new instance. It puts an empty method dictionary into the class you create as an instance of my cls. This segfaults because you are writing outside of memory. >> >> So just make sure you properly create classes, with a proper format! >> >> This test should crash all VMs btw... at least at some point. Since you are writing in random memory it might take longer to notice it in some cases; especially when padded memory is owned by the garbage collector :) >> >> cheers, >> Toon >> >> On 03/21/2011 10:24 AM, Tudor Girba wrote: >>> Hi, >>> >>> Alex recently wrote a test in Moose that seems to crash the Cog VM at least on Mac. >>> >>> How to reproduce: >>> >>> - download the following image >>> http://dl.dropbox.com/u/18323746/Tmp/moose-crashing-cog-jit.zip >>> >>> - execute the following code in the workspace (already provided in the image) >>> cls := Class new superclass: MooseElement; yourself. >>> cls compileSilently: 'mooseName ^ 1/0'. >>> element := cls new. >>> >>> - I used all of the followings and they all crashed: >>> https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Cocoa/4/artifact/cog/build/Cog.zip >>> https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Cocoa/2/artifact/cog/build/StackVM.zip >>> http://www.mirandabanda.org/files/Cog/VM/VM.r2370/Cog.app.tgz >>> http://www.mirandabanda.org/files/Cog/VM/VM.r2361/Cog.app.tgz >>> >>> >>> The strange thing is that the crash only happens when we subclass MooseElement, but not another class. >>> >>> Could someone take a look? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing should have the right to be different." >>> >>> >>> >>> >> > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > > |
|
|
In reply to this post by Tudor Girba
On 21 March 2011 11:29, Tudor Girba <[hidden email]> wrote:
> Thanks, Toon! > > I changed the code to explicitly set the format, and it seems to fix the problem: > > cls := Class new superclass: MooseElement; > setFormat: MooseElement format; > yourself. > cls compileSilently: 'mooseName ^ 1/0'. > element := cls new. > > Is this correct? > Yes, you should pay attention to have correct format. But of course VM could also be more cautios and verify if your class are well formed before creating an instance of it.. > Cheers, > Doru > -- Best regards, Igor Stasenko AKA sig. |
|
|
I couldn't agree more!
However, here the problem is not that the format isn't a correct format. The problem is that a bytecode is activated that is incompatible with the instance format. So basically on every bytecode accessing an instance you would have to check if this is a valid access. And as we all know, Smalltalk avoids this; it makes things faster :) Toon On 03/21/2011 12:49 PM, Igor Stasenko wrote: > On 21 March 2011 11:29, Tudor Girba<[hidden email]> wrote: >> Thanks, Toon! >> >> I changed the code to explicitly set the format, and it seems to fix the problem: >> >> cls := Class new superclass: MooseElement; >> setFormat: MooseElement format; >> yourself. >> cls compileSilently: 'mooseName ^ 1/0'. >> element := cls new. >> >> Is this correct? >> > Yes, you should pay attention to have correct format. > But of course VM could also be more cautios and verify if your class > are well formed before creating an instance of it.. > > > >> Cheers, >> Doru >> > > |
|
|
On 21 March 2011 13:14, Toon Verwaest <[hidden email]> wrote:
> I couldn't agree more! > > However, here the problem is not that the format isn't a correct format. The > problem is that a bytecode is activated that is incompatible with the > instance format. So basically on every bytecode accessing an instance you > would have to check if this is a valid access. And as we all know, Smalltalk > avoids this; it makes things faster :) > In other words, a responsibility of having correct bytecode lies on image side, not on VM side. Adding a bytecode verifier to VM will be a lot of work.. And of course it could verify it only when you installing a method, not when you activating it. > Toon > > On 03/21/2011 12:49 PM, Igor Stasenko wrote: >> >> On 21 March 2011 11:29, Tudor Girba<[hidden email]> wrote: >>> >>> Thanks, Toon! >>> >>> I changed the code to explicitly set the format, and it seems to fix the >>> problem: >>> >>> cls := Class new superclass: MooseElement; >>> setFormat: MooseElement format; >>> yourself. >>> cls compileSilently: 'mooseName ^ 1/0'. >>> element := cls new. >>> >>> Is this correct? >>> >> Yes, you should pay attention to have correct format. >> But of course VM could also be more cautios and verify if your class >> are well formed before creating an instance of it.. >> >> >> >>> Cheers, >>> Doru >>> >> >> > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
Yes you are right! Bytecode validation would be very important here. If
you ask me, the VM should only allow verified bytecode to be executed. Here it could have a dual model, where bytecodes are "internalized" whenever you give them to the VM first. At that point they are validated. Once it's internalized, it can't be modified anymore from the outside, since the Smalltalk world doesn't have direct access to the internalized version. All changes to the bytecode "source", needs to be propagated to the VM by re-internalizing it. This is exactly the model I'm using in Pinocchio... and that allows us to not use bytecodes in the first place :) You just need a way to map the internal version back onto the highlevel version for debugging. (We don't verify the bytecode yet though). Bytecode verification btw shouldn't be too hard. You just need to make sure that all the codes are safe for the instance at hand, and for the method contexts you create. Anything else is just a runtime semantical error which you can't guarantee, since you don't know what the programmer is trying to do. We don't verify it yet since I'm still designing my register-based bytecodes; and since I atm have too much work at hand :) cheers, Toon On 03/21/2011 02:22 PM, Igor Stasenko wrote: > On 21 March 2011 13:14, Toon Verwaest<[hidden email]> wrote: >> I couldn't agree more! >> >> However, here the problem is not that the format isn't a correct format. The >> problem is that a bytecode is activated that is incompatible with the >> instance format. So basically on every bytecode accessing an instance you >> would have to check if this is a valid access. And as we all know, Smalltalk >> avoids this; it makes things faster :) >> > In other words, a responsibility of having correct bytecode lies on > image side, not on VM side. > > Adding a bytecode verifier to VM will be a lot of work.. And of course > it could verify it only when you installing a method, > not when you activating it. > >> Toon >> >> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >>> On 21 March 2011 11:29, Tudor Girba<[hidden email]> wrote: >>>> Thanks, Toon! >>>> >>>> I changed the code to explicitly set the format, and it seems to fix the >>>> problem: >>>> >>>> cls := Class new superclass: MooseElement; >>>> setFormat: MooseElement format; >>>> yourself. >>>> cls compileSilently: 'mooseName ^ 1/0'. >>>> element := cls new. >>>> >>>> Is this correct? >>>> >>> Yes, you should pay attention to have correct format. >>> But of course VM could also be more cautios and verify if your class >>> are well formed before creating an instance of it.. >>> >>> >>> >>>> Cheers, >>>> Doru >>>> >>> >> >> > > |
|
|
Thanks for this fruitful discussion. Thanks Doru for fixing my test. It was hard to predict this problem, since it went green on my machine.
Good job Guys! Alexandre Le 21 mars 2011 à 09:57, Toon Verwaest <[hidden email]> a écrit : > Yes you are right! Bytecode validation would be very important here. If you ask me, the VM should only allow verified bytecode to be executed. Here it could have a dual model, where bytecodes are "internalized" whenever you give them to the VM first. At that point they are validated. Once it's internalized, it can't be modified anymore from the outside, since the Smalltalk world doesn't have direct access to the internalized version. All changes to the bytecode "source", needs to be propagated to the VM by re-internalizing it. > > This is exactly the model I'm using in Pinocchio... and that allows us to not use bytecodes in the first place :) You just need a way to map the internal version back onto the highlevel version for debugging. (We don't verify the bytecode yet though). > > Bytecode verification btw shouldn't be too hard. You just need to make sure that all the codes are safe for the instance at hand, and for the method contexts you create. Anything else is just a runtime semantical error which you can't guarantee, since you don't know what the programmer is trying to do. We don't verify it yet since I'm still designing my register-based bytecodes; and since I atm have too much work at hand :) > > cheers, > Toon > > On 03/21/2011 02:22 PM, Igor Stasenko wrote: >> On 21 March 2011 13:14, Toon Verwaest<[hidden email]> wrote: >>> I couldn't agree more! >>> >>> However, here the problem is not that the format isn't a correct format. The >>> problem is that a bytecode is activated that is incompatible with the >>> instance format. So basically on every bytecode accessing an instance you >>> would have to check if this is a valid access. And as we all know, Smalltalk >>> avoids this; it makes things faster :) >>> >> In other words, a responsibility of having correct bytecode lies on >> image side, not on VM side. >> >> Adding a bytecode verifier to VM will be a lot of work.. And of course >> it could verify it only when you installing a method, >> not when you activating it. >> >>> Toon >>> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >>>> On 21 March 2011 11:29, Tudor Girba<[hidden email]> wrote: >>>>> Thanks, Toon! >>>>> >>>>> I changed the code to explicitly set the format, and it seems to fix the >>>>> problem: >>>>> >>>>> cls := Class new superclass: MooseElement; >>>>> setFormat: MooseElement format; >>>>> yourself. >>>>> cls compileSilently: 'mooseName ^ 1/0'. >>>>> element := cls new. >>>>> >>>>> Is this correct? >>>>> >>>> Yes, you should pay attention to have correct format. >>>> But of course VM could also be more cautios and verify if your class >>>> are well formed before creating an instance of it.. >>>> >>>> >>>> >>>>> Cheers, >>>>> Doru >>>>> >>>> >>> >>> >> >> > > |
Re: test crashing the cog vm
|
|
In reply to this post by Toon Verwaest-2
This would be a nice little topic... this bytecode verifier.
Stef On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote: > Yes you are right! Bytecode validation would be very important here. If you ask me, the VM should only allow verified bytecode to be executed. Here it could have a dual model, where bytecodes are "internalized" whenever you give them to the VM first. At that point they are validated. Once it's internalized, it can't be modified anymore from the outside, since the Smalltalk world doesn't have direct access to the internalized version. All changes to the bytecode "source", needs to be propagated to the VM by re-internalizing it. > > This is exactly the model I'm using in Pinocchio... and that allows us to not use bytecodes in the first place :) You just need a way to map the internal version back onto the highlevel version for debugging. (We don't verify the bytecode yet though). > > Bytecode verification btw shouldn't be too hard. You just need to make sure that all the codes are safe for the instance at hand, and for the method contexts you create. Anything else is just a runtime semantical error which you can't guarantee, since you don't know what the programmer is trying to do. We don't verify it yet since I'm still designing my register-based bytecodes; and since I atm have too much work at hand :) > > cheers, > Toon > > On 03/21/2011 02:22 PM, Igor Stasenko wrote: >> On 21 March 2011 13:14, Toon Verwaest<[hidden email]> wrote: >>> I couldn't agree more! >>> >>> However, here the problem is not that the format isn't a correct format. The >>> problem is that a bytecode is activated that is incompatible with the >>> instance format. So basically on every bytecode accessing an instance you >>> would have to check if this is a valid access. And as we all know, Smalltalk >>> avoids this; it makes things faster :) >>> >> In other words, a responsibility of having correct bytecode lies on >> image side, not on VM side. >> >> Adding a bytecode verifier to VM will be a lot of work.. And of course >> it could verify it only when you installing a method, >> not when you activating it. >> >>> Toon >>> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >>>> On 21 March 2011 11:29, Tudor Girba<[hidden email]> wrote: >>>>> Thanks, Toon! >>>>> >>>>> I changed the code to explicitly set the format, and it seems to fix the >>>>> problem: >>>>> >>>>> cls := Class new superclass: MooseElement; >>>>> setFormat: MooseElement format; >>>>> yourself. >>>>> cls compileSilently: 'mooseName ^ 1/0'. >>>>> element := cls new. >>>>> >>>>> Is this correct? >>>>> >>>> Yes, you should pay attention to have correct format. >>>> But of course VM could also be more cautios and verify if your class >>>> are well formed before creating an instance of it.. >>>> >>>> >>>> >>>>> Cheers, >>>>> Doru >>>>> >>>> >>> >>> >> >> > > |
Re: test crashing the cog vm
|
|
On Mon, Mar 21, 2011 at 7:23 PM, Stéphane Ducasse <[hidden email]> wrote: This would be a nice little topic... this bytecode verifier. Probably on top of Opal
|
|
|
On Mon, Mar 21, 2011 at 12:13 PM, Mariano Martinez Peck <[hidden email]> wrote:
The bytecode verifier must be in the VM. If it is up in the image it can be side-stepped. The VM is the ultimate executor of code and so it must apply verification. It could be written in Smalltalk and verified in Smalltalk and then translated. But it must be part of the VM and used by the VM before running any previously unverified method.
best, Eliot
|
|
|
On 21 March 2011 21:14, Eliot Miranda <[hidden email]> wrote:
> > > On Mon, Mar 21, 2011 at 12:13 PM, Mariano Martinez Peck > <[hidden email]> wrote: >> >> >> On Mon, Mar 21, 2011 at 7:23 PM, Stéphane Ducasse >> <[hidden email]> wrote: >>> >>> This would be a nice little topic... this bytecode verifier. >> >> Probably on top of Opal > > The bytecode verifier must be in the VM. If it is up in the image it can be > side-stepped. The VM is the ultimate executor of code and so it must apply > verification. It could be written in Smalltalk and verified in Smalltalk > and then translated. But it must be part of the VM and used by the VM > before running any previously unverified method. indeed > best, > Eliot >> >> >>> >>> Stef >>> >>> On Mar 21, 2011, at 2:57 PM, Toon Verwaest wrote: >>> >>> > Yes you are right! Bytecode validation would be very important here. If >>> > you ask me, the VM should only allow verified bytecode to be executed. Here >>> > it could have a dual model, where bytecodes are "internalized" whenever you >>> > give them to the VM first. At that point they are validated. Once it's >>> > internalized, it can't be modified anymore from the outside, since the >>> > Smalltalk world doesn't have direct access to the internalized version. All >>> > changes to the bytecode "source", needs to be propagated to the VM by >>> > re-internalizing it. >>> > >>> > This is exactly the model I'm using in Pinocchio... and that allows us >>> > to not use bytecodes in the first place :) You just need a way to map the >>> > internal version back onto the highlevel version for debugging. (We don't >>> > verify the bytecode yet though). >>> > >>> > Bytecode verification btw shouldn't be too hard. You just need to make >>> > sure that all the codes are safe for the instance at hand, and for the >>> > method contexts you create. Anything else is just a runtime semantical error >>> > which you can't guarantee, since you don't know what the programmer is >>> > trying to do. We don't verify it yet since I'm still designing my >>> > register-based bytecodes; and since I atm have too much work at hand :) >>> > >>> > cheers, >>> > Toon >>> > >>> > On 03/21/2011 02:22 PM, Igor Stasenko wrote: >>> >> On 21 March 2011 13:14, Toon Verwaest<[hidden email]> wrote: >>> >>> I couldn't agree more! >>> >>> >>> >>> However, here the problem is not that the format isn't a correct >>> >>> format. The >>> >>> problem is that a bytecode is activated that is incompatible with the >>> >>> instance format. So basically on every bytecode accessing an instance >>> >>> you >>> >>> would have to check if this is a valid access. And as we all know, >>> >>> Smalltalk >>> >>> avoids this; it makes things faster :) >>> >>> >>> >> In other words, a responsibility of having correct bytecode lies on >>> >> image side, not on VM side. >>> >> >>> >> Adding a bytecode verifier to VM will be a lot of work.. And of course >>> >> it could verify it only when you installing a method, >>> >> not when you activating it. >>> >> >>> >>> Toon >>> >>> >>> >>> On 03/21/2011 12:49 PM, Igor Stasenko wrote: >>> >>>> On 21 March 2011 11:29, Tudor Girba<[hidden email]> wrote: >>> >>>>> Thanks, Toon! >>> >>>>> >>> >>>>> I changed the code to explicitly set the format, and it seems to >>> >>>>> fix the >>> >>>>> problem: >>> >>>>> >>> >>>>> cls := Class new superclass: MooseElement; >>> >>>>> setFormat: MooseElement format; >>> >>>>> yourself. >>> >>>>> cls compileSilently: 'mooseName ^ 1/0'. >>> >>>>> element := cls new. >>> >>>>> >>> >>>>> Is this correct? >>> >>>>> >>> >>>> Yes, you should pay attention to have correct format. >>> >>>> But of course VM could also be more cautios and verify if your >>> >>>> class >>> >>>> are well formed before creating an instance of it.. >>> >>>> >>> >>>> >>> >>>> >>> >>>>> Cheers, >>> >>>>> Doru >>> >>>>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> > >>> > >>> >>> >> > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Eliot Miranda-2
Indeed, Mariano's response made me want to scream: NOOOOO! :) HOWEVER!, Thinking about it now, it's actually a very interesting proposal! What if we write this piece of software in Smalltak and give it to the VM as part of the VM definition. The VM decides what the application can see, so it might as well not give access to this smalltalk-written bytecode validator that it knows to be safe. If it's built by a separate classbuilder in a separate environment, it can be clearly separated, invulnerable to become: and other evil-doing. So, in short. It's written in Smalltalk (YAY!), but becomes part of the VM runtime, not of the image running on the VM. If we just make sure that we can write out image segments that the VM can use as part of its core (exactly what I do in Pinocchio incidentally), we can just develop and test it nicely in Pharo. Ain't that super-duper cool? Ok, I think I drank too much Yerba Mate. Bad bad caffeine :) cheers, Toon |
|
|
In reply to this post by Eliot Miranda-2
On Mar 22, 2011, at 12:17 AM, Toon Verwaest wrote:
If we would have solved the security problem already, then we could use it for the bytecode verifyer, too... (guarantee that nobody tampers with the verifyer). We need to reify that was makes "the VM" special and provide it for all smalltalk code. But that is of course research and completely not clear yet what it means. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
|
|
On 22 March 2011 08:55, Marcus Denker <[hidden email]> wrote:
> > On Mar 22, 2011, at 12:17 AM, Toon Verwaest wrote: > >> On Mon, Mar 21, 2011 at 7:23 PM, Stéphane Ducasse >> <[hidden email]> wrote: >>> >>> This would be a nice little topic... this bytecode verifier. >> >> Probably on top of Opal > > The bytecode verifier must be in the VM. If it is up in the image it can be > side-stepped. The VM is the ultimate executor of code and so it must apply > verification. It could be written in Smalltalk and verified in Smalltalk > and then translated. But it must be part of the VM and used by the VM > before running any previously unverified method. > best, > Eliot > > Indeed, Mariano's response made me want to scream: NOOOOO! :) > > HOWEVER!, Thinking about it now, it's actually a very interesting proposal! > What if we write this piece of software in Smalltak and give it to the VM as > part of the VM definition. The VM decides what the application can see, so > it might as well not give access to this smalltalk-written bytecode > validator that it knows to be safe. If it's built by a separate classbuilder > in a separate environment, it can be clearly separated, invulnerable to > become: and other evil-doing. So, in short. It's written in Smalltalk > (YAY!), but becomes part of the VM runtime, not of the image running on the > VM. If we just make sure that we can write out image segments that the VM > can use as part of its core (exactly what I do in Pinocchio incidentally), > we can just develop and test it nicely in Pharo. Ain't that super-duper > cool? > > > If we would have solved the security problem already, then we could use it > for the bytecode verifyer, too... (guarantee that nobody tampers with the > verifyer). > We need to reify that was makes "the VM" special and provide it for all > smalltalk code. But that is of course research and completely not clear > yet what it means. By stretching, you can treat VM as a hardware which you can't change and must follow its rules. But as someone said, hardware is an early crystallized software, which means that we can change it, but at much higher cost(s) in terms of engineering effort and time. As we hopefully approach closer to self-sustaining systems (like SqueakNOS shows) the need in VM, as a separate software layer between hardware and a language is smearing. And i would really like to see it completely disappeared at some day. There are a family of languages which is already very close to self-sustaining form - a concatenative languages, like Forth or Factor. Most of them are implemented in themselves, and have very thin layer between language and hadrware implemented in C, the rest is already in language. See http://concatenative.org/wiki/view/Factor/Optimizing%20compiler > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Best regards, Igor Stasenko AKA sig. |
Re: test crashing the cog vm
|
|
In reply to this post by Eliot Miranda-2
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 |
|
|
In reply to this post by Eliot Miranda-2
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. |
|
|
In reply to this post 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. I agree with Stef. It is not obvious for me why it has to be done at the VM. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |