Towards Pharo 1.0
Locked
12
12
 
|
FFI has (it seems to me) long been viewed as an evil in the Squeak community. I have no idea whether that is justified, but I have to say that the analogous features in Dolphin have been essential.
Unless there is a very good reason to exclude it, I would ask for FFI in 1.0. For myself, the next big hurdle is underscores, largely because so many of the external entities to which I would be mapping contain them. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of John M McIntosh Sent: Tuesday, February 24, 2009 12:53 PM To: Stéphane Ducasse Cc: [hidden email] Subject: Re: [Pharo-project] Towards Pharo 1.0 Well the current macintosh VM has the support code in it. I can't speak for the windows or unix version. Oomeone *has* to review the alien compiler changes and confirm they are ok, Yesterday I realized there were three class vars missing from ParseNode and 1 method from MethodNode. That I have fixed. The Pharo team has to decided if they want to make Alien (or some FFI) product part of the base system, versus the current thought of only loading FFI if you understand you need it. For Sophie loading FFI in to the base app then let us build components subclassed by operating system to provide functionality faster than doing primitives, and of course modifiable by any smalltalker. On 24-Feb-09, at 5:36 AM, Stéphane Ducasse wrote: > Hi john > > what is the work to be done to get alien in pharo? > > Stef -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Schwab,Wilhelm K wrote:
> FFI has (it seems to me) long been viewed as an evil in the Squeak > community. I have no idea whether that is justified, but I have to > say that the analogous features in Dolphin have been essential. The motiviation behind not including FFI in the "standard" image was security. FFI allows you to circumvent the Squeak sandbox. Which is only really interesting for Squeak applications that download untrusted code from somewhere (e.g. etoys projects). > > Unless there is a very good reason to exclude it, I would ask for FFI > in 1.0. For myself, the next big hurdle is underscores, largely > because so many of the external entities to which I would be mapping > contain them. I would support that, if it wasn't for Alien, which should be replacing FFI any time now :-) Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Michael,
Alien vs. FFI - it's all the same to me - I think??? Whatever you guys want to do, as long as we can connect to the outside world. The less we get tripped up by underscores in doing it, the better. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Rueger Sent: Tuesday, February 24, 2009 3:24 PM To: [hidden email] Subject: Re: [Pharo-project] Towards Pharo 1.0 Schwab,Wilhelm K wrote: > FFI has (it seems to me) long been viewed as an evil in the Squeak > community. I have no idea whether that is justified, but I have to > say that the analogous features in Dolphin have been essential. The motiviation behind not including FFI in the "standard" image was security. FFI allows you to circumvent the Squeak sandbox. Which is only really interesting for Squeak applications that download untrusted code from somewhere (e.g. etoys projects). > > Unless there is a very good reason to exclude it, I would ask for FFI > in 1.0. For myself, the next big hurdle is underscores, largely > because so many of the external entities to which I would be mapping > contain them. I would support that, if it wasn't for Alien, which should be replacing FFI any time now :-) Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Michael Rueger-6
On Feb 24, 2009, at 9:23 PM, Michael Rueger wrote: > Schwab,Wilhelm K wrote: >> FFI has (it seems to me) long been viewed as an evil in the Squeak >> community. I have no idea whether that is justified, but I have to >> say that the analogous features in Dolphin have been essential. > > The motiviation behind not including FFI in the "standard" image was > security. FFI allows you to circumvent the Squeak sandbox. by sandboxing you mean protected from squeak. You cannot access the file system if you do not have FFI Because one day we will have also to think about sandboxing pharo from its own downloaded code. > Which is only > really interesting for Squeak applications that download untrusted > code > from somewhere (e.g. etoys projects). > >> >> Unless there is a very good reason to exclude it, I would ask for FFI >> in 1.0. For myself, the next big hurdle is underscores, largely >> because so many of the external entities to which I would be mapping >> contain them. > > I would support that, if it wasn't for Alien, which should be > replacing > FFI any time now :-) > > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Concerning FFI sandboxing..
why not just add -noffi option at startup time (and similar flag to Interpreter) then simply fail all prims which trying to use FFI callouts. Then regardless of what you doing (loaded ffi code or not) you can't escape sandbox. 2009/2/24 Stéphane Ducasse <[hidden email]>: > > On Feb 24, 2009, at 9:23 PM, Michael Rueger wrote: > >> Schwab,Wilhelm K wrote: >>> FFI has (it seems to me) long been viewed as an evil in the Squeak >>> community. I have no idea whether that is justified, but I have to >>> say that the analogous features in Dolphin have been essential. >> >> The motiviation behind not including FFI in the "standard" image was >> security. FFI allows you to circumvent the Squeak sandbox. > > by sandboxing you mean protected from squeak. > You cannot access the file system if you do not have FFI > Because one day we will have also to think about sandboxing pharo from > its own > downloaded code. > >> Which is only >> really interesting for Squeak applications that download untrusted >> code >> from somewhere (e.g. etoys projects). >> >>> >>> Unless there is a very good reason to exclude it, I would ask for FFI >>> in 1.0. For myself, the next big hurdle is underscores, largely >>> because so many of the external entities to which I would be mapping >>> contain them. >> >> I would support that, if it wasn't for Alien, which should be >> replacing >> FFI any time now :-) >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Igor Stasenko wrote:
> Concerning FFI sandboxing.. > why not just add -noffi option at startup time (and similar flag to Interpreter) > then simply fail all prims which trying to use FFI callouts. > Then regardless of what you doing (loaded ffi code or not) you can't > escape sandbox. The core issue about having FFI or Alien available in the standard system is that then people start coding against it. One you go down that road, it is hard to reverse that and make a system "sandboxable". Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/2/25 Michael Rueger <[hidden email]>:
> Igor Stasenko wrote: >> Concerning FFI sandboxing.. >> why not just add -noffi option at startup time (and similar flag to Interpreter) >> then simply fail all prims which trying to use FFI callouts. >> Then regardless of what you doing (loaded ffi code or not) you can't >> escape sandbox. > > The core issue about having FFI or Alien available in the standard > system is that then people start coding against it. One you go down that > road, it is hard to reverse that and make a system "sandboxable". > sound like: a) isolationists tactics b) teaching others how to write good code i really don't like when people deciding upfront what is good or bad and don't providing any choice how to change this. This is against the spirit of smalltalk. Use java then, with its sealed classes :) > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Igor Stasenko wrote:
>> The core issue about having FFI or Alien available in the standard >> system is that then people start coding against it. One you go down that >> road, it is hard to reverse that and make a system "sandboxable". >> > > sound like: > a) isolationists tactics > b) teaching others how to write good code > > i really don't like when people deciding upfront what is good or bad > and don't providing any choice how to change this. > This is against the spirit of smalltalk. > Use java then, with its sealed classes :) I think you are missing the point. An example: in order to get the MIME type of a file on a Mac you can use a certain system call to do that. There two choices: you write or extend a plugin (sandbox safe, but a lot of work) or you use FFI/Alien (not sandbox safe, but quick to do and maintain). If FFI is not default, then people tend to do the extra work to work with a plugin. If it is available, people will avoid that extra work and I think that is absolutely legitimate and has nothing to do with good or bad code. Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/2/25 Michael Rueger <[hidden email]>:
> Igor Stasenko wrote: > >>> The core issue about having FFI or Alien available in the standard >>> system is that then people start coding against it. One you go down that >>> road, it is hard to reverse that and make a system "sandboxable". >>> >> >> sound like: >> a) isolationists tactics >> b) teaching others how to write good code >> >> i really don't like when people deciding upfront what is good or bad >> and don't providing any choice how to change this. >> This is against the spirit of smalltalk. >> Use java then, with its sealed classes :) > > I think you are missing the point. > An example: > in order to get the MIME type of a file on a Mac you can use a certain > system call to do that. There two choices: you write or extend a plugin > (sandbox safe, but a lot of work) or you use FFI/Alien (not sandbox > safe, but quick to do and maintain). > If VM in control whether allow or disallow FFI calls then you get much more security than leaving it to be handled by OS and hoping that there is no squeakFFI library in same directory where VM located or in one of the search dirs. > If FFI is not default, then people tend to do the extra work to work > with a plugin. > If it is available, people will avoid that extra work and I think that > is absolutely legitimate and has nothing to do with good or bad code. > can't take it as a strong argument. Maybe Croquet doing it in wrong way by using FFI to make GL calls. But it was ultimately their own choice. To encourage people to write a plugins instead of use of FFI, a better way would be to improve VMMaker tool and simplify VM building procedure. But limiting people from use of FFI in hope that they eventually start writing plugins i think is spoiled idea. > Michael > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
What about more generic security rule:
- allow/deny to use external modules ? then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure. As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :) -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Sig,
If I am following, then the command line flag you describe is the only way to be certain anyway. Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair?? Of course, there are evils, and then there are evils. Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Besides, if you don't want things crashing, what are you doing on Windows? :) Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 7:02 PM To: [hidden email] Subject: Re: [Pharo-project] Towards Pharo 1.0 What about more generic security rule: - allow/deny to use external modules ? then VM could simply check this flag at attempt of loading ANY external module - be it plugin or something else. Then, it is safe to ship VM with FFI built-in, and you can even run FFI tests, because test functions will be sitting inside a VM but not in an external library. But once you try to make a call which requires loading new dynamic library - you will have a primitive failure. As you maybe know, in windows, when you loading a .dll, OS calling a DllMain function. And there are a chance that it can do something evil, what may crash VM and your sandbox is no longer a sandbox :) -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/2/25 Schwab,Wilhelm K <[hidden email]>:
> Sig, > > If I am following, then the command line flag you describe is the only way to be certain anyway. Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair?? > Yes (except that i can't parse 'and one's head is in the sandbox at that point'). > Of course, there are evils, and then there are evils. Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Besides, if you don't want things crashing, what are you doing on Windows? :) who said that my Windows is crashy? ;) My box crashing only on power grid failures, which happens maybe once in a month. My old UPS is dead and i'm too lazy to buy new one. > > Bill > > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko > Sent: Tuesday, February 24, 2009 7:02 PM > To: [hidden email] > Subject: Re: [Pharo-project] Towards Pharo 1.0 > > What about more generic security rule: > - allow/deny to use external modules ? > > then VM could simply check this flag at attempt of loading ANY > external module - be it plugin or something else. > Then, it is safe to ship VM with FFI built-in, and you can even run > FFI tests, because test functions will be sitting inside a VM but not > in an external library. > But once you try to make a call which requires loading new dynamic > library - you will have a primitive failure. > > As you maybe know, in windows, when you loading a .dll, OS calling a > DllMain function. And there are a chance that it can do something > evil, what may crash VM and your sandbox is no longer a sandbox :) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Sig,
"Head in the sandbox" is a play on words on "head in the sand." Perhaps it is a cultural thing - it refers to the (mythical) comforting yet pointless behavior of an ostrich: http://www.phrases.org.uk/meanings/80800.html Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko Sent: Tuesday, February 24, 2009 8:24 PM To: [hidden email] Subject: Re: [Pharo-project] Towards Pharo 1.0 2009/2/25 Schwab,Wilhelm K <[hidden email]>: > Sig, > > If I am following, then the command line flag you describe is the only way to be certain anyway. Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair?? > Yes (except that i can't parse 'and one's head is in the sandbox at that point'). > Of course, there are evils, and then there are evils. Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Besides, if you don't want things crashing, what are you doing on Windows? :) who said that my Windows is crashy? ;) My box crashing only on power grid failures, which happens maybe once in a month. My old UPS is dead and i'm too lazy to buy new one. > > Bill > > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko > Sent: Tuesday, February 24, 2009 7:02 PM > To: [hidden email] > Subject: Re: [Pharo-project] Towards Pharo 1.0 > > What about more generic security rule: > - allow/deny to use external modules ? > > then VM could simply check this flag at attempt of loading ANY > external module - be it plugin or something else. > Then, it is safe to ship VM with FFI built-in, and you can even run > FFI tests, because test functions will be sitting inside a VM but not > in an external library. > But once you try to make a call which requires loading new dynamic > library - you will have a primitive failure. > > As you maybe know, in windows, when you loading a .dll, OS calling a > DllMain function. And there are a chance that it can do something > evil, what may crash VM and your sandbox is no longer a sandbox :) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/2/25 Schwab,Wilhelm K <[hidden email]>:
> Sig, > > "Head in the sandbox" is a play on words on "head in the sand." Perhaps it is a cultural thing - it refers to the (mythical) comforting yet pointless behavior of an ostrich: > :) > http://www.phrases.org.uk/meanings/80800.html > > Bill > > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko > Sent: Tuesday, February 24, 2009 8:24 PM > To: [hidden email] > Subject: Re: [Pharo-project] Towards Pharo 1.0 > > 2009/2/25 Schwab,Wilhelm K <[hidden email]>: >> Sig, >> >> If I am following, then the command line flag you describe is the only way to be certain anyway. Otherwise, one could fall victim to an FFI library that happens to be visible to the vm, and one's head is in the sandbox at that point - fair?? >> > Yes (except that i can't parse 'and one's head is in the sandbox at > that point'). > >> Of course, there are evils, and then there are evils. Things like openssl are unlikely to go wrong in my experience, and they offer functionality that is hard to replace, and stature that might be impossible to replace (we want _that_ library...). Besides, if you don't want things crashing, what are you doing on Windows? :) > > who said that my Windows is crashy? ;) > My box crashing only on power grid failures, which happens maybe once > in a month. My old UPS is dead and i'm too lazy to buy new one. > >> >> Bill >> >> >> >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko >> Sent: Tuesday, February 24, 2009 7:02 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Towards Pharo 1.0 >> >> What about more generic security rule: >> - allow/deny to use external modules ? >> >> then VM could simply check this flag at attempt of loading ANY >> external module - be it plugin or something else. >> Then, it is safe to ship VM with FFI built-in, and you can even run >> FFI tests, because test functions will be sitting inside a VM but not >> in an external library. >> But once you try to make a call which requires loading new dynamic >> library - you will have a primitive failure. >> >> As you maybe know, in windows, when you loading a .dll, OS calling a >> DllMain function. And there are a chance that it can do something >> evil, what may crash VM and your sandbox is no longer a sandbox :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |