Asahi Linux avança em Apple Silicon: hipervisor volta a rodar no M4 e M3 fica perto de release oficial

O projeto Asahi Linux publicou seu relatório de progresso alinhado ao lançamento do Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → 7.2, e a mensagem central é que rodar Linux nativo em MacBooks com Apple Silicon deixou de ser um exercício restrito às gerações M1 e M2. Há avanços concretos em M3, M4 e até bringup inicial de M5, mas cada um veio à custa de contornar barreiras arquiteturais impostas pela Apple.

Para quem desenvolve no Brasil e adotou (ou considera) um Mac M-series como máquina principal, o relatório importa por um motivo prático: define quanto do hardware realmente funciona sob Linux hoje e o que ainda depende de engenharia reversa contínua.

O problema do power management: PSCI sem EL3

A maior trava para melhorar a autonomia de bateria não estava nos blocos de gerenciamento de energia (SMC, PMGR, PMP), e sim nos próprios núcleos de CPU. O kernel arm64 upstream exige que todo gerenciamento de energia de CPU passe pelo PSCI (Power State Coordination Interface), o que impede o Asahi de enviar seu driver cpuidle específico da Apple para o kernel oficial.

O detalhe que trava tudo: o PSCI espera despachar chamadas para firmware rodando em EL3 via instruções SMC ou HVC. Mas, como o time explica, os núcleos da Apple simplesmente não implementam EL3. Com o kernel já em EL2 e nada em EL3 para conversar, não há como usar PSCI da forma padrão.

A saída proposta por Sven é criativa: usar o m1n1 (o bootloader do projeto, que se comporta quase como firmware) como um novo conduit PSCI baseado em UEFI Runtime Services. A leitura é que a especificação do Arm define a API sem amarrar a um conduit específico, listando SMC e HVC apenas como exemplos. O m1n1 reserva sua região de memória como outros blobs de firmware e deixa uma implementação PSCI ativa que o kernel pode chamar de volta, mesmo rodando no mesmo Exception Level. Os patches já estão na lista de discussão do kernel como RFC.

O bug do WFI que derrubava o M4

O gatilho para esse trabalho foi um problema no M4. A especificação Arm manda que núcleos em loop de WFI (Wait For Interrupt) preservem todo o estado, mas isso não é o comportamento padrão no Apple Silicon. Nos SoCs M1 a M3, dava para configurar a retenção de estado por núcleo via chicken bits.

A partir do M4, a Apple passou a definir esses bits no mBoot e travar os registradores que os controlam. Resultado: no M4, chamar WFI faz o núcleo perder o estado e derrubar o que estivesse rodando nele. Yureka identificou isso durante o bringup e adicionou um parâmetro de linha de comando do kernel para configurar o comportamento do loop de idle (incluindo um loop no-op básico), evitando o crash na inicialização inicial antes do driver cpuidle assumir. Esses patches já estão no linux-next.

SPTM: o hipervisor volta a funcionar no M4

O obstáculo mais espinhoso é o Secure Page Table Monitor (SPTM), evolução da Page Protection Layer da Apple. O SPTM isola o gerenciamento de tabelas de página dentro do Guarded Execution Framework (GXF), um conjunto de Exception Levels paralelos ao ARM64 padrão, com um sistema próprio de permissões chamado SPRR.

Em dispositivos modernos, o mBoot carrega o SPTM em GL2 antes do XNU; se o XNU não conseguir contato com o SPTM, ele entra em pânico logo no init. Como o SPTM passou a ser obrigatório para XNU no M4 e superiores, o hipervisor do m1n1, ferramenta essencial para engenharia reversa de novo hardware, ficou totalmente inoperante nessas máquinas.

A solução veio do trabalho antigo de Sven em fazer engenharia reversa de SPRR e GXF: ele ensinou o hipervisor a emular ambos. Isso permite carregar o próprio blob SPTM da Apple do jeito que o XNU espera, fazer uma pequena cirurgia no binário XNU e voltar a monitorar acessos MMIO como nos M1 a M3. O tracing ficou mais lento nessas máquinas, mas, segundo o relatório, não a ponto de inviabilizar. É o que mantém viva a capacidade de dar suporte a hardware novo.

"You have to appreciate the effort Apple puts into security, goes some way to understanding why they won't endorse/support installing an alternative operating system."

djfergus, no Hacker News

M3 quase pronto para release oficial

Para quem tem um Mac M3, esse é o trecho mais concreto. O relatório lista suporte que passou a funcionar:

O ponto de USB 3.0 e Thunderbolt vale destaque técnico: do M3 Pro/Max em diante, a Apple trocou o controlador de porta USB TI CD3217 (ACE2), que ficava no barramento I2C, pelo ACE3, que usa o barramento SPMI. O esforço combinado de mildsunrise e chaos_princess descobriu que o ACE3 tem praticamente o mesmo conjunto de registradores do CD3217, só embrulhado numa interface SPMI. No thread do Hacker News, JLO64, dono de um M3 Pro, resume o sentimento de quem depende desse trabalho:

"When I got my M3 Pro MBP, I got it with the intention of eventually installing Linux on it. In hindsight I seriously underestimated the amount of effort needed for even partial Linux compatibility, which makes me all the more grateful for the work Asahi contributors have put in!"

JLO64, no Hacker News

Com esses marcos, o time anunciou estar "quase pronto" para cortar uma release oficial para M3, com mais detalhes nas próximas semanas.

M4 e M5: NVMe funciona, mas ainda não é para o dia a dia

Além do WFI, M4 e M5 sofriam com uma mudança quebrando o firmware do controlador NVMe no bundle do macOS 15.x. Yureka e Sven implementaram as mudanças no m1n1 e no Linux, e agora há NVMe funcionando em M4 e M5. O PCIe já enumera dispositivos no barramento, e foi corrigido um bug que travava o Linux logo após o boot com mais de um núcleo ativo. Ainda assim, o relatório é claro: pouca coisa mais funciona nesses SoCs, e eles não serão habilitados no Asahi Installer por enquanto.

Decodificação de vídeo esbarra no ecossistema desktop

O Apple Video Decoder (AVD) acelera H.264, H.265 e VP9 em M1/M2, além de AV1 em M3 e superiores, e o suporte a AVC, HEVC e VP9 já funciona de forma majoritariamente confiável. O obstáculo aqui não é a Apple, e sim o Linux: o AVD é um decodificador stateless, o que combina com a API V4L2 Stateless, mas software desktop (navegadores, FFmpeg) historicamente foca em VA-API, NVDEC e VDPAU.

A ponte é uma camada de tradução VA-API para V4L2 Stateless, originalmente da Bootlin e abandonada, retomada num fork de megi e adaptada por sofus. Com ela instalada e uma variável de ambiente configurada, software com suporte a VA-API já usa o AVD. A ressalva: ainda não vem por padrão no Fedora Asahi Remix e não funciona com o sandbox de decodificação do Firefox. No thread, o próprio megous alerta sobre limites dessa abordagem:

"Yeah, you'll find out that va-api is not a good match for v4l2-requests. It does not pass decoded bitstream to the drivers as is, but pre-computes some things for some codecs, while v4l2-requests mostly expects original information parsed from the bitstream."

megous, no Hacker News

O que fica em aberto

Para o desenvolvedor brasileiro avaliando um Mac como estação Linux, a leitura honesta é: M1 e M2 seguem os mais maduros, M3 caminha para suporte oficial, e M4/M5 ainda estão em bringup. A autonomia de bateria, historicamente o calcanhar de Aquiles do Linux em laptops, depende do avanço do PSCI via UEFI Runtime Services, ainda em RFC. Nada disso está finalizado, mas o relatório mostra que os principais bloqueios arquiteturais têm caminho de solução em andamento.

Fontes: Hacker News · Reações no Hacker News