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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Yoshiki Ohshima-2
 
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
Reply | Threaded
Open this post in threaded view
|

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

johnmci
 
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
=
=
=
========================================================================




Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
 
Very good, John. That does seem to fix it. Yoshiki, I think I can build
a new version over the weekend if you like.

Cheers,
   - Andreas

John M McIntosh wrote:

>
> 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
> ===========================================================================
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by johnmci
 
Hi John

  ok, I get it.  Ignore the previous message.  Apologies.

On Fri, Jul 10, 2009 at 11:29 AM, John M McIntosh <[hidden email]> wrote:

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
===========================================================================





Reply | Threaded
Open this post in threaded view
|

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

Yoshiki Ohshima-2
In reply to this post by Andreas.Raab
 
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
Reply | Threaded
Open this post in threaded view
|

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

johnmci
 
Mantis report is

http://bugs.squeak.org/view.php?id=7349


On 10-Jul-09, at 12:03 PM, Yoshiki Ohshima wrote:

>
> 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

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================