on a binary validator to isolate the OS interface, preventing direct access to the OS and resources such as the file system and the network.
Despite the different implementation techniques, the idea behind Xax and Native Client is similar, according to Howell. “Let the software use the processor however it likes,” he says, “and rely for isolation on a simple bit of hardware designed to do just that.”
Xax and Native Client are but two of the software technologies designed to close the performance gap and strengthen the security of Web browsers. Sun’s Java, Microsoft’s Silverlight, and Adobe’s AIR represent another approach to isolating untrusted modules from OS interfaces while narrowing the performance gap with native execution. Of course, unlike Xax and Native Client, these application frameworks tend to be used mainly as replacements for the browser-based application environment.
Another alternative approach that is gaining popularity is full virtualization. Systems such as Xen or VMware aren’t commonly used to deploy Web-based applications, but that might change soon. Because virtualization systems use code-distribution formats based on native code, they avoid the performance obstacles of JavaScript and other similar languages. And to protect native OS interfaces, they wrap untrusted code in an entire instance of the OS and run that on top of simulated hardware.
“The desire is to have some kind of strong isolation barrier that an attack will not be able to penetrate,” says Mendel Rosenblum, cofounder of VMware and a computer science professor at Stanford University. “Hardware-level virtual machines provide precisely that high-assurance barrier yet can run existing browsers at near-native speeds.”
Rosenblum says the computer industry’s focus on low-level isolation mechanisms is missing the larger point about what virtualization layers can do for performance and security, especially as the Web evolves from a document-delivery mechanism into an ecosystem of interactive applications. “The ability to run sophisticated code safely, and with high performance on the clients, will allow the new applications running in the cloud to support the richer, highly interactive interfaces users are accustomed to,” he says.
In the meantime, despite the proliferation of technologies that aim to sidestep the performance issues associated with running single-threaded scripts in browsers, JavaScript remains indisputably popular among developers as the only viable choice for programming browsers today. While most believe it is unlikely that JavaScript performance will catch up to the speed of native code execution, both Firefox’s TraceMonkey and Google’s V8, the JavaScript rendering engine in the Chrome browser, have received industrywide praise for narrowing the performance gap.
“One thing we should never lose sight of is the fact that language virtual machines are not all about straight-line speed of code and that there are many moving parts in the system that need to be balanced against each other,” says Ivan Posva, a Google software engineer who developed the V8 JavaScript implementation for Chrome. Still, he says, V8 has narrowed the gap.
In terms of the next speed increase that users can expect from JavaScript rendering engines, Posva says he remains skeptical about the ability of ap-plication-specific or language-specific hardware to offer significant improvement. “Currently in V8 there are still many more optimizations that can be applied on general-purpose CPUs,” he says. “I do not think that JavaScript-oriented hardware support would be a silver bullet.”
In addition to the performance issue, there remains the matter of security. JavaScript running in a browser opens up the possibility for local security attacks in which a malicious application tries to elevate its privileges. “Browser designers need to be aware that the more control we give the third-party programmers via JavaScript, the more control somebody malicious could potentially have,” Posva says.
“This is not a security issue on its own, but there is a lot more potential control in modern, high-performance virtual machines that can be used to exploit an independent security bug.”
To mitigate these risks, V8 uses a layered approach with a sandboxed renderer. “V8 tries to minimize the attack surface by not giving total control over the generated code for a piece of JavaScript and by following common practices such as marking all data nonexecutable,” says Posva. “V8 has to ensure that the policies set by the binding layer are followed properly.”
Posva says the performance of V8 will improve regardless of whether it is embedded in a sandboxed environment. “We had to make some design decisions in V8 to allow it being embedded in the sandboxed renderer process within Google Chrome,” he says. “But none of these decisions prevent a nonsandboxed use of V8, and none of these decisions had an impact on the real-world performance of V8.”
That performance versatility might become increasingly important as browsers evolve, perhaps even to the point where they are no longer distinguishable from the applications they run. “In a few years,” says Microsoft’s Howell, “I don’t think we’ll mean the same thing by ‘browser’ that we mean today; we’ll mean much less.” Howell predicts that most of the functions of the traditional browser will be rendered moot, replaced by flexible code linked directly into the Web sites users visit.
Howell’s prediction amounts to saying that the browser itself will become the sandbox, more or less a simple isolation framework. “Because Xax has such a narrow interface, and because we can compile the browser itself for the Xax container, you can think of Xax as a way to virtualize the browser,” says Howell, who maintains that treating the host OS as something special is a short-lived phenomenon.
“As Web applications get richer, they’re just as important to protect as the host OS,” he says. “If Web applications are sandboxed, users can try one with no risk of exposing everything on their computer.”
Based in Los Angeles, Kirk L. Kroeker is a freelance editor and writer specializing in science and technology.
© 2009 ACM 0001-0782/09/0700 $10.00
References:
Archives