Google ya trabaja en la migración de diferentes componentes de Android a Rust

Desde hace ya varios meses, hemos compartido aquí en el blog algunas de las noticias más destacadas sobre el apoyo y aceptación que ha tenido Rust en los diferentes proyectos y desarrollos, de los cuales muchos de ellos son pesos pesados, dígase Linux, Windows e incluso Android.

A pesar de tener una gran aceptación por parte de los grandes, el cambio hacia Rust no es fácil, ya que incluso para poder ser aceptado como segundo lenguaje de programación en el Kernel de Linux, tuvo que pasar por bastantes cosas para que Linus Torvalds diera el visto bueno.

Para el caso de Google, esto no ha sido una excepción y desde hace ya varios meses, Google ha introducido Rust en muchos de sus proyectos y Android es uno de ellos y en el cual se ha llevado una etapa de migración bastante controlada, pues como parte de sus esfuerzos para fortalecer la seguridad de los componentes de software críticos de la plataforma, ahora Google dio a conocer que ha finalizado con el trabajo de la migración del fimware «Android Virtualization Framework’s protected VM (pVM)» a Rust.

Este firmware es utilizado para organizar el funcionamiento de las máquinas virtuales lanzadas por el hipervisor pVM desde Android. Anteriormente, el firmware se escribía en C y se implementaba sobre el gestor de arranque U-Boot, en cuyo código se encontraron previamente vulnerabilidades causadas por problemas con la memoria.

El hipervisor pVM toma el control en una etapa temprana del arranque y proporciona un aislamiento completo de la memoria de la máquina virtual del entorno del host, evitando el acceso desde el sistema host a las máquinas virtuales protegidas que procesan datos confidenciales. El firmware pvmfm (Firmware de máquina virtual protegida) toma el control inmediatamente después de iniciar la máquina virtual, verifica el entorno generado y decide abortar el inicio si se detectan problemas de integridad o genera un certificado de inicio para el sistema invitado si se confirma la cadena de confianza.

La reescritura de Rust hace que sea más fácil y seguro cumplir con la » regla de dos » de Google para mantener seguros los componentes del sistema Android. De acuerdo con esta regla, cualquier código agregado debe cumplir no más de dos de tres condiciones: trabajar con datos de entrada no validados, usar un lenguaje de programación no seguro (C/C++) y ejecutarse con privilegios elevados. Esta regla implica que el código para procesar datos externos debe reducirse a privilegios mínimos (aislado) o escribirse en un lenguaje de programación seguro. Según las estadísticas de Google, aproximadamente el 70% de todas las vulnerabilidades peligrosas identificadas en Android se deben a errores al trabajar con la memoria.

Entre las dificultades que surgen en el proceso de desarrollo de componentes de bajo nivel como controladores en el lenguaje Rust, se menciona la necesidad de trabajar con punteros en modo inseguro, ya que Rust se crea pensando en el uso de la memoria asignada en el lenguaje Rust.

Entre las desventajas, también cabe destacar la necesidad de una sintaxis mejorada para acceder a campos de estructura e índices de matriz a través de punteros simples sin crear referencias, así como limitaciones en la creación de enlaces seguros sobre operaciones inseguras que pueden causar un comportamiento indefinido y no pueden ser verificadas por el compilador.

Cabe mencionar que el nuevo firmware reescrito en Rust se incluye en Android 14 y las bibliotecas universales creadas durante el proceso de desarrollo del firmware se empaquetan como paquetes y se transfieren a la comunidad de Rust. El tamaño del código resultante en comparación con la versión anterior del firmware pVM que ocupaba 220 kB, el nuevo código ocupa 460 kB, pero se agregaron nuevas funciones a la versión reescrita, gracias a las cuales fue posible deshacerse de algunos otros componentes utilizados durante el arranque.

Como resultado, el tamaño total de todos los componentes antiguos y nuevos del maletero resultó ser comparable. Cabe señalar que cuando el tamaño es más importante que el rendimiento, se pueden lograr resultados comparables a los del lenguaje C habilitando modos de optimización de tamaño adicionales en el compilador, descartando dependencias innecesarias y sin utilizar formateadores de cadenas.

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/LH8pafR
via IFTTT

Nos lo habían prometido y ya está aquí. La Raspberry Pi 5 está a la vuelta de la esquina, y no podía llegar sin un buen traje de gala. Ese traje será el Raspberry Pi OS basado en el Debian 12 que llegó en junio, y esa es la novedad más destacada de todo lo que incluye la actualización. Es en la base en donde residen componentes como la versión de Python, PipeWire, redes y todo lo que hace que un sistema operativo se mueva con software más moderno.

El kernel que usa este Raspberry Pi OS es el mismo que el de la versión anterior, ya que el hecho de que esta distribución para placas de la frambuesa esté basada en Debian no obliga a que tengan que usar todo igual que su antecesor, y si no que se lo digan a su hijo favorito. En definitiva, el kernel es Linux 6.1, y a continuación tenéis una lista con lo más destacado que ha llegado con este Bookworm para las Pi.

Novedades más destacadas de Raspberry Pi OS «Bookworm»

• Basado en Debian 12.
• Linux 6.1, soportado hasta diciembre de 2026. Cambia raspberrypi-kernel por el basado en Debian linux-image-rpi.
• Ahora usa Wayfire Wayland como gestor de ventanas, pero sólo para las RPi4 y RPi5. En versiones anteriores sigue usando Openbox.
• LXpanel ha sido modificado por wf-panel-pi, este cambio motivado por el del punto anterior. Otros componentes han seguido el mismo camino o similar, con actualizaciones o cambios en su totalidad para mejorar el soporte y la consistencia con Wayland.
• PipeWire se usa ahora por defecto.
• El gestor de redes pasa a ser NetworkManager.
• El navegador por defecto pasa a ser Firefox, dejando atrás al Chromium que había usado siempre.

32bits como versión principal

No circulaban rumores ni nadie esperaba otra cosa, pero hay que mencionar que la imagen de 32bits sigue siendo la opción principal. Hay una de 64bits, pero como opción.

¿Es esto importante? No. Y sí. Ofreciendo como opción principal la imagen de 32bits se asegura que el soporte con todo lo existente es bueno, pero no se «presiona» para un avance. Sin esa presión, los desarrolladores no actualizarán su software para los 64bits y no se podrá usar en esa versión.

Las Raspberry Pi 4/5/400 tienen una opción con 8GB de RAM. Si alguien quiere aprovechar toda esa memoria tiene que usar la imagen de los 64bit,s y si los terceros desarrolladores no están por la labor habrá menos compatibilidad.

Descarga Raspberry Pi OS

Las imágenes de Raspberry Pi OS están todas en la página de descargas del proyecto. Si se usa Imager, se pueden descargar e instalar desde el software oficial de la compañía.

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