Sobre los Exclaves de Apple

 (medium.com/@randomaugustine)
1 puntos por GN⁺ 2025-03-10 | 1 comentarios | Compartir por WhatsApp
  • Los Exclaves de Apple son una función de aislamiento pensada para mantener ciertos recursos sensibles en una zona separada incluso si el kernel XNU es comprometido, y la publicación del código fuente de XNU para M4 y A18 dejó ver parte de su estructura
  • XNU está basado en Mach, pero en la práctica muchas funciones reales del sistema se concentran en el mismo nivel de privilegio y por eso funciona más como un kernel monolítico; Exclaves se ubica sobre una línea de defensa en profundidad que continúa desde Secure Enclave, PPL y SPTM
  • Exclaves se compone de dominios y recursos definidos durante el arranque, y protege desde XNU, mediante nuevos tipos de página de SPTM, buffers de memoria compartida, buffers de audio, sensores, Conclave, servicios y más
  • El Secure Kernel (SK) corre en el mismo procesador de aplicaciones que XNU y, por las pistas del código fuente, podría usar una línea basada en seL4 y el secure world de ARM TrustZone, aunque buena parte de su implementación interna no ha sido publicada
  • Su efecto de seguridad real depende de qué componentes se muevan a Exclaves; las imágenes de build actuales apuntan al uso para indicadores de seguridad de cámara y micrófono, parte del Apple Neural Engine, algunos drivers y componentes de comunicación con Secure Enclave

Kernel monolítico y el refuerzo de aislamiento de Apple

  • Los sistemas operativos modernos normalmente funcionan con dos dominios de protección: modo usuario y modo kernel
    • Las aplicaciones no pueden realizar directamente operaciones de alto privilegio, como acceder a archivos o comunicarse por red, y deben pedirlo al kernel mediante llamadas al sistema
    • El kernel verifica los permisos de acceso y luego devuelve al modo usuario resultados como handles que representan archivos abiertos
  • La mayoría de los sistemas operativos usa una arquitectura de kernel monolítico, donde el kernel tiene acceso sin restricciones al hardware, la memoria y todos los datos del usuario
    • Mientras más crece el kernel, mayor es la posibilidad de que aparezcan vulnerabilidades
    • La explotación de una vulnerabilidad del kernel puede derivar en el compromiso de todo el sistema
  • Un microkernel puede mejorar el aislamiento de seguridad al reducir funciones dentro del kernel y mover la mayoría del trabajo a procesos separados sin privilegios
    • Sus desventajas siguen siendo los problemas de rendimiento y el aumento de complejidad del software de aplicaciones
  • XNU, compartido por iOS, macOS, tvOS, visionOS y watchOS, está basado en el microkernel Mach, pero en la implementación varias funciones del sistema comparten el mismo rango de privilegio, así que en la práctica opera como un kernel monolítico

Aislamiento de seguridad de Apple antes de Exclaves

  • En 2013, el iPhone 5s introdujo Secure Enclave
    • En un núcleo de CPU reforzado y dedicado corre un sistema operativo basado en microkernel llamado SepOS
    • El kernel de SepOS es cL4, una versión personalizada de L4-embedded de Apple
    • Se usa para proteger claves criptográficas y datos biométricos como Face ID
    • Aunque el kernel de iOS sea comprometido, por lo general Secure Enclave no se ve afectado a menos que exista un exploit adicional dirigido específicamente a ella
    • Secure Enclave y Secure Exclaves son objetivos distintos
  • En 2017, con los iPhone 8 y iPhone X basados en A11, se introdujo Page Protection Layer (PPL)
    • Solo da a una parte del kernel permiso para modificar tablas de páginas de memoria, y evita que el resto del kernel las cambie directamente
    • Su superficie de ataque era pequeña y rara vez se lograba evadir, pero el resto del kernel seguía conservando muchos privilegios necesarios para comprometer datos
  • Entre 2021 y 2023, con A15 e iOS 17, Secure Page Table Monitor (SPTM) reemplazó y mejoró a PPL
    • Protege funciones adicionales de memoria y aísla componentes pequeños del kernel
    • También separa la verificación de firmas de código que valida si algo está firmado por Apple
    • En ese periodo aparecieron referencias indirectas a exclaves en el código fuente de XNU, y en ese momento se estimó que eran un subsistema administrado por SPTM

La llegada de XNU Exclaves en 2024

  • La publicación del código fuente de XNU con soporte para sistemas M4 y A18 dejó ver parte de la estructura de Exclaves
    • Apunta a sistemas como el iPhone 16
    • En procesadores anteriores Exclaves no está habilitado
  • Exclaves se refiere a recursos separados de XNU, diseñados para quedar protegidos incluso si el kernel es comprometido
    • Los recursos se definen por adelantado durante el build del sistema operativo
    • Se identifican por nombre o por ID
    • Tienen un tipo y se inicializan durante el arranque
    • Se organizan en dominios propios
  • SPTM protege la memoria Exclave frente a XNU mediante tipos de página dedicados a Exclave
  • Los tipos de recursos identificados muestran dónde aparece la frontera entre XNU y Exclave
    • Buffers de memoria compartida a los que pueden acceder tanto XNU como Exclave
      • Desde la perspectiva de XNU, pueden configurarse como solo lectura o lectura y escritura
    • Buffers de audio y sensores usados para asegurar funciones como los indicadores de acceso a cámara y micrófono
    • Conclave y Conclave Manager, que agrupan varios recursos dentro de su propio dominio de seguridad
    • Servicios que pueden ejecutar código en el espacio Exclave cuando un hilo de XNU los invoca

Secure Kernel y secure world

  • Para que los servicios de Exclave se ejecuten aislados de XNU, Apple introdujo Secure Kernel (SK)
  • El archivo de imagen de SK incluye la cadena de versión “cL4”
    • La estructura de IPC parece más cercana a seL4 que al L4-embedded del cL4 original de SepOS
    • En las cadenas de SK aparecen con frecuencia términos de la familia seL4 como capability, frame, untyped memory y minting
    • Apple anunció en abril de 2024 su incorporación a la seL4 Foundation
  • A diferencia de SepOS, que corre en un procesador dedicado, SK se ejecuta en el mismo procesador de aplicaciones de alto rendimiento que XNU/iOS
  • Esta estructura requiere un nivel adicional de privilegio del procesador, y entre las bases posibles se mencionan extensiones de virtualización, funciones extra de SPTM de Apple y ARM TrustZone
    • En el código fuente de XNU hay referencias a transiciones al secure world de TrustZone
    • Se interpreta que XNU e iOS corren en el insecure world, mientras que SK corre en el secure world
  • SK ofrece un entorno operativo limitado para Exclave, recursos y servicios
    • Es distinto al patrón de diseño de Trusted Applications propuesto por ARM
    • Como la superficie de ataque de los servicios Exclave y de Secure Kernel es limitada, es probable que escapar del secure world para comprometer XNU sea mucho más difícil que atacar directamente XNU desde el insecure world
  • En el código fuente de XNU, la transición al secure world se denomina RINGGATE
    • La idea de que SPTM gestione esa transición sigue siendo especulativa, y esa parte no es open source, por lo que requiere análisis binario

Dominios, recursos y Conclave

  • Durante el arranque, XNU inicializa una estructura de tablas de kernel de dos niveles para guardar la información de los recursos Exclave detectados
    • root_table identifica los dominios por nombre
    • Cada dominio referencia una tabla de segundo nivel con los recursos de ese dominio
  • La estructura de dominios identificada es la siguiente
    • com.apple.kernel
      • Incluye Conclave launcher, servicios de depuración, ExclaveIndicatorController para indicadores de seguridad, servicio de logs y FrameMint usado para arrancar ExclaveKit
      • También incluye el buffer de memoria compartida com.apple.storage.backend, usado para que servicios Exclave hagan file I/O en el espacio XNU mediante upcalls
      • Incluye un recurso Conclave Manager por cada Conclave
    • com.apple.darwin
      • No tiene casos de uso dentro de los componentes open source
    • com.apple.conclave.name
      • Existe un dominio por cada Conclave
      • Puede incluir servicios, buffers de audio, buffers de memoria compartida y más
    • com.apple.driver.*name*
      • Se menciona su existencia en comentarios como dominios por driver de dispositivo, pero no se confirma realmente en el código open source
  • Conclave es al mismo tiempo un tipo de recurso que puede contener varios recursos y una unidad de seguridad que permite acceso compartido entre servicios y recursos
    • Las tareas Mach tienen restringido a qué Conclave pueden invocar
    • Cada Conclave tiene un Conclave Manager ubicado en el dominio del kernel
    • Conclave tiene un ciclo de vida con estados como attach, launch, stop y detach
    • También existen estados de transición como launching y stopping

Creación, enlace y ejecución de Conclave

  • posix_spawn() de XNU puede llamar a task_add_conclave() para vincular una task con un recurso Conclave Manager
    • La relación es 1:1
    • Una task solo puede vincularse a un Conclave Manager, y lo mismo aplica a la inversa
  • Quien puede hacer spawn de un Conclave es launchd o una task con el entitlement com.apple.private.exclaves.conclave-spawn
    • El entitlement com.apple.private.exclaves.conclave-host se interpreta más como permiso para hacer attach sobre sí misma que para hacer spawn de una nueva task
  • El kernel busca en el dominio com.apple.kernel el recurso Conclave Manager conectado al Conclave objetivo
    • Después guarda en la estructura de recurso Conclave un endpoint de Tightbeam que apunta al endpoint del Conclave Manager
    • Tightbeam parece ser un framework RPC para comunicación entre componentes Exclave
  • La ejecución del Conclave debe hacerse desde la task Conclave Manager asociada
    • Los intentos de launch esperan hasta que Exclaves termine de arrancar por completo y llegue al estado EXCLAVES_BS_BOOTED_EXCLAVEKIT
    • Un nuevo Mach trap entra por la función _exclaves_ctl_trap(), y EXCLAVES_CTL_OP_LAUNCH_CONCLAVE se usa para ejecutar un Conclave
    • En entornos de producción, un host de Conclave lanzado puede quedar en estado tainted, y luego exit() podría provocar un kernel panic

Nuevo Mach trap para Exclaves

  • _exclaves_ctl_trap() es un nuevo Mach trap que maneja funciones de Exclave
    • Realiza distintas acciones según el parámetro operation
    • Normalmente valida los entitlements necesarios para la operación invocada
  • EXCLAVES_CTL_OP_BOOT se llama dos veces durante el arranque del sistema
    • Inicio de Exclaves boot stage 2
    • Arranque de ExclaveKit
    • El llamador debe ser launchd o tener el entitlement com.apple.private.exclaves.boot
  • El resto de las operaciones principales requieren al menos que la task actual tenga el entitlement com.apple.private.exclaves.kernel-domain o que sea la task Conclave Manager relacionada
    • EXCLAVES_CTL_OP_LOOKUP_SERVICES: busca servicios en el dominio Exclave de la task actual, y si falla, revisa los dominios Darwin y kernel según los permisos
    • EXCLAVES_CTL_OP_ENDPOINT_CALL: invoca un endpoint de servicio Exclave del dominio de la task actual para que el hilo actual haga transición al secure world y ejecute código específico
    • Creación de named buffer y operaciones copyin/copyout
    • Creación de audio buffer y copyout
    • Creación de sensor, start, stop y status
    • Búsqueda de notification resource

Downcall y Upcall

  • Downcall es la invocación de un endpoint de servicio Exclave en el secure world, y es el punto donde comienza la ejecución de código de secure world
  • Downcall cambia el hilo actual al secure world y comienza la ejecución en el entry point del código seguro
    • No delega el trabajo a otro hilo
    • La task que llama debe tener el entitlement de kernel domain o ser la task Conclave Manager vinculada al Conclave de ese servicio
    • Un Conclave puede tener hasta 128 servicios invocables
  • Parece que XNU programa el hilo en Secure Kernel mediante sk_enter()
    • Es posible que SK no tenga hilos independientes y que XNU gestione toda la planificación de hilos del secure world
    • Un hilo que se ejecuta en el secure world puede realizar acciones normales del scheduler como yield, wait, suspend e interrupt
    • En ese caso, el hilo sale del secure world, vuelve al contexto del kernel XNU y luego el código de scheduling de Exclave lo reprograma al secure world
  • La estructura IPC de Downcall se configura como buffers de request y response antes de entrar al secure world
    • Las interrupciones y la apropiación se deshabilitan mientras se prepara la estructura final de IPC request y se llama a sk_enter()
    • Esto se debe a que solo existe una de estas estructuras por cada núcleo de CPU
    • La respuesta de Downcall puede volver al response buffer por núcleo de otra CPU debido a interrupciones, upcalls, yield o reprogramación
  • Upcall es el mecanismo por el cual un hilo que corre en el secure world llama al upcall handler de Exclaves a través de Tightbeam cuando necesita ayuda de XNU
    • Está limitado a funciones específicas permitidas de XNU
    • Un hilo en medio de un upcall no puede regresar a modo usuario
    • Tampoco se permite reingresar haciendo un nuevo downcall al secure world
    • El hilo debe volver al contexto del secure world en el punto donde realizó el upcall
  • Las categorías de upcall observadas en el código son memoria, almacenamiento de archivos, DriverKit, DriverKit Apple Neural Engine y control de Conclave

XNUProxy y etapas de arranque

  • Hay muchas referencias a XNUProxy, pero su ubicación y función exactas no están confirmadas
    • Podría ser un dominio Exclave independiente
    • Podría ser un servicio o conjunto de servicios dentro del dominio com.apple.kernel que procesa ciertos downcalls
    • También podría ser un subsistema de SPTM que realiza downcalls hacia el secure world
  • Un comentario en Exclaves_L4.h dice que XNU Proxy vuelve reachables múltiples Exclave
    • Plantilla de app de usuario
    • Driver de audio
    • ExclaveDriverKit
    • SecureRTBuddy para Always On Processor y Display Coprocessor
    • Conclave control, Conclave debug y más
  • El arranque de Exclaves requiere coordinación entre el insecure world y el secure world, y si algo falla normalmente termina en panic()
  • El arranque se divide en tres etapas
    • Stage 1 no aparece en el código open source y podría ser un proceso de secure boot que carga SK en memoria, verifica su firma de código y lo deja listo para ejecutar
    • Stage 2 realiza la inicialización del upcall server, recolección de información de arranque del secure kernel, inicialización del scheduler de Exclave, inicialización del kext XrtHostedXNU, inicialización multicore, inicialización de XNU Proxy, detección de recursos Exclave estáticos y creación de endpoints de Conclave Manager
    • Stage 3 busca el servicio com.apple.service.FrameMint y realiza llamadas relacionadas con framemint_framemint__init() y framemint_framemint_populate(), tras lo cual entra en estado EXCLAVES_BS_BOOTED_EXCLAVEKIT

Tipos de memoria SPTM y limitaciones pendientes

  • SPTM asigna tipos a las páginas de memoria para control de acceso por subsistema
    • Entre los tipos existentes están XNU_USER_EXEC, XNU_USER_DEBUG, XNU_USER_JIT, XNU_ROZONE, XNU_KERNEL_RESTRICTED y tipos relacionados con TXM y DART
  • Exclaves agrega nuevos tipos relacionados con SK
    • SK_DEFAULT: exclusivo de SK, sin acceso desde XNU
    • SK_IO: exclusivo de SK, sin acceso desde XNU
    • SK_SHARED_RO: compartido entre SK y XNU, pero XNU solo lectura
    • SK_SHARED_RW: compartido entre SK y XNU, con lectura y escritura para XNU
  • Exclaves puede verse como una gran inversión para agregar defence in depth a los sistemas operativos de Apple
    • Aísla recursos sensibles para reducir la superficie potencial de ataque
    • Va en la dirección de disminuir el impacto de un compromiso único del kernel
  • No se analizó directamente qué componentes concretos se están moviendo del kernel a Exclaves
    • Las imágenes de build apuntan al uso para indicadores de seguridad de cámara y micrófono, algunas funciones del Apple Neural Engine, ciertos drivers de dispositivo y componentes que se comunican con Secure Enclave
    • En el futuro podrían migrarse más componentes a Exclaves
    • El área de XNU fuera de Exclaves sigue siendo objetivo de ataque
  • El análisis se basa en Apple Open Source XNU build 11215
    • La ubicación exacta de ExclaveKit, ExclaveDriverKit y XNUProxy, la forma en que XNU hace la transición al secure world, Secure Kernel y el userspace del secure world siguen siendo áreas que requieren análisis adicional

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-03-10
Opiniones en Hacker News

  • Los SoC recientes de teléfonos y laptops de Apple incluyen soporte de hardware para virtualización anidada, incluido el iPad Pro M4, que usa un exclave para el LED de la cámara.
    Espero que la próxima revisión de la guía Apple Platform Security cubra el exclave SK y las mitigaciones de banda base para la detección de radar por Wi‑Fi: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
    También hay un artículo de ingeniería inversa de SPTM sobre las funciones adicionales de SPTM de Apple: https://www.df-f.com/blog/sptm3
    XNU se está refactorizando hacia una arquitectura inspirada en microkernels, reduciendo la base de código y moviendo hacia afuera las tareas sensibles para la seguridad. El aislamiento del espacio de memoria lo ayuda el Secure Page Table Monitor (SPTM), y tareas como la firma de código, la verificación de permisos, Developer Mode y Restricted Execution Mode quedan a cargo del Trusted eXecution Monitor (TXM).
    Hay más de 150 CVE relacionadas con TrustZone: https://www.cve.org/CVERecord/SearchResults?query=trustzone
    Google también implementó hace unos años en los Pixel pKVM, que usa virtualización anidada por hardware, e incluso subió al mainline de Linux código que reduce de forma cooperativa los privilegios de TrustZone en comparación con pKVM L0. Sin embargo, aparte de la VM Debian “Linux Terminal”, no ha anunciado funciones defensivas que aprovechen pKVM/AVF.

    • La mayoría de los CVE de TrustZone están relacionados con software vulnerable que los fabricantes pusieron en el entorno protegido por TrustZone. Entre ese software hay mucho de pésima calidad, y hay muy pocos reportes de vulnerabilidades del hardware en sí.
    • El autor publicó una entrada de seguimiento y un diagrama corregido: https://randomaugustine.medium.com/more-speculation-on-excla...
      Al principio especuló con el uso de TrustZone, pero parece que los exclaves también podrían usar los niveles de privilegio existentes de SPTM y GXF (Guarded Execution). Si es así, dejando de lado los requisitos de RAM y el esfuerzo de desarrollo, podría no haber una razón fundamental para que no se soporte incluso en iPhone 13 o posteriores. Claro que, aun para Apple, sin duda sería una tarea enorme.

  • Steve parecía creer sinceramente que “una laptop es el diario personal de una persona” y que Apple tenía la responsabilidad de protegerlo.
    Creo que Tim tampoco habría llegado a CEO si no compartiera esa misma convicción de Steve. Suena raro, pero de verdad extraño a Steve.
    https://www.youtube.com/watch?v=Ij-jlF98SzA

    • Desde la perspectiva de alguien que fabrica equipos industriales y científicos, los dispositivos de consumo de Apple son completamente inútiles. Me parece un desperdicio bloquear de esta forma dispositivos de cómputo bastante capaces.
      Tampoco me gusta la forma en que Apple controla el mercado de dispositivos y software incluso después de que cambia el propietario del equipo. Evito por completo este tipo de ecosistema, y no entiendo por qué tantos supuestos “hackers” se entusiasman con sistemas a los que les soldaron el cofre para que no se pueda abrir.
    • Jobs era divisivo y a menudo áspero; para empezar, uno podría preguntarse por qué habría que extrañar a un multimillonario tecnológico. Aun así, siento que les debo algo a Jobs y a la gente de Apple que contribuyó a crear productos que me gustan, como la Mac, el iPod y el iPad.
      Muchas cosas que dijo Jobs todavía me resuenan. Apple lanzó hace poco un protector de pantalla “classic Mac”, y muestra lo cuidadosamente diseñada que estaba la GUI original de la Mac. Nadie va a extrañar la época en que un bug en una app podía tumbar el sistema operativo, pero ojalá Apple siguiera obsesionada con los detalles tanto como entonces.
    • Al ver los sentimientos sinceros hacia Jobs, me pregunto si algo parecido se activa cuando la gente usa y experimenta con los LLM.
      Dicho de forma un poco más directa, parece haber ahí un componente místico o religioso. Se siente como un anhelo por un hombre amable casi divino que ofrece milagros, oráculos, productos y rituales hermosos, y un futuro pulido, abundante y eterno. Como si se llenara una especie de “vacío” espiritual.
      No intento menospreciar a quienes sienten afinidad por Jobs o por los LLM; solo comparto lo que observo.
    • Entiendo que el artículo sobre exclaves te haya hecho pensar en Steve, pero no me queda claro cómo una cosa llevó a la otra. Me gustaría saber si puedes explicarlo.

  • Hilo relacionado: “Apple rearranged its XNU kernel with exclaves” https://news.ycombinator.com/item?id=43314171

    • Según el resumen de ese artículo, un exclave se refiere a recursos específicos separados de XNU, el kernel principal, y explica que no se puede acceder a ellos aunque el kernel sea comprometido.
      También dice que no es raro que una versión intermedia de macOS incluya funciones que preparan la siguiente versión mayor, y que la función más fundamental e importante agregada en Sonoma 14.4, iOS 17.4, iPadOS 17.4 y watchOS 10.4 podría ser el exclave.
      https://eclecticlight.co/2024/08/20/sonomas-unfinished-busin...

  • Es bastante sorprendente que se use un enclave de seguridad para controlar el LED físico de la cámara, y parece un diseño excesivamente complejo para una tarea simple
    Habría bastado con poner una lógica de hardware dedicada muy pequeña en el módulo de la cámara. Bastaría con bloquear la E/S digital o la alimentación de la cámara, y agregar un estirador de pulso para que el LED permanezca encendido al menos unos segundos cada vez, a fin de evitar ataques que enciendan y apaguen rápidamente la lógica de la cámara
    También sería bueno tener un circuito similar para el micrófono y un LED físico de otro color. El punto mostrado por software en la pantalla no es suficiente

    • Es más complejo de lo que parece. Una “cámara” es un conjunto de varios componentes. Uno querría tomar como referencia la alimentación del sensor CMOS, pero hay varios niveles de energía, como espera, ahorro de energía e inactividad. Así que es muy probable que el circuito de hardware tenga que conocer no solo el voltaje, sino también la corriente. O tal vez tenga que parsear mensajes como I2C a un nivel más alto para leer los cambios de modo de energía
      El controlador del LED también tendría que conocer el brillo de la pantalla o la información del sensor de luz ambiental. Debe ser lo bastante brillante para verse bajo luz solar directa, pero ese brillo puede resultar molesto en entornos oscuros e incluso interferir con el uso normal de la cámara
      Si se cree que el SK es seguro, usarlo sería más simple y además podría funcionar mejor. Si se considera que el SK no es seguro, de todos modos se derrumba toda la premisa
    • No es un diseño excesivo. Es necesario por investigaciones como esta y por resultados de otros investigadores como Charlie Miller
      Apple, en general, no hace las cosas complejas a propósito sin una buena razón
      https://news.ycombinator.com/item?id=42260379
    • Me pregunto si es un diseño excesivo o si es una solución a algo que descubrieron al distribuir una cantidad enorme de teléfonos. Nunca había pensado en la cámara como un vector de seguridad, pero quizá Apple sí
    • Hay más contexto relacionado aquí: https://news.ycombinator.com/item?id=42260379
    • Parece que no se trata solo del LED de la cámara, sino también de los indicadores en pantalla, como los puntos naranja, verde y azul que aparecen en la barra de menús cuando una app accede al micrófono, la cámara o la grabación de pantalla

  • Me pregunto quién es el autor de este texto. Es un artículo muy refinado y bien escrito, y también está muy bien organizado incluso para quienes venían siguiendo los exclaves

  • Me pregunto cómo se compara esto con Virtualization Based Security de Linux
    Según la página que tiene el video, esta función de seguridad puede reforzar el kernel y garantizar que recursos importantes del kernel no sean modificados aunque el kernel se vea comprometido. VBS usa virtualización de hardware y el hipervisor Hyper‑V para crear un entorno virtual aislado que se ejecuta en un nivel de confianza más alto, Virtual Trust Level 1 (VTL1), y VTL1 tiene su propio kernel, separado del kernel Guest: el Secure Kernel
    https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

    • Exclave se ejecuta en un nivel de confianza paralelo

  • Exclave es importante, pero parece un paso intermedio. Apple está haciendo que XNU sea menos riesgoso, pero todavía se mueve de forma defensiva en lugar de adoptar por completo una arquitectura de microkernel
    Si tuviera que apostar, diría que los exclaves son un puente hacia un cambio más grande. Podría ser un sistema operativo más modular como Fuchsia, o un modelo de seguridad al estilo CHERI que imponga la seguridad de memoria a nivel de hardware
    Apple va a la vanguardia en seguridad de sistemas operativos de consumo, pero los exclaves se parecen más a una mejora tipo patchwork que al resultado de repensar por completo el diseño del sistema. Aun así, probablemente sea el mayor cambio de seguridad en el diseño de sistemas operativos mainstream de la última década, y tomará años ver todo su impacto

    • Parece una vuelta a los microkernels de antes. Solo que en una forma que incorpora soluciones modernas y nuevos requisitos
      Cuando se creó Mach, la seguridad no era una preocupación tan grande como ahora. Las máquinas actuales son tan potentes que quizá la sobrecarga que genera la comunicación entre procesos de un microkernel se haya vuelto despreciable

  • No estoy familiarizado con contenido de este nivel, pero por lo que se ve parece que se puede atacar el enclave en sí y escalar a privilegios más altos que los del kernel. Me pregunto si esta pieza de hardware es algo así como un coprocesador

    • Exclave no es hardware, sino software aislado que maneja ciertas tareas sensibles a las que se quiere impedir que acceda el kernel
      Por eso, si se lo explota, efectivamente se obtienen permisos de acceso que el kernel no tiene. Pero justamente esa es la intención. El objetivo es que, aunque el kernel sea comprometido, no se pueda acceder a esas áreas sensibles

  • Según la documentación de Apple, SPTM no se usa, así que me pregunto qué impacto tendrá esto en la seguridad de macOS: https://support.apple.com/guide/security/operating-system-in...
    Por ahora, cosas como el exclave existente que muestra el indicador de cámara no parecen aplicarse mucho a macOS, ya que las MacBook tienen hardware dedicado. Pero en el futuro podrían aparecer exclaves que también se apliquen a macOS

    • Hay que releer esa nota al pie. Dice que Page Protection Layer (PPL) y Secure Page Table Monitor (SPTM) imponen la ejecución de código firmado y confiable en todas las plataformas excepto macOS. Eso se debe a que macOS está diseñado para ejecutar código arbitrario. Otras propiedades de seguridad, incluida la protección de tablas de páginas, existen en todas las plataformas compatibles
      Es decir, no significa que macOS no use SPTM. Significa que macOS no usa SPTM para impedir la ejecución de código sin firmar. Esto se debe a que macOS debe permitir que el usuario ejecute código sin firmar tras seguir algunos pasos

  • Me pregunto si los desarrolladores de apps pueden usar Exclave. Me molesta que Apple cree internamente funciones nuevas increíbles y luego las deje totalmente bloqueadas para los desarrolladores. Como resultado, cosas como apps bancarias, billeteras y mensajería segura tienen que seguir ejecutándose en un espacio de usuario con seguridad débil.

    • No necesariamente. El espacio de usuario de Apple también se ha vuelto cada vez más seguro.
      Como ejemplo simple, las versiones recientes de macOS ejecutan todas las apps dentro de un sandbox, aunque la app no lo elija explícitamente. Este sandbox evita que las apps modifiquen los archivos de otras, algo que antes era una gran debilidad del sistema de seguridad, porque la firma del bundle solo se verificaba en el primer lanzamiento y no en cada ejecución.
    • Según entiendo, con el diseño actual no se puede. Exclave está integrado en todo el sistema operativo y se inicia como parte del proceso de arranque, por lo que es relativamente estático. Por razones de seguridad, es probable que las relaciones entre estos componentes también estén definidas de forma estática.
      Además, ahora tiene una estructura de kernel a kernel, así que, si hubiera soporte para terceros, probablemente se limitaría a implementar cosas como drivers de dispositivos de seguridad. Pero Apple ha intentado empujar los drivers de terceros al espacio de usuario, no al hipervisor. Dado que esta transición ocurre en paralelo con el desarrollo de exclave, no parece que vaya a cambiar de rumbo para permitir que los desarrolladores de drivers de terceros usen exclave.
      Es común que Apple estabilice mucho más internamente este tipo de funciones de plataforma impuestas por el kernel antes de abrirlas al exterior. La autenticación de punteros de arm64e es un ejemplo similar.
    • Actualmente no se puede.