Seguridad y privacidad · Perspectiva 08

Seguridad de memoria con capacidades: autoridad espacial, tiempo de vida y revocación

Acotar la autoridad de un puntero y demostrar que su objeto sigue vivo son problemas distintos.

Citar artículo

La traducción de IA puede contener errores. Comprueba el contenido con el original.

Traducción asistida por IA · La traducción de IA puede contener errores. Comprueba el contenido con el original. Leer el original
La notación matemática, el código, los datos bibliográficos y el texto dentro de las figuras conservan su forma original.

Ilustración editorial conceptual para Seguridad de memoria con capacidades: autoridad espacial, tiempo de vida y revocación
Ilustración conceptual · ImageGen integrado · No constituye evidencia experimental

Resumen

Los sistemas de memoria basados en capacidades pueden restringir a qué puede acceder un puntero y qué operaciones puede realizar. Estas garantías espaciales y de autoridad son sustanciales, pero no establecen automáticamente la seguridad del tiempo de vida de los objetos, la autorización de la aplicación ni la confidencialidad frente a todos los canales laterales. Esta revisión se apoya en los trabajos de compartimentación de CHERI, Cornucopia y el informe de la ISA de CHERI para examinar la separación entre límites y revocación. Un pequeño modelo de capacidades comprueba límites, permisos y generaciones de asignación, y después presenta un ejemplo testigo de puntero obsoleto en un diseño basado únicamente en límites. Dos figuras contables cuantifican la sobrecarga idealizada de las etiquetas y la memoria en cuarentena. El argumento resultante es que las afirmaciones sobre seguridad de memoria deben especificar la granularidad de asignación, la gestión del tiempo de vida, el código de confianza y las fronteras de compatibilidad. Los ejemplos ejecutables son modelos explicativos y no emulan ni certifican el hardware CHERI.

Un puntero puede ser válido en el espacio e inválido en el tiempo

Un puntero puede direccionar bytes dentro de una región previamente asignada incluso después de que esa asignación haya terminado. Si un objeto nuevo ocupa posteriormente la misma región, una comprobación de límites puede seguir superándose. El puntero es espacialmente plausible, pero temporalmente obsoleto. Esta distinción explica por qué eliminar los accesos fuera de límites no elimina automáticamente los errores de uso después de liberar memoria.

El contrato pertinente tiene varias dimensiones. La seguridad espacial restringe el intervalo de direcciones. Los permisos restringen operaciones como leer o escribir. La procedencia y la imposibilidad de falsificación restringen cómo se crea la autoridad. La seguridad temporal restringe si esa autoridad sigue refiriéndose a un objeto vivo. Una política de aplicación puede imponer restricciones adicionales, como qué documento puede editar un usuario. Por tanto, una capacidad de memoria es una capa de autoridad, no un sustituto de todas las decisiones de autorización del sistema.

La investigación primaria distingue estas capas

El artículo sobre compartimentación de CHERI describe una arquitectura híbrida de capacidades que admite autoridad de granularidad más fina y fronteras entre compartimentos de software. Cornucopia aborda la seguridad temporal de los montículos de CHERI mediante un diseño orientado a la revocación. El informe de la versión nueve de la ISA especifica con mucho más detalle el comportamiento arquitectónico de las capacidades y las opciones de representación.

Estas fuentes no deben condensarse en la afirmación de que una etiqueta de capacidad por sí sola resuelve todos los errores de memoria. Los trabajos sobre seguridad temporal existen porque la gestión del tiempo de vida requiere mecanismos adicionales. Asimismo, una especificación de comprobaciones arquitectónicas no demuestra por sí misma la seguridad de todos los asignadores, interfaces de funciones externas o componentes heredados que rodean esas comprobaciones. Utilizamos un registro de capacidad deliberadamente idealizado para hacer visibles las distintas obligaciones de prueba antes de considerar una implementación concreta. [1], [2], [3]

Un registro de capacidad idealizado

Representemos una capacidad mediante una dirección base, una longitud, un conjunto de permisos y una generación de asignación. Una operación de memoria proporciona una dirección, una longitud de acceso y un permiso requerido. El predicado espacial comprueba que todo el intervalo al que se accede se encuentra dentro del intervalo de la capacidad. El predicado de autoridad comprueba el permiso. El predicado temporal compara la generación registrada con la generación de la asignación viva.

Este registro es una abstracción explicativa, no una codificación literal de una capacidad CHERI. En particular, el campo de generación se introduce para modelar una posible comprobación del tiempo de vida, no para afirmar que la arquitectura implementa exactamente este esquema. Separar los predicados permite que el apéndice de alcance finito pruebe cada fallo de forma independiente. Una lectura fuera de límites, una escritura mediante autoridad de solo lectura y un acceso con una generación obsoleta son controles negativos distintos.

El ejemplo testigo del puntero obsoleto

Asígnese el objeto A en una región de dieciséis bytes con la generación uno y emítase una capacidad para él. Libérese A y, después, asígnese el objeto B en la misma región con la generación dos. La capacidad antigua sigue designando un intervalo de direcciones que contiene B. Un comprobador basado únicamente en límites acepta un acceso a través de ella; el comprobador de juguete que tiene en cuenta las generaciones lo rechaza.

El ejemplo testigo no demuestra que cualquier esquema de generaciones sea suficiente. Un contador finito de generaciones puede dar la vuelta, la concurrencia puede producir carreras entre la revocación y el acceso, y puede haber capacidades copiadas en lugares que el asignador no puede inspeccionar. Demuestra un punto más limitado: la contención espacial por sí sola no puede distinguir dos tiempos de vida que ocupan los mismos bytes. Toda garantía temporal que se afirme debe explicar el mecanismo que impide que una autoridad obsoleta vuelva a ser válida tras la reutilización.

La monotonía de la autoridad permite inspeccionar la delegación

Una disciplina útil de capacidades permite derivar una autoridad más débil de otra más fuerte: estrechar un intervalo o eliminar permisos. Un componente que recibe un segmento de solo lectura no debería poder fabricar un permiso de escritura ni ampliar el segmento a objetos vecinos. Esta monotonía permite razonar localmente sobre la delegación.

El software circundante debe seguir eligiendo los límites iniciales adecuados. Una capacidad para una asignación grande completa puede permitir un acceso erróneo desde un subobjeto lógico a otro, a menos que el sistema cree capacidades derivadas suficientemente estrechas o imponga reglas adicionales del lenguaje. Las vías de compatibilidad que conservan una autoridad amplia también pueden limitar la protección práctica. Por tanto, una evaluación apropiada mide qué accesos están realmente acotados y con qué granularidad, en lugar de limitarse a contar cuántos punteros utilizan una representación de capacidad. [1], [3]

La revocación introduce trabajo y coordinación

Revocar la autoridad requiere alguna forma de impedir el uso futuro de referencias antiguas. Entre las estrategias posibles están retrasar la reutilización, seguir los tiempos de vida, inspeccionar las capacidades alcanzables o combinar mecanismos. Cada una modifica los costes y los supuestos. Un esquema de reutilización diferida reduce las oportunidades de reutilización inmediata, pero no demuestra por sí solo que una referencia obsoleta haya desaparecido después de un plazo arbitrario.

Cornucopia es pertinente porque trata la protección temporal como un mecanismo de sistema con un asignador y un flujo de trabajo de revocación. Nuestra revisión no reproduce sus resultados de rendimiento. En su lugar, plantea preguntas transferibles: cuándo es seguro reutilizar una región liberada, qué carreras son posibles durante la transición, qué memoria se inspecciona o se rastrea y qué ocurre si la recuperación no puede seguir el ritmo de la presión de asignación. Estas preguntas determinan tanto la seguridad como el comportamiento de los recursos. [2]

La sobrecarga de las etiquetas es solo una parte del coste de memoria

Si un sistema idealizado almacena un bit de etiqueta adicional por cada g bytes de datos, su proporción bruta de etiquetas respecto de datos es uno dividido entre el producto de ocho y g. Con g igual a dieciséis bytes, la proporción es del 0.78125 por ciento. La primera figura varía el tamaño del gránulo para mostrar esta relación contable elemental.

Esta no es la sobrecarga total de CHERI ni de otra máquina de capacidades. Los punteros más anchos, la alineación, los metadatos, la organización de la caché, el diseño del controlador de memoria y la disposición del software pueden dominar o modificar el coste físico. Una representación comprimida de capacidades también implica reglas de representabilidad que la fórmula de juguete no modela. El cálculo solo es útil cuando se identifica como almacenamiento bruto de etiquetas. Presentarlo como la sobrecarga completa de memoria del sistema confundiría un campo visible con el diseño entero.

La cuarentena genera un presupuesto de tasa por tiempo

Supongamos que la memoria liberada entra en cuarentena hasta que un proceso de recuperación pueda ponerla a disposición de forma segura. Si la memoria se libera a una tasa estable r bytes por segundo y la permanencia media en cuarentena es W segundos, la cantidad retenida es aproximadamente rW bytes en un modelo de flujo estable. A 100 millones de bytes por segundo y diez milisegundos, eso equivale a un millón de bytes.

La segunda figura varía r y W, omitiendo deliberadamente la fragmentación del asignador y el carácter de ráfagas. Una ráfaga puede generar una acumulación instantánea mucho mayor de lo que sugiere la fórmula de la media. Si la capacidad de recuperación cae por debajo de la tasa de llegada, puede no existir una media en estado estacionario. Por ello, un estudio de despliegue debería informar de la memoria retenida máxima, la dinámica de la acumulación y la latencia de asignación, junto con la condición que autoriza la reutilización. Una sobrecarga media baja no puede compensar una regla de recuperación insegura.

Las fronteras entre lenguajes y con código externo siguen siendo importantes

Un lenguaje con seguridad de memoria puede seguir interactuando con código nativo inseguro, búferes de dispositivos, rutinas de serialización o ensamblador escrito a mano. Un sistema de capacidades puede restringir algunos de los errores resultantes, pero la frontera debe preservar la autoridad prevista. Pasar una capacidad amplia a un componente auxiliar y esperar que se mantenga una política de aplicación estrecha es una decisión de política que requiere revisión.

Del mismo modo, la seguridad de memoria no valida el significado de negocio de un campo de longitud, no impide un error lógico en el control de acceso ni establece una ejecución en tiempo constante. Estas son propiedades distintas. Un plan de migración útil inventaría los lugares donde la autoridad se amplía, se convierte, se comparte o se conserva a través de distintos tiempos de vida. Después evalúa la compatibilidad y el rendimiento en esas vías, en lugar de suponer que una compilación satisfactoria implica una transición de seguridad completa.

Una evaluación con controles negativos independientes

La evaluación propuesta comienza con infracciones espaciales, de permisos y temporales que pueden observarse de forma independiente. Incluye subobjetos adyacentes, accesos de longitud cero y en los límites, referencias obsoletas tras reutilizar direcciones, liberación y acceso concurrentes, y reutilización de generaciones en cualquier esquema que emplee identificadores finitos. Los accesos legítimos deben seguir siendo válidos bajo las mismas pruebas.

Para el hardware real, deben registrarse la ISA exacta, el modo del compilador, el asignador, la configuración de revocación y la proporción de código heredado. Deben notificarse los fallos que quedan fuera de cobertura. El apéndice local ejecuta únicamente el comprobador del registro idealizado y el ejemplo testigo de reutilización de direcciones. Su propósito es hacer reproducibles las distinciones, no afirmar una mejora de seguridad medida ni ofrecer un modelo completo de una implementación de capacidades en producción.

Conclusión: explicitar la garantía sobre el tiempo de vida

Las capacidades proporcionan una forma potente de concretar la autoridad y restringir su propagación. Su contribución se vuelve más clara cuando se separan las propiedades afirmadas: límites, permisos, imposibilidad de falsificación, fronteras entre compartimentos y seguridad del tiempo de vida. Un resultado sobre una de estas dimensiones no debería sustituir tácitamente a las demás.

El ejemplo testigo del puntero obsoleto demuestra qué información falta en una comprobación basada únicamente en límites. Las figuras contables muestran por qué la protección temporal también genera obligaciones de recursos. Una afirmación rigurosa sobre un sistema une, por tanto, la imposición arquitectónica con la semántica del asignador y de la recuperación, identifica las interfaces restantes en las que se confía e informa de los costes del mismo modo de protección que se evaluó realmente.

Ejecutado localmente · Alcance acotado

Límites, permisos y tiempo de vida con generaciones ideales

Enteros matemáticos y un modelo ideal de generaciones, no un emulador de CHERI.

Se superaron 4 aserciones. Estas comprobaciones validan el ejemplo proporcionado, no los sistemas citados.

Inspeccionar el ejemplo testigo registrado
{
  "reused_address": 4,
  "old_generation": 1,
  "live_generation": 2
}

Un modelo analítico declarado

Cuatro ecuaciones, supuestos explícitos

a≤p ∧ p+ℓ≤a+na\le p\ \land\ p+\ell\le a+n

(1) Predicado espacial para la base a, la extensión n, el inicio de acceso p y la longitud ell, utilizando enteros matemáticos. Una implementación real debe evitar el desbordamiento aritmético en la comprobación.

valid=bounds∧permission∧(gcap=glive)\mathrm{valid}=\mathrm{bounds}\land\mathrm{permission}\land(g_{\mathrm{cap}}=g_{\mathrm{live}})

(2) Un modelo idealizado de capacidades que tiene en cuenta las generaciones; no se afirma que el campo de generación sea la codificación literal de CHERI.

ρtag=18g\rho_{\mathrm{tag}}=\frac{1}{8g}

(3) Un bit de etiqueta por cada g bytes de datos. Esto cuenta únicamente el almacenamiento bruto de etiquetas.

Mquarantine≈rWM_{\mathrm{quarantine}}\approx rW

(4) Flujo medio estable con tasa de bytes liberados r y tiempo medio de permanencia W; se excluyen las ráfagas y la recuperación inestable.

Ejemplos construidos · Datos reproducibles

Inspeccionar el argumento cuantitativo

Estas curvas se calculan a partir de los modelos declarados. No son observaciones de los estudios citados. Cada figura incluye sus datos numéricos y su versión vectorial.

Un bit de etiqueta no es el coste completo de memoria. Solo contabilidad bruta de bits; se excluyen la granularidad del almacenamiento físico, ECC, la anchura de las capacidades y las cachés de metadatos. No es una sobrecarga medida de CHERI.
Figura 1. Un bit de etiqueta no es el coste completo de memoria. Solo contabilidad bruta de bits; se excluyen la granularidad del almacenamiento físico, ECC, la anchura de las capacidades y las cachés de metadatos. No es una sobrecarga medida de CHERI.
La reutilización diferida retiene memoria. Tasa estable de liberación multiplicada por una demora fija de cuarentena. Se excluyen la reasignación, la fragmentación y las liberaciones en ráfagas; esto no es una prueba de rendimiento de Cornucopia.
Figura 2. La reutilización diferida retiene memoria. Tasa estable de liberación multiplicada por una demora fija de cuarentena. Se excluyen la reasignación, la fragmentación y las liberaciones en ráfagas; esto no es una prueba de rendimiento de Cornucopia.

¿Qué evidencia responde a cada pregunta?

PropiedadEjemplo de imposiciónCuestión independiente
Contención espacialLímites sobre un intervalo al que se accedeTiempo de vida del objeto
Restricción de permisosAutoridad de solo lectura o sin permiso de ejecuciónPolítica de aplicación correcta
Seguridad temporalUn protocolo justificado de revocación y reutilizaciónConcurrencia y reutilización de identificadores
Aislamiento de compartimentosCapacidades delegadas de alcance estrechoCanales laterales y autoridad amplia para compatibilidad

Un protocolo de validación propuesto

Este es un diseño de evaluación propuesto. No se realizó ninguna prueba de rendimiento de sistemas de producción ni de hardware. Los modelos finitos ejecutados por separado se documentan en las comprobaciones ejecutables.

  1. Probar por separado los accesos válidos, fuera de límites, denegados por permisos y con un tiempo de vida obsoleto.
  2. Incluir un ejemplo testigo de reutilización de direcciones que un comprobador basado únicamente en límites acepte incorrectamente.
  3. Comprobar la monotonía del estrechamiento de intervalos y de la eliminación de permisos.
  4. Revisar la vuelta de los identificadores finitos y las carreras de revocación concurrente en cualquier diseño concreto.
  5. Medir la acumulación en cuarentena, la memoria máxima y la latencia de asignación bajo ráfagas.
  6. Inventariar las fronteras con código externo, asignadores, dispositivos y autoridad heredada.

Qué establecen las fuentes primarias

Robert N.M. Watson, Jonathan Woodruff, Peter G. Neumann et al. · 2015 [1]

Contribución. La arquitectura híbrida de capacidades de CHERI admite autoridad acotada y compartimentación.

Límite. El enfoque arquitectónico no establece por sí solo todas las propiedades de seguridad a nivel de aplicación.

Localización de la fuente. Identidad del artículo de IEEE y registro de publicaciones de los autores sobre CHERI.

Nathaniel Wesley Filardo, Brett F. Gutstein, Jonathan Woodruff et al. · 2020 [2]

Contribución. Cornucopia trata la seguridad temporal de los montículos de CHERI como un problema de revocación y asignación.

Límite. Su mecanismo y evaluación completos no pueden sustituirse por la comprobación de generaciones de juguete.

Localización de la fuente. Resumen y diseño de seguridad temporal.

Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff et al. · 2023 [3]

Contribución. La versión nueve de la ISA de CHERI especifica la semántica arquitectónica de las capacidades y las opciones de representación.

Límite. Una especificación de ISA es distinta de la validación de una pila de software desplegada.

Localización de la fuente. Informe técnico de la Universidad de Cambridge UCAM-CL-TR-987.

Límites de este análisis

  • El modelo ejecutable es explicativo y no emula instrucciones CHERI.
  • La fórmula de etiquetas brutas excluye los punteros más anchos, la alineación, las cachés y la sobrecarga de implementación física.
  • La fórmula de cuarentena supone tasas estables y no establece una recuperación segura.
  • No se realizó ninguna prueba de seguridad del hardware ni de rendimiento de CHERI o Cornucopia.

Una revisión analítica centrada en tres fuentes primarias fundacionales seleccionadas, con ejemplos desarrollados originales. No es un estudio exhaustivo ni sistemático de la literatura hasta 2026. Las notas de acceso y versión de las fuentes se registran junto con la bibliografía.

Preguntas que cambiarían la conclusión

  1. ¿Con qué granularidad se acotan los accesos reales: asignación, objeto o subobjeto?
  2. ¿Qué evidencia garantiza que la reutilización sea segura después de la revocación en presencia de concurrencia?
  3. ¿Qué vías de compatibilidad conservan una autoridad más amplia que la política de compartimentos prevista?

Referencias

  1. Robert N.M. Watson, Jonathan Woodruff, Peter G. Neumann et al.. CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization. 2015 IEEE Symposium on Security and Privacy (2015). 10.1109/sp.2015.9.
  2. Nathaniel Wesley Filardo, Brett F. Gutstein, Jonathan Woodruff et al.. Cornucopia: Temporal Safety for CHERI Heaps. 2020 IEEE Symposium on Security and Privacy (SP) (2020). 10.1109/sp40000.2020.00098.
  3. Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff et al.. Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 9). University of Cambridge Technical Report UCAM-CL-TR-987 (2023). 10.48456/tr-987.

Acceso a la fuente [1]. Registro primario, resumen y textos accesibles seleccionados; no una auditoría exhaustiva del texto completo ni del material suplementario.

Acceso a la fuente [2]. Registro primario, resumen y textos accesibles seleccionados; no una auditoría exhaustiva del texto completo ni del material suplementario.

Acceso a la fuente [3]. Registro primario, resumen y textos accesibles seleccionados; no una auditoría exhaustiva del texto completo ni del material suplementario.

Las identidades bibliográficas se contrastaron con Crossref y con registros primarios de editoriales, autores o instituciones. Las notas de acceso y versión de las fuentes que figuran a continuación describen el alcance; no se trata de una auditoría exhaustiva de los textos completos.

Autoría y procedencia

Escrito y sometido a autorrevisión técnica por Codex (IA). Las referencias identifican a los investigadores originales; las construcciones analíticas y los diseños de evaluación propuestos se atribuyen a este artículo.

Las portadas son ilustraciones conceptuales de ImageGen. Las figuras técnicas se calculan a partir de modelos declarados o ejemplos finitos, y se proporcionan Python y CSV. No son mediciones de productos desplegados ni pruebas de rendimiento reproducidas.

Este borrador local no tiene constancia de revisión por pares independiente ni de aceptación en una revista. Los ejemplos ejecutables acotados comprueban los pequeños modelos declarados; no constituyen una verificación formal de los sistemas citados.

Revisión de investigación por encargo · v5. Citar artículo · Registro de la fuente original · Registro de publicación