Introducción
Este documento resume mis visiones de qué y cómo puede y debe ser mejorada sobre el Marco del Sistema Operativo Genode a fin de hacer utilizable en una base de día a día en diversas aplicaciones.
Por favor, tenga en cuenta que algunas de estas opiniones pueden estar sesgados porque mi principal interés en Genode lo está utilizando como una solución de virtualización para sistemas integrados (es decir, , los teléfonos inteligentes y Tablet PC). Algunas de las ideas están inspiradas en una experiencia de portar Genode a un teléfono Samsung Galaxy Nexus, por lo que se correlacionan con lo que tengo la intención de trabajar en lo largo de 2013. Norman Feske de Genode laboratorios ha expresado su desacuerdo sobre algunos puntos aquí, así que le invitamos a comentar y añadir tus ideas y vamos a ver cómo resulta.
Y sí, quiero que cualquier teléfono móvil geek y un hacker incrustado por ahí leyendo este post se une el esfuerzo de hacer Genode funcionar con al menos un teléfono disponible en el mercado. Cmon, XDA multitud, ¿dónde estás?
Mientras que este texto puede parecer excesivamente prolijo, traté de explicar los puntos en un lenguaje sencillo para que mi motivación detrás de cada idea es clara para todos los lectores, incluso aquellos familiarizado con el área del desarrollo del sistema operativo y sin el conocimiento de diseño de hardware incorporado.
En general, creo que tenemos que portar un montón de funcionalidades comunes a la mayoría de los núcleos del sistema operativo, como controladores, protocolos de apoyo del sistema de archivos y creación de redes, pero al mismo tiempo me gustaría evitar reimplementar todo el linux en C + +. Tal vez la mejor solución es mantener los conductores dentro Genode, y dejando una instancia linux paravirtualizado gestionar redes y servir de plataforma para la ejecución de aplicaciones de espacio de usuario.
De hecho, Genode en ARM hoy es como linux fue hace 7-10 años. De hecho, puede hacer que se ejecute, pero la infraestructura controlador de dispositivo no está y usted tendrá que escribir todo desde cero. Y va a ser lenta y hambriento de poder.
Seguridad
En la actualidad, el problema de seguridad más fuerte con Genode es la falta de control sobre el mapeo de la memoria IO. Cualquier servicio que tiene la capacidad de una organización internacional o la conexión es capaz de asignar el área de memoria arbitraria. Además, la asignación de memoria es exclusiva y múltiples servicios no puede asignar la misma región. Esto trae dos problemas de seguridad y los inconvenientes de programación.
IO
propongo un nuevo asignador de memoria IO ser escrito para proporcionar de grano región de mapeo. En primer lugar, debe ser inicializado con una lista de regiones de memoria. Cada región debe contener su nombre, la base física y longitud. He aquí un ejemplo de cómo la configuración sería así:
;
Cada servicio que requiera el acceso RM debe utilizar un proxy para limitar su acceso a determinadas regiones. Ejemplo:
Para algunos SoC (System on Chip, esencialmente, un microprocesador y la lógica que viene dentro de ella como de visualización o de memoria los controladores) regiones IO, podríamos definirlos dentro del código de servicio (conductor platform_drv) de modo que las definiciones no tienen que ser duplicados dentro del archivo de configuración XML.
Tal enfoque implica levantar las regiones por su nombre se elimina la necesidad de almacenar las definiciones de región en archivos de cabecera y las duplican en configuraciones de servidores proxy.
Como alternativa, podríamos escribir un proxy que restringiría IO acceso a un área de memoria específica y crear una instancia de la misma para todos los servicios que desea tener acceso a la memoria IO . La desventaja de este enfoque es que las definiciones de región IO serán repartidos por el archivo de configuración de conjunto y posiblemente duplicadas en ambas cabeceras de C + + y configuraciones.
Hardware – marco genérico
Si bien Techically podríamos utilizar Genode como una capa de virtualización fino y justo delante de todo IO a un núcleo tradicional virtualizado (linux) como Xen hace, eso no resolvería los problemas de fiabilidad, seguridad y administración. Trasladar los controladores de dispositivo para Genode en vez de correr en kernels paravirtualizados da ciertas ventajas:
- Aislamiento – cada conductor se está ejecutando en un espacio de memoria virtual independiente
- invitados (virtualizado) kernel se pueden actualizar de forma independiente de los controladores de hardware
Por lo tanto, echemos un vistazo a lo que necesitamos en que ha implementado con el fin de utilizar