Node.js runtime as camkes component

[Deleted user]

@lsf37 I thought about your reply a few days ago, was reading the seL4 whitepaper and when I saw the diagram of gradually breaking out the system into camkes components, a lightbulb went off 🤔

If Node.js was a tightly integrated camkes component, would that not be superior to Rust because of the security guarantees seL4 provides and the vast ecosystem of JS?

If this works, it can bring contributors and enterprises in seL4's direction which can ultimately accelerate the funding of big-ticket items like the arm64 and multicore kernels.

Also, other languages jump on board and contribute their libraries to seL4.

As I understand it, Node.js has 6 dependencies: V8, libuv, llhttp, c-ares, openssl, zlib. I'm assuming openssl and zlib are already good to go, and (again, assuming) libuv isn't relevant.

Is porting these 3 to seL4 feasible?

Edit: This would also replace hacks like chroot and containers where Node.js is the only runtime.

[lsf37]

Multiple questions here, let me try to answer some of then:

• porting a JS runtime to seL4: would certainly be possible with enough resources and the core of it would probably be a fun project. Things like V8 tend to assume an underlying OS, though, not just a microkernel, i.e. they need file system, drivers, etc. These would have to be provided first, or the language runtime would have to be restricted to the parts that don't use these. Implementing all of it is probably on the order of those big ticker items you mention. Implementing a small prototype could be much simpler.

• language ecosystem: for the same reason (OS services), language ecosystem is not really the most important factor for language choice in this space. C has a gigantic ecosystem of libraries, but they tend to assume a POSIX interface, which seL4 does not provide, and which for a microkernel-based system is not a good OS interface to build towards (according to Gernot, who I trust in such things). We had a Java runtime and a Python runtime on seL4 some years back, but they hit similar problems: availability of the language doesn't mean availability of the ecosystem. It could in the future, but they need enough infrastructure to have an effect. Over time that infrastructure will appear, but without it, more language runtime ports are unlikely to drive adoption.

• JS for low-level code: JS is not a good choice for low-level code, because it is a language with automatic memory allocation and garbage collection. This makes timing and memory use hard to predict. For low-level code, you usually want to keep tight control over these, which C and Rust allow (one big reason Rust is popular in this space is that it combines that control with a modern type system). JS or TS are fine for higher-level applications, but low-level code like file systems, drivers, etc are not that great targets for it.

• security through isolation: yes, the isolation seL4 provides makes it less important what language is chosen for component implementation. If the component itself provides a security function, though, the security of the code itself still matters. So, depending on what kind of component it is, you can choose what language or paradigm suits best and also what level of analysis you need for each.

[Deleted user]

I found this runtime for both JS and TypeScript; interestingly, no file, network, or environment access unless enabled.