Slashdot Mirror
Google x86 Native Browser Client Maybe Not So Crazy After All
GMGruman writes "Google's experimental technology to run native x86 binaries in the browser shows lots of potential, writes Neil McAllister. He's previously said it was a crazy idea, but a new version of Native Client (NaCl) caused McAllister to take a fresh look, which has led him to conclude the technology is crazy like a fox. McAllister explains what NaCl is useful for, how to use it, and why it's not a Java or a Flash or a JavaScript replacement, but something else."
Hopefully Google will make this more secure than ActiveX.
If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time.
This sounds suspiciously like Microsoft's foray into native binaries with ActiveX technology and COM.
Can't wait for this thing to get hooked to App Engine once they are both stable enough. The results will likely be breathtaking, to say the least.
I am qualified to comment because I have skimmed the article summary. Furthermore, I know perfectly well that any time a browser allows for new features, it's a way to get hacked by eastern bloc countries. Finally, I can't remember why I was angry in the first place, but I can guarantee you that if whatever it was is also the reason the honeybees have been dying off. I am getting so sick of this stuff!
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
So a proprietary, but open SDK to run native binaries on one vendors browser. What could possibly go wrong?
I hope Google put a heck of a lot more effort into security/sandbox issues than Microsoft did or I'm going to have to start telling people to never install Chrome. ActiveX was the best attack vector for Windows for the longest time, and as far as I know it's still pretty effective against the great unwashed who will click anything to make a dialog go away.
XML is a known as a key material required to create SMD: Software of Mass Destruction
The article is light on details, but they do say that the executables are contained in .nexe files which are apparently NOT your run-of-the-mill PE format, so they can't just execute from a double click. And they do say that there's this annoying multi-second lag as the thing fires up. From this, I assume they are doing dynamic code instrumentation to implement whatever security measures they have in place.
If done correctly, this can be secure. I've been working with Intel's Pin library a lot lately, mostly for security-related projects. With these sorts of things you can intercept all memory accesses, function calls, system calls, instrument and analyze arbitrary instructions in arbitrary ways, etc. Again, if done correctly a dynamic instrumentation approach could make this idea viable. But you'd need a very skilled team to do it right.
That might take 10,000 lines of code. What are the chances of an error in that?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Yes. The media framework (audio, OpenGL, etc) is called Pepper.
What is with this urge over the last decade to make the browser an OS?
I already have an OS. It plays movies, games, and anything else I throw at it. I don't need to run a 2nd OS on top of it to replicate the functions of the original.
Maybe we can come up with something to replace the browser that runs inside our current browser and then replicate everything again. If we can replicate functions twice, why not three or more times?
"Disobedience is the true foundation of liberty. The obedient must be slaves. " ---Henry David Thoreau
I use it all the time... I put it on french fries. I spread a lot of it on my driveway and sidewalk this year. The only real drawback is the high blood pressure that can result if you consume too much of it.
Brawndo: It's what plants crave!
I too am qualified to comment. I'm not fully convinced it's a great idea, but I like the idea of running "next to the hardware" code in a sandbox (the browser). It's sort-of the best of virtualization (sandbox, controlled by the browser) and C-style performance.
I don't see this as something that would be extensively used on a lot of web sites, and there are potential security issues that need to be scrutinized, but it's another tool available to developers. I like it.
Basically this technology turns the browser from a platform-independent, architecture-independent development platform into an architecture-dependent one. That is, if somebody developed their little app for Intel and I'm on a Mac or Arm, the app won't work for me.
From where I stand, that's no better than being forced to VNC into a Windows box just so that I can access an ActiveX based site which will only run on Explorer.
ActiveX also is a nice case study to show what the tech would be used for- which is, about 50% of the time to exploit security holes, and 49% of the time, to do stuff that could just as well have been accomplished through W3C standards or (much more portable) Java.
Bad idea. *flush*
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
I'm NOT running an x86 capable processor...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Why not just work on making JS more efficient, and if needed, give it more capability?
Applets were explored in the past and died because they were not what people wanted..
MABASPLOOM!
Well, it is for pouring on the wounds of browser security
PocketPermissions Android Permission Guide
Bowser! Come here boy!
Oh wait...
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
That's been around for a while. x86 machine code has to be written in a special way which prevents certain problems, such as buffer overflows into return addresses. Google has a modified GCC for this. Read the research paper. It uses the rarely-used segmentation protection features of x86 CPUs to help provide an inner section of sandboxing. That's not enough, though; static analysis of the code, to check that all branches go to valid instructions, is necessary. This works much like the Java byte code verifier, the checker that runs as Java code loads. All returns and calls have to go through some extra code to insure that control goes where it is supposed to.
The 64-bit extensions to the x86 instruction set don't have the segmentation machinery. The AMD designer of that mode once told me "nobody uses that". So this approach doesn't translate well to 64-bit code, and all code under this system runs in 32 bit mode.
This comes with an API and an OS shim. Executable modules can make about a hundred system calls, which are portable across Windows and Linux. In the original version, you couldn't get at the graphics hardware, so it wasn't a suitable delivery mechanism for games. But now, Google has a connection to OpenGL in the thing. That makes it more useful. Games with full system performance could be delivered through this approach, while appearing to run within the browser. The performance is about 90 to 98% of unprotected code.
It's very clever, and a good idea from a security standpoint. Untrusted processes communicating through narrow interfaces are always a good thing from a security perspective. The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.
The OS can protect your system by having users that don't have full access to your system. Just apply that concept to these processes. You can remove all the safety overhead that Java and Flash provide while still preventing the process from harming any process except itself. By allowing use of C, you allow people to leverage a lot of existing libraries, which avoids the problem of introducing a new language. However, I really have doubts about being cross platform. Flash and Java do this fine (as long as you do all your own painting, instead of relying on a smart GUI that matches the platform).
Yes, this is a good generalization and an interesting idea. But I would argue that HTML+JS, or even Java, is still better than using native machine code. My main beef with this NaCl system has to do with the fact that x86 isn't the only platform out there. FTFA, every NaCl app already has to be compiled twice -- once for x86-32, once for x86-64. How many web developers will bother to also recompile their app for ARMv7, PowerPC, Itanium? When we all migrate to the latest and greatest ISA for our mobile devices in 2025, all the closed-source apps from 2015 that their maintainers have abandoned will be unusable. JavaScript and Java don't have this problem. The best you could do would be to package some sort of dynamic recompilation engine with NaCl to translate between machine languages... but that seems a rather roundabout way of arriving at the JVM, doesn't it?
I'm sorry, but calling it NaCl is just asking for people to be confused when it comes up in discussion. We already have enough problems with people using the intials of something where by pure happenstance those initials are the same as some more common reference. Now we have Google intentionally using the chemical abreviation for salt for this new initiative of theirs. If this was something that endusers could add to any software to amplify some aspect of the software (not that I can imagine how that could be done), then I would see comparing it to salt to be a potentially usefull comparison. However, this just doesn't work. I can't see how this is in anyway like salt.
The truth is that all men having power ought to be mistrusted. James Madison
I really wish folks wouldn't intermix this crap with a web browser. I'm all for having some kind of a cloud browser for accessing Internet-based applications with the client running java or nacl or whatever. But when I'm surfing the web looking at untrusted sites, I don't want ANYTHING running browser-side. Not even javascript.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Apart from the security catastrophe this would surely cause, it's a bad idea because it's architecture-specific. Name one other web technology that is, apart from shitty ActiveX that nobody uses (and is also OS-specific and browser-specific). Go on. I'll wait.
You can talk to anyone with a PhD in computer science and they'll tell you the same thing. You can call them all short-sighted idiots too if you like.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Gentlemen, let me present to you the REAL Chrome OS. Run native apps directly in your browser, straight down to a hypervisor. Windows and Linux need not apply.
http://thedailywtf.com/Articles/The_Inner-Platform_Effect.aspx
"What sane person could live in this world and not be crazy?"
about 10,000 chances
Google seems to have fully realized that as long as the Windows/Office monopoly is pumping billions of dollars into the coffers of Microsoft, it can simply wait out any competitor. Unless holes are poked in that firehose Google is just one stumble away from being vaporized. So it does what it can to make sure Microsoft plays defense.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
The idea is web servers running your native code (or within 5% of its speed) securely on Google's servers. Even DOTNET vm running on AppEngine! (Not that i'd want taht, quick to add before i get stoned)
You know, reading the name of the project, I'd assume it runs on the client. As in, in the browser.
How exactly would you run a browser on AppEngine?
This would run only "pure" native code, and not access any OS features of the main OS on the client's machine. Any OS features would be provided by the browser. In a sense the browser would implement a virtual machine and become an OS running on top of any other OS that Chrome runs on.
Google wants control of as much of "app space" as they can, as all the major players do... Not necessarily for dominance; it may simply be to get around the dominance of others. For maximum control, you control the OS (ideally, the processor as well, then you really can do whatever you want to iphone).
Google can create its own OS and try to get people to use that...
or it can just build an OS into its browser and say "who cares what OS you have underneath, I'mma ignore it."
Yes, different native binaries need to be compiled for each architecture supported, but they already do that for Android with NDK. It's not "that bad" because there aren't a lot of architectures that need to be supported, and one can compile for all of them on a single machine. However, it supports monopolization of architectures and suppresses alternatives.
Eventually, Google will be making its own processors. You'll run Chrome in whatever OS you have, and Chrome will encourage you to go fullscreen, and then it'll take your OS out back and beat it up, and you'll say to Chrome "Ok how do I switch back to other windows?" and it'll say "Windows? What's that?"
The blatant security issues of allowing websites to download and execute native code far outweigh any benefits. Even Google must know that.
So it seems that this is really just a first step to rid PC's of Windows OS entirely, such that the PC boots right into a browser.
As far as I'm concerned, even though the superficial concept sucks, separating the mainstream from its Microsoft addiction would be worth the price.
Lines not words. You need to multiply by at least two.
Native Client was designed to easily allow portability across all popular current platforms using cross-compilation. On a single development machine you can currently build executables for x86-32, x86-64, and arm. There is currently support for Windows, Linux, and OSX. Here is an article on the generals.
Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf concerning that effort.
You are also significantly underestimating the effort that they have put into this BSD licensed project.
But going from this (particularly the C/C++ friendliness), you could almost run a Unix/Linux implementation across the entire cloud, with each browser being a separate 'login'?
It almost seems designed with that as a goal.
Pug
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
This technology is only intended for one thing : Digital Rights Management. Delivering binaries, that's what they want to do...
While I appreciate the funny mod, it wasn't meant as a joke. http://code.google.com/chrome/nativeclient/docs/reference/pepperc/index.html
This is great news! Now I can pull up that copy of VisiCalc.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
Jesus Christ, that was horrible, you feel very bad for that.
It is a bad idea because of the architecture and OS specific part. It is not clear it is security problem though. It presumably runs in ring 3, so all OS traps, naughty memory traipses, etc. can be caught. What specific security problem do you expect it to cause?
I can only think of one, if there is a problem in the underlying OS....well, since we're probably talking MS here, multiple security problems in the underlying OS that can be accessed through OS traps that go to kernel mode or any that MS left out in user land.
Seems google took more than the tech talent from the rotting corpse of Bell Labs. They seem to have captured the marketing folks as well.
Yeah I really wish there was a way to run native code on a web server.
pithy response either incorporating trending memes or exploiting unclosed double-entendres in parent post
CPU microcode vulnerabilities could also be exploited, such as this one:
http://www.networkworld.com/community/node/39825
"When information is power, privacy is freedom" - Jah-Wren Ryel
Yeah, you wouldn't want to confuse anyone by saying "I'm running my Windows code in a browser window on my Apple".
They'd think you're mad, talking about windows that run inside apples.
"McAllister explains what NaCl is useful for" Cookies, brownies, Tortilla chips... with guac.... mmmm
Sadly, I can confirm that H2O poisoning is actually a serious issue. My mom worked in a mental health ward. A patient had the idea, "Water is good for me, more water must be better.' That patient ended up drowning in their own body tissue (basically, the lungs couldn't keep the water out). Mom says it was one of the worst things she has ever seen.
Only wish I were joking.
There's nothing browser specific about the base technology. It's just that their main use case for it is in the browser. They could fairly easily adapt it for running code on the app engine, if they wanted.
Maybe they were laughing about all the PP references in the Pepper API?
Momentarily, the need for the construction of new light will no longer exist.
You talk like this is the first time that Google has done this. Remember a few months back when they came up with a programming language that was a common 2-letter word, and the name of an existing board game? I wonder what tweaking to their search algorithms they had to do to make it come up as high as #3 on that search, or even on the first page at all.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Unlike 32-bit Windows, 64-bit Windows does not provide user-mode programs the ability to create arbitrary selectors. NtSetLdtEntries returns STATUS_NOT_IMPLEMENTED in 64-bit Windows. In fact, in Vista 64 and XP 64, the kernel does "xor eax, eax \ lldt ax" and never touches LDTR again. This means that even drivers couldn't create selectors on behalf of user-mode programs, because the Windows scheduler does not save or restore LDTR during a task switch.
This is absolutely core functionality that is necessary in order for this to work - if user mode can't create selectors with shorter limits, Google's design plain doesn't work.
In contrast, even in 64-bit mode, Linux allows modify_ldt() and Mac OS allows i386_set_ldt(). In fact, this functionality is the only reason WINE is possible on these platforms.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
My parent's are unclosed double-entendres, you insensitive clod!
Sometimes, life itself is sarcasm...
Just integrate Bochs into your browser. :-)
The Tao of math: The numbers you can count are not the real numbers.
The first exploit using this technology should be called "corrosion".
NaCl is salt isn't it?
in girum imus nocte et consumimur igni
At least 0.01% per line.
I am officially gone from
Obligatory "I for one welcome our new memetic overlords".
Except that this will never be as widely referred to as either MS Windows or Apple computers.
The truth is that all men having power ought to be mistrusted. James Madison
And as you might remember, that programming language was almost dead on arrival.
The truth is that all men having power ought to be mistrusted. James Madison
That's why they're going for PNaCl.
As always, all IMO. Insert "I think" everywhere grammatically possible.
I don't know if I've heard anyone since high school chemistry refer to salt as "NaCl". It's "salt" or "sodium chloride".
I say "sodium chloride", but I usually write NaCl. Of course, that is when I don't simply say or write "salt".
The truth is that all men having power ought to be mistrusted. James Madison
Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf [llvm.org] concerning that effort.
The LLVM version is the ONLY version which should exist. It's funny that the LLVM version is called Portable Native Client because that infers that the x86/arm version is the Non-Portable Native Client. Damn right.
So what happens if I'm not x86-32, x86-64 or arm? What if I'm MIPS, running on a set-top box? What about Itanium? What about one of the lesser known architectures out there? Do I add support to NaCl, then ask every web developer in the world to recompile?
That's NOT how the web is supposed to work. This is an abomination of a web tech - it simply should not be promoted. Portable NaCl, fine, because architecture support means adding LLVM support, and doesn't require a recompile.
It's not like I have to recompile my HTML every time someone invents a new CPU.
It's called "Native Client". "NaCl" is just an abbreviation (and a pun attempt).
Lines have characters, variables, operators and syntax in them. You need to multiply by ALOT more than 2 as another post suggested. One time by accident I made a 1 character bug that totally ruined an entire experiment we were doing and about 40 hours of someone else's time. Now everyone gives me shit for it.
That brings me to an interesting point, / . is just "the ramblings of socially-inept, technology-literate news-mongers".
pithy response either incorporating trending memes or exploiting unclosed double-entendres in parent post
You really must be new here
I did that, too. Dr. Square was running a COSY experiment on a 200 MHz Varian NMR. The system appeared to be locked and I _really_ wanted to take a single pass (16 or 32 scan) spectrum on a single experiment. The user's manual seemed to indicate that the twelve hour experiment's data was being saved on disk as it was acquired and that it would be possible to cycle the power, run my experiment, and then resume his.
I read something wrong. It wasn't being saved to disk as it was being acquired. He was pissed.
the NPG electrode was replaced with carbon blac
When Microsoft thought of this (ActiveX) everyone thought it was stupid! When Google thinks of it, people are open to it. We'll have to wait for Apple to invent it for it to be wonderful!
Apple won't... at least not until it will own a cloud.
Questions raise, answers kill. Raise questions to stay alive.
The first exploit using this technology should be called "corrosion".
And the protection against the exploits? "Paint Symantec Antivirus" or "Intel Electro-plating Suite"?
Questions raise, answers kill. Raise questions to stay alive.
How many layers of software between me and my hardware do I need to achieve the same results.
Just enough to boost Google profits. Year-on-year.
Questions raise, answers kill. Raise questions to stay alive.
NaCl = common table salt
I thought we should limit the salt intake
Naah... You can have it as much as your kidney manage to eliminate. Beer helps.
Questions raise, answers kill. Raise questions to stay alive.
It could be sandboxed within micro virtual machine running Windows compatible micro OS.
Yes, the LLVM version would be quite similar to a JIT compiler, but it is more efficient than most of the JIT compilers currently available. Unlike e.g. the Java VM, there is no need to do much bounds checking and type checking; for example, on x86-64 the code can have all kinds of buffer overflow problems, but the compiled code is generated in a way that makes it possible to verify before running that all stores can only end up in a 4GB slice of the address space, so other code running in the same process remain unaffected. As a result, it is possible to compile the large body of existing C code to run on the NaCl virtual machine, and have it run at about 90-95% the speed of ordinary C code. This is not possible on the JVM.
Moreover, there remains the possibility of processor-specific optimization using e.g. SIMD instructions. For example, if we want to make the JVM support AVX instructions, we need quite a bit of additional code in the JIT compiler, and usually some kind of API must be introduced so that the application can use these instructions manually (compilers are not yet so smart). On NaCl it is only necessary to modify the verifier so that only valid uses of these instructions are allowed; actual generation of the instructions is left to the ahead-of-time compiler, which hardly has to be changed if the new instructions do not make verification difficult.
Check out some of the papers from Google about how they do the security validation for Native Client - the Wikipedia article might be a good place to start. It's pretty cool - they define a restricted subset of x86 instructions which can be statically checked to prove they are safe (don't access memory outside a certain range, don't make system calls, etc). Then once the code has been verified, you can execute it and let rip! Kind of like the opposite approach to Java or .NET - instead of defining a new virtual machine, why not take an existing instruction set and modify it slightly to make it sandboxable but still execute at native speed?
-- Ed Avis ed@membled.com
This is absurd, insane and stupid. What on earth would this accomplish. Just create a better JIT will you, and develop in Java.
From TFA:
NaCl's intended niche is as a method of allowing Web applications to execute complex algorithms at native speed. Picture 3D modeling for scientific applications, for example, or running complex graphic transformations in a Web-based paint program.
It is raw C/C++. It is platform-independent. Its limitation is the processor architecture. Binaries must be compiled for each architecture. The only similarity between this and ActiveX is that you are running a compiled binary.
IMO it is a dead end unless other browsers follow suit and allow compatibility with these modules, or Chrome takes a larger market share, possibly in the mobile space. Otherwise it will be difficult to convince the execs, directors, managers, etc. that it makes economic sense to produce yet another browser plug-in.
On the other hand it could make Chrome more of a specialty browser used in certain communities where you can't get the same functionality from other browsers for performance reasons.
Drinking saltwater is a dumb idea, but salt isn't evil. Drink your piss sometime. Taste salty? That's right, your body is quite efficient at getting rid of excess salt, minerals, vitamins (water soluble ones, at least), etc.
But, but, but, I ate 3 bags of potato chips a day for 60 years and now I have health problems! It must be the salt, couldn't possibly involve my lifestyle.
Do you even lift?
These aren't the 'roids you're looking for.
If Android is any indication of Google's commitment to security, a free wallpaper application will be able to read all your text messages and track your location in real-time.
Only if you explicitly give the app permission to do those things.
So how do I explicitly give the app permission to do some but not all of those things? Neither Android Market nor the "Unknown sources" APK installer allows the user any options between "grant all permissions requested by the package" and "cancel installation".
This is until the "consumers" will use mainly your technology and have all their data saved in the sandbox.
Then why doesn't it make a separate sandbox for each origin? I haven't had a chance to read the spec yet, and the Wikipedia article about Google Native Client is still a stub, but I'd imagine that it draws at least some boundaries between origins.
when you install an Android application it forces you to review the list of permissions the application is requesting.
And it gives me a Hobson's choice as to which permissions to grant: all or nothing. I can't cherry pick from the list.
It could be that all realistic programs can be proven to halt.
And if one models "all realistic programs" as all linear bounded automata, then yes, all realistic programs do halt.
Sounds like a tricky problem - difficult enough that it's previously only been solved by (1) restricted languages like Java and C#
And that's exactly how NaCl works. It verifies the code as if it were a bytecode with semantics that are a subset of x86 semantics, and then it hands the code off to the CPU to execute.
they started with x86 and it might be the more mature implementation, but there are versions for x86-64 and ARM. You only need a recompile to target different architectures
So how do I test a Native Client module that will be deployed to the public without buying an x86 machine, an x86-64 machine, and an ARM machine?
So what happens if I'm not x86-32, x86-64 or arm? What if I'm MIPS, running on a set-top box?
Then even your PNaCl module won't carry the digital signature of your set-top box's manufacturer and therefore won't run. As I understand it, development of applications for set-top boxes is even more tightly restricted than for smartphones.
What about Itanium?
Native Client, not Native Server, at the moment.
I'm all for having some kind of a cloud browser for accessing Internet-based applications with the client running java or nacl or whatever. But when I'm surfing the web looking at untrusted sites, I don't want ANYTHING running browser-side. Not even javascript.
Then how does a site get promoted from "untrusted sites" to "Internet-based applications"?
I see nothing that this can do that Java couldn't - but safer and with portability.
A site is a site. A cloud app is a cloud app. If I want to run a cloud app, I fire up the app runner.
What is the fundamental difference in implementation between a browser for sites and an app runner for cloud apps? How do you run a cloud app that you have learned about from a site? And would you consider an online store a "site" or an "app"?
And I don't have to worry about sandbox security because I've chosen to run the app, no different than if I'd downloaded and installed it.
Some people are paranoid enough to use a sandbox even on applications that have been "downloaded and installed", such as Sandboxie for Windows or the jail facility in FreeBSD.