Su tutte le macchine con chip della serie M3 funzionano ora webcam, microfoni integrati, USB 3.0 e Thunderbolt. Lo scrive il progetto Asahi Linux nel suo ultimo rapporto sui lavori in corso, che raccoglie mesi di reverse engineering su tre fronti distinti: il completamento del supporto M3, il risparmio energetico dei core applicativi e il recupero dell’hypervisor sulle macchine M4. Il supporto vive per ora nei rami downstream del progetto, non nel kernel Linux ufficiale.
Il progetto si dice ormai vicino a una release con il supporto M3 funzionante per chi usa il codice downstream, con altri dettagli attesi nelle prossime settimane; portare lo stesso lavoro nel kernel ufficiale richieder� parecchio pi� tempo, perch� ogni pezzo va proposto e discusso in upstream. In lavorazione c’� anche il direct scan-out per la GPU, che per� non � ancora nelle condizioni di essere consegnato agli utenti.
Le modifiche introdotte da Apple sulla serie M3 sono in larga parte incrementali. Il processore di segnale d’immagine della webcam � rimasto quasi identico, salvo un messaggio di inizializzazione saltato sul solo M3 Max: chaos_princess ha aggiunto il supporto per quel caso al driver Linux, e con quello la webcam funziona su tutti i dispositivi M3 che ne montano una. I microfoni integrati hanno richiesto un lavoro simile: la serie M3 introduce un decimatore ad alta frequenza che vuole un nuovo set di coefficienti e un messaggio di inizializzazione ben pi� corposo.
Il blocco ATCPHY, che negozia le connessioni USB3, DisplayPort e Thunderbolt sulle porte USB Type-C, ha richiesto una nuova sequenza di valori di taratura in fase di inizializzazione, conseguenza del passaggio al nodo produttivo N3 di TSMC. Il cambiamento pi� sostanzioso riguarda invece il controller delle porte USB. Da M1 fino all’M3 base Apple usava un controller Texas Instruments su misura, il CD3217 (o ACE2), collegato al bus I2C; a partire da M3 Pro e M3 Max � passata ad ACE3, che parla sul bus SPMI. Il reverse engineering di mildsunrise e chaos_princess ha mostrato che ACE3 ha in pratica lo stesso set di registri del predecessore, solo avvolto in un’interfaccia SPMI invece che indirizzato via I2C.
Il risparmio energetico dei core e il vincolo PSCI
Il modo pi� elementare per mettere a riposo un core ARM � l’istruzione WFI, che ferma l’esecuzione fino all’arrivo di un interrupt lasciando per� il core alimentato e con il suo stato intatto. I core Apple offrono una variante profonda della stessa istruzione, che spegne molto di pi� a costo di perdere lo stato: il driver cpuidle di Asahi configura WFI in quella modalit�, salva lo stato del core e poi entra nel ciclo di attesa. Quel driver non pu� finire nel kernel ufficiale, perch� i manutentori del codice arm64 impongono che tutto l’hardware upstream gestisca l’alimentazione dei core attraverso PSCI, l’interfaccia standard con cui il sistema operativo chiama funzioni implementate dal firmware di sistema.
PSCI prevede che quelle chiamate viaggino su canali precisi, e il kernel ne supporta due: le istruzioni SMC e HVC, entrambe pensate per cedere l’esecuzione a un livello di eccezione pi� alto. Linux gira in EL2 e si aspetta di trovare il firmware in EL3, che sui core Apple non esiste. La via d’uscita passa da m1n1, il bootloader del progetto, che sulle installazioni reali carica U-Boot proprio per sfruttarne l’implementazione UEFI: Sven ha modificato m1n1 perch� si riservi una regione di memoria e vi lasci dentro un’implementazione PSCI, raggiungibile dal kernel attraverso i Runtime Services UEFI invece che con un salto a un livello di eccezione superiore. La lettura � che la specifica pubblicata da Arm definisce l’API senza legarla a un canale specifico, e cita SMC e HVC solo come esempi. Le patch che abilitano il meccanismo sono gi� sulla mailing list come RFC.
Su M4 la WFI fa perdere lo stato al core
La specifica ARM prevede che un core in ciclo WFI conservi tutto il suo stato, ma su Apple Silicon quello non � il comportamento predefinito. Dalle serie M1 a M3 la ritenzione si configura core per core tramite bit di controllo a basso livello, i cosiddetti chicken bits. Con la serie M4 Apple li imposta in mBoot e poi blocca i registri che li governano: m1n1 ha marginalmente meno lavoro da fare, ma il comportamento dei core non � pi� regolabile in modo fine. Il risultato � che su M4 chiamare WFI fa perdere lo stato al core e manda in crash quello che ci girava sopra.
Il problema � emerso durante il lavoro di portabilit� su M4, e Yureka ha aggiunto un parametro da riga di comando del kernel che rende configurabile il comportamento del ciclo di idle, fino al semplice ciclo a vuoto. La modifica evita il crash nelle prime fasi di inizializzazione, prima che il driver cpuidle sia stato caricato; quando il driver subentra, salva lo stato che andrebbe perso e solo dopo emette la WFI. Le relative patch sono gi� in linux-next.
SPTM e il ritorno dell’hypervisor su M4
Sul fronte della sicurezza, Apple ha spostato la gestione della memoria fuori dal kernel. Il Page Protection Layer, introdotto anni fa in XNU, isolava via hardware la gestione delle tabelle delle pagine dal resto del kernel, e ha funzionato bene finch� gli attaccanti non hanno trovato il modo di entrarci e di ottenere accesso completo al sistema. Da l� � nato il Secure Page Table Monitor, che prende PPL e lo colloca dentro il Guarded Execution Framework, un insieme di livelli di eccezione paralleli a quelli standard di ARM64, dotato di un sistema di permessi sulle tabelle delle pagine tutto suo, SPRR.
All’avvio, iBoot o mBoot verificano se il payload configurato � un’immagine XNU: in quel caso caricano prima SPTM in GL2, che imposta le tabelle delle pagine e si riserva il controllo della gestione della memoria. XNU parte dopo e vi dialoga attraverso un ulteriore protocollo IPC; se non riesce a contattare SPTM va in panic prima ancora di completare l’inizializzazione. Poich� SPTM � obbligatorio per XNU da M4 in poi, l’hypervisor di m1n1 su quelle macchine era inservibile: caricando XNU senza SPTM il sistema andava in crash, e presentando m1n1 a mBoot come binario XNU andava in crash m1n1, incapace di gestire la memoria come gli serve.
Sven ha insegnato all’hypervisor a emulare GXF e SPRR, sulla base del reverse engineering fatto agli albori del progetto. m1n1 pu� cos� caricare il blob SPTM di Apple esattamente nel modo in cui XNU se lo aspetta, sistemare quanto basta il binario di XNU, caricarlo e poi osservare gli accessi MMIO di entrambi come gi� avveniva da M1 a M3. Il tracciamento su queste macchine � pi� lento, ma non al punto da risultare inutilizzabile, e con questo la strada per portare Linux sull’hardware nuovo resta aperta.
Delle tre linee di lavoro una sola ha gi� toccato l’albero del kernel: il parametro sul comportamento dell’idle � in linux-next, mentre le patch per il canale PSCI su Runtime Services UEFI restano una RFC sulla mailing list. Tutto il resto vive nei rami del progetto, dove il lavoro su M4 e M5 prosegue.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
