# Registro de evidencia por afirmación — edición de trabajo v4.4

Fuentes: 52; citadas en manuscrito: 38; afirmaciones auditadas: 41.
Estado: la v4.4 está archivada en Zenodo con DOI [10.5281/zenodo.22924864](https://doi.org/10.5281/zenodo.22924864). La auditoría multi-IA no constituye revisión humana independiente. Las inferencias no son citas textuales de las fuentes. S identifica la fuente del catálogo; R identifica la referencia del manuscrito.

| ID / URL | Afirmación | Sección del manuscrito | Tipo / estado | Fuente y localizador | Lectura alternativa |
|---|---|---|---|---|---|
| [C01](https://hardwaresecurityhistory.org/research/claims/C01/) | Atlas y System/360 documentan límites tempranos distintos entre programas ordinarios, control supervisor y memoria protegida. | Genealogía temprana: Atlas y System/360 | historical synthesis; both primary documents page-verified; comparison only | S001 (R10), S002 (R12); Atlas Supervisor (1961), printed pp. 279–280 and 283 (AFIPS scan PDF pp. 295–296, 299/396); IBM System/360 Principles of Operation (1970), System Structure, printed pp. 16–17 | Las fuentes también priorizan planificación y eficiencia, no solo seguridad; no establecen un linaje causal entre diseños. |
| [C02](https://hardwaresecurityhistory.org/research/claims/C02/) | Una IOMMU puede traducir direcciones DMA mediante dominios de protección a los que se asignan dispositivos. | Expansión de la frontera: IOMMU | documented mechanism; verified primary; domain sharing explicitly preserved | S038 (R19); Ben-Yehuda et al., OLS 2006, pp. 71–74 | El aislamiento efectivo depende también de que el software configure correctamente tablas e identidades. |
| [C03](https://hardwaresecurityhistory.org/research/claims/C03/) | Las implementaciones IOMMU descritas pueden usar una caché de traducción de E/S, por lo que la protección puede tener una dimensión de rendimiento. | Expansión de la frontera: IOMMU | documented mechanism; verified primary | S038 (R19); Ben-Yehuda et al., OLS 2006, pp. 72–74 | La trayectoria histórica de adopción no se deduce solo del diseño de caché. |
| [C04](https://hardwaresecurityhistory.org/research/claims/C04/) | El diseño de lanzamiento medido registra el contenido ejecutable antes de ejecutarlo y protege las mediciones con un TPM. | Expansión de la frontera: TPM | documented mechanism; verified primary | S011 (R21); Sailer et al., USENIX Security 2004, abstract and design section | Registrar evidencia no equivale a rechazar automáticamente toda ejecución insegura. |
| [C05](https://hardwaresecurityhistory.org/research/claims/C05/) | La medición por sí sola no es enforcement local; un punto de decisión debe actuar sobre la evidencia para bloquear la operación. | Pruebas negativas: medición | inference; analytical test | S011 (R21); Sailer et al., USENIX Security 2004, abstract; operational criterion is this study's inference | Una parte verificadora puede imponer después una compuerta, cambiando el resultado para una operación definida. |
| [C06](https://hardwaresecurityhistory.org/research/claims/C06/) | FLUSH+RELOAD explota páginas compartidas y estado de caché para revelar información a través de un límite de aislamiento. | Estado microarquitectónico y canales laterales | documented attack; verified primary | S045 (R29); Yarom and Falkner, USENIX Security 2014, abstract | El ataque no implica que haya fallado toda comprobación lógica de acceso. |
| [C07](https://hardwaresecurityhistory.org/research/claims/C07/) | Las capacidades etiquetadas llevan límites y permisos que se comprueban al usarse. | Capacidades: CHERI | documented mechanism; verified primary | S050 (R36); Watson et al., UCAM-CL-TR-941, protection model, pp. 7–9 (PDF pagination) | Esto sustenta la comprobación espacial, no una garantía completa de revocación temporal. |
| [C08](https://hardwaresecurityhistory.org/research/claims/C08/) | La reutilización de direcciones puede retrasarse hasta revocar capacidades pendientes; esto no es solo una comprobación local de instrucción. | Capacidades: revocación | documented mechanism; verified primary | S050 (R36); Watson et al., UCAM-CL-TR-941, §5.1.2 | Distintas implementaciones de CHERI pueden elegir mecanismos y garantías diferentes de revocación. |
| [C09](https://hardwaresecurityhistory.org/research/claims/C09/) | CHERIvoke propone cuarentena, metadatos sombra y barrido para revocar punteros. | Capacidades: CHERIvoke | documented proposal; verified primary | S051 (R37); Xia et al., MICRO-52 (2019), §§3.1–3.3 | Una propuesta y su evaluación no prueban despliegue operativo universal. |
| [C10](https://hardwaresecurityhistory.org/research/claims/C10/) | Para una garantía fijada, la responsabilidad de enforcement puede abarcar CPU, dispositivo, firmware, software o puntos de decisión externos; la conservación de la garantía debe demostrarse caso por caso. | Conclusiones | inference; bounded analytical hypothesis; not a cross-source historical finding | S011 (R21), S038 (R19), S050 (R36), S051 (R37); Cross-source synthesis; no single historical document uses this terminology | Compatibilidad, costo y rendimiento pueden explicar los mismos cambios arquitectónicos. |
| [C11](https://hardwaresecurityhistory.org/research/claims/C11/) | Para un acceso B5000 a palabra mediante descriptor de datos con tamaño distinto de cero, el procesador comprueba límites antes de acceder: es un caso negativo local y acotado. | Genealogía temprana: Burroughs B5000 | documented mechanism + analytical test; verified primary; scope limited | S036 (R14); Burroughs B5000 Operational Characteristics (1963), printed pp. 4-1 and 5-2 (mirror PDF pp. 34 and 53) | La creación de descriptores, las rutas de E/S y los tamaños especiales quedan fuera de esta prueba. |
| [C12](https://hardwaresecurityhistory.org/research/claims/C12/) | El manual del 80386 documenta rutas de ejecución heredadas bajo control del modo protegido, incluido el modo virtual 8086. | Genealogía temprana: x86 80286–80386 | documented mechanism; primary manual; chapter and section verified | S006 (R18); Intel 80386 Programmer's Reference Manual (1986), ch. 15 §15.1 (virtual 8086); Harvard mirror PDF p. 217/421 | La disponibilidad arquitectónica no establece la extensión de su uso. |
| [C13](https://hardwaresecurityhistory.org/research/claims/C13/) | Los diseñadores recordaron después una tensión entre un diseño lineal simple de 32 bits y la compatibilidad binaria, con direcciones lineales detrás de la segmentación. | Genealogía temprana: x86 80286–80386 | documented testimony + historical inference; retrospective testimony triangulated with manual | S052 (R38), S006 (R18); Computer History Museum oral-history transcript (2008), printed pp. 7–9; compare Intel 80386 manual, chs. 4–7 (segmentation/privilege) and ch. 15 §15.1 (virtual 8086) | El recuerdo retrospectivo puede ser selectivo y no mide adopción ni intención institucional. |
| [C14](https://hardwaresecurityhistory.org/research/claims/C14/) | Las dos sistematizaciones organizan la ejecución confiable asistida por hardware en mecanismos y bloques arquitectónicos diversos, no en un mecanismo único. | Posicionamiento historiográfico | comparative literature; primary abstracts verified; comparison only | S031 (R07), S032 (R08); Zhao et al. (2019), arXiv:1910.04957, abstract; Schneider et al. (2022), arXiv:2205.12742, abstract | Una taxonomía no demuestra adopción histórica, despliegue ni linaje causal. |
| [C15](https://hardwaresecurityhistory.org/research/claims/C15/) | Anderson y Kuhn documentan ataques a procesadores resistentes a la manipulación; las barreras físicas no equivalen a garantías absolutas. | Fabricación y variación física | documented attack + inference; primary abstract verified; attack scope limited to reported examples | S049 (R35); Anderson and Kuhn, USENIX Electronic Commerce Workshop 1996, abstract; author-hosted PDF pp. 1–11 | Los ataques descritos no demuestran que todo dispositivo o diseño sea igual de vulnerable. |
| [C16](https://hardwaresecurityhistory.org/research/claims/C16/) | Arm MTE compara etiquetas de cuatro bits en dirección y memoria y puede detectar discrepancias; la cantidad finita de etiquetas no garantiza detectar toda violación en una ejecución. | Metadatos de ejecución: Arm MTE | documented mechanism + scope limit; primary technical paper verified; probabilistic limit explicit | S043 (R27); Armv8.5-A Memory Tagging Extension white paper (2019), 'Memory safety with MTE' and 'Architectural Details', PDF pp. 2–4/9 | Un asignador puede usar etiquetas distintas en asignaciones sucesivas y detectar más casos específicos; la configuración también decide si la discrepancia se informa de forma síncrona o asíncrona. |
| [C17](https://hardwaresecurityhistory.org/research/claims/C17/) | El manual B6500 describe una interrupción por índice inválido del descriptor y la intervención del programa de control maestro cuando un descriptor ausente requiere transferir datos desde disco. | Genealogía temprana: Burroughs B6500 | documented mechanism + historical comparison; primary manual page verified; B6500 only | S037 (R15); Burroughs B6500 Information Processing Systems Reference Manual (1969), printed p. 3-4; Archive.org scan PDF p. 69/377 | Esta conducta del B6500 de 1969 no demuestra semántica idéntica ni despliegue del B5000 de 1963. |
| [C18](https://hardwaresecurityhistory.org/research/claims/C18/) | VT-d revisión 4.1 asigna solicitudes DMA de dispositivos a dominios definidos por software mediante hardware de remapeo y ofrece remapeo separado de interrupciones; la capacidad configurada no prueba despliegue universal. | Expansión de la frontera: VT-d | documented mechanism + deployment limit; primary revision-matched specification page-verified; configuration scope | S039 (R20); Intel VT-d Architecture Specification, rev. 4.1, printed §§2.5.2 and 3.2–3.4, pp. 2-6 and 3-1–3-4; Intel PDF pp. 25, 28–31/326 | La exposición por firmware, la configuración de tablas por software y el remapeo habilitado son condiciones previas; la especificación sola no prueba su uso en una máquina concreta. |
| [C19](https://hardwaresecurityhistory.org/research/claims/C19/) | Con una clave firmante válida, TPM2_Quote firma una atestación con el resumen de los PCR seleccionados y qualifyingData del llamador; TPM_RH_NULL puede producir una firma nula. | Evidencia de plataforma: TPM2_Quote | documented command + operational inference; verified primary; signing-handle exception explicit | S012 (R22); TCG TPM 2.0 Library, rev. 01.59 (2019), Part 3: Commands, §18.4.2 (TPM2_Quote), printed pp. 152–153; Part 1: Architecture, printed p. 83 | Una quote no bloquea por sí misma la operación medida; los comandos TPM sujetos a política son otro uso del estado PCR. Los valores PCR pueden cambiar entre la quote y una lectura separada. |
| [C20](https://hardwaresecurityhistory.org/research/claims/C20/) | Intel CET revisión 3.0 especifica comparación de direcciones de retorno con una pila en la sombra y seguimiento de destinos de salto indirecto con ENDBRANCH; son comprobaciones distintas y dependen de su habilitación. | Metadatos de ejecución: Intel CET | documented execution mechanisms; primary specification sections verified; enablement required | S041 (R25); Intel CET Specification, rev. 3.0 (2019), printed §§1.1–1.2, 2.3 and 3.3–3.4, pp. 10–13 and 20–22 | CET no afirma que toda transferencia o semántica del destino sea automáticamente segura; el software configura destinos válidos y el estado de habilitación. |
| [C21](https://hardwaresecurityhistory.org/research/claims/C21/) | La descripción Arm de Armv8.3-A de 2016 explica crear, comprobar y quitar un código de autenticación de puntero en bits altos de la dirección; un fallo de comprobación corrompe el puntero y su uso indirecto posterior puede provocar una excepción. | Metadatos de ejecución: Arm PAC | documented architecture announcement; primary architecture announcement section verified; implementation and use not inferred | S042 (R26); David Brash, 'Armv8-A architecture: 2016 additions' (26 Oct. 2016), 'Pointer authentication' section | El anuncio señala que la implementación y el soporte de software evolucionan durante años; no prueba que todo puntero o producto de 2016 usara autenticación. |
| [C22](https://hardwaresecurityhistory.org/research/claims/C22/) | El paper SGX de Intel de 2013 describe comprobaciones de hardware sobre páginas de enclave que excluyen el acceso directo de software ordinario y privilegiado a su código y datos; el OS conserva la gestión de mapas, recursos y planificación. | TEE: aislamiento SGX | documented mechanism + scope limit; primary design paper sections verified; architectural model only | S014 (R23); McKeen et al., HASP 2013, §§2–4, Intel PDF pp. 1–3/8 | Impedir el acceso directo al EPC no garantiza disponibilidad, ausencia de canales laterales ni despliegue en toda máquina. |
| [C23](https://hardwaresecurityhistory.org/research/claims/C23/) | Costan y Devadas distinguen la maquinaria de atestación SGX de sus límites de seguridad y explican por qué un OS malicioso todavía puede explotar tiempos de caché contra un enclave; su informe es análisis independiente, no una especificación de implementación Intel. | TEE: límites y atestación SGX | security analysis + source-status distinction; author analysis sections verified; some implementation details conjectural | S040 (R24); Costan & Devadas, Intel SGX Explained (2016), §§5.8, 6.6.6–6.6.7, MIT mirror PDF pp. 83, 109–110/118 | La crítica al modelo de amenazas no demuestra que todo enclave filtre ni cuantifica el riesgo de un despliegue particular. |
| [C24](https://hardwaresecurityhistory.org/research/claims/C24/) | Los autores de Spectre muestran que la predicción de saltos influida por un atacante puede llevar a una víctima a acceder transitoriamente a datos que ella sí puede leer y codificarlos en un canal de caché incluso tras la reversión arquitectónica. | Estado microarquitectónico: Spectre | documented attack + observability limit; primary attack paper sections verified; demonstrator scope | S018 (R30); Kocher et al., IEEE S&P 2019 author PDF, §I.B and §III, pp. PDF 2 and 5/19 | No equivale a que el atacante cargue directamente una página prohibida del núcleo; requiere instrucciones aprovechables en la víctima y un canal observable. |
| [C25](https://hardwaresecurityhistory.org/research/claims/C25/) | En procesadores afectados del estudio Meltdown, una carga en modo usuario desde una dirección del núcleo mapeada pero privilegiada puede generar o suprimir una excepción y aun así dejar un efecto de caché dependiente del secreto que el atacante mide. | Estado microarquitectónico: Meltdown | documented attack + platform limit; primary attack paper sections verified; affected-platform scope | S019 (R31); Lipp et al., USENIX Security 2018, §§3–5.1, printed pp. 976–980 (PDF pp. 5–9/19) | Sus condiciones incluyen direcciones del núcleo mapeadas y procesadores afectados; no implica que toda CPU especulativa permita esa carga. |
| [C26](https://hardwaresecurityhistory.org/research/claims/C26/) | Anderson define un mecanismo de validación de referencia mediante invocación continua, resistencia a alteraciones y simplicidad suficiente para el análisis. | Introducción: monitor de referencia | documented conceptual formulation; bounded source-level audit; exact edition retained in bibliography | S025 (R01); Anderson (1972), Computer Security Technology Planning Study, reference-monitor formulation | La formulación no exige que toda garantía de plataforma posterior resida en un único bloque físico. |
| [C27](https://hardwaresecurityhistory.org/research/claims/C27/) | Saltzer y Schroeder describen la mediación completa y el mínimo privilegio como principios de diseño, no como afirmaciones de que un mecanismo particular sea suficiente. | Introducción: principios de protección | documented design principles; bounded source-level audit; journal pagination identified | S026 (R02); Saltzer and Schroeder (1975), design-principles section, pp. 1282–1283 | Los principios no identifican por sí mismos rutas modernas de DMA, firmware o microarquitectura. |
| [C28](https://hardwaresecurityhistory.org/research/claims/C28/) | MacKenzie y Pottinger vinculan la verificación formal en seguridad informática con instituciones militares y confianza producida históricamente. | Posicionamiento historiográfico | historiographic interpretation; bounded article-level historiographic audit | S027 (R03); IEEE Annals 19(3), pp. 41–59 | La historia institucional no determina la semántica técnica de un mecanismo. |
| [C30](https://hardwaresecurityhistory.org/research/claims/C30/) | Lipner documenta el auge y declive del Orange Book como régimen de evaluación cuyos efectos no pueden inferirse solo de manuales de procesador. | Posicionamiento historiográfico | documented historical account; bounded article-level historiographic audit | S029 (R05); IEEE Annals 37(2), pp. 19–31 | Una historia participante puede enfatizar las decisiones de política y evaluación de modo distinto a los estudios archivísticos. |
| [C31](https://hardwaresecurityhistory.org/research/claims/C31/) | Karger y Schell muestran que la evaluación de seguridad de Multics expuso lecciones de implementación y garantía no recuperables solo desde la arquitectura de anillos. | Posicionamiento historiográfico y Multics | retrospective technical account; bounded article-level retrospective audit | S030 (R06); ACSAC 2002, pp. 119–126 | Una retrospectiva treinta años posterior puede seleccionar lecciones desde preocupaciones posteriores. |
| [C32](https://hardwaresecurityhistory.org/research/claims/C32/) | Shamon presenta control de acceso obligatorio distribuido entre componentes de enforcement mientras coordina política y estado. | Posicionamiento historiográfico: monitor distribuido | documented system architecture; bounded paper-level technical audit | S033 (R09); McCune et al., ACSAC 2006, pp. 23–32 | Un sistema MAC distribuido no equivale a la categoría histórica más amplia del manuscrito. |
| [C33](https://hardwaresecurityhistory.org/research/claims/C33/) | El relato de planificación de Atlas documenta asignación y planificación de recursos escasos mediadas por el supervisor. | Genealogía temprana: Atlas | documented system operation; verified primary in AFIPS 1963 edition | S054 (R11); Howarth, Jones, and Wyld, AFIPS 1963 SJCC, vol. 23, pp. 59–67, doi: 10.1145/1461551.1461560 | Los objetivos de planificación y eficiencia no prueban que cada mecanismo se introdujera por seguridad. |
| [C34](https://hardwaresecurityhistory.org/research/claims/C34/) | El manual del programa de control MFT de System/360 separa la gestión de tareas del software operativo de las funciones de protección de la máquina. | Genealogía temprana: System/360 | documented implementation organization; bounded manual-level audit; section locator | S002 (R12), S035 (R13); IBM System/360 Principles of Operation (1970), printed pp. 16-17; IBM Y27-7128-3 (1968), 'Control Program Organization' and 'Task Management' | El manual documenta una configuración de sistema operativo y no establece todos los despliegues System/360. |
| [C35](https://hardwaresecurityhistory.org/research/claims/C35/) | Schroeder y Saltzer describen anillos de protección por hardware y puertas controladas para autoridad ordenada entre subsistemas. | Genealogía temprana: Multics | documented hardware architecture; bounded paper-level mechanism audit | S003 (R16); Communications of the ACM 15(3), pp. 157–170 | Las transiciones de anillo no median toda ruta de dispositivo, física o microarquitectónica. |
| [C36](https://hardwaresecurityhistory.org/research/claims/C36/) | El manual del 80286 documenta ejecución protegida mediada por descriptores junto a comportamiento de compatibilidad en modo de direcciones reales. | Genealogía temprana: 80286 | documented architecture; bounded manual-level audit; chapter locator | S005 (R17); Intel 80286/80287 Programmer's Reference Manual (1987), ch. 3 (real-address mode) and ch. 7 (protection mechanisms) | La compatibilidad arquitectónica no cuantifica uso de software ni adopción. |
| [C37](https://hardwaresecurityhistory.org/research/claims/C37/) | Kocher demuestra que el tiempo de ejecución dependiente del secreto puede revelar información aunque las salidas funcionales nominales permanezcan protegidas. | Estado microarquitectónico: temporización | documented attack method; bounded primary-paper audit | S044 (R28); CRYPTO 1996, pp. 104–113 | El método demostrado no implica igual fuga en toda implementación o entorno. |
| [C38](https://hardwaresecurityhistory.org/research/claims/C38/) | Lampson formula el confinamiento como impedir que un servicio transmita información mediante canales fuera de sus salidas previstas. | Estado microarquitectónico: confinamiento | documented conceptual problem; bounded paper-level conceptual audit | S046 (R32); Communications of the ACM 16(10), pp. 613–615 | La nota aporta una advertencia conceptual, no una taxonomía completa de canales microarquitectónicos modernos. |
| [C39](https://hardwaresecurityhistory.org/research/claims/C39/) | NIST SP 800-90B exige caracterización de la fuente, estimación de entropía y pruebas de salud, con acondicionamiento cuando corresponda. | Fabricación y variación física: entropía | documented normative requirements; verified normative requirements; optional conditioning preserved | S047 (R33); NIST SP 800-90B (2018), entropy-source requirements and validation | La conformidad con la recomendación no prueba la calidad entrópica de un dispositivo sin evidencia de evaluación. |
| [C40](https://hardwaresecurityhistory.org/research/claims/C40/) | Suh y Devadas usan variación de fabricación como primitiva específica del dispositivo para autenticación y generación de claves secretas. | Fabricación y variación física: PUF | documented proposal; bounded primary-paper audit | S048 (R34); DAC 2007, pp. 9–14 | Una propuesta PUF no prueba imposibilidad de clonación, fiabilidad ni inscripción segura en toda implementación. |
| [C41](https://hardwaresecurityhistory.org/research/claims/C41/) | Tras el envío correcto de las invalidaciones aplicables, VT-d revisión 4.1 ordena los descriptores previos, los drenajes solicitados dentro de su alcance y la finalización exitosa de la espera; ATS, Device-TLB, PASID, unidades múltiples, tráfico peer y errores de cola dependen de la configuración. | De un componente a una topología | documented lifecycle mechanism + analytical classification; verified primary; source semantics only, not proof of F1 | S039 (R20); Intel VT-d rev. 4.1, §§6.5.2, 6.5.2.8, 6.5.2.11, 6.5.3.3, 6.5.4; printed pp. 6-23–6-45 (PDF pp. 102–125/326) | La especificación no prueba que una plataforma concreta habilite, ejecute correctamente o despliegue esta ruta. |
| [C42](https://hardwaresecurityhistory.org/research/claims/C42/) | La serie de parches VFIO propuesta en 2012 presentó grupos IOMMU, núcleo y soporte PCI de VFIO, un backend IOMMU modular, documentación de acceso desde espacio de usuario y trabajo QEMU asociado como una ruta integrada sujeta a revisión. | Los dispositivos se convierten en principales | documented implementation process; verified primary proposed patch series; no merge or deployment inference | S053 (R39); A. Williamson, LKML patch series [PATCH 00/13] IOMMU Groups + VFIO, May 11, 2012, archived by LWN | Una serie de parches documenta código y revisión, no prevalencia ni configuración correcta en producción. |

## Fuentes citadas

R01 / S025 Anderson (1972), *Computer Security Technology Planning Study*. https://seclab.cs.ucdavis.edu/projects/history/papers/ande72a.pdf; Formulación del monitor de referencia
R02 / S026 Saltzer & Schroeder (1975), *The Protection of Information in Computer Systems*. https://doi.org/10.1109/PROC.1975.9939; Principios de diseño y mecanismos de protección
R03 / S027 MacKenzie & Pottinger (1997), *Mathematics, Technology, and Trust: Formal Verification, Computer Security, and the U.S. Military*. https://doi.org/10.1109/85.601735; IEEE Annals 19(3), pp. 41–59
R05 / S029 Lipner (2015), *The Birth and Death of the Orange Book*. https://doi.org/10.1109/MAHC.2015.27; IEEE Annals 37(2), pp. 19–31
R06 / S030 Karger & Schell (2002), *Thirty Years Later: Lessons from the Multics Security Evaluation*. https://doi.org/10.1109/CSAC.2002.1176285; ACSAC 2002, pp. 119–126
R07 / S031 Zhao et al. (2019), *SoK: Hardware Security Support for Trustworthy Execution*. https://arxiv.org/abs/1910.04957; Taxonomía y comparación de TEE
R08 / S032 Schneider et al. (2022), *SoK: Hardware-supported Trusted Execution Environments*. https://arxiv.org/abs/2205.12742; Revisión sistemática y taxonomía
R09 / S033 McCune et al. (2006), *Shamon: A System for Distributed Mandatory Access Control*. https://doi.org/10.1109/ACSAC.2006.47; ACSAC 2006, pp. 23–32
R10 / S001 Kilburn, Payne & Howarth (1961), *The Atlas Supervisor*. https://bitsavers.trailing-edge.com/pdf/afips/1961-12_%2320.pdf; AFIPS 1961 EJCC, pp. impresas 279–280 y 283; escaneo PDF pp. 295–296 y 299/396
R11 / S054 Howarth, Jones & Wyld (1963), *The Atlas Scheduling System*. https://doi.org/10.1145/1461551.1461560; AFIPS 1963 SJCC, vol. 23, pp. 59–67
R12 / S002 IBM (1970), *System/360 Principles of Operation*. https://vtda.org/docs/computing/IBM/Mainframe/Hardware/System/GA22-6821-8_System360PrinciplesOperation_Nov70.pdf; System Structure, pp. impresas 16–17 (estados de programa y protección)
R13 / S035 IBM (1968), *System/360 Operating System: Control Program with MFT*. https://bitsavers.org/pdf/ibm/360/os/R15-16_May68/plm/Y27-7128-3_IBM_System_360_Operating_System_Control_Program_with_MFT_4th_ed_196805_plus_TNL_Y28-2349_19681115.pdf; Organización del programa de control y gestión de tareas
R14 / S036 Burroughs (1963), *The Operational Characteristics of the Processors for the Burroughs B5000*. https://bitsavers.trailing-edge.com/pdf/burroughs/LargeSystems/B5000_5500_5700/5000-21005_B5000_operChar_1963.pdf; Descriptores, pilas y modos del procesador
R15 / S037 Burroughs (1969), *B6500 Information Processing Systems Reference Manual*. https://archive.org/download/bitsavers_burroughsB0RefManSep69_19454288/1043676_B6500_RefMan_Sep69.pdf; Pp. impresas 3-4–3-5: bits de presencia, índice inválido y solo lectura
R16 / S003 Schroeder & Saltzer (1972), *A Hardware Architecture for Implementing Protection Rings*. https://doi.org/10.1145/361268.361275; Modelo de anillos de protección
R17 / S005 Intel (1987), *80286 Programmer’s Reference Manual*. https://bitsavers.org/components/intel/80286/210498-005_80286_and_80287_Programmers_Reference_Manual_1987.pdf; Capítulos sobre modo protegido
R18 / S006 Intel (1986), *80386 Programmer’s Reference Manual*. https://bitsavers.org/components/intel/80386/230985-001_80386_Programmers_Reference_Manual_1986.pdf; Caps. 4–7 (segmentación, privilegio, paginación); cap. 15 §15.1 (modo virtual 8086)
R19 / S038 Ben-Yehuda et al. (2006), *Utilizing IOMMUs for Virtualization in Linux and Xen*. https://www.kernel.org/doc/ols/2006/ols2006v1-pages-71-86.pdf; OLS 2006, pp. 71–86
R20 / S039 Intel (2023), *Intel Virtualization Technology for Directed I/O Architecture Specification*. https://cdrdv2-public.intel.com/774206/vt-directed-io-spec%20.pdf; Revisión 4.1 (D51397-016), §§ impresas 2.5.2 y 3.2–3.4, pp. 2-6 y 3-1–3-4; PDF pp. 25, 28–31/326
R21 / S011 Sailer et al. (2004), *TCG-based Integrity Measurement Architecture*. https://www.usenix.org/legacy/events/sec04/tech/full_papers/sailer/sailer.pdf; Secciones de arquitectura y attestation
R22 / S012 Trusted Computing Group (2019), *TPM 2.0 Library Specification*. https://trustedcomputinggroup.org/resource/tpm-library-specification/; Revisión 01.59 (2019), Parte 3: Comandos, §§18.4 y 22 (TPM2_Quote y PCR)
R23 / S014 McKeen et al. (2013), *Innovative Instructions and Software Model for Isolated Execution*. https://www.intel.com/content/dam/develop/external/us/en/documents/hasp-2013-innovative-instructions-and-software-model-for-isolated-execution.pdf; HASP 2013, §§2–4, pp. PDF 1–3/8: acceso al enclave y control de recursos por el OS
R24 / S040 Costan & Devadas (2016), *Intel SGX Explained*. https://css.csail.mit.edu/6.858/2020/readings/costan-sgx.pdf; Costan y Devadas (2016), §§5.8 y 6.6.6–6.6.7, pp. PDF 83 y 109–110/118; análisis independiente, en parte conjetural
R25 / S041 Intel (2019), *Control-flow Enforcement Technology Specification*. https://kib.kiev.ua/x86docs/Intel/CET/334525-003.pdf; Revisión 3.0 (334525-003), §§ impresas 1.1–1.2, 2.3 y 3.3–3.4, pp. 10–13 y 20–22
R26 / S042 Brash (2016), *Armv8-A Architecture: 2016 Additions*. https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions; Arm Community (26 oct. 2016), sección «Pointer authentication»
R27 / S043 Arm (2019), *Armv8.5-A Memory Tagging Extension*. https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Arm_Memory_Tagging_Extension_Whitepaper.pdf; Memory safety with MTE, pp. PDF 2–4/9 (comprobaciones y etiquetas finitas)
R28 / S044 Kocher (1996), *Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems*. https://doi.org/10.1007/3-540-68697-5_9; CRYPTO 1996, pp. 104–113
R29 / S045 Yarom & Falkner (2014), *FLUSH+RELOAD: A High Resolution, Low Noise, L3 Cache Side-Channel Attack*. https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/yarom; Método de ataque y evaluación
R30 / S018 Kocher et al. (2019), *Spectre Attacks*. https://spectreattack.com/spectre.pdf; PDF de autores IEEE S&P 2019, §§I.B y III, pp. PDF 2 y 5/19
R31 / S019 Lipp et al. (2018), *Meltdown*. https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-lipp.pdf; USENIX Security 2018, §§3–5.1, pp. impresas 976–980, PDF pp. 5–9/19
R32 / S046 Lampson (1973), *A Note on the Confinement Problem*. https://doi.org/10.1145/362375.362389; Communications of the ACM 16(10), pp. 613–615
R33 / S047 NIST (2018), *Recommendation for the Entropy Sources Used for Random Bit Generation*. https://www.nist.gov/publications/recommendation-entropy-sources-used-random-bit-generation-0; SP 800-90B: requisitos y validación de fuentes de entropía
R34 / S048 Suh & Devadas (2007), *Physical Unclonable Functions for Device Authentication and Secret Key Generation*. https://doi.org/10.1145/1278480.1278484; DAC 2007, pp. 9–14
R35 / S049 Anderson & Kuhn (1996), *Tamper Resistance — A Cautionary Note*. https://www.usenix.org/publications/library/proceedings/ec96/kuhn.html; USENIX Electronic Commerce 1996
R36 / S050 Watson, Moore, Sewell & Neumann (2019), *An Introduction to CHERI*. https://doi.org/10.48456/tr-941; UCAM-CL-TR-941: modelo de protección y revocación
R37 / S051 Xia et al. (2019), *CHERIvoke: Characterising Pointer Revocation using CHERI Capabilities for Temporal Memory Safety*. https://doi.org/10.1145/3352460.3358288; MICRO-52, §§3.1–3.3
R38 / S052 Computer History Museum (2008), *Intel 386 Microprocessor Design and Development Oral History Panel*. https://archive.computerhistory.org/resources/text/Oral_History/Intel_386_Design_and_Dev/102702019.05.01.acc.pdf; Transcripción pp. 7–9; panel retrospectivo, contrastar con manual Intel 80386
R39 / S053 Williamson (2012), *IOMMU Groups + VFIO*. https://lwn.net/Articles/497009/; LKML [PATCH 00/13], 11 mayo 2012

Este registro es un suplemento metodológico; los localizadores pendientes no deben presentarse como páginas verificadas.