On Tue, Jul 26, 2011 at 9:04 PM, Igor Stasenko <[email protected]> wrote:
> 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. > Try [1] instead of a marketing summary. What they do is severely constrain the x86 execution model and limit interaction with OS interfaces. Is it 100% safe? Probably not. [1] http://www.chromium.org/nativeclient/reference/research-papers > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
