El mejor runtime de WebAssembly puede ser ningún runtime

Artículo original ↗ Discusión en Hacker News ↗

Compilar módulos de WebAssembly de vuelta a C se presenta como una forma de ejecutar código nativo portátil y sandboxeado sin un runtime pesado, permitiendo cosas como sistemas de plugins más seguros y binarios multiplataforma. Los comentaristas comparan este enfoque con tecnologías anteriores como Google Native Client, discuten cómo el modelo restringido y bien especificado de WASM y su ecosistema de herramientas lo hacen atractivo como una capa intermedia universal, y señalan el uso que Firefox ya hace de esta técnica. También destacan limitaciones y compromisos: los errores internos de memoria en C siguen presentes, la comprobación de límites y el determinismo pueden añadir sobrecarga, la integración con lenguajes de nivel superior y con el DOM sigue siendo incómoda, y algunos consideran que el hype general de WASM supera su soporte real para lenguajes y plataformas.

Wasm→C como sandboxing “sin VM”

  • Idea: compilar C (u otros lenguajes) a WebAssembly, luego transpilar wasm a C y compilar nativamente, heredando las garantías de seguridad de wasm sin un runtime pesado.
  • Firefox ya hace una variante (RLBox): wasm como frontera de aislamiento y luego recompilado para velocidad.
  • w2c2 actualmente se centra en la portabilidad, no en el sandboxing; wasm2c apunta a una seguridad conforme a la especificación (comprobaciones de límites, llamadas indirectas con seguridad de tipos).

Seguridad, comprobación de límites y aislamiento del sistema operativo

  • Algunos sostienen que esto es redundante: los procesos ya obtienen aislamiento basado en MMU; los sandbox estilo seccomp y los contenedores clásicos pueden ser tan seguros o más, con superficies de syscall más estrechas.
  • Otros dicen que wasm incrustado resulta atractivo cuando no puedes levantar procesos/contendedores, y para casos de uso tipo plugins.
  • Wasm se basa en memoria lineal con límites aplicados; los motores de producción usan páginas de guardia + mprotect/manejadores de fallos para comprobaciones de coste casi cero.
  • Limitación importante: wasm no corrige errores lógicos ni corrupción de memoria dentro del módulo; los módulos no confiables quedan aislados del host, pero el C inseguro interno sigue siendo inseguro.

NaCl, PNaCl y cómo llegamos a wasm

  • Native Client resolvía problemas similares, pero era específico de CPU; el formato wire de bitcode LLVM de PNaCl y el enredo con glibc eran complicados.
  • asm.js surgió como una alternativa más simple; wasm fue una estandarización multivendor de esas lecciones.
  • Algunos ven el fracaso de NaCl sobre todo como técnico; otros enfatizan razones políticas / de ecosistema.

C vs LLVM IR vs otros IRs

  • A favor de C: C es estable, ampliamente soportado y funciona como IR portátil, incluso en sistemas operativos oscuros (p. ej., Mac OS 9, CPUs extrañas).
  • En contra de C: C no puede expresar un aliasing más rico, sum types, ni un manejo detallado de UB; LLVM IR sería más expresivo, pero es un objetivo móvil y depende de versiones.
  • Visión: wasm como una capa intermedia universal (→wasm→C/anything) en lugar de añadir comprobaciones de límites a cada compilador C.

Debates sobre diseño de bytecode y rendimiento

  • Algunos critican el diseño basado en pila de wasm por añadir complejidad frente a IRs basados en registros; otros lo defienden como suficiente y probado en batalla.
  • Hay desacuerdo sobre cuán “universal” seguirá siendo wasm a medida que crezca (GC, threads, funciones más ricas) frente a volverse más opinado como JVM/CLR.

Casos de uso, hype y escepticismo

  • Los entusiastas: wasm es una ISA portátil para plugins sandboxeados, serverless, embebido, bibliotecas entre lenguajes y preservación de software; los efectos de red superan los defectos técnicos.
  • Los escépticos: el hype exagera la novedad y la seguridad; bytecodes y VMs existentes abordaron objetivos similares durante décadas; wasm no resuelve de forma inherente los problemas de UI web (complejidad de HTML/CSS/JS).
  • Algunos ven wasm fuera del navegador (WASI, sistemas de plugins, empaquetado estilo Cosmopolitan) como más impactante que las apps web.

GC, lenguajes de alto nivel y DOM

  • Se espera que wasm GC ayude a los lenguajes gestionados, pero existen preocupaciones sobre el desajuste con runtimes como Go/Java y la falta de cosas como un cambio de pila eficiente.
  • Wasm no puede tocar directamente DOM/WebGPU; se requieren shims de JS. Algunos quieren apps web totalmente libres de JS; otros argumentan que el DOM y las Web APIs tienen inherentemente forma de JS y que la sobrecarga es insignificante en relación con los costes del DOM.