On 26 July 2011 23:04, BGB <[email protected]> wrote: > On 7/26/2011 5:34 AM, Igor Stasenko wrote: >> >> On 26 July 2011 05:21, Alan Kay<[email protected]> wrote: >>> >>> Again good points. >>> >>> Java itself could have been fixed if it were not for the Sun marketing >>> people who rushed "the electronic toaster language" out where it was not >>> fit >>> to go. Sun was filled with computerists who knew what they were doing, >>> but >>> it was quickly too late. >>> >>> And you are right about Mark Miller. >>> >>> My complaint is not about JS per se, but about whether it is possible to >>> get >>> all the cycles the computer has for certain purposes. One of the main >>> unnecessary violations of the spirit of computing in the web is that it >>> wasn't set up to allow safe access to the whole machine -- despite this >>> being the goal of good OS design since the mid-60s. >>> >> Indeed. And the only lucky players in the field who can access raw >> machine power is plugins like Flash. >> And only because they gained enough trust as being "well safe". >> As for the rest of developers (if they are not using existing >> mechanisms in browser) the computer's resources still closed behind >> solid fence. >> >> Another interesting fact that while we having a hardware which can do >> virtualization (not saying about software), >> the only application of it which adopted widely is to run one >> operating system inside another, host one. >> >> But hey, things could be much more lightweight! >> For instance , look at SqueakNOS project. Its boot time is like 10-15 >> seconds (and most of it not belongs to SqueakNOS itself but to bios >> and boot loader). >> >> So, it remains a mystery to me, why we cannot use web+virtualization. >> It seems like a good balance between accessing raw machine power and >> being safe at the same time. >> >> I hope that NaCl partly using it , but then i wonder why they spending >> an effort to validate native code, because if something vent wrong, >> you can just kill it or freeze it (or do anything which virtualization >> allow you to do), >> without any chance of putting host system in danger. > > because NaCl was not built on virtualization... from what I heard it was > built on using segmented memory. > > the problem then is that unverified code could potentially far-pointer its > way right out of the sandbox. > > Hmm. As they mentioning on this page: ------ http://code.google.com/games/technology-nacl.html
Native Client is a sandboxing system. It runs code in a virtual environment where all OS calls are intercepted by the NaCl runtime. This has two benefits. First, it enhances security by preventing untrusted code from making dangerous use of the operating system. Second, because OS calls are virtualized, NaCl code is OS-independent. You can run the same binary executable on MacOS, Linux, and Windows. But syscall virtualization by itself wouldn't be as secure as Javascript, because clever hackers can always find ways to exit the sandbox. NaCl's real contribution is a software verification system that scans each executable module before it runs. The verifier imposes a set of constraints on the program that prevent the code from exiting the sandbox. This security comes at a relatively small performance price, with NaCl code generally running at about 95% the speed of equivalent compiled code. ------ so, it leaves me clueless, how it can escape the sandbox if you are intercepting all system calls. And what level of safety will give you a static analyzis, if your NaCl could be a Virtual Machine with JIT - so potentially it could generate and run arbitrary native code. Or can download the code from internet and then execute it. > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
