Sobre os Exclaves da Apple

 (medium.com/@randomaugustine)
1 pontos por GN⁺ 2025-03-10 | 1 comentários | Compartilhar no WhatsApp
  • Os Exclaves da Apple são um recurso de isolamento pensado para manter alguns recursos sensíveis em uma área separada mesmo que o kernel XNU seja comprometido, e parte da sua estrutura veio à tona com a publicação do código-fonte do XNU para M4 e A18
  • O XNU é baseado em Mach, mas na prática várias funções do sistema ficam concentradas no mesmo nível de privilégio, funcionando como um kernel monolítico, e os Exclaves se apoiam na linha de aprofundamento defensivo que passa por Secure Enclave, PPL e SPTM
  • Os Exclaves são compostos por domínios e recursos definidos no boot, e o XNU protege por meio de novos tipos de página do SPTM buffers de memória compartilhada, buffers de áudio, sensores, Conclave, serviços e mais
  • O Secure Kernel (SK) roda no mesmo processador de aplicações que o XNU, e indícios no código sugerem possível uso de uma linhagem seL4 e do secure world do ARM TrustZone, embora grande parte da implementação interna não tenha sido divulgada
  • O efeito real de segurança depende de quais componentes forem movidos para os Exclaves, e as imagens de build atuais apontam para o uso em indicadores de segurança de câmera e microfone, parte do Apple Neural Engine, alguns drivers e componentes de comunicação com o Secure Enclave

Kernel monolítico e a evolução do isolamento de segurança da Apple

  • Sistemas operacionais modernos normalmente funcionam com dois domínios de proteção: modo usuário e modo kernel
    • Aplicativos não podem executar diretamente operações com privilégios elevados, como acesso a arquivos ou comunicação de rede, e precisam pedir isso ao kernel por meio de chamadas de sistema
    • O kernel verifica as permissões de acesso e então devolve ao modo usuário resultados como handles que representam arquivos abertos
  • A maioria dos sistemas operacionais usa uma arquitetura de kernel monolítico, na qual o kernel tem acesso irrestrito ao hardware, à memória e a todos os dados do usuário
    • Quanto maior o kernel, maior também a chance de surgirem vulnerabilidades
    • A exploração de falhas no kernel pode levar ao comprometimento de todo o sistema
  • Microkernels podem melhorar o isolamento de segurança ao reduzir as funções internas do kernel e empurrar a maior parte do trabalho para processos separados e sem privilégios
    • As desvantagens continuam sendo problemas de desempenho e maior complexidade do software aplicativo
  • O XNU, compartilhado por iOS, macOS, tvOS, visionOS e watchOS, é baseado no microkernel Mach, mas na implementação várias funções do sistema ficam no mesmo nível de privilégio e, na prática, ele opera como um kernel monolítico

O isolamento de segurança da Apple antes dos Exclaves

  • Em 2013, o iPhone 5s trouxe o Secure Enclave
    • Um sistema operacional baseado em microkernel chamado SepOS roda em um núcleo de CPU dedicado e reforçado
    • O kernel do SepOS é o cL4, uma versão customizada do L4-embedded da Apple
    • Ele é usado para proteger chaves criptográficas e dados biométricos como o Face ID
    • Mesmo que o kernel do iOS seja comprometido, o Secure Enclave em geral não é afetado sem um exploit adicional voltado especificamente a ele
    • Secure Enclave e Secure Exclaves são alvos diferentes
  • Em 2017, no iPhone 8 e iPhone X com A11, foi introduzida a Page Protection Layer (PPL)
    • Ela dá apenas a uma parte do kernel a permissão para modificar tabelas de páginas de memória, impedindo que o restante do kernel faça isso diretamente
    • A superfície de ataque era pequena e desvios eram raros, mas o restante do kernel ainda mantinha muitos privilégios necessários para comprometer dados
  • Entre 2021 e 2023, com o A15 e o iOS 17, o Secure Page Table Monitor (SPTM) substituiu e aprimorou a PPL
    • Ele protege recursos adicionais de memória e isola componentes em unidades menores dentro do kernel
    • A verificação de assinatura de código para confirmar se algo foi assinado pela Apple também foi separada
    • Nesse período surgiram referências indiretas a exclaves no código-fonte do XNU, então interpretadas como um subsistema gerenciado pelo SPTM

A chegada dos Exclaves ao XNU em 2024

  • A publicação do código-fonte do XNU com suporte a sistemas baseados em M4 e A18 revelou parte da estrutura dos Exclaves
    • Isso inclui sistemas como o iPhone 16
    • Em processadores anteriores, os Exclaves não são ativados
  • Exclaves se refere a recursos separados do XNU, projetados para permanecer protegidos mesmo que o kernel seja comprometido
    • Os recursos são definidos previamente no build do sistema operacional
    • São identificados por nome ou ID
    • Têm tipos próprios e são inicializados no boot
    • São organizados em domínios distintos
  • O SPTM protege a memória Exclave contra o XNU usando tipos de página dedicados aos Exclaves
  • Os tipos de recurso já identificados mostram onde surgem os limites entre o XNU e os Exclaves
    • Buffers de memória compartilhada aos quais XNU e Exclave podem acessar juntos
      • Do ponto de vista do XNU, eles podem ser configurados como somente leitura ou leitura e escrita
    • Buffers de áudio e sensores usados na segurança de funções como indicadores de acesso à câmera e ao microfone
    • Conclave e Conclave Manager, que agrupam vários recursos em seu próprio domínio de segurança
    • Serviços capazes de executar código no espaço Exclave quando chamados por threads do XNU

Secure Kernel e secure world

  • Para que serviços Exclave rodem isolados do XNU, a Apple introduziu o Secure Kernel (SK)
  • O arquivo de imagem do SK contém a string de versão “cL4”
    • A estrutura de IPC parece mais próxima do seL4 do que do L4-embedded do cL4 original do SepOS
    • No SK aparecem com frequência termos da família seL4 como capability, frame, untyped memory e minting
    • Em abril de 2024, a Apple anunciou sua entrada na seL4 Foundation
  • Ao contrário do SepOS, que roda em um processador dedicado, o SK executa no mesmo processador de aplicações de alta velocidade que o XNU/iOS
  • Essa arquitetura exige um nível adicional de privilégio do processador, e extensões de virtualização, recursos extras do SPTM da Apple e o TrustZone da ARM são apontados como bases possíveis
    • Há referências no código-fonte do XNU à troca para o secure world do TrustZone
    • A interpretação é de que XNU e iOS rodam no insecure world, enquanto o SK roda no secure world
  • O SK oferece um ambiente operacional restrito a Exclaves, recursos e serviços
    • Isso difere do padrão de projeto de Trusted Applications proposto pela ARM
    • Como a superfície de ataque dos serviços Exclave e do Secure Kernel é limitada, escapar do secure world para comprometer o XNU pode ser muito mais difícil do que atacar diretamente o XNU a partir do insecure world
  • No código-fonte do XNU, a transição para o secure world é chamada de RINGGATE
    • A ideia de que o SPTM gerencia essa transição ainda é especulativa, e essa parte exige análise binária porque não está no código aberto

Domínios, recursos e Conclave

  • Durante o boot, o XNU inicializa uma estrutura de tabelas de kernel em dois níveis para armazenar informações sobre os recursos Exclave detectados
    • A root_table identifica domínios pelo nome
    • Cada domínio aponta para uma tabela de segundo nível com os recursos desse domínio
  • A estrutura de domínios identificada é a seguinte
    • com.apple.kernel
      • Inclui Conclave launcher, serviço de depuração, ExclaveIndicatorController para indicadores de segurança, serviço de log e FrameMint usado no boot do ExclaveKit
      • Também inclui o buffer de memória compartilhada com.apple.storage.backend, usado para que serviços Exclave façam I/O de arquivos no espaço XNU por meio de upcall
      • Inclui um recurso Conclave Manager para cada Conclave
    • com.apple.darwin
      • Não há casos de uso nos componentes de código aberto
    • com.apple.conclave.name
      • Existe um domínio para cada Conclave
      • Pode incluir serviços, buffers de áudio, buffers de memória compartilhada e mais
    • com.apple.driver.*name*
      • A existência é mencionada em comentários como domínios por driver de dispositivo, mas não foi confirmada diretamente no código aberto
  • Conclave é ao mesmo tempo um tipo de recurso capaz de conter vários recursos e uma unidade de segurança que permite acesso compartilhado entre serviços e recursos
    • Uma task Mach tem limitação sobre quais Conclaves pode chamar
    • Cada Conclave tem um Conclave Manager localizado no domínio do kernel
    • O ciclo de vida de um Conclave inclui attach, launch, stop e detach
    • Também existem estados de transição como launching e stopping

Criação, associação e execução de Conclaves

  • O posix_spawn() do XNU pode chamar task_add_conclave() para associar uma task a um recurso Conclave Manager
    • A relação é 1:1
    • Uma task só pode se associar a um Conclave Manager, e o inverso também vale
  • Quem pode fazer spawn de um Conclave é o launchd ou uma task com a entitlement com.apple.private.exclaves.conclave-spawn
    • A entitlement com.apple.private.exclaves.conclave-host parece dar permissão para fazer attach em si mesmo, e não para criar uma nova task
  • O kernel encontra no domínio com.apple.kernel o recurso Conclave Manager associado ao Conclave de destino
    • Em seguida, armazena na estrutura do recurso Conclave um endpoint Tightbeam apontando para o endpoint do Conclave Manager
    • O Tightbeam parece ser um framework de RPC para comunicação entre componentes Exclave
  • A execução de um Conclave precisa ser feita pela task Conclave Manager associada
    • Tentativas de launch ficam bloqueadas até que os Exclaves terminem o boot completo no estado EXCLAVES_BS_BOOTED_EXCLAVEKIT
    • Uma nova Mach trap entra pela função _exclaves_ctl_trap(), e EXCLAVES_CTL_OP_LAUNCH_CONCLAVE é usado para executar um Conclave
    • Em ambiente de produção, um host de Conclave lançado pode entrar em estado tainted, e depois disso um exit() pode causar kernel panic

Nova Mach trap para Exclaves

  • _exclaves_ctl_trap() é a nova Mach trap que trata recursos dos Exclaves
    • Ela executa diferentes ações conforme o parâmetro operation
    • Em geral, valida as entitlements necessárias para a operação chamada
  • EXCLAVES_CTL_OP_BOOT é chamado duas vezes durante o boot do sistema
    • Início do estágio 2 de boot dos Exclaves
    • Boot do ExclaveKit
    • O chamador precisa ser o launchd ou ter a entitlement com.apple.private.exclaves.boot
  • As demais operações principais exigem, no mínimo, que a task atual tenha a entitlement com.apple.private.exclaves.kernel-domain ou seja a task Conclave Manager relacionada
    • EXCLAVES_CTL_OP_LOOKUP_SERVICES: procura serviços no domínio Exclave da task atual e, em caso de falha, consulta os domínios Darwin e kernel conforme a permissão
    • EXCLAVES_CTL_OP_ENDPOINT_CALL: chama o endpoint de um serviço Exclave do domínio da task atual, fazendo a thread atual trocar para o secure world e executar código específico
    • criação de named buffer e copyin/copyout
    • criação de audio buffer e copyout
    • criação de sensor, start, stop e status
    • lookup de recurso de notificação

Downcall e Upcall

  • Downcall é a chamada a um endpoint de serviço Exclave no secure world, e marca o início da execução de código nesse ambiente
  • O downcall troca a thread atual para o secure world e inicia a execução no entry point do código seguro
    • Não é um modelo que delega o trabalho a outra thread
    • A task chamadora precisa ter a entitlement do kernel domain ou ser a task Conclave Manager associada ao Conclave do serviço
    • Um Conclave pode ter até 128 serviços chamáveis
  • O XNU aparentemente agenda a thread no Secure Kernel por meio de sk_enter()
    • É possível que o SK não tenha threads próprias e que o XNU cuide de todo o agendamento das threads do secure world
    • Uma thread em execução no secure world pode passar por ações normais do escalonador como yield, wait, suspend e interrupt
    • Nesses casos, a thread sai do secure world, volta ao contexto do kernel XNU e depois é reagendada no secure world pelo código de escalonamento dos Exclaves
  • A estrutura de IPC do downcall é configurada com buffers de request e response antes da entrada no secure world
    • Interrupções e preempção são desativadas enquanto a estrutura final de request é preparada e sk_enter() é chamado
    • Isso ocorre porque essa estrutura existe apenas uma vez por núcleo de CPU
    • A resposta do downcall pode voltar no buffer de resposta por núcleo de outra CPU por causa de interrupções, upcall, yield ou reagendamento
  • Upcall é o mecanismo pelo qual uma thread executando no secure world chama o handler de upcall dos Exclaves via Tightbeam quando precisa de ajuda do XNU
    • Ele é limitado a funções específicas permitidas do XNU
    • Uma thread em upcall não pode voltar ao modo usuário
    • Também não pode reentrar fazendo um novo downcall para o secure world
    • A thread precisa retornar ao contexto do secure world exatamente no ponto em que executou o upcall
  • As categorias de upcall identificadas no código são memória, armazenamento de arquivos, DriverKit, DriverKit Apple Neural Engine e controle de Conclave

XNUProxy e estágios de boot

  • Há muitas referências ao XNUProxy, mas sua localização e função exatas ainda não estão definidas
    • Pode ser um domínio Exclave independente
    • Pode ser um serviço ou conjunto de serviços no domínio com.apple.kernel que trata downcalls específicos
    • Também pode ser um subsistema do SPTM responsável por fazer downcalls para o secure world
  • Um comentário em Exclaves_L4.h diz que o XNU Proxy torna vários Exclaves reachable
    • template de app de usuário
    • driver de áudio
    • ExclaveDriverKit
    • SecureRTBuddy para Always On Processor e Display Coprocessor
    • controle de Conclave, depuração de Conclave e mais
  • O boot dos Exclaves exige coordenação entre insecure world e secure world, e quando há problemas normalmente o resultado é panic()
  • O boot é dividido em três estágios
    • O estágio 1 não aparece no código aberto e pode ser o processo de secure boot que carrega o SK na memória, valida sua assinatura de código e o torna executável
    • O estágio 2 executa inicialização do servidor de upcall, coleta de informações de boot do secure kernel, inicialização do scheduler Exclave, inicialização da kext XrtHostedXNU, inicialização multicore, inicialização do XNU Proxy, descoberta de recursos Exclave estáticos e criação de endpoints de Conclave Manager
    • O estágio 3 encontra o serviço com.apple.service.FrameMint, executa chamadas relacionadas a framemint_framemint__init() e framemint_framemint_populate(), e então entra no estado EXCLAVES_BS_BOOTED_EXCLAVEKIT

Tipos de memória do SPTM e limitações restantes

  • O SPTM atribui tipos às páginas de memória para controlar acesso por subsistema
    • Entre os tipos existentes estão XNU_USER_EXEC, XNU_USER_DEBUG, XNU_USER_JIT, XNU_ROZONE, XNU_KERNEL_RESTRICTED e tipos relacionados a TXM e DART
  • Os Exclaves adicionam novos tipos relacionados ao SK
    • SK_DEFAULT: exclusivo do SK, sem acesso pelo XNU
    • SK_IO: exclusivo do SK, sem acesso pelo XNU
    • SK_SHARED_RO: compartilhado entre SK e XNU, mas o XNU só pode ler
    • SK_SHARED_RW: compartilhado entre SK e XNU, e o XNU pode ler e escrever
  • Os Exclaves podem ser vistos como um grande investimento para adicionar defence in depth aos sistemas operacionais da Apple
    • Eles isolam recursos sensíveis e reduzem a superfície potencial de ataque
    • A ideia é diminuir o impacto de um comprometimento único do kernel
  • Ainda não foi analisado diretamente quais componentes estão de fato migrando do kernel para os Exclaves
    • As imagens de build apontam para o uso em indicadores de segurança de câmera e microfone, parte das funções do Apple Neural Engine, alguns drivers de dispositivo e componentes que se comunicam com o Secure Enclave
    • Mais componentes podem migrar para os Exclaves no futuro
    • A área do XNU fora dos Exclaves continua sendo alvo de ataque
  • A análise se baseia no Apple Open Source XNU build 11215
    • A localização exata de ExclaveKit, ExclaveDriverKit e XNUProxy, a forma como o XNU faz a transição para o secure world, o Secure Kernel e o userspace do secure world continuam sendo áreas que exigem análise adicional

Leituras relacionadas

1 comentários

 
GN⁺ 2025-03-10
Opiniões no Hacker News

  • Os SoCs recentes de celulares e notebooks da Apple incluem suporte de hardware a virtualização aninhada, incluindo o iPad Pro M4, que usa um exclave para o LED da câmera
    Espero que a próxima revisão do guia Apple Platform Security trate do SK exclave e das mitigações na baseband para detecção de radar por Wi‑Fi: https://help.apple.com/pdf/security/en_US/apple-platform-sec...
    Sobre os recursos adicionais do SPTM da Apple, também há um texto de engenharia reversa do SPTM: https://www.df-f.com/blog/sptm3
    O XNU está sendo refatorado para uma estrutura inspirada em microkernel, com a direção de reduzir a base de código e mover para fora operações sensíveis de segurança. O isolamento do espaço de memória é ajudado pelo Secure Page Table Monitor (SPTM), enquanto tarefas como assinatura de código, verificação de permissões, Developer Mode e Restricted Execution Mode ficam a cargo do Trusted eXecution Monitor (TXM)
    Há mais de 150 CVEs relacionados ao TrustZone: https://www.cve.org/CVERecord/SearchResults?query=trustzone
    O Google também implementou há alguns anos, no Pixel, o pKVM, que usa virtualização aninhada em hardware, e até colocou no Linux mainline código para reduzir de forma cooperativa os privilégios do TrustZone em relação ao L0 do pKVM. No entanto, fora a VM Debian “Linux Terminal”, não anunciou recursos de defesa que aproveitem pKVM/AVF

    • A maior parte dos CVEs de TrustZone está relacionada a software vulnerável que os fabricantes colocaram no ambiente protegido pelo TrustZone. Entre esses softwares há muita coisa péssima, e há pouquíssimos relatos de vulnerabilidades no hardware em si
    • O autor publicou um texto de acompanhamento e um diagrama corrigido: https://randomaugustine.medium.com/more-speculation-on-excla...
      No começo ele especulava sobre o uso de TrustZone, mas parece que o exclave também pode usar o SPTM existente e o nível de privilégio GXF (Guarded Execution). Se for o caso, excluindo os requisitos de RAM e o esforço de desenvolvimento, pode não haver um motivo fundamental para não dar suporte também no iPhone 13 ou posterior. Claro, certamente seria um trabalho enorme até para a Apple

  • Steve parecia acreditar sinceramente que “o notebook é o diário pessoal” de uma pessoa, e que a Apple tinha a responsabilidade de protegê-lo
    Acho que Tim também não teria se tornado CEO se não tivesse a mesma crença que Steve. Soa estranho, mas sinto muita falta do Steve
    https://www.youtube.com/watch?v=Ij-jlF98SzA

    • Do ponto de vista de quem fabrica equipamentos industriais e científicos, os dispositivos da Apple voltados ao consumidor são completamente inúteis. Parece um desperdício trancar dessa forma dispositivos de computação suficientemente capazes
      Também não gosto da forma como a Apple controla o mercado de dispositivos e software mesmo depois que a posse do aparelho muda. Evito completamente esse ecossistema e não entendo por que tantos supostos “hackers” ficam entusiasmados com sistemas cujo capô foi soldado para ficar fechado
    • Jobs era polarizador e muitas vezes ríspido; para começo de conversa, dá até para se perguntar por que deveríamos sentir falta de um bilionário da tecnologia. Ainda assim, sinto que devo algo a Jobs e às pessoas da Apple que contribuíram para criar produtos de que gosto, como Mac, iPod e iPad
      Muitas coisas que Jobs disse ainda ressoam comigo. Recentemente a Apple lançou o protetor de tela “classic Mac”, que mostra como a GUI original do Mac foi projetada com cuidado. Ninguém sente saudade da época em que um bug de aplicativo derrubava o sistema operacional, mas eu gostaria que a Apple ainda fosse tão obsessiva com detalhes quanto naquela época
    • Ao ver os sentimentos sinceros em relação a Jobs, fico me perguntando se algo parecido entra em ação quando as pessoas usam e vivenciam LLMs
      Falando de forma um pouco direta, parece haver nisso um elemento místico ou religioso. Dá a impressão de uma ânsia por milagres, oráculos, produtos e rituais belos, e por um homem bondoso quase divino que ofereça um futuro polido, abundante e eterno. É como se uma espécie de “buraco” espiritual fosse preenchido
      Não quero depreciar quem sente simpatia por Jobs ou por LLMs; estou apenas compartilhando uma observação
    • Entendo que o texto sobre exclaves tenha feito você pensar em Steve, mas não sei bem como uma coisa levou à outra. Fico curioso se você poderia explicar

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

    • Pelo resumo daquele texto, um exclave significa recursos específicos separados do XNU, o kernel principal, e explica que eles não podem ser acessados mesmo que o kernel seja comprometido
      Também diz que não é incomum que releases intermediários do macOS tragam recursos que preparam a próxima versão major, e que o recurso mais fundamental e importante adicionado ao Sonoma 14.4, iOS 17.4, iPadOS 17.4 e watchOS 10.4 pode ser o exclave
      https://eclecticlight.co/2024/08/20/sonomas-unfinished-busin...

  • Usar um enclave seguro para controlar o LED físico da câmera é bem surpreendente, e parece uma arquitetura excessivamente complexa para uma tarefa simples
    Parece que bastaria colocar uma lógica de hardware dedicada bem pequena no módulo da câmera. Seria só fazer gate da E/S digital ou da alimentação da câmera e incluir um pulse stretcher para manter o LED aceso por pelo menos alguns segundos a cada vez, evitando ataques que liguem e desliguem rapidamente a lógica da câmera
    Seria bom ter um circuito semelhante para o microfone e um LED físico de outra cor. Apenas um ponto exibido por software na tela não é suficiente

    • É mais complexo do que parece. “Câmera” é um conjunto de vários componentes. Você talvez quisesse usar a alimentação do sensor CMOS como referência, mas há vários estágios de energia, como espera, economia de energia e ocioso. Então é bem provável que um circuito de hardware precise saber não só a tensão, mas também a corrente. Ou talvez precise, em um nível mais alto, fazer parsing de mensagens como I2C para ler mudanças no modo de energia
      O driver do LED também precisa saber o brilho da tela ou informações do sensor de luz ambiente. Ele precisa ser brilhante o suficiente para ser visível sob luz solar direta, mas esse brilho pode ser incômodo em ambientes escuros e até atrapalhar o uso normal da câmera
      Se você acredita que o SK é seguro, usá-lo é mais simples e pode funcionar melhor. Se você acha que o SK não é seguro, então todos os pressupostos desmoronam de qualquer forma
    • Não é uma arquitetura excessiva. Ela é necessária por causa desta pesquisa e dos resultados de outros pesquisadores, como Charlie Miller
      Em geral, a Apple não torna as coisas complexas deliberadamente sem um bom motivo
      https://news.ycombinator.com/item?id=42260379
    • Fico me perguntando se é excesso de engenharia ou uma solução para algo que eles descobriram ao despachar uma quantidade enorme de celulares. Eu não pensava na câmera como vetor de segurança, mas talvez a Apple pense
    • Há mais contexto relacionado aqui: https://news.ycombinator.com/item?id=42260379
    • Parece envolver não só o LED da câmera, mas também os indicadores na tela, como os pontos laranja, verde e azul que aparecem na barra de menus quando um app acessa o microfone, a câmera ou a gravação de tela

  • Fico curioso para saber quem é o autor. É um texto muito sofisticado e bem escrito e, mesmo para quem vinha acompanhando exclaves, está muito bem organizado

  • Fico curioso sobre como isso se compara ao Virtualization Based Security do Linux
    Segundo a página com o vídeo, esse recurso de segurança pode fortalecer o kernel e garantir que recursos importantes do kernel não sejam adulterados mesmo que o kernel seja comprometido. O VBS usa virtualização de hardware e o hipervisor Hyper‑V para criar um ambiente virtual isolado que opera em um nível de confiança mais alto, o Virtual Trust Level 1 (VTL1), e o VTL1 tem seu próprio kernel, separado do kernel Guest: o Secure Kernel
    https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

    • Exclaves rodam em um nível de confiança paralelo

  • Exclave é importante, mas parece uma etapa intermediária. A Apple está tornando o XNU menos arriscado, mas ainda está agindo de forma defensiva, em vez de adotar completamente uma arquitetura de microkernel
    Se eu tivesse que apostar, diria que exclaves são uma ponte para uma mudança maior. Pode ser um sistema operacional mais modular, como o Fuchsia, ou um modelo de segurança no estilo CHERI, que impõe segurança de memória no nível de hardware
    A Apple está à frente em segurança de sistemas operacionais de consumo, mas exclave parece mais uma melhoria em forma de patchwork do que o resultado de repensar completamente o desenho do sistema. Ainda assim, provavelmente é a maior mudança de segurança no design de sistemas operacionais mainstream na última década, e levará anos até que seu impacto total apareça

    • Parece uma volta ao estilo dos microkernels antigos, só que refletindo soluções modernas e novos requisitos
      Quando o Mach foi criado, segurança não era uma preocupação tão grande quanto hoje. As máquinas atuais ficaram tão potentes que talvez o overhead criado pela comunicação entre processos de um microkernel tenha se tornado desprezível

  • Não estou familiarizado com conteúdo nesse nível, mas, pelo que parece, seria possível atacar o próprio enclave e escalar para privilégios mais altos que os do kernel. Fico me perguntando se esse pedaço de hardware é algo como um coprocessador

    • Exclave não é hardware; é software isolado que lida com determinadas tarefas sensíveis às quais o kernel não deveria ter acesso
      Portanto, se você o explorar, de fato ganha permissões de acesso que o kernel não tem. Mas é exatamente essa a intenção. O objetivo é impedir que, mesmo se o kernel for comprometido, essa área sensível seja acessada

  • Segundo a documentação da Apple, o SPTM não é usado, então fico curioso sobre como isso afetará a segurança do macOS: https://support.apple.com/guide/security/operating-system-in...
    Por enquanto, coisas como o exclave existente que mostra o indicador da câmera provavelmente não se aplicam muito ao macOS, já que o MacBook tem hardware dedicado para isso. Mas, no futuro, podem surgir exclaves que também se apliquem ao macOS

    • É preciso reler essa nota de rodapé. Ela diz que o Page Protection Layer (PPL) e o Secure Page Table Monitor (SPTM) impõem a execução de código assinado e confiável em todas as plataformas, exceto no macOS. Isso porque o macOS foi projetado para executar código arbitrário. Outras propriedades de segurança, incluindo proteção de tabelas de páginas, existem em todas as plataformas compatíveis
      Ou seja, não significa que o macOS não use SPTM. Significa que o macOS não usa o SPTM para impedir a execução de código não assinado. Isso porque o macOS precisa permitir que o usuário execute código não assinado depois de passar por algumas etapas

  • Fico curioso se desenvolvedores de apps podem usar Exclaves. É frustrante quando a Apple cria internamente recursos novos incríveis e os bloqueia completamente para desenvolvedores. Como resultado, coisas como apps de banco, carteiras e mensageiros seguros continuam tendo que rodar no espaço de usuário, que é menos seguro

    • Não necessariamente. O espaço de usuário da Apple também vem ficando cada vez mais seguro
      Como exemplo simples, o macOS recente executa todos os apps dentro de um sandbox, mesmo que o app não opte explicitamente por isso. Esse sandbox impede que apps modifiquem os arquivos uns dos outros, algo que antes era uma grande fraqueza do sistema de segurança. Isso porque a assinatura do bundle era verificada apenas na primeira execução, e não a cada execução
    • Pelo que entendo, com o design atual isso não é possível. Exclaves são integrados ao sistema operacional inteiro e iniciados como parte do processo de boot, então são relativamente estáticos. Por motivos de segurança, é bem provável que as relações entre esses componentes também sejam definidas estaticamente
      Hoje também é uma estrutura kernel-a-kernel, então, se houvesse suporte a terceiros, provavelmente ficaria limitado a algo como implementar drivers de dispositivos de segurança. Mas a Apple vem tentando empurrar drivers de terceiros para o espaço de usuário, não para o hipervisor. Considerando que essa transição ocorre em paralelo ao desenvolvimento de exclaves, não parece provável que ela vá mudar de direção para permitir que desenvolvedores de drivers de terceiros usem exclaves
      É comum a Apple estabilizar muito mais internamente esse tipo de recurso de plataforma imposto pelo kernel antes de abri-lo ao público. A autenticação de ponteiros do arm64e é um exemplo parecido
    • Atualmente, não