Consulta cifrado memoria, cache y DMA
Carlos Pantelides
Pedro Martos
Hola,ando con una curiosidad, quizás no esté del todo ordenado pues son temas y preguntas interrelacionados.Entiendo que existe el cifrado de RAM, en particular TME de Intel, que lo que hace es eso, cifrar y descifrar la RAM.Entiendo que para dispositivos memory mapped obviamente deben estar sin cifrar, ya que por ejemplo el trocito de RAM para dejar un frame ethernet no se puede cifrar, se rompería. Para ello se le debe instruir a TME que no cifre esas regiones.DUDA 1.1: Suponiendo todo lo anterior correcto, me intriga o incluso dificulta el pensamiento el escenario de DMA copiando de una zona cifrada a una no cifrada o viceversa.DUDA 1.2: ¿Solo se podría usar DMA entre regiones de la misma condición?DUDA 1.3: ¿Existen dispositivos que entienden el cifrado y si se les provee la key se integran transparentemente?
Aparte, entiendo que al comienzo de los tiempos DMA lo hacía un dispostivo dedicado (intel 8237), disparado por la CPU. Luego, los dispositivos pudieron tomar el control del bus y actuar según la CPU los hayan configurado.Entiendo que PCI hace un barrido detectando dispositivos y luego le reporta al S.O. tal que este luego carga los drivers necesarios para interactuar con los mismos.DUDA 2: En una computadora sin ninguna protección o configuración relativa a IOMMU activada, puede un dispositivo vivir completamente invisible, no reportar al scan PCI. O necesita registrarse de algún modo?
Me imagino que este proceso está lo más cerca posible de la RAM, o sea, que los datos en los caches están cleartext.Entiendo que las operaciones de DMA no están "auditadas", o sea, no hay manera de saber que ocurrió por protocolo.
DUDA 3: qué pasa con los caches cuando una dirección que está en cache es sobreescrita por DMA?
DUDA 4: Si un dispositivo por error o malicia decidiera hacer una operación de DMA y parte de la memoria de destino estuviera cacheada y suponiendo que la respuesta a la DUDA 1 es que el cache se invalida, ¿se podría detectar como efecto colateral esta invalidación inesperada?
DUDA 5: en qué "nivel" está DMA respecto al cifrado?
CPU (cifrado?) caches (cifrado?) DMA (cifrado?) RAMTodo esto lo estoy preguntando para comprender si el cifrado de RAM es una medida potencialmente efectiva para protegerse de dispositivos cuyo propósito sea leer o escribir zonas arbitrarias.
Gracias y saludos
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/embebidos32/821bb918-6695-470d-8e4e-293da9b27bcfn%40googlegroups.com.
Carlos Pantelides
Cifrado de RAM (TME) y DMA
Es correcto que TME (Total Memory Encryption) de Intel cifra y descifra la RAM. Y sí, para dispositivos mapeados en memoria (MMIO) que necesitan acceso directo a la RAM, como una interfaz Ethernet, se deben configurar regiones sin cifrar. Si estos datos se cifraran, el dispositivo no podría entenderlos.
DUDA 1.1: Suponiendo todo lo anterior correcto, me intriga o incluso dificulta el pensamiento el escenario de DMA copiando de una zona cifrada a una no cifrada o viceversa.
Cuando DMA copia datos entre una zona cifrada y una no cifrada (o viceversa), el proceso generalmente funciona de la siguiente manera:
- De zona cifrada a zona no cifrada: Si un dispositivo DMA necesita leer datos de una región cifrada, la CPU (o el controlador de memoria, que en el caso de TME maneja el cifrado/descifrado) descifra los datos antes de que se entreguen al dispositivo. El dispositivo DMA recibe los datos en texto claro y los copia a la región no cifrada, donde no se realiza ningún cifrado adicional.
- De zona no cifrada a zona cifrada: Si un dispositivo DMA escribe datos en una región cifrada, el dispositivo escribe los datos en texto claro. El controlador de memoria intercepta estos datos y los cifra antes de que se almacenen en la RAM.
En esencia, el punto clave es que el controlador de memoria (que implementa TME) actúa como un "traductor" transparente entre el dispositivo DMA y la RAM cifrada/descifrada. El dispositivo DMA opera siempre con datos en texto claro.
DUDA 1.2: ¿Solo se podría usar DMA entre regiones de la misma condición?
No, como se explicó en la DUDA 1.1, se puede usar DMA entre regiones de diferente condición (cifradas y no cifradas). El controlador de memoria se encarga de la traducción necesaria.
DUDA 1.3: ¿Existen dispositivos que entienden el cifrado y si se les provee la key se integran transparentemente?
En general, no es común que los dispositivos DMA "entiendan" el cifrado de RAM por sí mismos o que se les provea la clave de cifrado. La filosofía detrás de TME y soluciones similares es que el cifrado y descifrado sean transparentes para los dispositivos I/O. La clave de cifrado está protegida dentro del hardware de la CPU y del controlador de memoria, y no se expone a los dispositivos externos.
Si un dispositivo pudiera acceder a la clave de cifrado, socavaría la seguridad del sistema. En su lugar, el controlador de memoria se encarga de presentar los datos descifrados al dispositivo y de cifrar los datos del dispositivo antes de escribirlos en la RAM.
Visibilidad de Dispositivos PCI y DMA
DUDA 2: En una computadora sin ninguna protección o configuración relativa a IOMMU activada, ¿puede un dispositivo vivir completamente invisible, no reportar al scan PCI. O necesita registrarse de algún modo?
En un sistema estándar basado en PCI/PCIe, un dispositivo no puede vivir completamente invisible y no reportar al scan PCI. El proceso de enumeración PCI es fundamental para que el sistema operativo detecte y configure los dispositivos. Cada dispositivo PCI/PCIe debe responder a la enumeración para que el sistema operativo pueda asignarle recursos (direcciones de memoria, puertos I/O, interrupciones, etc.) y cargar el driver apropiado.
Si un dispositivo no se registra durante el scan PCI, el sistema operativo simplemente no tendrá conocimiento de su existencia y, por lo tanto, no podrá interactuar con él ni utilizarlo. Esto no significa que un dispositivo malicioso no pueda intentar evadir o manipular el proceso de enumeración o incluso intentar "hacerse pasar" por otro dispositivo, pero el mecanismo estándar requiere registro.
Caches, DMA y Cifrado
Tienes razón al suponer que los datos en los caches de la CPU suelen estar en texto claro. Esto se debe a que la CPU opera con los datos en texto claro y el cifrado/descifrado ocurre en la interfaz con la RAM.
DUDA 3: ¿Qué pasa con los caches cuando una dirección que está en cache es sobrescrita por DMA?
Cuando una dirección de memoria que está presente en la caché de la CPU es sobrescrita por una operación de DMA, el sistema implementa un mecanismo para garantizar la coherencia de la caché. Generalmente, ocurre lo siguiente:
- Invalidación de caché (Cache Invalidation): Cuando una operación de DMA escribe en una línea de caché que está en un estado "modificado" o "exclusivo" en la caché de la CPU, la controladora de memoria o el controlador de DMA (a menudo con la ayuda de la IOMMU si está presente) invalida esa línea de caché. Esto significa que la copia en la caché se marca como no válida, forzando a la CPU a leer la versión más reciente de la RAM la próxima vez que necesite esos datos.
- Write-through/Write-back: Dependiendo de la política de escritura de la caché, la sobrescritura por DMA puede desencadenar una escritura de los datos modificados de la caché a la RAM (write-back) antes de la invalidación, o simplemente invalidar la línea si los datos ya fueron escritos a RAM (write-through).
El objetivo es asegurar que la CPU siempre vea la información más actualizada, ya sea que provenga de la RAM o de la caché.
DUDA 4: Si un dispositivo por error o malicia decidiera hacer una operación de DMA y parte de la memoria de destino estuviera cacheada y suponiendo que la respuesta a la DUDA 1 es que el cache se invalida, ¿se podría detectar como efecto colateral esta invalidación inesperada?
En general, no directamente ni de forma trivial por el software de aplicación. El proceso de invalidación de caché es una operación de hardware interna y de bajo nivel, diseñada para ser transparente para el software. No hay un "evento" o "interrupción" directo que el sistema operativo o una aplicación puedan registrar para saber que una línea de caché específica fue invalidada por DMA.
Sin embargo, en entornos altamente controlados o con herramientas de depuración de hardware muy avanzadas, teóricamente se podría observar el tráfico de coherencia de caché. Pero esto está fuera del alcance de la operación normal de un sistema operativo.
Si un dispositivo malicioso realiza DMA a regiones de memoria que no le corresponden, la detección de esto se haría a través de mecanismos como la IOMMU (Input/Output Memory Management Unit). Una IOMMU crea un "espacio de direcciones virtual" para los dispositivos I/O, lo que permite al sistema operativo controlar qué regiones de memoria física pueden ser accedidas por qué dispositivos. Si un DMA fuera de límites ocurre, la IOMMU generaría un error, que el sistema operativo sí puede detectar y manejar.
DUDA 5: ¿En qué "nivel" está DMA respecto al cifrado?
Aquí tienes una representación del flujo, con la aclaración de dónde ocurre el cifrado/descifrado:
CPU (opera con datos CLEARTEXT en sus registros y unidades funcionales)
|
V
Caches (ALMACENAN datos CLEARTEXT)
|
V
[CONTROLADOR DE MEMORIA / TME] <-- AQUÍ OCURRE EL CIFRADO/DESCIFRADO
|
V
RAM (ALMACENA datos ENCRIPTADOS)
^
|
DMA (opera con datos CLEARTEXT, el controlador de memoria los cifra/descifra al interactuar con RAM)
Explicación detallada:
- CPU: La CPU internamente procesa datos en texto claro.
- Caches: Los datos en los caches de la CPU (L1, L2, L3) también están en texto claro. No se cifran porque el propósito de la caché es proporcionar acceso rápido a la CPU a datos con los que está trabajando activamente.
- Controlador de Memoria / TME: Este es el "cerebro" del cifrado. Se encuentra entre los caches de la CPU (y la lógica DMA) y la RAM física. Cuando la CPU escribe datos en RAM, el controlador de memoria los cifra. Cuando la CPU lee datos de RAM, el controlador de memoria los descifra antes de pasarlos a la caché o directamente a la CPU.
- RAM: La memoria RAM física es donde los datos se almacenan en su forma cifrada.
- DMA: Las operaciones de DMA se originan desde los dispositivos I/O (o el controlador DMA). El dispositivo DMA opera con datos en texto claro. Cuando un dispositivo DMA necesita leer de una región cifrada en RAM, el controlador de memoria descifra los datos antes de enviarlos al dispositivo. Cuando un dispositivo DMA escribe en una región cifrada en RAM, el controlador de memoria cifra los datos que el dispositivo le proporciona en texto claro.
Conclusión sobre la efectividad del cifrado de RAM
Sí, el cifrado de RAM, como TME, es una medida potencialmente efectiva para protegerse de dispositivos cuyo propósito sea leer o escribir zonas arbitrarias, PERO solo si se combina con otras medidas de seguridad clave, especialmente la IOMMU.
Razones:
- Protección contra "Cold Boot Attacks" y acceso físico: Si alguien apaga el sistema y retira la RAM para intentar leer su contenido, los datos estarán cifrados y serán ilegibles sin la clave. Esto es un beneficio importante.
- Protección de datos en tránsito a RAM: El cifrado asegura que los datos se almacenan cifrados en la RAM, protegiéndolos de sondas o ataques que intenten interceptar los datos mientras viajan en el bus de memoria.
- DMA y Transparencia: Como hemos discutido, TME hace que el cifrado sea transparente para los dispositivos DMA. Esto significa que un dispositivo DMA (malicioso o no) aún puede solicitar leer o escribir en una dirección de memoria específica. Aquí es donde la IOMMU se vuelve crucial.
Sin IOMMU: Un dispositivo DMA malicioso podría intentar realizar un ataque de "DMA directo" y leer o escribir en cualquier parte de la memoria física. Aunque los datos en RAM estén cifrados, el controlador de memoria descifrará los datos para el dispositivo DMA si este solicita una dirección válida. Si el atacante controla el dispositivo DMA y puede especificar las direcciones, podría obtener datos descifrados o corromper el sistema.
Con IOMMU (VT-d de Intel, AMD-Vi de AMD): La IOMMU actúa como un "firewall" de memoria para los dispositivos I/O. Permite que el sistema operativo defina qué regiones de memoria cada dispositivo DMA puede acceder. Si un dispositivo intenta acceder a una dirección fuera de sus permisos asignados, la IOMMU bloquea la operación y genera un error.
En resumen:
- Cifrado de RAM (TME): Protege los datos en reposo en la RAM física y en tránsito desde/hacia la CPU.
- IOMMU: Protege contra el acceso no autorizado de dispositivos DMA a regiones de memoria que no les corresponden.
Para una protección robusta contra dispositivos maliciosos que intentan leer o escribir en zonas arbitrarias de la RAM, se necesita la combinación de cifrado de RAM (como TME) y una IOMMU activada y configurada adecuadamente. El cifrado por sí solo no impide que un dispositivo DMA bien programado (o maliciosamente controlado) acceda a los datos descifrados si la IOMMU no restringe su acceso.
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/evWU3uxiswQ/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/embebidos32/821bb918-6695-470d-8e4e-293da9b27bcfn%40googlegroups.com.
--
Carlos Pantelides
Carlos Pantelides
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/evWU3uxiswQ/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/embebidos32/CAM1aq_9NLbWsK-dyUP%3DCcGgjkK%2ByUzeO3GOzQ-yxdUTzzS%3Dgdg%40mail.gmail.com.