Zircon destacado: vDSO (objeto virtual dinámico compartido)

Circón? Que es esto

En agosto de 2016, sin ningún anuncio oficial de Google, se descubrieron las fuentes del nuevo sistema operativo. Fucsia. Este sistema operativo se basa en un microkernel llamado Zircon, que a su vez se basa en LK (Little Kernel) .

Fuchsia no es Linux

¿Qué se discutirá en el artículo?

vDSO en Zircon es el único medio para acceder a las llamadas del sistema (syscalls) .

¿Es realmente imposible llamar directamente a las instrucciones del procesador SYSENTER / SYSCALL desde nuestro código? No, estas instrucciones de procesador no forman parte del sistema ABI. El código de usuario tiene prohibido seguir directamente estas instrucciones.

Aquellos que quieran conocer más detalles sobre este paso arquitectónico, los invito a Cat.

Zircon vDSO (objeto virtual compartido dinámico)

El acrónimo vDSO significa V ithual D dinámico S hared O bject:

• Dynamic Shared Object es un término utilizado para referirse a bibliotecas compartidas para el formato ELF (archivos .so).
• Este objeto es virtual porque no se carga desde un archivo separado existente en el sistema de archivos. La imagen vDSO es proporcionada directamente por el núcleo.

Soporte de kernel

El soporte para vDSO como el único ABI controlado para aplicaciones en modo de usuario se implementa de dos maneras:

1. Proyectar un objeto de memoria virtual ( VMO, objeto de memoria virtual ).
   
   Cuando zx_vmar_map procesa VMO para vDSO (y ZX_VM_PERM_EXECUTE solicita ZX_VM_PERM_EXECUTE en los argumentos), el núcleo requiere que el desplazamiento y el tamaño coincidan estrictamente con el segmento ejecutable de vDSO. Esto (incluido) garantiza solo una proyección vDSO en la memoria del proceso. Después de la primera proyección exitosa de vDSO en el proceso, ya no se puede eliminar. Y un intento de volver a proyectar vDSO en la memoria del proceso, intenta eliminar el VMO proyectado para vDSO o el proyecto con el desplazamiento y / o tamaño incorrecto falla con el error ZX_ERR_ACCESS_DENIED .
   El desplazamiento y el tamaño del código vDSO se extraen en la etapa de compilación del archivo ELF y luego se utilizan en el código del núcleo para realizar las comprobaciones anteriores. Después de la primera proyección exitosa de vDSO, el núcleo del sistema operativo recuerda la dirección del proceso de destino para acelerar las comprobaciones.

   
   

2. Verifique las direcciones de retorno para las funciones de llamada del sistema.
   
   Cuando el código de modo de usuario llama al núcleo, se transmite un número de llamada de sistema de bajo nivel en el registro. Las llamadas de sistema de bajo nivel son la interfaz interna (privada) entre vDSO y el núcleo Zircon. Algunos (la mayoría) corresponden directamente a las llamadas del sistema de la ABI pública, mientras que otros no.
   Para cada llamada de sistema de bajo nivel en el código vDSO, hay un conjunto fijo de compensaciones en el código que realiza esta llamada. El código fuente de vDSO define caracteres internos que identifican cada una de esas ubicaciones. En el momento de la compilación, estas ubicaciones se recuperan de la tabla de símbolos vDSO y se utilizan para generar el código del núcleo que determina la predicción de la validez de la dirección del código para cada llamada de sistema de bajo nivel. Estos predicados le permiten verificar rápidamente la validez del código de llamada, dado el desplazamiento desde el comienzo del segmento de código vDSO.
   Si el predicado determina que el código de llamada no tiene permiso para realizar una llamada al sistema, se genera una excepción sintética, similar a la de si el código de llamada intentara ejecutar una instrucción inexistente o privilegiada.

   
   

vDSO al crear un nuevo proceso

Para iniciar la ejecución del primer subproceso de un proceso recién creado, se utiliza la llamada al sistema zx_process_start . El último parámetro de esta llamada al sistema (ver arg2 en la documentación) pasa el argumento para el primer hilo del proceso creado. Según el acuerdo aceptado, el cargador del programa asigna vDSO al espacio de direcciones del nuevo proceso (a un lugar aleatorio seleccionado por el sistema) y transfiere la dirección base de la asignación con el argumento arg2 al primer subproceso del proceso creado. Esta dirección es la dirección del encabezado del archivo ELF, en el que se pueden encontrar las funciones con nombre necesarias para realizar llamadas al sistema.

Tarjeta de memoria (diseño) vDSO

vDSO es una biblioteca compartida EFL regular que puede considerarse como cualquier otra. Pero para vDSO, se selecciona intencionalmente un pequeño subconjunto de todo el formato ELF. Esto tiene varias ventajas:

• El mapeo de dicho ELF en el proceso es simple y no incluye ningún caso límite complejo que se requiera para apoyar completamente los programas ELF.
• El uso de vDSO no requiere un enlace ELF dinámico completamente funcional. En particular, vDSO no tiene reubicaciones dinámicas. Proyectar segmentos PT_LOAD de un archivo ELF es la única acción requerida.
• El código vDSO no tiene estado y es reentrante. Funciona exclusivamente con registros de procesador y la pila. Esto lo hace adecuado para su uso en una amplia variedad de contextos con restricciones mínimas, que cumple con el sistema operativo ABI obligatorio. También simplifica el análisis de código y la verificación de confiabilidad y seguridad.

Toda la memoria vDSO está representada por dos segmentos consecutivos, cada uno de los cuales contiene páginas enteras alineadas:

1. El primer segmento es de solo lectura e incluye encabezados ELF y datos constantes.
2. El segundo segmento es ejecutable y contiene código vDSO.

Toda la imagen vDSO consta de solo las páginas de estos dos segmentos. Solo se requieren dos valores extraídos de los encabezados ELF para mostrar la memoria vDSO: el número de páginas en cada segmento.

Datos constantes del tiempo de arranque del sistema operativo

Algunas llamadas al sistema simplemente devuelven valores que son constantes (los valores deben solicitarse en tiempo de ejecución y no pueden compilarse en el código de modo de usuario). Estos valores son fijos en el núcleo en el momento de la compilación, o determinados por el núcleo en el momento del arranque (parámetros de arranque y parámetros de hardware). Por ejemplo: zx_system_get_version () , zx_system_get_num_cpus () y zx_ticks_per_second () . El valor de retorno de la última función, por ejemplo, se ve afectado por el parámetro de línea de comando del núcleo .

Como estos valores son constantes, no tiene sentido pagar las llamadas reales del sistema al núcleo del sistema operativo. En cambio, su implementación son funciones simples de C ++ que devuelven datos leídos del segmento constante vDSO. Los valores capturados durante la compilación (como la cadena de versión del sistema) simplemente se compilan en vDSO.

Para valores determinados en el momento del arranque, el núcleo debe modificar el contenido de vDSO. Esto se realiza utilizando un código ejecutable temprano que forma el VMO vDSO antes de que el núcleo inicie el primer proceso de usuario (y le pase el descriptor de VMO). Durante la compilación, las compensaciones de la imagen vDSO ( vdso_constants ) se extraen del archivo ELF y luego se incrustan en el núcleo. Y en el momento del arranque, el núcleo muestra temporalmente páginas que abarcan vdso_constants en su propio espacio de direcciones para preinicializar la estructura con los valores correctos (para el inicio actual del sistema).

¿Por qué todo este dolor de cabeza ?

Una de las razones más importantes es la seguridad. Es decir, si un atacante logra ejecutar código arbitrario (shell), tendrá que usar funciones vDSO para llamar a las funciones del sistema. El primer obstáculo será la aleatorización antes mencionada de la dirección de inicio de vDSO para cada proceso creado. Y dado que el kernel del sistema operativo es responsable del VMO (objeto de memoria virtual) de vDSO, puede elegir asignar un vDSO completamente diferente a un proceso específico, lo que prohíbe las llamadas de sistema peligrosas (y no necesarias para un proceso en particular). Por ejemplo: puede evitar que los controladores generen procesos secundarios o manejar áreas MMIO proyectadas. Esta es una gran herramienta para reducir la superficie de ataque.

Nota: Actualmente, el soporte para varios vDSO se está desarrollando activamente. Ya existe una implementación de prueba de concepto y pruebas simples, pero se necesita más trabajo para mejorar la confiabilidad de la implementación y determinar qué opciones están disponibles. El concepto actual proporciona opciones de imagen vDSO que solo exportan un subconjunto de la interfaz de llamada completa del sistema vDSO.