Memoria, direcciones, procesos y aislamiento

La misma dirección no significa el mismo dato

Un programa registra que leyó la dirección 0x4000 y otro proceso registra exactamente la misma dirección. ¿Han leído el mismo contenido? No se puede responder sin saber en qué espacio de direcciones, bajo qué traducción y en qué momento ocurrió cada acceso. Una dirección que el procesador recibe no es necesariamente una posición física única; suele ser una referencia virtual interpretada dentro de un contexto de ejecución.

Esta distinción sostiene una gran parte de la seguridad de sistemas. Un proceso debe poder usar direcciones cómodas y estables sin poder leer arbitrariamente la memoria de otro proceso. El kernel debe traducir esas referencias, imponer permisos y cambiar el contexto sin dejar que una identidad, un mapeo o un dato residual crucen la frontera equivocada. Cuando cualquiera de esos supuestos falla, el resultado puede ser una lectura fuera de límites, exposición de información, corrupción de estado o una condición de ejecución con más autoridad. El nombre del resultado no reemplaza la reconstrucción del mecanismo.

Este capítulo construye un modelo de trabajo: espacio de direcciones, traducción por páginas, permisos, fallos, proceso y mecanismos de aislamiento. Después lo aplica a memoria compartida y a errores de límites. La tesis es acotada: el aislamiento no es una propiedad que una dirección posea, sino una relación entre referencias, tablas de traducción, autoridad, estado y operaciones que deben conservarse durante todo el ciclo de vida.

Cuatro cosas que no deben mezclarse

Una dirección virtual es un valor que una instrucción usa para referirse a memoria dentro de un espacio de direcciones. Una dirección física identifica una ubicación en el espacio que el hardware de memoria puede seleccionar. La traducción relaciona ambas según tablas y reglas de la arquitectura; no convierte todas las direcciones virtuales en posiciones físicas permanentes ni hace que una dirección virtual sea global al sistema.

El contenido es el valor almacenado o transferido en una ubicación. Una referencia a 0x4000 no es el contenido de 0x4000, y el contenido no demuestra quién tiene autoridad para leerlo. Tampoco una dirección es un activo por sí misma: puede apuntar a una clave, una instrucción, una estructura vacía o una página no presente. Para analizar una pérdida hay que identificar el objeto, su propiedad y la operación.

Un espacio de direcciones es el conjunto de referencias y reglas de traducción visibles para un contexto. Dos procesos pueden tener un espacio con rangos numéricos similares y traducciones físicas diferentes. Un proceso puede además mapear una misma región física en dos direcciones virtuales distintas, o compartir deliberadamente una página con otro proceso. La igualdad numérica de las referencias no decide ninguna de esas relaciones.

Un proceso es una abstracción operativa que reúne una ejecución con recursos y estado que el sistema operativo administra: espacio de direcciones, hilos, credenciales, descriptores, límites y relaciones con otros objetos. No es sólo un programa en disco ni una lista de registros. El proceso ofrece una frontera de administración; su aislamiento efectivo depende de cómo el kernel, la arquitectura y las interfaces mantienen esa frontera.

De una referencia a una página

Las arquitecturas modernas suelen dividir el espacio virtual en páginas de tamaño definido por la arquitectura o por la configuración. Una dirección virtual puede separarse conceptualmente en un número de página y un desplazamiento. El número indexa estructuras de traducción; el desplazamiento se conserva para localizar el byte dentro de la página. El tamaño no es universal: una misma familia puede admitir páginas de varios tamaños, y una configuración concreta cambia cuántos niveles de tabla intervienen.

Una tabla de páginas contiene entradas que relacionan una página virtual con una página física y codifican atributos de presencia, acceso y privilegio. «Lectura, escritura y ejecución» es aquí un modelo abstracto útil, no una promesa de que todas las ISA tengan tres bits independientes. En x86-64, por ejemplo, las entradas expresan escritura, usuario/supervisor y no ejecución, mientras la lectura no posee un bit de denegación equivalente; reglas adicionales como CR0.WP y otros controles modifican la decisión. El formato exacto pertenece a la ISA y al sistema operativo. La entrada no es una política de negocio: indica qué acceso de memoria puede realizar ese contexto, no si una persona puede consultar un expediente o modificar una transferencia. Intel SDM, Vol. 3, revisión 093, capítulos 4–5

En un acceso de lectura, el procesador toma la dirección virtual y el contexto de traducción, consulta una traducción almacenada o recorre las tablas y verifica los permisos aplicables. Si la traducción y el acceso son válidos, se obtiene un dato. Si falta una entrada, la página no está presente o el permiso no coincide, se produce un page fault (fallo de página). El fallo es una transición controlada hacia el kernel; no significa automáticamente que haya una vulnerabilidad ni que la página esté corrupta.

Un fallo puede ser parte normal de la demanda de páginas, de una copia en escritura o de una región que el programa decidió reservar sin materializarla. También puede indicar una referencia inválida, una operación no permitida o un error de sincronización. La evidencia necesaria es distinta en cada caso: dirección, instrucción, tipo de acceso, registros, tabla vigente, estado del proceso y respuesta del kernel. Un mensaje genérico de fallo no permite elegir una causa por intuición.

La referencia no lleva su significado incorporado: contexto, traducción y permiso separan un acceso válido de un fallo.

La TLB (Translation Lookaside Buffer) es una caché de traducciones recientes. Acelera el recorrido de tablas, pero no es una segunda política independiente. Si el kernel modifica un mapeo o sus permisos, debe mantener coherencia entre las tablas y las entradas de TLB relevantes, con mecanismos definidos por la arquitectura y la implementación. Un análisis que sólo observa una tabla puede perder el estado temporal de una traducción que todavía está en caché; uno que sólo observa la TLB tampoco reconstruye la configuración persistente.

Consideremos un proceso sintético que lee 0x4000. En el contexto A, la tabla puede traducir esa página a un marco que contiene el encabezado de una solicitud. En el contexto B, la misma referencia puede no estar mapeada y producir un fallo. Si el kernel asigna una página nueva al proceso B, ambos procesos siguen usando 0x4000, pero el contenido y la autoridad son distintos. La conclusión correcta no es «la dirección identifica el encabezado», sino «la referencia adquiere significado mediante un contexto y una traducción concretos».

Permisos, privilegio y límites de una página

Los permisos de página suelen resumirse pedagógicamente como combinaciones de lectura, escritura y ejecución, junto con una distinción entre accesos de usuario y de supervisor. Es una notación portable para razonar, no el formato literal de cada arquitectura: las combinaciones disponibles, los bits que las representan y sus excepciones dependen de la ISA y del estado de control. La protección de página impide ciertas operaciones de hardware; no valida que un tamaño calculado por la aplicación sea correcto ni que el objeto al que apunta una referencia pertenezca al principal adecuado.

Una región marcada como no ejecutable reduce una clase de uso de datos como instrucciones. Una región de código no escribible ayuda a preservar instrucciones después de cargarlas. Estas propiedades son controles con un objetivo y límites, no etiquetas de seguridad absoluta. Si un proceso puede escribir en una estructura que decide el destino de un salto, una página de código no escribible no elimina todas las formas de control indebido. Si el kernel expone una interfaz que copia datos sin validar longitud, los permisos de página no corrigen la lógica de esa interfaz.

La regla W^X (write xor execute) expresa una política frecuente: una página no debería ser escribible y ejecutable al mismo tiempo. Puede haber excepciones controladas para compilación dinámica o transición temporal; el análisis debe preguntar quién cambia el permiso, por qué ruta y qué evidencia demuestra que la ventana es limitada. ASLR (Address Space Layout Randomization) cambia ubicaciones para dificultar predicciones, pero no sustituye validación, separación de privilegios ni control de referencias. Un secreto de diseño o una dirección impredecible no es lo mismo que una frontera de autoridad.

El privilegio añade otra condición al acceso. Una página mapeada para supervisor puede ser inaccesible a una instrucción de usuario aunque la referencia numérica sea correcta. La CPU aplica la regla arquitectónica; el kernel decide qué tablas y permisos entregar al proceso y cómo responder a un fallo. Si el kernel mapea accidentalmente una página sensible como accesible al usuario, el hardware cumplirá el mapeo: la debilidad está en la decisión privilegiada, no en que la CPU haya ignorado sus reglas.

Qué hace que dos procesos estén aislados

El aislamiento entre procesos tiene varias capas. Primero, cada proceso recibe un espacio de direcciones y un conjunto de recursos administrados. Segundo, las tablas y los permisos limitan qué referencias puede traducir y qué operaciones puede realizar. Tercero, el kernel controla las transiciones de contexto, las llamadas al sistema y los recursos que pueden compartirse. Cuarto, la arquitectura y la plataforma pueden añadir mitigaciones frente a observaciones laterales o estados de hardware.

Ninguna capa basta en solitario. Un espacio de direcciones distinto no protege si una llamada al sistema copia desde una referencia equivocada. Un permiso de sólo lectura no evita una fuga si el proceso obtiene el dato legítimamente y lo exfiltra por una interfaz. Un kernel con más privilegio no demuestra que su código preserve cada invariante. La afirmación «los procesos están aislados» debe especificar de qué propiedad, contra qué acceso y bajo qué supuestos.

Cuando el planificador cambia de un hilo a otro, el kernel debe seleccionar el espacio de direcciones, los registros y las credenciales correspondientes. Las arquitecturas ofrecen mecanismos para identificar el contexto de traducción, pero los detalles de guardado, restauración y invalidación son propios de la ISA y del sistema operativo. Un cambio de hilo dentro del mismo proceso puede conservar el espacio de direcciones; un cambio entre procesos suele cambiarlo. En ambos casos, la identidad completa no cabe en una sola dirección ni en el valor de un registro.

Un ejemplo útil es un proceso A que tiene un puntero a una estructura y un proceso B que recibe el mismo número como texto en un mensaje. Para A, el puntero puede ser válido y apuntar a una estructura actual. Para B, el número puede no estar mapeado, apuntar a otra página o ser sólo datos. Pasar direcciones entre procesos como si fueran identificadores globales es un error de frontera. La interfaz debe pasar un identificador, una copia o un mecanismo explícito de compartición; el receptor debe validar su propia representación.

La igualdad numérica de dos direcciones no prueba identidad de contenido; compartir y copiar son transiciones explícitas.

Compartir memoria no destruye la frontera por accidente

Compartir memoria es una decisión explícita que permite a dos procesos mapear una región común o transferir páginas mediante mecanismos del sistema operativo. Puede ser útil para rendimiento, colas y comunicación de alta frecuencia. El hecho de que una página sea compartida no significa que ambos procesos compartan todas sus direcciones, permisos o credenciales. Cada espacio puede mapear la página en un rango distinto y con permisos distintos.

La memoria compartida introduce una responsabilidad adicional: sincronizar acceso y definir quién puede leer o modificar cada campo. Un proceso puede escribir un valor válido en el formato equivocado; otro puede observarlo durante una actualización parcial. La protección de página no ofrece atomicidad para una estructura arbitraria ni garantiza que una secuencia de lecturas sea consistente. Mutexes, operaciones atómicas, protocolos de versión y barreras tienen objetivos concretos; ninguno reemplaza el contrato de datos.

La operación copy-on-write (copia en escritura) muestra otra composición. Después de una duplicación lógica de un proceso, dos espacios pueden referir inicialmente páginas físicas comunes marcadas para que una escritura provoque un fallo. El kernel crea una copia para el escritor y actualiza su tabla. Hasta que ocurre la escritura, leer puede observar el mismo contenido; después, cada proceso puede observar una versión diferente. Por eso una prueba tomada antes del fallo no demuestra que el estado siga compartido tras una transición.

El aislamiento también puede romperse en el nivel de recursos no representados como memoria ordinaria: descriptores, dispositivos, archivos mapeados, memoria compartida del kernel o interfaces de depuración. Que una página no sea accesible desde otro proceso no prueba que no exista otro canal para obtener la misma información. Al formular un claim, hay que declarar si la frontera cubre sólo memoria virtual, todo el proceso o el conjunto de recursos que el proceso puede alcanzar.

Error frecuente: convertir límites de datos en límites de memoria

Un búfer puede ocupar una página con permisos correctos y, aun así, una función puede leer más elementos de los que el objeto contiene. La CPU traducirá las direcciones siguientes si están mapeadas y tienen permisos. El hardware no conoce la longitud lógica del arreglo, la propiedad del campo ni el tamaño que el emisor pretendía enviar. Un desbordamiento de búfer es, en primer lugar, un desajuste entre una operación y los límites de un objeto; sólo después hay que estudiar qué página, objeto o proceso resulta afectado.

Supongamos un parser que recibe una longitud de 128, reserva 64 bytes y copia según la longitud recibida. Si las dos regiones están dentro de páginas legibles y escribibles, la traducción puede tener éxito. El page fault no aparecerá como alarma que revele el error. La evidencia debe comparar la longitud aceptada, el tamaño reservado, el número de bytes copiados, la disposición del objeto y la ruta de salida. Si el destino cruza una página no accesible, el fallo puede detener la copia, pero su aparición tardía no convierte la validación en correcta.

La relación con un proceso vecino exige más pruebas todavía. Una escritura fuera de los límites de un objeto dentro del mismo espacio puede corromper una estructura, pero no demuestra lectura de otro proceso. Para afirmar cruce de aislamiento habría que demostrar que la operación alcanza un mapeo perteneciente al otro contexto o que una interfaz privilegiada entrega sus datos. Una dirección alta, un valor llamativo o un crash no bastan. La separación entre observación, inferencia e impacto posible evita atribuir al bug una autoridad que no se ha probado.

Otro error es tratar un use-after-free como una simple dirección inválida. En lenguajes y asignadores con gestión manual de vida —el ejemplo de este capítulo se limita a C/C++— terminar la vida de un objeto invalida usos que dependían de ella, aunque el rango virtual continúe mapeado. El asignador puede reutilizar ese almacenamiento para otro objeto, de modo que la traducción de página tenga éxito mientras el acceso viola el contrato de vida del lenguaje. Para diagnosticarlo se necesitan procedencia de la asignación, momento de liberación, reutilización, sincronización y operación del consumidor; instrumentos como AddressSanitizer observan esta capa con sus propios supuestos. Esto no se universaliza a lenguajes con otro modelo de memoria. C++ working draft, [basic.life]; Clang AddressSanitizer

Observaciones que permiten reconstruir el mecanismo

Un profesional puede comenzar por el mapa del espacio de direcciones: rangos, permisos, origen de cada mapeo, tamaño de página, bibliotecas, pila, heap y regiones compartidas. Ese mapa es una fotografía contextual, no una prueba de todos los accesos históricos. Debe acompañarse de versión del proceso, arquitectura, credenciales, momento de captura y procedencia del artefacto.

Para un fallo, conviene conservar la instrucción que realizó el acceso, la dirección virtual, si era lectura, escritura o ejecución, los registros relevantes, el contexto de traducción y la respuesta del kernel. Un registro de page fault permite acotar la clase de evento; no siempre identifica el objeto lógico ni la causa inicial. Una traza de asignador o un instrumento de memoria puede conectar la dirección con su vida útil. Cada herramienta observa una capa diferente.

Para una revisión de aislamiento, un control positivo debe confirmar que un acceso legítimo funciona dentro del proceso y un control negativo debe mostrar que una referencia de otro espacio se rechaza o no revela contenido. Hay que repetir con la misma versión y configuración, cambiar una sola condición relevante y conservar los errores completos. Un resultado negativo puede indicar ausencia del camino probado, no ausencia universal de una condición.

La observación de una tabla de páginas debe interpretarse con cuidado. Una página puede estar presente pero ser inaccesible para usuario; una entrada puede cambiar entre dos capturas; una TLB puede mantener una traducción hasta que se invalida; una página compartida puede tener marcos distintos tras copy-on-write. El argumento profesional documenta el momento y la relación entre capturas. No llama «memoria física del proceso» a todo marco que aparezca en un volcado.

Una traducción correcta y un fallo tardío no resuelven la pregunta sobre el objeto ni sobre el proceso afectado.

Aislamiento y observación lateral

La separación arquitectónica limita accesos directos, pero no elimina toda señal compartida. Cachés, predicción, tiempo de respuesta, consumo de recursos y dispositivos pueden producir observaciones relacionadas con actividad de otro contexto. La existencia y magnitud del canal dependen de la microarquitectura, del sistema, de la programación y del método de medición. No debe confundirse una señal lateral con la lectura directa de una página ni descartarse toda señal porque las tablas estén separadas.

Este capítulo sólo fija la frontera conceptual. Un análisis profesional tendría que declarar CPU, virtualización, sistema operativo, aislamiento entre núcleos, política de planificación y ruido de la medición. Un claim como «un proceso no puede conocer ningún dato de otro» es demasiado fuerte para la evidencia de una tabla de páginas. Un claim acotado podría ser: «bajo esta arquitectura y configuración, un acceso de usuario a la página marcada como supervisor produce una excepción y no entrega el contenido arquitectónico». La afirmación es verificable y no pretende cubrir canales que no mide.

Uso profesional: de un dato observado a una conclusión

Una revisión de memoria puede estructurarse en cinco preguntas. ¿Qué referencia se usó y en qué contexto? ¿Qué traducción y permisos estaban vigentes? ¿Qué objeto lógico debía representar la región? ¿Qué transición produjo el acceso o el cambio de mapeo? ¿Qué propiedad y qué impacto quedan demostrados por la evidencia? Estas preguntas mantienen separados el hardware, el kernel y la aplicación.

En threat modeling, el activo puede ser un secreto en heap, la integridad de una tabla de permisos o la disponibilidad de un proceso. La amenaza puede ser una entrada malformada, un proceso con credenciales abusivas o un fallo de aislamiento. La vulnerabilidad es la condición susceptible de explotación bajo precondiciones: un mapeo demasiado amplio, una comprobación de tamaño ausente o una transición de contexto defectuosa. El riesgo requiere después escenario, incertidumbre e impacto; no se deriva del simple hecho de que exista una dirección sospechosa.

En un informe, la frase «A leyó la memoria de B» debería descomponerse. Una observación podría ser que una instrucción de A produjo bytes iguales a los registrados en una región de B. La inferencia requiere descartar valores coincidentes, datos compartidos y fuentes intermedias. La conclusión sobre cruce de aislamiento exige evidencia de traducción, permisos, identidad de procesos y ruta de entrega. El impacto posible depende de qué contenían los bytes y qué autoridad permitían obtener. Cada salto debe ser auditable.

Límites del modelo

El modelo de páginas no describe por sí solo coherencia entre núcleos, orden de memoria, DMA, dispositivos, paginación completa, deduplicación, memoria persistente, hypervisores ni todos los canales laterales. Tampoco define el contrato de un lenguaje, un asignador o una biblioteca. Cuando el texto menciona esas capas lo hace para marcar preguntas pendientes, no para afirmar que una regla de traducción las resuelva.

La abstracción de proceso también tiene límites. Hilos del mismo proceso comparten un espacio, pero pueden tener estados de ejecución y sincronización diferentes. Un contenedor o sandbox puede añadir una frontera de nombres y recursos sin ser una frontera física equivalente a la de una máquina virtual. Un proceso privilegiado puede acceder a más espacios sin que eso convierta a todos sus accesos en legítimos. La palabra aislamiento necesita siempre un objeto, un adversario y una propiedad.

Síntesis

Una dirección virtual es una referencia situada dentro de un espacio de direcciones. Las tablas de páginas, los permisos, la TLB y el contexto de traducción determinan si esa referencia obtiene un contenido, produce un fallo o entra en una ruta del kernel. Una dirección física no es el significado del dato, y una traducción válida no prueba que la operación sea correcta para el objeto lógico.

Un proceso agrupa ejecución, memoria y recursos bajo administración del sistema operativo. Su aislamiento emerge de la composición entre arquitectura, kernel, tablas, permisos, cambios de contexto e interfaces. La memoria compartida, copy-on-write y las llamadas privilegiadas son mecanismos explícitos que modifican la relación; requieren nuevos supuestos y nueva evidencia. ASLR, W^X y la no ejecución son controles acotados, no garantías universales.

El error profesional más común es saltar de una dirección, un fallo o un volcado a una conclusión sobre otro proceso. La disciplina consiste en reconstruir contexto, traducción, permisos, objeto, transición y evidencia; después separar observación, inferencia, impacto posible y decisión. En el capítulo siguiente, kernel, llamadas al sistema, excepciones e interrupciones ampliarán la transición que aquí termina en una página y un proceso.

Comprobación de comprensión

1. Misma referencia, distintos contextos. Dos procesos usan la dirección virtual 0x4000. Explica tres razones por las que no puedes concluir que leen el mismo dato. Respuesta modelo: cada proceso puede tener un espacio distinto, tablas que traduzcan la página a marcos diferentes o ningún mapeo. Incluso con un marco compartido, pueden diferir permisos, instante y sincronización. Límite: la dirección numérica no identifica globalmente el contenido.
2. Diagnóstico de un fallo. Compara una página no presente, demanda legítima, copy-on-write y permiso incompatible. ¿Qué evidencia discrimina las hipótesis? Respuesta modelo: instrucción y tipo de acceso, dirección, contexto de traducción, entrada y permisos, motivo arquitectónico, estado del proceso y respuesta del kernel; la historia de asignación y si era escritura ayudan a separar las rutas. Límite: el page fault aislado no adjudica la causa lógica.
3. Virtual, física y contenido. Construye un ejemplo donde A mapea un marco común en 0x4000 y B en 0x9000. Respuesta modelo: las referencias virtuales son distintas, el marco puede ser el mismo y el contenido es el valor almacenado; permisos y escrituras pueden cambiar la relación. Límite: ninguna noción es sinónimo de las otras.
4. Ruta de un acceso válido. Ordena instrucción, traducción, permisos, objeto y resultado; añade dónde aparece un page fault. Respuesta modelo: la instrucción produce una referencia en un contexto; la CPU consulta TLB o tablas y verifica presencia y permisos; el programa relaciona la región con un objeto; finalmente ocurre lectura o escritura. Una entrada ausente, permiso incompatible o transición como copy-on-write puede desviar la ruta antes del resultado.
5. Límite de objeto. Un parser copia 128 bytes en un búfer de 64 y todas las páginas son legibles y escribibles. ¿Qué queda demostrado y qué no? Respuesta modelo: con evidencia de asignación y copia queda demostrado un desajuste entre operación y objeto; no quedan demostrados un page fault, cruce de proceso, ejecución arbitraria ni impacto concreto. Hay que estudiar disposición, datos afectados y frontera de la interfaz.
6. Copy-on-write. Explica qué ocurre cuando dos procesos leen una página común y después uno escribe. Respuesta modelo: antes de escribir pueden observar un marco común; la escritura provoca la separación prevista por el mecanismo y actualiza la traducción del escritor. Límite: no puede suponerse que ambos continúan compartiendo el mismo estado.
7. Controles acotados. ¿Por qué W^X y ASLR no permiten afirmar aislamiento completo? Respuesta modelo: W^X limita una combinación de permisos bajo una configuración, pero no cubre datos, interfaces ni errores lógicos; ASLR dificulta predecir ubicaciones, pero no impide por sí sola lectura, corrupción o fuga. Cada claim debe declarar arquitectura, configuración y alcance.
8. Claim entre procesos. Un informe afirma: «A leyó la memoria de B porque los bytes coinciden». Critica el argumento y especifica evidencia mínima. Respuesta modelo: la coincidencia admite datos públicos, memoria compartida, copias intermedias o azar. Se necesitan identidad y versión, capturas temporales, mapas y permisos, instrucción y tipo de acceso, traducción o ruta de interfaz, procedencia y un control negativo antes de afirmar un cruce real.

Problema de transferencia

Un servicio sintético recibe de un proceso cliente un puntero virtual y una longitud. En una versión nueva, una prueba con una longitud grande produce bytes de otra estructura del mismo proceso; una prueba con un puntero no mapeado produce un page fault. Modela la ruta desde la instrucción de llamada hasta la copia de retorno. Identifica el espacio de direcciones, la traducción, los permisos, la validación de longitud y la respuesta del kernel. Diseña un control positivo y uno negativo, formula dos claims con alcance distinto y especifica qué evidencia necesitarías antes de afirmar lectura de memoria de otro proceso.

Fuentes principales

• Intel. Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3, revisión 093, capítulos 4 y 5, paginación, protección y traducción; se usa para el ejemplo x86 concreto del texto.
• AMD. AMD64 Architecture Programmer’s Manual, Volume 2: System Programming, revisión 3.44, capítulo 5 y §8.4.2, traducción, protección y código de page fault; se usa como contraste de otra especificación de arquitectura.
• The Open Group. POSIX.1-2017, mmap(), semántica de mapeo de memoria y atributos de acceso; se usa para el contrato de una interfaz de proceso, no como descripción del hardware.
• Linux kernel documentation. Page Tables, organización conceptual de tablas y traducción en Linux; se conserva como documentación de implementación y no como regla universal.
• NIST. SP 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems, interfaces, propiedades, estados y argumentos de confianza; se usa para vincular el mecanismo con claims y límites profesionales.