5 ms·

Turbocall – Just-in-time compiler for Deno FFI

chatmasta 2y ago
There have been a lot of security bugs in Chrome related to this layer of V8, most of them caused by some form of type confusion. Is there worry about increasing the size of Deno's attack surface by adding this capability?
- Retr0id 2y ago
  JIT is a large attack surface, but it's mostly an attack surface from the perspective of migrating from "untrusted" (attacker-controlled) javascript execution, to arbitrary native code execution (e.g. malicious js on a webpage, breaking out). If a Deno user wants to use FFI to invoke system("rm -rf /*"), they can*, and they don't need to exploit a JIT bug to do so. FFI with JIT is almost certainly a larger attack surface than FFI without JIT, but in practice I don't think it's a big difference. *iiuc Deno is sandboxed by default, so presumably FFI capabilities (and the attack surface implications thereof) are something the developer needs to opt into from the start.
pjmlp 2y ago
This is one of the approaches for FFI taken by other runtimes, however it has the issue that without binding generators (jextract, P/Invoke code generators, ctypesgen), the type declarations are a pain to write. Thus something like this would need a similar tool.
- aapoalas 2y ago
  deno_bindgen exists which can be used to do this from Rust. I have written a partial solution for C, though it is bespoke for my libclang bindings, and a very rough one for C++. Both of these require more work to really be ready-to-use tools however. [1] libclang C binding generator: https://github.com/aapoalas/libclang_deno/blob/main/build/build.ts https://github.com/aapoalas/libclang_deno/blob/main/build/bu... [2] C++ binding generator: https://github.com/aapoalas/txx https://github.com/aapoalas/txx
  - pjmlp 2y ago
    I see, thanks for the heads up.
AbuAssar 2y ago
it is refreshing to witness deno surpasses bun in a benchmark!
diath 2y ago
Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?
- aapoalas 2y ago
  This feature and these APIs have been in Demo for a few years at this point.
- Kamq 2y ago
  This is only one strategy to get adoption. The other is to have better apis/more features so that new projects gradually move to your runtime. In this hypothetical, eventually being on node would become like still being on java 8 is today.
  - pjmlp 2y ago
    Except node, like Java, moves along, making those that made a bet being a better Java 8, seem irrelevant with time, unless they happened to have a platform holder sponsoring their existence. Deno needs a bit more than that for adoption.
- notnullorvoid 2y ago
  As a heavy Node user, I think it was a mistake for Deno to try to bake in a compatibility layer with Node. It's a moving target, and will detract from other valuable work. Node compatibility is not something that will get me to switch to Deno. I will switch once I'm not restricted to the bundled TSC version, and there is a well supported bundler for client code.
tekknolagi 2y ago
We built something similar for pypy! See the blog post: https://bernsteinbear.com/blog/typed-c-extensions/ https://bernsteinbear.com/blog/typed-c-extensions/ and paper: https://arxiv.org/abs/2403.02420 https://arxiv.org/abs/2403.02420 TL;DR: similar speedups! It works well
irq-1 2y ago
This only seems to speedup value functions (not struct/callback or other C functions.) From the referenced file: https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-fast-api-calls.h https://source.chromium.org/chromium/chromium/src/+/main:v8/... * Currently supported return types: * - void * - bool * - int32_t * - uint32_t * - float32_t * - float64_t * Currently supported argument types: * - pointer to an embedder type * - JavaScript array of primitive types * - bool * - int32_t * - uint32_t * - int64_t * - uint64_t * - float32_t * - float64_t

There have been a lot of security bugs in Chrome related to this layer of V8, most of them caused by some form of type confusion. Is there worry about increasing the size of Deno's attack surface by adding this capability?

Retr0id 2y ago
JIT is a large attack surface, but it's mostly an attack surface from the perspective of migrating from "untrusted" (attacker-controlled) javascript execution, to arbitrary native code execution (e.g. malicious js on a webpage, breaking out). If a Deno user wants to use FFI to invoke system("rm -rf /*"), they can*, and they don't need to exploit a JIT bug to do so. FFI with JIT is almost certainly a larger attack surface than FFI without JIT, but in practice I don't think it's a big difference. *iiuc Deno is sandboxed by default, so presumably FFI capabilities (and the attack surface implications thereof) are something the developer needs to opt into from the start.

pjmlp 2y ago

This is one of the approaches for FFI taken by other runtimes, however it has the issue that without binding generators (jextract, P/Invoke code generators, ctypesgen), the type declarations are a pain to write. Thus something like this would need a similar tool.

aapoalas 2y ago
deno_bindgen exists which can be used to do this from Rust. I have written a partial solution for C, though it is bespoke for my libclang bindings, and a very rough one for C++. Both of these require more work to really be ready-to-use tools however. [1] libclang C binding generator: https://github.com/aapoalas/libclang_deno/blob/main/build/build.ts https://github.com/aapoalas/libclang_deno/blob/main/build/bu... [2] C++ binding generator: https://github.com/aapoalas/txx https://github.com/aapoalas/txx
- pjmlp 2y ago
  I see, thanks for the heads up.

AbuAssar 2y ago

it is refreshing to witness deno surpasses bun in a benchmark!

diath 2y ago

Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?

aapoalas 2y ago
This feature and these APIs have been in Demo for a few years at this point.
Kamq 2y ago
This is only one strategy to get adoption. The other is to have better apis/more features so that new projects gradually move to your runtime. In this hypothetical, eventually being on node would become like still being on java 8 is today.
- pjmlp 2y ago
  Except node, like Java, moves along, making those that made a bet being a better Java 8, seem irrelevant with time, unless they happened to have a platform holder sponsoring their existence. Deno needs a bit more than that for adoption.
notnullorvoid 2y ago
As a heavy Node user, I think it was a mistake for Deno to try to bake in a compatibility layer with Node. It's a moving target, and will detract from other valuable work. Node compatibility is not something that will get me to switch to Deno. I will switch once I'm not restricted to the bundled TSC version, and there is a well supported bundler for client code.

tekknolagi 2y ago

We built something similar for pypy! See the blog post: https://bernsteinbear.com/blog/typed-c-extensions/ https://bernsteinbear.com/blog/typed-c-extensions/ and paper: https://arxiv.org/abs/2403.02420 https://arxiv.org/abs/2403.02420 TL;DR: similar speedups! It works well

irq-1 2y ago

This only seems to speedup value functions (not struct/callback or other C functions.) From the referenced file: https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-fast-api-calls.h https://source.chromium.org/chromium/chromium/src/+/main:v8/... * Currently supported return types: * - void * - bool * - int32_t * - uint32_t * - float32_t * - float64_t * Currently supported argument types: * - pointer to an embedder type * - JavaScript array of primitive types * - bool * - int32_t * - uint32_t * - int64_t * - uint64_t * - float32_t * - float64_t