Posted in

Chicory:在 WebAssembly 中编写,克服 JVM 的局限_AI阅读总结 — 包阅AI

包阅导读总结

1.

– `Chicory`、`WebAssembly`、`JVM`、`Runtime`、`Identity Management`

2.

Chicory 是一个 JVM 原生的 WebAssembly 运行时,旨在为 JVM 带来 WebAssembly 的优势。它能在 JVM 可达之处运行 Wasm 程序,具有安全性等特点,虽新但有潜力,目前工作仍在进行。

3.

– Chicory 的背景

– JVM 用于运行 Java 代码和应用,WebAssembly 新兴可跨环境部署应用。

– Chicory 的特点

– 为 JVM 带来 Wasm 优势,如安全性和双沙箱。

– 可零依赖、无 JNI 运行 Wasm 程序。

– WebAssembly 的优势与局限

– 计算时默认沙箱,需提供能力。

– 内存安全等是优势,与 JVM 结合有复杂性。

– Chicory 的灵感与应用

– 受 Wazero 启发。

– 可用于身份管理软件,使复杂企业应用更易扩展。

– Chicory 的现状与未来

– 不能克服 Java 固有慢的问题,新且有工作待完成。

– 部分测试完成,前编译更快,提供设置说明。

思维导图:

文章地址:https://thenewstack.io/chicory-write-to-webassembly-overcome-jvm-shortcomings/

文章来源:thenewstack.io

作者:B. Cameron Gain

发布时间:2024/7/19 19:33

语言:英文

总字数:1413字

预计阅读时间:6分钟

评分:89分

标签:WebAssembly,JVM,Chicory,安全性,沙箱


以下为原文内容

本内容来源于用户推荐转载,旨在分享知识与观点,如有侵权请联系删除 联系邮箱 media@ilingban.com

The Java Virtual Machine (JVM) and WebAssembly have their inherent capabilities. The JVM has been tried and trusted for decades to run Java code and applications. As an inherent part of running Java applications on cloud, mobile especially, on-premises or anywhere Java is run, the JVM has been in wide-scale use across most sectors, including finance, manufacturing, banks and finance. Security and monitoring are provided and through just-in-time (JIT) compilers the JVM has been developed over the years to execute Java code on a range of devices and endpoints, including edge devices, servers, mobile environments and PCs.

WebAssembly (also known as Wasm), on the other hand, has emerged more recently as a way to bundle applications of your choice, written in the language of your choice, and deploy simultaneously across any host environment from edge to cloud wherever there is a CPU instruction set that is compatible with Wasm. Like the JVM, Wasm is — rightly or wrongly — associated with “write once, run anywhere,” although language compatibility struggles to finalize a standard component model to standardize endpoint distribution and other challenges remain. Again, the JVM also is write once, run anywhere only where there are JVM endpoints, unlike a WebAssembly module, which in theory should be able to run anywhere there is a device capable of running a CPU instruction set.

Meanwhile, Chicory was created to bring some of the benefits of Wasm to native JVM. It’s like a virtual machine within a virtual machine, given the security, the tunnel, the sandbox aspects of WebAssembly. With an additional closed module that the JVM offers, the user benefits from a double sandbox, so to speak.

As described on Chicory’s readme.md file on GitHub, Chicory is a JVM-native WebAssembly runtime. It was created so WebAssembly programs can run with zero native dependencies or Java Native Interface (JNI). “Chicory can run Wasm anywhere that the JVM can go. It is designed with simplicity and safety in mind,” its creators write.

Wasm Help

On its own, Wasm can’t do anything but compute, explained Benjamin Eckel, co-creator of Chicory and CTO and co-founder of Dylibso — which makes Extism,a framework designed to enable software end users to enhance existing applications with Wasm. Since, in theory, it cannot affect the outside world, WebAssembly might seem like a weakness, but this is actually Wasm’s greatest strength, Eckel said.

By default, programs are sandboxed and have no capabilities. If a program needs capabilities, capabilities must be provided. This puts the developer in the position of the operating system. A module can ask for a capability by listing an “import” function in the bytecode format. This import can be fulfilled with a host function written in Java. Regardless of the language of the module, the module can call this Java function when needed. Host functions can be thought of as syscalls or a language’s standard library, but host functions are determined and implemented in Java, Eckel said.

If linking to a native object in the JVM, the object must be shipped with the application or library, Eckel noted. One of the main reasons for using the JVM is that it compiles to a platform-independent bytecode, which is the primary benefit of writing your application for the JVM. However, this creates the problem of compiling for every OS, architecture, and libc that needs to be shipped, he said.

On the runtime side, to communicate with some shared object, most systems require using a foreign function interface. In Java, there are a few different names for this, but it is roughly the same concept. There is significant complexity and many problems when execution leaves the safety and observability of the JVM, Eckel said.

If staying within the JVM boundaries, guaranteed memory safety is provided, which has been a reliable feature for a long time, according to Eckel. Fault isolation is also provided, meaning that if a Wasm program is like JVM bytecode, it cannot crash the JVM, which is a major advantage for many applications. Additionally, a super-advanced JIT is available. When using a foreign function interface (FFI), the JIT from the JVM sees the program as a series of holes, going in and out. However, if everything was just one continuous stream of JVM bytecode, the benefits would be much greater, he said.

Memory vulnerabilities are increasingly a concern, and the U.S. government has signaled they will start enforcing use of memory-safe languages, Eckel said in an email response. Meanwhile, by default, Java code is memory-safe and the implementation of the JVM just needs to be checked. “But, if you call native code, you leave the safety of the JVM,” Eckel said. “It’s more opportunity for attackers and more opportunities for mistakes.”

Inspiration

Andrea Peruffo, principal software engineer, for Red Hat, explains how to get started with Chicory.

The open source project Wazero has served as an inspiration for Chicory. With it, runtimes execute WebAssembly modules, which are usually binaries with a .wasm extension, according to Wazero’s documentation. Wazero, for now, is also a zero-dependency WebAssembly runtime written in Go. So, like Chicory, Wazero was created to help make writing a runtime in different languages — C++, Go, Java, Rust and others — easier.

One of the more interesting use cases for Chicory is for identity management software, Andrea Peruffo, principal software engineer, for Red Hat, discussed during a talk “Chicory: Creating a Language-Native Wasm Runtime,” during the Linux Foundation Wasm I/0 conference in 2023. He described how Keycloak is a very popular identity management software that enables single sign-on and other related operations. However, what might not be known is that it contains complex, spaghetti code designed to integrate with any kind of legacy system. Active Directory can be on one side, LDAP, and then Kerberos, and so on. While rewriting these integrations in Rust might seem appealing, it’s not practical. This is where the power of Java comes in. Enterprise applications like these are not easy to replace, so the goal is to empower them and make their usage more flexible, Peruffo noted.

In Keycloak, if custom operations are needed, such as checking a user’s identity against different providers or inserting custom business rules, typically a Java plugin has to be written, Peruffo continued. But why limit development to Java? By importing a JVM library, plugins can be written in any language that compiles to WebAssembly, such as Rust, C, Go, JavaScript and more. An initial proof of concept was created in just two hours by importing a JVM library. This approach makes enterprise applications, which are often heavy and complex, easily extensible with a lightweight system. It simply involves importing a library and enabling the application to load and run Wasm code. This capability is incredibly useful, Peruffo said.

Up and Running

Chicory is not able to overcome Java’s inherent slowness, compared to other languages, yet it remains potentially practical for the reason described above. Still, Chicory is a new project and work remains to be done. Thus far, it can (according to the documentation):

Bootstrap a bytecode interpreter and test suite and features:

By the end of summer, it should be able to:

  • Make all tests green with the interpreter (important for correctness).
  • Implement validation logic (important for safety).
  • Draft of the v1.0 API (important for stability and dx).

Other new roadmap updates from the project’s readme.md include:

  • Completion of about 30,000 tests to ensure Wasm specifications are met.
  • Bytecode validation is 95% complete.
  • The ahead-of-time compilation is in production and has proven to be much faster than the interpreter mode, the project’s creators say.

Set-Up

While I was not yet able to get Chicory to load and run on my Windows laptop, stay tuned for a review about how to set it up and run. Chicory’s readme.md provides solid setup instructions to get started, in the meantime:

Add the com.dylibso.chicory:runtime dependency to the dependency management system to use the runtime:

<dependency>

<groupId>com.dylibso.chicory</groupId>

<artifactId>runtime</artifactId>

<version>0.0.10</version>

</dependency>

Implementation:

‘com.dylibso.chicory:runtime:0.0.10’

The Java generator CLI is available for download on Maven at the link:

https://repo1.maven.org/maven2/com/dylibso/chicory/cli/<version>/cli<version>.sh

For more information about the project and how to contribute, a dedicated Zulip channel is available.

YOUTUBE.COM/THENEWSTACK

Tech moves fast, don’t miss an episode. Subscribe to our YouTubechannel to stream all our podcasts, interviews, demos, and more.

GroupCreated with Sketch.