Software:Google Native Client

From HandWiki
Google Native Client
Developer(s)Google, others
Initial release16 September 2011; 15 years ago (2011-09-16)[1]
Stable release
SDK: Google Pepper 45 / 10 July 2015; 11 years ago (2015-07-10)
Samsung Pepper 63 / 22 March 2018; 8 years ago (2018-03-22)
Dæmon Saigo 20260925 / 25 September 2026; 14 days ago (2026-09-25)

Clients: Same as Google Chrome

Written inC, C++
Operating systemWindows, Linux, macOS, ChromeOS, Tizen
Platformx86, ARM, MIPS
SuccessorWebAssembly
TypeSandbox for native code in web browsers or as standalone virtual machine
LicenseNew BSD
Website{{{1}}}

Google Native Client (NaCl) is a discontinued sandboxing technology for running either a subset of Intel x86, ARM, or MIPS native code, or a portable executable, in a sandbox. Google Chrome and other Chromium-based web browsers incorporated NaCl to safely run native code within web apps and browser extensions, largely independent of the user operating system and at near-native speeds. This capability was imperative for Google's plans for ChromeOS as a general-purpose computing platform. NaCl was also used for securing browser plugins, like Adobe Flash Player, and parts of other applications or full applications[2] such as ZeroVM.[3]

The general concept of NaCl (running native code in the web browser) has been implemented before in ActiveX, but NaCl runs content in a sandbox while ActiveX application has full access to the system (disk, memory, user-interface, registry, etc.). Mozilla proposed asm.js as an alternative to both ActiveX and NaCl. asm.js also allows applications written in C or C++ to be compiled to run in the browser and also supports ahead-of-time compilation, but is a subset of JavaScript and hence backwards-compatible with browsers that do not support it directly.

In 2016, Google de-prioritized feature development for Pepper and Native Client. On 30 May 2017, Google announced deprecation of PNaCl in favor of WebAssembly.[4][5] Over the following years, Google Chrome slowly deprecated and removed NaCl on different platforms. ChromeOS version 138 became the last Google platform and version to support Native Client until July 2025 with the release of ChromeOS 139 dropping support for Native Client.[6][7][8]

Overview

Native Client was an open-source project developed by Google.[9] Games such as Quake,[10] XaoS, Battle for Wesnoth,[11] Doom,[12] Lara Croft and the Guardian of Light,[13] From Dust,[14] and MAME, as well as the sound processing system Csound, have been ported to Native Client. Native Client has been available in the Google Chrome web browser since version 14, and has been enabled by default since version 31, when the Portable Native Client (PNaCl, pronounced: pinnacle) was released.[15][16][17] Native Client has also been used to safely run downloaded code in software other than web browsers, like in the Dæmon game engine.[18]

An ARM implementation was released in March 2010.[19] x86-64, IA-32, and MIPS were also supported.

To run an application portably under PNaCl, it must be compiled to an architecture-agnostic and stable subset of the LLVM intermediate representation bytecode.[20] The executables are called PNaCl executables (pexes). The PNaCl Toolchain makes .pexe files; NaCl Toolchain .nexe files. The magic number of .nexe files is 0x7F 'E' 'L' 'F', which is ELF. In Chrome, they are translated to architecture-specific executables so that they can be run.

NaCl uses software fault detection and isolation for sandboxing on x86-64 and ARM.[21][22] The x86-32 implementation of Native Client is notable for its novel sandboxing method, which makes use of the x86 architecture's rarely used segmentation facility.[23] Native Client sets up x86 segments to restrict the memory range that the sandboxed code can access. It uses a code verifier to prevent use of unsafe instructions such as those that perform system calls. To prevent the code from jumping to an unsafe instruction hidden in the middle of a safe instruction, Native Client requires that all indirect jumps be jumps to the start of 32-byte-aligned blocks, and instructions are not allowed to straddle these blocks.[23] Because of these constraints, C and C++ code must be recompiled to run under Native Client, which provides customized versions of the GNU toolchain, specifically GNU Compiler Collection (GCC), GNU Binutils, and LLVM.

Native Client is licensed under a BSD-style license.

Native Client uses Newlib as its C library, but a port of GNU C Library (GNU libc) is also available.[24]

History

On 8 December 2008, Google introduced Native Client to the public shortly after the September introduction of Google Chrome.[25] NaCl became generally available to the web when it was released in a stable Chrome version in September 2011.[1]

On 9 December 2011, Google demonstrated the readiness of the technology by announcing availability of several new Chrome-only versions of games known for their rich and processor-intensive graphics, including Bastion (no longer supported on the Chrome Web Store). NaCl runs hardware-accelerated 3D graphics (via OpenGL ES 2.0), sandboxed local file storage, dynamic loading, full screen mode, and mouse capture. There were also plans to make NaCl available on handheld devices.[26][27]

In 2013 Google introduced the Portable Native Client (PNaCl), an architecture-independent compiled ahead-of-time version of NaCl.[28] Portable Native Client (PNaCl) is an architecture-independent version. PNaCl apps are compiled ahead-of-time. PNaCl is recommended over NaCl for most use cases.[29] The general concept of NaCl (running native code in web browser) has been implemented before in ActiveX, which, while still in use, has full access to the system (disk, memory, user-interface, registry, etc.). Native Client avoids this issue by using sandboxing.

An alternative by Mozilla was asm.js, which also allows applications written in C or C++ to be compiled to run in the browser and also supports ahead-of-time compilation, but is a subset of JavaScript and hence backwards-compatible with browsers that do not support it directly.

On 12 October 2016, a comment on the Chromium issue tracker indicated that Google's Pepper and Native Client teams had been destaffed.[30] On 30 May 2017, Google announced deprecation of PNaCl in favor of WebAssembly.[4][5] Although initially Google planned to remove PNaCl in first quarter of 2018,[4] and later in the second quarter of 2019,[31] it has been removed in June 2022 (together with Chrome Apps).[32][33] Support in ChromeOS continued up to ChromeOS 138 and ended in July 2025 with the release of ChromeOS 139 dropping Native Client support.[6][7][8]

LLVM 22, released in February 2026, became the first version to lose support for building NaCl binaries.[34]

Pepper

NaCl denotes sodium chloride, common table salt; as a pun, the name of pepper was also used. Pepper API is a cross-platform, open-source API for creating Native Client modules.[35] Pepper Plugin API, or PPAPI[36][37] is a cross-platform API for Native Client-secured web browser plugins, first based on Netscape's NPAPI, then rewritten from scratch. It was used in Chromium and Google Chrome to enable the PPAPI version of Adobe Flash[38] and the built-in PDF viewer.[39]

PPAPI

On 12 August 2009, a page on Google Code introduced a new project, Pepper, and the associated Pepper Plugin API (PPAPI),[40] "a set of modifications to NPAPI to make plugins more portable and more secure".[41] This extension is designed specifically to ease implementing out-of-process plugin execution. Further, the goals of the project are to provide a framework for making plugins fully cross-platform. Topics considered include:

  • Uniform semantics for NPAPI across browsers.
  • Execution in a separate process from the renderer-browser.
  • Standardize rendering using the browser's compositing process.
  • Defining standardized events, and 2D rasterizing functions.
  • Initial attempt to provide 3D graphics access.
  • Plugin registry.

The Pepper API also supports Gamepads (version 19) and WebSockets (version 18).[42]

As of 13 May 2010, Google's open source browser, Chromium, was the only web browser to use the new browser plug-in model.[43] As of 2020, Pepper is supported by Chrome, Chromium and Blink layout engine-based browsers such as Opera and Microsoft Edge.

In August 2020, Google announced that support for PPAPI would be removed from Google Chrome and Chromium in June 2022.[44]

PPAPI in Firefox

Firefox developers stated in 2014 that they would not support Pepper, as there were no full specification of the API beyond its implementation in Chrome, which itself was designed for use with Blink layout engine only, and had private APIs specific to the Flash Player plugin which were not documented.[45] In October 2016, Mozilla announced that it had re-considered and was exploring whether to incorporate the Pepper API and PDFium in future releases of Firefox,[46] however no such steps were taken. In July 2017, Adobe deprecated Flash and announced its end-of-life in the end of 2020.[47] By January 2021, Adobe Flash Player, Google Chrome, Firefox, Safari, and Windows[48] received updates disabling or entirely removing Flash.

Applications

One website[49] used NaCl on the server to let users experiment with the Go programming language from their browsers.[50]

Usage in Smart TVs

Tizen has supported NaCl in Smart TV applications[51] from 2013[52] to products released until 2021 (included)[53], with development integration in Tizen Studio[54]. The Samsung Studio website describes various usages like creating 3D games using OpenGL ES 2.0, perform sound-mixing with sample-level audio control, using advanced video codecs, implementing multicast streaming over UDP or simply leveraging computational power.

Usage in game engines

The open-source Unvanquished game makes use of Native Client in the Dæmon game engine[55] in replacement of the Q3VM (Quake III virtual machine).[56][57] In such game engine, the Native Client sandbox is used to safely run arbitrary game code (mods) downloaded from game servers. Using the Native Client technology makes possible for gameplay developers to use the C++ language for games running in the virtual machine, to use C++ libraries, to share code between the game and the engine and to get better performance than with the Q3VM.[18]

Reception

Some groups of browser developers supported the Native Client technology while others did not.

Supporters

Chad Austin (of IMVU) praised the way Native Client can bring high-performance applications to the web (with about 5% penalty compared to native code) in a secure way, while also accelerating the evolution of client-side applications by giving a choice of the programming language used (besides JavaScript).[58]

Id Software's John D. Carmack praised Native Client at QuakeCon 2012, saying: "if you have to do something inside a browser, Native Client is much more interesting as something that started out as a really pretty darn clever x86 hack in the way that they could sandbox all of this in user mode interestingly. It's now dynamic recompilation, but something that you program in C or C++ and it compiles down to something that's going to be not your -O4 optimization level for completely native code but pretty damn close to native code. You could do all of your evil pointer chasings, and whatever you want to do as a to-the-metal game developer."[59]

Detractors

Other IT professionals were more critical of this sandboxing technology as it had substantial or substantive interoperability issues.

Mozilla's vice president of products, Jay Sullivan, said that Mozilla has no plans to run native code inside the browser, as "These native apps are just little black boxes in a webpage. [...] We really believe in HTML, and this is where we want to focus."[60]

Mozilla's Christopher Blizzard criticized NaCl, claiming that native code cannot evolve in the same way that the source code-driven web can. He also compared NaCl to Microsoft's ActiveX technology, plagued with DLL Hell.[2]

Håkon Wium Lie, Opera's CTO, believed that "NaCl seems to be 'yearning for the bad old days, before the web'", and that "Native Client is about building a new platform – or porting an old platform into the web [...] it will bring in complexity and security issues, and it will take away focus from the web platform."[2]

Successors

The second generation of sandboxing developed in Google is gVisor.[61][62] It is intended to replace NaCl in Google Cloud, to be more exact in Google App Engine.

Google has also been promoting WebAssembly as an alternative to NaCl for usage in web browsers.[63] WebAssembly defines a single architecture-independent virtual ISA that can be compiled to run on different host architectures.[64] Like Native Client, WebAssembly can be used in browsers or for standalone usage.[65] [66]

Lightweight Fault Isolation or LFI is another Software-based fault isolation developed as an alternative to Native Client.[67][68][69] Initiated in Standford University, it received contributions from Google [70], and is based on LLVM like Native Client.[71][72] Unlike PNaCl and WebAssembly, but like NaCl, LFI doesn't target an hardware-agnostic representation and should be compiled for the processor target. LFI supports x86_64 and ARM64.[73][74] Unlike WebAssembly and Native Client which are designed to support sandboxed code in web browsers as well as other environments, LFI is designed as a native-code sandboxing technology whose sandboxed programs run within an LFI runtime hosted by the application.[75]

See also

References

  1. ↑ 1.0 1.1 "Google's Native Client goes live in Chrome". The Register. 2011-09-16. https://www.theregister.co.uk/2011/09/16/native_client_debuts_in_chrome/. 
  2. ↑ 2.0 2.1 2.2 Metz, Cade (12 September 2011). "Google Native Client: The web of the future – or the past?". The Register. https://www.theregister.co.uk/2011/09/12/google_native_client_from_all_sides/. 
  3. ↑ "ZeroVM Architecture". http://zerovm.org/architecture.htm. 
  4. ↑ 4.0 4.1 4.2 Nelson, Brad (2017-05-30). "Goodbye PNaCl, Hello WebAssembly!" (in en-US). https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html. 
  5. ↑ 5.0 5.1 Armasu, Lucian (2017-05-31). "Chrome To Deprecate ‘PNaCl,’ Embrace New ‘WebAssembly’ Standard" (in en-US). https://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly%2C34583.html. 
  6. ↑ 6.0 6.1 "Native Client". https://developer.chrome.com/docs/native-client. "ChromeOS 138 will mark the end of life for NaCl technology on ChromeOS" 
  7. ↑ 7.0 7.1 "ChromeOS 139 release summary". https://support.google.com/chrome/a/answer/10314655?hl=en&sjid=9999252884287590981-EU#139. "Native Client (NaCl) deprecation" 
  8. ↑ 8.0 8.1 "Chrome 139 Enterprise and Education release notes" (PDF). 2025-08-13. https://storage.cloud.google.com/support-kms-prod/LgR0si6b3FysscG8OTUVRpQNB6BXjppDW1TH. "Native Client (NaCl) deprecation" 
  9. ↑ "Google Native Client on Google Code". https://code.google.com/p/nativeclient/. 
  10. ↑ davemichael (3 October 2020). "GitHub - davemichael/NaCl-Quake: Quake for Native Client (based on the SDL Quake port)". GitHub. https://github.com/davemichael/NaCl-Quake. 
  11. ↑ "The Battle for Wesnoth". https://chrome.google.com/webstore/detail/the-battle-for-wesnoth/pobnonecghmlpppkkjpdiiblmakhhldb. 
  12. ↑ "Index of /". http://doom.pdox.net/. 
  13. ↑ "Chrome Web Store - Lara Croft and the Guardian of Light". https://chrome.google.com/webstore/detail/lara-croft-and-the-guardi/dcfdbmpeeihbpddkneaploeinlbaaodn. 
  14. ↑ "From Dust". https://chrome.google.com/webstore/detail/from-dust/anelkojiepicmcldgnmkplocifmegpfj. 
  15. ↑ Chen, Brad (8 December 2008). "Native Client: A Technology for Running Native Code on the Web". Google-code-updates.blogspot.com. http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html. 
  16. ↑ "The Chromium Blog: Native Client Brings Sandboxed Native Code to Chrome Web Store Apps". Blog.chromium.org. 18 August 2011. https://blog.chromium.org/2011/08/native-client-brings-sandboxed-native.html. 
  17. ↑ "Google Code Blog: Portable Native Client: The "pinnacle" of speed, security, and portability". blog.chromium.org. 12 November 2013. https://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html. 
  18. ↑ 18.0 18.1 "Unvanquished Continues Work On Its PNaCl Support". 2014-03-15. https://www.phoronix.com/news/MTYzMDk. "PNaCl sandboxes allow game-play developers to use modern C++ and C/C++ libraries directly within their virtual machines and will allow for better code sharing between the engine code and game logic. PNaCl is also reported to offer better performance than the original Quake III virtual machines." 
  19. ↑ "Google's Native Client goes ARM and beyond". The H. 18 March 2010. http://www.h-online.com/open/news/item/Google-s-Native-Client-goes-ARM-and-beyond-957478.html. 
  20. ↑ "PNaCl: Portable Native Client Executables". http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf. 
  21. ↑ Sehr, David; Muth, Robert; Biffle, Cliff L.; Khimenko, Victor; Pasko, Egor; Yee, Bennet; Schimpf, Karl; Chen, Brad (2010). "Adapting Software Fault Isolation to Contemporary CPU Architectures". 19th USENIX Security Symposium. http://research.google.com/pubs/pub35649.html. 
  22. ↑ Yedidia, Zachary (2024). "Lightweight Fault Isolation: Practical, Efficient, and Secure Software Sandboxing". Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems. doi:10.1145/3620665.3640374. https://www.scs.stanford.edu/~zyedidia/docs/papers/lfi.pdf. "Google Native Client (NaCl) was a major project that initially applied SFI to x86 using segments [66], and then expanded to ARM32 and x86-64 using pure software techniques.". 
  23. ↑ 23.0 23.1 Yee, Bennet; Sehr, David; Dardyk, Greg; Chen, Brad; Muth, Robert; Ormandy, Tavis; Okasaka, Shiki; Narula, Neha et al. (2009). "Native Client: A Sandbox for Portable, Untrusted x86 Native Code". IEEE Symposium on Security and Privacy (Oakland'09). http://research.google.com/pubs/pub34913.html. 
  24. ↑ "Native Client: Building". developer.chrome.com. http://developer.chrome.com/native-client/devguide/devcycle/building. 
  25. ↑ Chen, Brad (8 December 2008). "Native Client: A Technology for Running Native Code on the Web". http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html. 
  26. ↑ Rosenblatt, Seth (9 December 2011). "Native Client turns Chrome into high-end gaming platform". CNET. http://download.cnet.com/8301-2007_4-57340015-12/native-client-turns-chrome-into-high-end-gaming-platform/. 
  27. ↑ "Google Code Blog: Games, apps and runtimes come to Native Client". Googlecode.blogspot.com. 9 December 2011. http://googlecode.blogspot.com/2011/12/games-apps-and-runtimes-come-to-native.html. 
  28. ↑ "Portable Native Client: The "pinnacle" of speed, security, and portability". 12 November 2013. https://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html. 
  29. ↑ "NaCl and PNaCl". https://developer.chrome.com/native-client/nacl-and-pnacl#when-to-use-pnacl. 
  30. ↑ "Bugs.chromium.org". 12 October 2016. https://bugs.chromium.org/p/chromium/issues/detail?id=239656#c160. 
  31. ↑ "WebAssembly Migration Guide - Google Chrome". https://developer.chrome.com/native-client/migration. 
  32. ↑ "Changes to the Chrome App Support Timeline". 10 August 2020. https://blog.chromium.org/2020/08/changes-to-chrome-app-support-timeline.html. 
  33. ↑ Li, Abner (10 August 2020). "Google delays deprecation of Chrome Apps on all platforms" (in en-US). https://9to5google.com/2020/08/10/chrome-apps-deprecation/. 
  34. ↑ "LLVM 22 Eliminates The Final Support For Google Native Client "NaCl"" (in en). https://www.phoronix.com/news/LLVM-22-Removes-Native-Client. 
  35. ↑ "Technical Overview". https://developer.chrome.com/native-client/overview. 
  36. ↑ "Pepper Plugin API project at". https://developer.chrome.com/native-client/pepper_stable/index. 
  37. ↑ "Chrome Source: Index of /trunk/src/ppapi". Src.chromium.org. https://src.chromium.org/viewvc/chrome/trunk/src/ppapi/. 
  38. ↑ "The road to safer, more stable, and flashier Flash". 8 August 2012. https://blog.chromium.org/2012/08/the-road-to-safer-more-stable-and.html. 
  39. ↑ Metz, Cade (18 June 2010). "Google hugs Adobe harder with Chrome-PDF merge". The Register. https://www.theregister.co.uk/2010/06/18/chrome_dev_builds_get_built_in_pdf_reader/. 
  40. ↑ "Getting Started: Background and Basics – The Chromium Projects". Chromium.org. https://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics#TOC-Pepper-Plugin-API-PPAPI-. 
  41. ↑ "Pepper.wiki". 24 February 2012. https://code.google.com/p/ppapi/wiki/Concepts. 
  42. ↑ "Release Notes". https://developer.chrome.com/native-client/sdk/release-notes. 
  43. ↑ Metz, Cade (13 May 2010). "Google heats up native code for Chrome OS". Theregister.co.uk. https://www.theregister.co.uk/2010/05/13/google_native_client_sdk/. 
  44. ↑ Anthony Laforge (10 August 2020). "Changes to the Chrome App Support Timeline". https://blog.chromium.org/2020/08/changes-to-chrome-app-support-timeline.html. 
  45. ↑ Zbarsky, Boris. "Bug 729481 - Support the "Pepper" Plugin api". https://bugzilla.mozilla.org/show_bug.cgi?id=729481#c83. 
  46. ↑ Metz, Cade (3 October 2016). "Project Mortar". Mozilla. https://wiki.mozilla.org/Mortar_Project. 
  47. ↑ "Flash & The Future of Interactive Content". Adobe Inc.. July 25, 2017. https://theblog.adobe.com/adobe-flash-update/. 
  48. ↑ Salter, Jim (2021-05-04). "Goodbye again, Flash—Microsoft makes removal from Windows 10 mandatory" (in en-us). https://arstechnica.com/gadgets/2021/05/microsoft-will-remove-adobe-flash-from-windows-10-this-summer/. 
  49. ↑ "The Go Playground". https://play.golang.org. 
  50. ↑ "Inside the Go Playground - The Go Blog". https://blog.golang.org/playground#TOC_3.. 
  51. ↑ "NaCl ToolChain". https://developer.samsung.com/smarttv/develop/extension-libraries/nacl/download.html. "The Native Client technology allows to run native C/C++ applications inside a web browser. Tizen Web applications can take full advantage of the increased performance of native code over JavaScript." 
  52. ↑ "Overview". https://developer.samsung.com/smarttv/develop/extension-libraries/nacl/overview.html. "Samsung has customized the NaCl technology and has supported it on Smart TVs since 2013." 
  53. ↑ "Overview". https://developer.samsung.com/smarttv/develop/extension-libraries/nacl/overview.html. "Due to NaCl deprecation by the Chromium project, Tizen TV will continue its support for NaCl only until 2021-year products." 
  54. ↑ "Using Tizen Studio for NaCl". https://developer.samsung.com/smarttv/develop/extension-libraries/nacl/using-tizen-studio-for-nacl.html. "The Tizen Studio, Samsung TV Extension, and Samsung NaCl SDK provide various features to help you develop NaCl applications for Samsung TVs." 
  55. ↑ Larabel, Michael (2015-07-09). "Unvanquished Alpha 41 Released, Still Moving Towards NaCl VM Usage". https://www.phoronix.com/news/Unvanquished-Alpha-41. "They've continued moving along with their open-source game and Daemon engine. […] their libRocket implementation has moved into the NaCl VM." 
  56. ↑ "Unvanquished Continues Work On Its PNaCl Support". 2014-03-15. https://www.phoronix.com/news/MTYzMDk. "Open-source Unvanquished developers continue working on support for using Google's Portable Native Client (PNaCl) to replace Quake III QVMs." 
  57. ↑ "Unvanquished Alpha 34 Brings Fixes, Still Being Ported To PNaCl". 2014-12-08. https://www.phoronix.com/news/MTg1NzA. "Under the hood, they remain hard at work on porting the game logic from QVMs to Portable Native Client (PNaCl)." 
  58. ↑ Austin, Chad (8 January 2011). "Chad Austin: In Defense of Language Democracy (Or: Why the Browser Needs a Virtual Machine)". Chadaustin.me. http://chadaustin.me/2011/01/in-defense-of-language-democracy/. 
  59. ↑ Carmack, John (3 August 2012). "QuakeCon 2012". youtube.com. https://www.youtube.com/watch?v=wt-iVFxgFWk&t=2h36m18s. 
  60. ↑ Metz, Cade (24 June 2010). "Mozilla: Our browser will not run native code". The Register. https://www.theregister.co.uk/2010/06/24/jay_sullivan_on_firefox/. 
  61. ↑ "Beta release of PHP 7.2 in the Google App Engine standard environment | Hacker News". https://news.ycombinator.com/item?id=17810591. 
  62. ↑ "Google/Gvisor". 15 October 2021. https://github.com/google/gvisor. 
  63. ↑ Avram, Abel (31 May 2017). "Google Is to Remove Support for PNaCl" (in en). https://www.infoq.com/news/2017/05/pnacl-webassembly-google/. "As a replacement, Google is now pushing WebAssembly." 
  64. ↑ "WebAssembly Core Specification". World Wide Web Consortium. https://www.w3.org/TR/wasm-core-2/. "At its core, WebAssembly is a virtual instruction set architecture (virtual ISA). […] Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike." 
  65. ↑ "WebAssembly Core Specification". World Wide Web Consortium. https://www.w3.org/TR/wasm-core-2/. "Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments." 
  66. ↑ "Non-Web Embeddings". https://webassembly.org/docs/non-web/. "WebAssembly is also capable of being executed without a JavaScript VM present. […] WASI is a set of standards-track APIs being developed by the WASI Subgroup intended for use in many environments, including in non-browser and non-JS engines." 
  67. ↑ Yedidia, Zachary (2024). "Lightweight Fault Isolation: Practical, Efficient, and Secure Software Sandboxing". Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems. doi:10.1145/3620665.3640374. https://www.scs.stanford.edu/~zyedidia/docs/papers/lfi.pdf. "Like LFI, NaCl x86-64 took advantage of instructions that operate on 32-bit subsets of 64-bit registers to accelerate SFI.". 
  68. ↑ "Lightweight Fault Isolation (LFI) in LLVM". LLVM Project. https://llvm.org/docs/LFI.html. "Lightweight Fault Isolation (LFI) is a compiler-based sandboxing technology for native code. Like WebAssembly and Native Client, LFI isolates sandboxed code in-process (i.e., in the same address space as a host application)." 
  69. ↑ "Lightweight Fault Isolation". Stanford University. https://os.stanford.edu/. "LFI is a system for sandboxing native code. Like WebAssembly and Native Client, LFI isolates sandboxed code in-process (i.e., in the same address space as a host application)." 
  70. ↑ Larabel, Michael (2026-07-11). "LLVM Merges x86 LFI "Lightweight Fault Isolation" Target For In-Process Sandboxing". https://www.phoronix.com/news/LLVM-x86-LFI-Merged. "LFI was born out of Stanford research while Google and others have been interested in this research for helping to provide additional memory safety to C/C++ code with minimal cost. Google in turn has also been contributing engineering resources to LFI." 
  71. ↑ Larabel, Michael (2026-07-11). "LLVM Merges x86 LFI "Lightweight Fault Isolation" Target For In-Process Sandboxing". https://www.phoronix.com/news/LLVM-x86-LFI-Merged. "Stanford researchers have been developing Lightweight Fault Isolation "LFI" compiler passes and targets for LLVM as a means of efficient, native code sandboxing." 
  72. ↑ Larabel, Michael (2026-07-23). "LLVM 23.1-rc1 Released With AMD Zen 6 & AVX-512 BMM Support, Other Compiler Enhancements". https://www.phoronix.com/news/LLVM-23.1-rc1. "LLVM 23 brings x86 Lightweight Fault Isolation "LFI" target support." 
  73. ↑ Yedidia, Zachary; Garfinkel, Tal; Noh, Taehyun; Narayan, Shravan; Khan, Sharjeel; Nainar, Pirama Arumuga; Egge, Nathan. "RFC: Lightweight Fault Isolation (LFI): Efficient Native Code Sandboxing — Upstream LFI Target and Compiler Changes". LLVM Project. https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380. "Our current LFI implementation supports both ARM64 and x86-64 processors with experimental RISC-V support." 
  74. ↑ "Lightweight Fault Isolation". Stanford University. https://os.stanford.edu/. "At present, we support Arm64 and x86-64 targets, and have experimental RISC-V support." 
  75. ↑ Yedidia, Zachary; Garfinkel, Tal; Noh, Taehyun; Narayan, Shravan; Khan, Sharjeel; Nainar, Pirama Arumuga; Egge, Nathan. "RFC: Lightweight Fault Isolation (LFI): Efficient Native Code Sandboxing — Upstream LFI Target and Compiler Changes". LLVM Project. https://discourse.llvm.org/t/rfc-lightweight-fault-isolation-lfi-efficient-native-code-sandboxing-upstream-lfi-target-and-compiler-changes/88380. "WebAssembly makes significant performance and compatibility compromises. These compromises make sense for the Web, where properties like platform independence are important. However, it limits its utility for sandboxing in other settings. Lightweight Fault Isolation (LFI) is a lower level approach to in-process sandboxing that prioritizes performance and compatibility with existing code." 

Examples



Retrieved from "https://handwiki.org/wiki/index.php?title=Software:Google_Native_Client&oldid=4629995"