El objetivo es crear sistemas seguros verificables para hardware integrado o dispositivos periféricos

Hace poco Google dio a conocer mediante una publicación de blog a KataOS, un sistema operativo centrado en dispositivos integrados que ejecutan cargas de trabajo de aprendizaje automático. KataOS es está diseñado para estar enfocado en la seguridad, ya que utiliza el lenguaje de programación Rust y se basa en el microkernel seL4 como base.

KataOS está diseñado para usarse con la cantidad cada vez mayor de dispositivos conectados, con un enfoque particular en el hardware integrado que ejecuta aplicaciones de aprendizaje automático. Dado el creciente enfoque industrial de RISC-V, esta arquitectura de procesador es un enfoque de soporte principal para KataOS.

Sobre KataOS

Google presentó su sistema operativo KataOS, aún en desarrollo, cuyo objetivo es brindar un sistema de seguridad para dispositivos embebidos.

Menciona que nació de una observación, debido a la necesidad de trabajar en un proyecto de este tipo, «cada vez se comercializan más dispositivos conectados que recopilan y procesan información ambiental«. Sin embargo, según Google, estos dispositivos son más susceptibles a problemas de seguridad. La empresa señala, por ejemplo, que los datos que recopilan estos dispositivos pueden ser vulnerables a atacantes externos. Esto implica que los virus pueden robar fotos, grabaciones de audio y otros datos.

Para comenzar a colaborar con otros, hemos abierto varios componentes para nuestro sistema operativo seguro, llamado KataOS, en GitHub, así como asociaciones con Antmicro en su simulador Renode y marcos relacionados. Como base para este nuevo sistema operativo, hemos elegido seL4 como microkernel porque prioriza la seguridad; está matemáticamente probado como seguro, con confidencialidad, integridad y disponibilidad garantizadas.

Para Google, una solución simple para lidiar con esto sería un sistema seguro verificable para el hardware a bordo. ¿Por qué ? La seguridad del sistema a menudo se trata como una función de software que se puede agregar a los sistemas existentes o resolver con una pieza adicional de hardware ASIC, que generalmente no es suficiente. Es en este contexto que nació KataOS.

Google también está colaborando con Antmicro. La asociación emulará y depurará GDB en dispositivos de destino utilizando Renode. Internamente, KataOS tiene la capacidad de cargar y ejecutar dinámicamente programas de terceros. Incluso los programas creados fuera del marco CAmkES pueden ejecutarse allí. Los componentes necesarios para ejecutar estas aplicaciones aún no están presentes en la fuente de Github. Sin embargo, Google tiene la intención de que estas operaciones estén disponibles pronto.

Gracias al marco seL4 CAmkES, también podemos proporcionar componentes de sistema analizables y definidos estáticamente. KataOS proporciona una plataforma segura verificable que protege la privacidad de los usuario porque es lógicamente imposible que las aplicaciones violen las protecciones de seguridad del hardware del kernel y los componentes del sistema son verificablemente seguros. KataOS también se implementa casi por completo en Rust, lo que proporciona un punto de partida sólido para la seguridad del software, ya que elimina clases completas de errores, como errores únicos y desbordamientos de búfer.

Google también ha creado una implementación de referencia para KataOS llamada Sparrow. La razón de Sparrow es mostrar completamente el sistema de entorno seguro.

Utiliza KataOS con una plataforma de hardware segura, pues sparrow incluye una raíz de confianza claramente segura creada con OpenTitan en la arquitectura RISC-V. Esto se suma al núcleo del sistema operativo seguro. Sin embargo, para el lanzamiento inicial de KataOS, Google apunta a usar la emulación QEMU. Utilizará esta emulación para ejecutar el sistema ARM de 64 bits más estándar.

Finalmente para los interesados, deben saber que el proyecto se aloja en GitHub y actualmente el repositorio incluye la mayoría de las piezas principales de KataOS, incluidos los marcos que usamos para Rust (como sel4-sys, que proporciona las API de llamadas al sistema seL4), un servidor root alternativo escrito en Rust (necesario para la gestión dinámica de la memoria en todo el sistema) y las modificaciones del núcleo a seL4 que pueden reclamar la memoria utilizada por el servidor raíz.

Pueden visita el repositorio del proyecto en el siguiente enlace.

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

Ya hace mucho tiempo desde que Martin Wimpress, líder del proyecto Ubuntu MATE y quien en aquel momento era jefe del escritorio de Canonical, nos habló de Rolling Rhino. Con nombre de un animal y un adjetivo empezando por la misma letra, lo que propuso era básicamente usar unos scripts para hacer que la versión Daily de Ubuntu pasara a usar los repositorios de desarrolladores, para así actualizarse de por vida como una distribución Rolling Release. Ahora sabemos que Rhino Linux quiere hacer lo mismo, pero usando la versión estable de Ubuntu.

Para ser honesto, yo no conocía la existencia de Rolling Rhino Remix hasta haberme topado con un artículo en la blogosfera Linux. Que lleve el apellido «Remix» puede significar que pretende entrar en la familia Ubuntu, pero que no lleve el nombre del sistema operativo podría ser un problema. El proyecto nació como suelen hacerlo muchos otros: un desarrollador decide hacer lo que le gusta como le gusta y comparte su trabajo. Lo hace por diversión, pero todo puede cambiar si la comunidad apoya la idea.

Rhino Linux no tiene fecha de lanzamiento

Fue el apoyo de la comunidad lo que hizo a http.llamaz cambiar sus planes. Rolling Rhino Remix ha pasado a llamarse Rhino Linux, y la intención es hacer un Ubuntu Rolling Release que no se tenga que actualizar cada seis meses o dos años. Los usuarios de Rhino Linux instalarían el sistema una vez, y recibirían actualizaciones para toda la vida.

Para ser más concretos, lo que obtendremos será un Xubuntu Rholling Release. Se ha elegido la versión Xfce por su estabilidad y velocidad, así como que es personalizable. El gestor de paquetes que usará será Pacstall, basado en AUR, pero muy lejos del repositorio de la comunidad de Arch Linux. Estando el sistema operativo basado en Ubuntu, se espera que también se pueda usar APT.

Sobre una fecha de lanzamiento, sólo se conoce un detalle: llegará en 2023.

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