Cheerp: un compilador de C++ para la Web

Se dio a conocer hace poco el lanzamiento de Cheerp 3.0, un compilador que permite compilar cualquier código C/C++ en WebAssembly o JavaScript. La nueva rama se destaca por mover el compilador y las bibliotecas que lo acompañan para usar licencias permisivas de Apache 2.0 y LLVM, en lugar de la política de licencias limitada aplicada anteriormente, que ofrece una opción de licencia GPLv2 para proyectos no comerciales y una licencia propietaria para proyectos comerciales.

Cheerp se puede utilizar tanto para portar bibliotecas y aplicaciones C/C++ existentes para ejecutarlas en el navegador como para crear aplicaciones web de alto rendimiento y componentes WebAssembly desde cero.

Ha pasado más de un año desde el lanzamiento anterior de Cheerp ( Cheerp 2.7 ), y esta nueva versión viene repleta de nuevas características y optimizaciones que, una vez más, mueven el estado del arte del uso de C++ como lenguaje de programación para aplicaciones Web y juegos.

Lo que es más importante, con este lanzamiento estamos realizando un cambio significativo en el modelo de licencias de Cheerp. A partir de Cheerp 3.0, todos los componentes y bibliotecas principales del compilador ahora tienen licencia permisiva bajo la licencia Apache 2.0/LLVM . Esto marca un cambio radical con respecto a nuestro modelo de licencia comercial dual/GPLv2 anterior, lo que permite que Cheerp 3.0 se use para cualquier propósito, sin restricciones.

Sobre Cheerp

El proyecto permite combinar código C/C++ y JavaScript en una aplicación web con la capacidad de acceder desde código JavaScript a funciones desarrolladas originalmente en C/C++, y desde código C/C++ a objetos JavaScript, JavaScript bibliotecas, Web API y todas las características DOM, ademas de que se permite crear compilaciones combinadas, parte del código que se compila en JavaScript y parte en WebAssembly. Admite proyectos de construcción que utilizan las bibliotecas libc y libc++ estándar.

En comparación con el compilador Emscripten, Cheerp genera código intermedio WebAssembly más optimizado y compacto (en promedio, el tamaño de los archivos resultantes es un 7 % más pequeño).

Conceptualmente, las diferencias se reducen al hecho de que Emscripten se utiliza como formato de objeto de WebAssembly y realiza el enlace y la optimización en la etapa de posprocesamiento de WebAssembly (wasm-opt). Cheerp usa el código de bytes LLVM como una representación intermedia para bibliotecas y archivos de objetos, lo que permite optimizaciones más amplias en todo el proyecto que usan metadatos de nivel LLVM sin necesidad de posprocesamiento.

Además, Cheerp usa el optimizador PreExecuter para ejecutar código de forma preventiva en tiempo de compilación, por ejemplo, para convertir constructores usados ​​para inicializar objetos globales en constantes. Además, durante la compilación se utiliza PartialExecuter, que, basándose en el análisis de los parámetros de la función, elimina código que se garantiza que no se utilizará durante la ejecución.

Cheerp también puede generar código JavaScript para trabajar dinámicamente con la memoria cubierta por el recolector de basura. En particular, en lugar de emular un espacio de direcciones tradicional con matrices escritas, Cheerp proporciona una asignación directa de objetos de C++ a objetos de JavaScript, lo que reduce el consumo de memoria porque el recolector de elementos no utilizados de JavaScript tiene la capacidad de eliminar objetos no utilizados. Para mejorar el rendimiento, el código intermedio WebAssembly generado utiliza extensiones SIMD para organizar la paralelización de las operaciones de datos.

Cheerp se puede usar como una plataforma para crear aplicaciones web integradas de cliente/servidor en C++. En la práctica actual, es común desarrollar un front-end separado basado en navegador escrito en JavaScript y un back-end separado escrito en PHP, Python, Ruby o JavaScript/Node.js.

Cheerp proporciona los medios para crear aplicaciones web C++ completas que admitan el backend y el frontend en una sola base de código.

Durante el proceso de compilación, el lado del servidor se compila en código nativo y la interfaz se convierte en una representación de JavaScript. La depuración de todos los componentes del proyecto, incluidos los convertidos a JavaScript, se lleva a cabo utilizando textos fuente C++ utilizando la tecnología Source Map.

Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

El código del compilador se basa en los desarrollos de LLVM y Clang e incluye optimizaciones adicionales para mejorar el rendimiento y reducir el tamaño del resultado compilado.

from Linux Adictos https://ift.tt/czChT8K
via IFTTT

NordVPN está lanzando tres de sus productos bajo una licencia de código abierto

El proveedor de VPN, NordVPN dio a conocer hace poco mediante una publicación de blog el lanzamiento de un cliente para Linux de código abierto, la biblioteca de red Libtelio y la biblioteca para compartir archivos Libdrop.

El cliente de Linux proporciona una interfaz de línea de comandos para administrar las conexiones a los servidores NordVPN, lo que permite seleccionar un servidor de la lista en función de la ubicación deseada, cambiar la configuración del protocolo y habilitar el modo Kill Switch, que bloquea el acceso a la red si la conexión a la VPN del servidor se pierde.

Para quienes desconocen de NordVPN, deben saber que este es un servicio VPN proporcionado por la empresa Nordsec con aplicaciones para Microsoft Windows, macOS, Linux, Android, iOS y Android TV.

NordVPN enruta el tráfico a través de un servidor remoto ocultando así la dirección IP y encriptando todos los datos entrantes y salientes. Para el cifrado, NordVPN ha estado utilizando las tecnologías OpenVPN e Internet Key Exchange v2/IPsec en sus aplicaciones y también introdujo su tecnología patentada NordLynx.

NordLynx es una herramienta VPN basada en el protocolo WireGuard , que tiene como objetivo un mejor rendimiento que los protocolos de tunelización IPsec y OpenVPN.

NordVPN para Linux

Sobre el cliente para Linux, se menciona que es compatible con los protocolos NordLynx (basados ​​en WireGuard) y OpenVPN. Usa iptables para cambiar la configuración del firewall, iproute para enrutar, tuntap para tunelizar conexiones y systemd-resolved para resolver nombres DNS.

La biblioteca Libtelio incluye funciones de red típicas y proporciona una implementación de una red virtual MeshNet formada a partir de sistemas de usuario y usada para comunicarse entre sí. Meshnet le permite establecer túneles encriptados entre dispositivos y crear una apariencia de una red local separada basada en ellos.

Estamos haciendo que estos productos sean de código abierto como una señal de nuestro compromiso con la transparencia y la responsabilidad. Queremos el aporte y el escrutinio de la comunidad de programación y mostrarle que tenemos confianza en nuestro propio software.

Este paso también subraya nuestra firme creencia en el progreso colaborativo. La comunidad de ciberseguridad y desarrollo de aplicaciones está llena de codificadores y pentesters talentosos que pueden aportar sus propias perspectivas únicas a nuestras aplicaciones.

A diferencia de VPN, las conexiones en Meshnet no se establecen entre el dispositivo y el servidor VPN, sino entre dispositivos finales, que también participan como nodos para el enrutamiento del tráfico.

Para toda la red MeshNet, puede definir un servidor común para interactuar con el mundo exterior (por ejemplo, si el nodo saliente está ubicado en la casa del usuario, entonces no importa a qué viajes y lugares se conecte el usuario desde los dispositivos conectados a MeshNet, para servicios externos, la actividad de la red se verá así, como si el usuario se estuviera conectando desde su dirección IP de casa).

El código abierto de Libtelio es un paso particularmente importante porque este código forma la columna vertebral de todas nuestras aplicaciones NordVPN, no solo de nuestro cliente Linux. Poner este material en manos de la comunidad de Linux, una de las comunidades de código abierto más sólidas actualmente activas, alienta a los codificadores y desarrolladores talentosos a examinar nuestro código y mejorar nuestro servicio.

Se pueden usar varias implementaciones de Wireguard para cifrar el tráfico en MeshNet. Tanto los servidores VPN como los nodos de usuario dentro de MeshNet se pueden usar como nodos de salida.

Se proporciona un filtro de paquetes configurable para limitar el tráfico dentro de la red y se proporciona un servicio basado en DNS para determinar los hosts. La biblioteca publicada le permite organizar sus propias redes MeshNet en sus aplicaciones.

La biblioteca Libdrop proporciona funciones para organizar el intercambio seguro de archivos entre dispositivos de usuario. Admite el envío y la recepción directos de archivos a través de MeshNet o la red global, sin involucrar servidores de terceros.

Finamente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

Debes saber que el código del cliente está abierto bajo la licencia GPLv3. En el desarrollo se utilizaron los lenguajes de programación Go, Rust, C y Python. Las distribuciones compatibles son Ubuntu, Fedora, Manjaro, Debian, Arch, Kali, CentOS y Rasbian.

from Linux Adictos https://ift.tt/prlnUCo
via IFTTT

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace pocos días se dio a conocer el lanzamiento de las actualizaciones correctivas de Wasmtime 6.0.1, 5.0.1 y 4.0.1 que llegan a solucionan una vulnerabilidad (ya catalogada bajo CVE-2023-26489) que se calificó como crítica.

La vulnerabilidad permite organizar la escritura de datos en un área de memoria fuera de los límites permitidos para el código WebAssembly aislado, que potencialmente puede ser utilizado por un atacante para organizar la ejecución de su código fuera del entorno WASI aislado.

Para quienes desconocen de Wasmtime, deben saber que este es un tiempo de ejecución para ejecutar aplicaciones WebAssembly con extensiones WASI (WebAssembly System Interface) como aplicaciones independientes normales.

Wasmtime está escrito en Rust y la vulnerabilidad se debe a un error lógico en la definición de reglas de direccionamiento de memoria lineal en el generador de código Cranelift, que traduce una representación intermedia independiente de las arquitecturas de hardware en un código de máquina ejecutable para la arquitectura x86_64.

Sobre la vulnerabilidad corregida, se menciona que en particular, se calcularon direcciones efectivas de 35 bits para las aplicaciones de WebAssembly en lugar de las direcciones de 33 bits permitidas en WebAssembly, lo que cambió el límite de memoria virtual permitida para operaciones de lectura y escritura a 34 GB, mientras que la configuración del entorno de espacio aislado proporciona protección para 6 GB. de la dirección base.

El generador de código de Wasmtime, Cranelift, tiene un error en los objetivos x86_64 donde el cálculo del modo de dirección calcularía por error una dirección efectiva de 35 bits en lugar de la dirección efectiva de 33 bits definida por WebAssembly. Este error significa que, con la configuración de generación de código predeterminada, una operación de carga/almacenamiento controlada por wasm podría leer/escribir direcciones de hasta 35 bits de distancia de la base de la memoria lineal. 

Como resultado, el rango de memoria virtual de 6 a 34 GB desde la dirección base estuvo disponible para lectura y escritura desde aplicaciones WebAssembly. Esta memoria puede albergar otros entornos de WebAssembly o componentes de tiempo de ejecución de WebAssembly.

Por ejemplo (i32.load (i32.shl (local.get 0) (i32.const 3))), se carga desde la dirección WebAssembly $local0 << 3. Cuando se traduce a Cranelift, el calculo de $local0 << 3 en un valor de 32 bits, se amplía a cero a un valor de 64 bits y luego se agrega a la dirección base de la memoria lineal. Cranelift generaría una instrucción de la forma movl (%base, %local0, 8), %dst que calcula %base + %local0 << 3.

El error aquí, sin embargo, es que el cálculo de la dirección ocurre con valores de 64 bits, donde $local0 << 3 se suponía que el cálculo se truncaba a un valor de 32 bits. Esto significa que %local0, que puede usar hasta 32 bits para una dirección, obtiene 3 bits adicionales de espacio de direcciones para ser accesible a través de movl .

Por último, como siempre se recomienda actualizar la paquetería a la última versión disponible, tambien vale la pena mencionar que existen varias soluciones posibles que se pueden emplear para mitigar este problema si la actualización no es posible.

Se menciona que ninguna de estas soluciones está activada de forma predeterminada y requiere una configuración explícita:

• Si no es posible actualizar la versión de Wasmtime, se menciona la opción «Config::static_memory_maximum_size(0)» para habilitar la verificación de límites separados obligatorios en cualquier acceso a la memoria lineal como solución alternativa para bloquear el error (da como resultado una degradación significativa del rendimiento).
• Otra opción es utilizar la configuración «Config::static_memory_guard_size(1 < 36)» para aumentar la cantidad de páginas de protección (Página de protección, se lanza una excepción cuando se accede) ubicadas en el rango de memoria virtual problemático (conduce a reservar una gran cantidad de memoria virtual y limitando el número de aplicaciones WebAssembly concurrentes).
• Si es posible usar un host que no sea x86_64, eso también solucionará este error. Este error no afecta al backend AArch64 de Wasmtime o Cranelift, por ejemplo.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/GJU8KhF
via IFTTT