Re: [squeakland] Re: [Fwd: Re: New Etoys installer for testing]

>
> At Fri, 10 Jul 2009 00:10:10 -0700,
> Andreas Raab wrote:
> >
> > The installer works fine but once I've installed it I get VM crashes
> > when trying to use the plugin a browser, regardless of which browser
> > (Firefox, IE7, Chrome).
> >
> > The crashes are extremely similar, see below:
>
>   Thank you for testing.  I do get the crash, actually, too.
>
>   One theory floating was OggPlugin, but removing it seems to take any
> effect.  As the debug log suggests, it could be in the security
> plugin.  I wonder what has changed.  I'll look into it.

>
> At Fri, 10 Jul 2009 08:26:49 -0700,
> Yoshiki Ohshima wrote:
>>
>> At Fri, 10 Jul 2009 00:10:10 -0700,
>> Andreas Raab wrote:
>>>
>>> The installer works fine but once I've installed it I get VM crashes
>>> when trying to use the plugin a browser, regardless of which browser
>>> (Firefox, IE7, Chrome).
>>>
>>> The crashes are extremely similar, see below:
>>
>>  Thank you for testing.  I do get the crash, actually, too.
>>
>>  One theory floating was OggPlugin, but removing it seems to take any
>> effect.  As the debug log suggests, it could be in the security
>> plugin.  I wonder what has changed.  I'll look into it.
>
>  It works fine with the VM we used to distribute with the previous
> public installer, which claim to be 3.10.10 but I think with some
> modification on the SecurityPlugin where it expands the
> pseudo-variables like %MYDOCUMENTS% in etoys.ini.  (But after
> substituting them in the .ini files it still crashes, so the expanding
> them may not be a problem.)
>
>  If I put self halt in #enterRestrictedMode and step execute it, it
> goes through fine.  It seems to suggest that some stack unbalance in a
> primitive (disableFileAccess or disableImageWrite) may be the issue.
>
>  For the interest of release time, I think I put up an installer with
> the old VM for now, and look into the difference from it and 3.11.2
> VM.
>
> -- Yoshiki

> From: John M McIntosh <[hidden email]>
> Date: May 3, 2009 1:58:29 PM PDT (CA)
> To: Andreas Raab <[hidden email]>
> Subject: Fwd: Squeak crash
>
>
>
> Sent from my iPhone
>
> Begin forwarded message:
>
>> From: John McIntosh <[hidden email]>
>> Date: May 3, 2009 1:43:21 PM PDT (CA)
>> To: Eliot Miranda <[hidden email]>
>> Cc: Bert Freudenberg <[hidden email]>
>> Subject: Re: Squeak crash
>>
>> Ok I'm older and wiser this morning now if I had turned check for
>> balanced stacks about a day ago the answer would be clearer.It seem
>> the code in disable read write pops the stack which unbalanced it.
>> Then the push literal sticks that constant in but then the method
>> return true uses that as the content index where in the past that  
>> slot
>> wasn't used or critical, so now you die
>>
>> I think andreas wrote the original security code, also was there not
>> some recovery code for unbalanced stacks somewhere?  My concern is
>> there other example of this which we not yet crashed over. So how
>> would we fix the VM to avoid? Or do we need to check all the plugin
>> prim code for coding issues.
>>
>> On 5/2/09, John M McIntosh <[hidden email]> wrote:
>>>
>>> On 30-Apr-09, at 9:12 AM, Eliot Miranda wrote:
>>>
>>>> John,
>>>>
>>>>    I owuld run under gdb, put a halt somehwere after the context is
>>>> created and before the primitive is called at put a watch on the
>>>> address of closureOrNil.
>>>
>>> Ok, I'm older, but not sure I"m wiser...  However
>>>
>>> what i did is use some of the message send tracing code to break at
>>> the point of the enterRestrictedMode send, then look at the method
>>> contexts being allocated.
>>> A quick check showed the message context was the third back from the
>>> point of break on message send of enterRestrictedMode/
>>>
>>> problem context is at
>>> S2077c9cc   <----- third back
>>> S207a1644
>>> S207a16a0(gdb) hereweare
>>> Undefined command: "hereweare".  Try "help".
>>> (gdb) 1f4367a4  is the problem at 0x14 from 2077c9cc
>>> 5f e3 9a 05 80 bc 77 20 e3 00 00 00 01 00 00 00
>>> 80 86 42 20 a4 67 43 1f 30 3b 8f 1f 30 3b 8f 1f
>>>
>>> method is
>>> enterRestrictedMode
>>>
>>> run again, now the context is 0x2077ceac, a set up of a
>>> watch location for 0x14 from the start of the context triggers on  
>>> the
>>> longAtPointerput.
>>>
>>>        CASE(81)
>>>            /* pushLiteralVariableBytecode */
>>>            {
>>>                flag("requires currentBytecode to be expanded to a  
>>> constant");
>>>                /* begin fetchNextBytecode */
>>>                currentBytecode = byteAtPointer(++localIP);
>>>                /* begin pushLiteralVariable: */
>>>                /* begin internalPush: */
>>>                longAtPointerput(localSP += BytesPerWord,  
>>> longAt(((longAt((foo-
>>>> method + BaseHeaderSize) + (((81 & 31) + LiteralStart) <<
>>> ShiftForWord))) + BaseHeaderSize) + (ValueIndex << ShiftForWord)));
>>>            }
>>> ;
>>>
>>>
>>> localReturnContext is 0x2077ceac
>>> localHomeContext is 0x2077ceac
>>> local SP is 0x2077cec0
>>> local IP is 0x204286fc
>>> currentByteCode is 112
>>>
>>> which stuffs 0x1f4367a4 into 0x2077cec0 which
>>> is offset 0x14 in localReturnContext
>>>
>>> then on the returnTrue for context 0x2077ceac we see the 0x1f4367a4
>>> and start the while loop until we get a memory exception...
>>>
>>> So let's look at the code.
>>>
>>> enterRestrictedMode
>>>    "Some insecure contents was encountered. Close all doors and  
>>> proceed."
>>>    self isInRestrictedMode ifTrue:[^true].
>>>    (SugarLauncher isRunningInRainbow or: [Preferences
>>> securityChecksEnabled not]) ifTrue: [^true]. "it's been your  
>>> choice..."
>>>    Preferences warnAboutInsecureContent ifTrue:[
>>>        (PopUpMenu confirm:
>>> 'You are about to load some insecure content.
>>> If you continue, access to files as well as
>>> some other capabilities will be limited.' translated
>>>            trueChoice:'Load it anyways' translated
>>>            falseChoice:'Do not load it' translated) ifFalse:[
>>>                "user doesn't really want it"
>>>                ^false.
>>>            ].
>>>    ].
>>>    "here goes the actual restriction"
>>>    self flushSecurityKeys.
>>>    self disableFileAccess.
>>>    self disableImageWrite.
>>>    "self disableSocketAccess."
>>>    FileDirectory setDefaultDirectory: self untrustedUserDirectory.
>>>    ^true
>>>
>>> I note we are at case(81) which is hex 51 which I guess would be the
>>> 120 <51> pushLit: FileDirectory
>>>
>>> 81 <70> self
>>> 82 <D0> send: isInRestrictedMode
>>> 83 <98> jumpFalse: 85
>>> 84 <79> return: true
>>> 85 <45> pushLit: SugarLauncher
>>> 86 <D4> send: isRunningInRainbow
>>> 87 <99> jumpFalse: 90
>>> 88 <71> pushConstant: true
>>> 89 <92> jumpTo: 93
>>> 90 <43> pushLit: Preferences
>>> 91 <D2> send: securityChecksEnabled
>>> 92 <D1> send: not
>>> 93 <98> jumpFalse: 95
>>> 94 <79> return: true
>>> 95 <43> pushLit: Preferences
>>> 96 <DC> send: warnAboutInsecureContent
>>> 97 <AC 0C> jumpFalse: 111
>>> 99 <47> pushLit: PopUpMenu
>>> 100 <29> pushConstant: 'You are about to load some insecure content.
>>> If you continue, access to files as well as
>>> some other capabilities will be limited.'
>>> 101 <D8> send: translated
>>> 102 <2A> pushConstant: 'Load it anyways'
>>> 103 <D8> send: translated
>>> 104 <2B> pushConstant: 'Do not load it'
>>> 105 <D8> send: translated
>>> 106 <83 66> send: confirm:trueChoice:falseChoice:
>>> 108 <A8 01> jumpTrue: 111
>>> 110 <7A> return: false
>>> 111 <70> self
>>> 112 <DD> send: flushSecurityKeys
>>> 113 <87> pop
>>> 114 <70> self
>>> 115 <DE> send: disableFileAccess
>>> 116 <87> pop
>>> 117 <70> self
>>> 118 <DF> send: disableImageWrite
>>> 119 <87> pop
>>> 120 <51> pushLit: FileDirectory
>>> 121 <70> self
>>> 122 <83 12> send: untrustedUserDirectory
>>> 124 <83 30> send: setDefaultDirectory:
>>> 126 <87> pop
>>> 127 <79> return: true
>>>
>>> Let's see if anything looks interesting
>>>
>>>  disableImageWrite
>>>    "SecurityManager default disableImageWrite"
>>>    "Primitive. Disable writing to an image file.
>>>    Cannot be revoked from the image."
>>>    <primitive: 'primitiveDisableImageWrite' module:  
>>> 'SecurityPlugin'>
>>>    ^self primitiveFailed
>>>
>>> EXPORT(sqInt) primitiveDisableImageWrite(void) {
>>>    ioDisableImageWrite();
>>>    if (!(interpreterProxy->failed())) {
>>>        interpreterProxy->pop(1);
>>>    }
>>> }
>>>
>>>
>>> int ioDisableImageWrite() {
>>>   allowImageWrite = 0;
>>>    return 0;
>>> }
>>>
>>>
>>> disableFileAccess
>>>    "SecurityManager default disableFileAccess"
>>>    "Primitive. Disable unlimited access to files.
>>>    Cannot be revoked from the image."
>>>    <primitive: 'primitiveDisableFileAccess' module: 'FilePlugin'>
>>>    ^self primitiveFailed
>>>
>>>
>>> EXPORT(sqInt) primitiveDisableFileAccess(void) {
>>>    if (sDFAfn != 0) {
>>>         ((sqInt (*)(void))sDFAfn)();
>>>    }
>>>    if (!(interpreterProxy->failed())) {
>>>        interpreterProxy->pop(1);
>>>    }
>>> }
>>>
>>>    sDFAfn = interpreterProxy-
>>> >ioLoadFunctionFrom("secDisableFileAccess",
>>> "SecurityPlugin");
>>>
>>>
>>> EXPORT(sqInt) secDisableFileAccess(void) {
>>>    return ioDisableFileAccess();
>>> }
>>>
>>> /* disabling/querying */
>>> int ioDisableFileAccess(void) {
>>>   allowFileAccess = 0;
>>>  return 0;
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ====================================================================
>>> John M. McIntosh <[hidden email]>   Twitter:
>>> squeaker68882
>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ====================================================================
>>>
>>>
>>>
>>>
>>>
>>

>
> As a reminder if this is being executed on a closure VM there is a bug
> in the VM where interacting with the SecurityPlugin
> can cause the VM to crash even if the image is not a closure based  
> image.  I attached the earlier note detailing this problem
>
> On 10-Jul-09, at 10:16 AM, Yoshiki Ohshima wrote:
>
>>
>> At Fri, 10 Jul 2009 08:26:49 -0700,
>> Yoshiki Ohshima wrote:
>>>
>>> At Fri, 10 Jul 2009 00:10:10 -0700,
>>> Andreas Raab wrote:
>>>>
>>>> The installer works fine but once I've installed it I get VM crashes
>>>> when trying to use the plugin a browser, regardless of which browser
>>>> (Firefox, IE7, Chrome).
>>>>
>>>> The crashes are extremely similar, see below:
>>>
>>>  Thank you for testing.  I do get the crash, actually, too.
>>>
>>>  One theory floating was OggPlugin, but removing it seems to take any
>>> effect.  As the debug log suggests, it could be in the security
>>> plugin.  I wonder what has changed.  I'll look into it.
>>
>>  It works fine with the VM we used to distribute with the previous
>> public installer, which claim to be 3.10.10 but I think with some
>> modification on the SecurityPlugin where it expands the
>> pseudo-variables like %MYDOCUMENTS% in etoys.ini.  (But after
>> substituting them in the .ini files it still crashes, so the expanding
>> them may not be a problem.)
>>
>>  If I put self halt in #enterRestrictedMode and step execute it, it
>> goes through fine.  It seems to suggest that some stack unbalance in a
>> primitive (disableFileAccess or disableImageWrite) may be the issue.
>>
>>  For the interest of release time, I think I put up an installer with
>> the old VM for now, and look into the difference from it and 3.11.2
>> VM.
>>
>> -- Yoshiki
>
>
>
> ----------
>
> Begin forwarded message:
>
>> From: John M McIntosh <[hidden email]>
>> Date: May 3, 2009 1:58:29 PM PDT (CA)
>> To: Andreas Raab <[hidden email]>
>> Subject: Fwd: Squeak crash
>>
>>
>>
>> Sent from my iPhone
>>
>> Begin forwarded message:
>>
>>> From: John McIntosh <[hidden email]>
>>> Date: May 3, 2009 1:43:21 PM PDT (CA)
>>> To: Eliot Miranda <[hidden email]>
>>> Cc: Bert Freudenberg <[hidden email]>
>>> Subject: Re: Squeak crash
>>>
>>> Ok I'm older and wiser this morning now if I had turned check for
>>> balanced stacks about a day ago the answer would be clearer.It seem
>>> the code in disable read write pops the stack which unbalanced it.
>>> Then the push literal sticks that constant in but then the method
>>> return true uses that as the content index where in the past that slot
>>> wasn't used or critical, so now you die
>>>
>>> I think andreas wrote the original security code, also was there not
>>> some recovery code for unbalanced stacks somewhere?  My concern is
>>> there other example of this which we not yet crashed over. So how
>>> would we fix the VM to avoid? Or do we need to check all the plugin
>>> prim code for coding issues.
>>>
>>> On 5/2/09, John M McIntosh <[hidden email]> wrote:
>>>>
>>>> On 30-Apr-09, at 9:12 AM, Eliot Miranda wrote:
>>>>
>>>>> John,
>>>>>
>>>>>    I owuld run under gdb, put a halt somehwere after the context is
>>>>> created and before the primitive is called at put a watch on the
>>>>> address of closureOrNil.
>>>>
>>>> Ok, I'm older, but not sure I"m wiser...  However
>>>>
>>>> what i did is use some of the message send tracing code to break at
>>>> the point of the enterRestrictedMode send, then look at the method
>>>> contexts being allocated.
>>>> A quick check showed the message context was the third back from the
>>>> point of break on message send of enterRestrictedMode/
>>>>
>>>> problem context is at
>>>> S2077c9cc   <----- third back
>>>> S207a1644
>>>> S207a16a0(gdb) hereweare
>>>> Undefined command: "hereweare".  Try "help".
>>>> (gdb) 1f4367a4  is the problem at 0x14 from 2077c9cc
>>>> 5f e3 9a 05 80 bc 77 20 e3 00 00 00 01 00 00 00
>>>> 80 86 42 20 a4 67 43 1f 30 3b 8f 1f 30 3b 8f 1f
>>>>
>>>> method is
>>>> enterRestrictedMode
>>>>
>>>> run again, now the context is 0x2077ceac, a set up of a
>>>> watch location for 0x14 from the start of the context triggers on the
>>>> longAtPointerput.
>>>>
>>>>        CASE(81)
>>>>            /* pushLiteralVariableBytecode */
>>>>            {
>>>>                flag("requires currentBytecode to be expanded to a
>>>> constant");
>>>>                /* begin fetchNextBytecode */
>>>>                currentBytecode = byteAtPointer(++localIP);
>>>>                /* begin pushLiteralVariable: */
>>>>                /* begin internalPush: */
>>>>                longAtPointerput(localSP += BytesPerWord,
>>>> longAt(((longAt((foo-
>>>>> method + BaseHeaderSize) + (((81 & 31) + LiteralStart) <<
>>>> ShiftForWord))) + BaseHeaderSize) + (ValueIndex << ShiftForWord)));
>>>>            }
>>>> ;
>>>>
>>>>
>>>> localReturnContext is 0x2077ceac
>>>> localHomeContext is 0x2077ceac
>>>> local SP is 0x2077cec0
>>>> local IP is 0x204286fc
>>>> currentByteCode is 112
>>>>
>>>> which stuffs 0x1f4367a4 into 0x2077cec0 which
>>>> is offset 0x14 in localReturnContext
>>>>
>>>> then on the returnTrue for context 0x2077ceac we see the 0x1f4367a4
>>>> and start the while loop until we get a memory exception...
>>>>
>>>> So let's look at the code.
>>>>
>>>> enterRestrictedMode
>>>>    "Some insecure contents was encountered. Close all doors and
>>>> proceed."
>>>>    self isInRestrictedMode ifTrue:[^true].
>>>>    (SugarLauncher isRunningInRainbow or: [Preferences
>>>> securityChecksEnabled not]) ifTrue: [^true]. "it's been your choice..."
>>>>    Preferences warnAboutInsecureContent ifTrue:[
>>>>        (PopUpMenu confirm:
>>>> 'You are about to load some insecure content.
>>>> If you continue, access to files as well as
>>>> some other capabilities will be limited.' translated
>>>>            trueChoice:'Load it anyways' translated
>>>>            falseChoice:'Do not load it' translated) ifFalse:[
>>>>                "user doesn't really want it"
>>>>                ^false.
>>>>            ].
>>>>    ].
>>>>    "here goes the actual restriction"
>>>>    self flushSecurityKeys.
>>>>    self disableFileAccess.
>>>>    self disableImageWrite.
>>>>    "self disableSocketAccess."
>>>>    FileDirectory setDefaultDirectory: self untrustedUserDirectory.
>>>>    ^true
>>>>
>>>> I note we are at case(81) which is hex 51 which I guess would be the
>>>> 120 <51> pushLit: FileDirectory
>>>>
>>>> 81 <70> self
>>>> 82 <D0> send: isInRestrictedMode
>>>> 83 <98> jumpFalse: 85
>>>> 84 <79> return: true
>>>> 85 <45> pushLit: SugarLauncher
>>>> 86 <D4> send: isRunningInRainbow
>>>> 87 <99> jumpFalse: 90
>>>> 88 <71> pushConstant: true
>>>> 89 <92> jumpTo: 93
>>>> 90 <43> pushLit: Preferences
>>>> 91 <D2> send: securityChecksEnabled
>>>> 92 <D1> send: not
>>>> 93 <98> jumpFalse: 95
>>>> 94 <79> return: true
>>>> 95 <43> pushLit: Preferences
>>>> 96 <DC> send: warnAboutInsecureContent
>>>> 97 <AC 0C> jumpFalse: 111
>>>> 99 <47> pushLit: PopUpMenu
>>>> 100 <29> pushConstant: 'You are about to load some insecure content.
>>>> If you continue, access to files as well as
>>>> some other capabilities will be limited.'
>>>> 101 <D8> send: translated
>>>> 102 <2A> pushConstant: 'Load it anyways'
>>>> 103 <D8> send: translated
>>>> 104 <2B> pushConstant: 'Do not load it'
>>>> 105 <D8> send: translated
>>>> 106 <83 66> send: confirm:trueChoice:falseChoice:
>>>> 108 <A8 01> jumpTrue: 111
>>>> 110 <7A> return: false
>>>> 111 <70> self
>>>> 112 <DD> send: flushSecurityKeys
>>>> 113 <87> pop
>>>> 114 <70> self
>>>> 115 <DE> send: disableFileAccess
>>>> 116 <87> pop
>>>> 117 <70> self
>>>> 118 <DF> send: disableImageWrite
>>>> 119 <87> pop
>>>> 120 <51> pushLit: FileDirectory
>>>> 121 <70> self
>>>> 122 <83 12> send: untrustedUserDirectory
>>>> 124 <83 30> send: setDefaultDirectory:
>>>> 126 <87> pop
>>>> 127 <79> return: true
>>>>
>>>> Let's see if anything looks interesting
>>>>
>>>>  disableImageWrite
>>>>    "SecurityManager default disableImageWrite"
>>>>    "Primitive. Disable writing to an image file.
>>>>    Cannot be revoked from the image."
>>>>    <primitive: 'primitiveDisableImageWrite' module: 'SecurityPlugin'>
>>>>    ^self primitiveFailed
>>>>
>>>> EXPORT(sqInt) primitiveDisableImageWrite(void) {
>>>>    ioDisableImageWrite();
>>>>    if (!(interpreterProxy->failed())) {
>>>>        interpreterProxy->pop(1);
>>>>    }
>>>> }
>>>>
>>>>
>>>> int ioDisableImageWrite() {
>>>>   allowImageWrite = 0;
>>>>    return 0;
>>>> }
>>>>
>>>>
>>>> disableFileAccess
>>>>    "SecurityManager default disableFileAccess"
>>>>    "Primitive. Disable unlimited access to files.
>>>>    Cannot be revoked from the image."
>>>>    <primitive: 'primitiveDisableFileAccess' module: 'FilePlugin'>
>>>>    ^self primitiveFailed
>>>>
>>>>
>>>> EXPORT(sqInt) primitiveDisableFileAccess(void) {
>>>>    if (sDFAfn != 0) {
>>>>         ((sqInt (*)(void))sDFAfn)();
>>>>    }
>>>>    if (!(interpreterProxy->failed())) {
>>>>        interpreterProxy->pop(1);
>>>>    }
>>>> }
>>>>
>>>>    sDFAfn =
>>>> interpreterProxy->ioLoadFunctionFrom("secDisableFileAccess",
>>>> "SecurityPlugin");
>>>>
>>>>
>>>> EXPORT(sqInt) secDisableFileAccess(void) {
>>>>    return ioDisableFileAccess();
>>>> }
>>>>
>>>> /* disabling/querying */
>>>> int ioDisableFileAccess(void) {
>>>>   allowFileAccess = 0;
>>>>  return 0;
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> =
>>>> =
>>>> =
>>>> ========================================================================
>>>>
>>>> John M. McIntosh <[hidden email]>   Twitter:
>>>> squeaker68882
>>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>>> =
>>>> =
>>>> =
>>>> ========================================================================
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>

>
> At Fri, 10 Jul 2009 11:51:00 -0700,
> Andreas Raab wrote:
>>
>> Very good, John. That does seem to fix it. Yoshiki, I think I can  
>> build
>> a new version over the weekend if you like.
>
>  Thank you, guys.  I didn't know that it was a known problem after
> all, but I guessed it right^^;
>
> Yes, Andreas, a fixed and official VM is really helpful.
>
> -- Yoshiki