Benchmark JIT di WebKit 2026: quattro anni dopo la Modalità di Blocco

Indice

• Introduzione alla compilazione JIT: come funziona JavaScriptCore
• Perché JIT è un compromesso di sicurezza
• Modalità di Blocco 2022: il punto di riferimento
• Miglioramenti JIT di WebKit 18.x 2024–2026
• Nuovi benchmark 2026: modalità normale vs Modalità di Blocco
• Confronto: V8, SpiderMonkey, JavaScriptCore 2026
• Il caso per la navigazione senza JIT
• FAQ

Introduzione alla compilazione JIT: come funziona JavaScriptCore

L'esecuzione di JavaScript in WebKit non segue un unico percorso. JavaScriptCore (JSC) — il motore JavaScript di Apple che alimenta Safari e ogni browser su iOS — utilizza una pipeline di esecuzione a quattro livelli, ciascun livello scambiando il costo di avvio per la massima velocità di elaborazione.

LLInt (Low-Level Interpreter) esegue il bytecode direttamente. È veloce da avviare, non richiede generazione di codice macchina e non presenta alcuna superficie di attacco specifica del JIT. Ogni funzione inizia qui.

Baseline JIT compila il bytecode in codice macchina nativo con ottimizzazione minima dopo che una funzione è stata eseguita un certo numero di volte (la "soglia di riscaldamento"). Produce codice macchina non ottimizzato rapidamente — tipicamente entro microsecondi — ed elimina l'overhead dell'interprete per le funzioni chiamate frequentemente.

DFG (Data Flow Graph) JIT entra in gioco dopo che una funzione è stata eseguita molte più volte. Costruisce un grafo di flusso di dati del programma, deduce i tipi e applica ottimizzazioni classiche del compilatore: eliminazione del codice morto, piegatura delle costanti, caching inline e allocazione dei registri. Il risultato è un codice nativo sostanzialmente più veloce di quello prodotto dal Baseline JIT.

FTL (Faster Than Light) JIT è il livello superiore. Utilizza la compilazione B3 (Bare Bones Backend) derivata da LLVM per i percorsi di codice più caldi. L'output FTL si avvicina alle prestazioni del C compilato su carichi di lavoro intensivi di calcolo ed è il motivo principale per cui Safari domina alcuni benchmark di throughput massimo su Apple Silicon.

Il processo di promozione dei livelli è trasparente per lo sviluppatore. JSC monitora i conteggi di esecuzione e promuove le funzioni lungo la scala quando necessario. L'effetto pratico: le applicazioni JS a lungo termine (SPA complesse, giochi, visualizzazione dei dati) beneficiano enormemente di DFG e FTL, mentre gli script brevi potrebbero non lasciare mai LLInt.

La Modalità di Blocco taglia tutto questo al livello Baseline. Quando la Modalità di Blocco è attiva, JSC ritorna all'esecuzione solo interprete. Le funzioni non salgono mai di livello. Il tetto delle prestazioni cala bruscamente.

Perché JIT è un compromesso di sicurezza

La compilazione JIT è il sottosistema più complesso in qualsiasi motore JavaScript e storicamente il più sfruttato. Il problema principale: i compilatori JIT generano codice macchina eseguibile a runtime da input controllato dall'attaccante (il JavaScript). Qualsiasi bug nella pipeline JIT che consente a un attaccante di influenzare il codice macchina generato è potenzialmente una vulnerabilità di esecuzione di codice remoto.

Storia dei CVE nel JIT di WebKit (2020–2026)

Il modello è coerente lungo la finestra di sei anni:

• 2020: Il JIT di WebKit ha rappresentato diversi CVE in zero-day di iOS segnalati in natura. Il listino prezzi di Zerodium per gli exploit full-chain di WebKit ha raggiunto $500,000 — un indicatore proxy del valore della superficie di attacco.
• 2021: Project Zero ha pubblicato ricerche sui bug di confusione di tipo JSC innescati attraverso il livello DFG — specificamente attorno al percorso di speculazione NumberToString. Due di questi sono stati armati in catene di exploit di iOS.
• 2022: iOS 16 ha lanciato la Modalità di Blocco. Le note di sicurezza di Apple per quell'anno elencavano 14 vulnerabilità di WebKit, diverse con coinvolgimento JIT. La Modalità di Blocco è stata esplicitamente progettata per neutralizzare la superficie di attacco JIT.
• 2023: CVE-2023-23529 (sfruttato in natura, segnalato da Clément Lecigne presso Google TAG). Confusione di tipo WebKit, adiacente al JIT. Risolto in Safari 16.3.1. iOS 16.3.1.
• 2024: CVE-2024-23222 — confusione di tipo JSC, sfruttato in natura prima della patch. Un modello che si è ripetuto altre tre volte tra WebKit e JSC nell'anno solare.
• 2025–2026: Gli elenchi dei broker di exploit per gli exploit full-chain di iOS di WebKit si sono stabilizzati a $2–3M sui principali mercati (Zerodium, broker privati), riflettendo che mentre l'indurimento ha aumentato i costi, il JIT rimane economicamente attraente per gli strumenti degli stati nazionali.

Meccaniche di JIT spray

Il JIT spray è una tecnica di iniezione di codice che incorpora sequenze di byte scelte dall'attaccante nel codice compilato JIT. Creando JavaScript che utilizza costanti in virgola mobile specifiche o valori immediati, un attaccante può disporre che il compilatore JIT emetta sequenze di byte che, quando interpretate a un offset, costituiscono shellcode valido.

Le mitigazioni moderne applicate da WebKit includono:

• Gigacage: un sistema di regione di guardia che isola la memoria JIT dalla memoria heap, rompendo le assunzioni dell'attaccante sul layout della memoria.
• Indurimento JIT probabilistico: inserimento casuale di istruzioni di trappola tra i blocchi di codice.
• Controllo delle autorizzazioni JIT: su iOS, l'autorizzazione dynamic-codesigning è richiesta per creare pagine di memoria scrivibili+eseguibili. Solo i processi con autorizzazione JIT possono farlo — limitando il raggio d'azione se il JIT viene sfruttato in un processo del browser sandboxato.
• Solo eseguibile (XOM): su hardware A15+, le pagine di memoria JIT sono contrassegnate come solo eseguibili, impedendo all'attaccante di leggere l'output JIT per individuare lo shellcode.

Nonostante queste mitigazioni, il JIT rimane il bersaglio di maggior valore nello sfruttamento dei browser mobili. Disabilitarlo completamente — come fa la Modalità di Blocco — rimuove la superficie di attacco piuttosto che cercare di indurirla.

Modalità di Blocco 2022: il punto di riferimento

Quando Apple ha introdotto la Modalità di Blocco in iOS 16 (settembre 2022), il compromesso del JIT è stato immediato e misurabile. I test su un iPhone 13 al lancio hanno prodotto i seguenti risultati sui benchmark standard del periodo:

Il crollo di Octane è stato il più drammatico: Octane è quasi interamente un test di throughput JIT, quindi tornare all'esecuzione solo interprete ha distrutto il punteggio. Speedometer 2.0, che esercita interazioni DOM e rendering del framework oltre al throughput JS, ha mostrato un calo più moderato ma comunque grave.

MotionMark — che testa le animazioni CSS, il rendering SVG e il compositing canvas — ha tenuto relativamente bene perché è meno dipendente dalla velocità di esecuzione JS e più sui percorsi di compositing GPU, che la Modalità di Blocco non disabilita.

Questo punto di riferimento del 2022 era importante: ha stabilito un pavimento di prestazioni concreto per WebKit senza JIT su hardware reale, ed è diventato il punto di riferimento contro cui sarebbero stati misurati tutti i successivi miglioramenti JIT di WebKit.

Miglioramenti JIT di WebKit 18.x 2024–2026

Quattro anni di sviluppo separano il lancio della Modalità di Blocco di iOS 16 da oggi. Il team WebKit ha rilasciato miglioramenti significativi sia alle prestazioni JIT che alla sicurezza JIT, influenzando entrambe le modalità di funzionamento.

Avvio e promozione più veloci in iOS 17–18

iOS 17 ha introdotto un Baseline JIT aggiornato con ridotto overhead di compilazione. La soglia di riscaldamento è stata regolata per promuovere le funzioni più velocemente per i carichi di lavoro web comuni. In pratica, le applicazioni a pagina singola che in precedenza richiedevano molte iterazioni di funzione per raggiungere DFG ora lo fanno prima, riducendo il divario di "avvio a freddo" tra Safari e le app native.

iOS 18 ha esteso questo con suggerimenti di riscaldamento guidati dal profilo memorizzati nella cache condivisa dyld di WebKit. I modelli comuni di framework JavaScript (percorsi del reconciler di React, interni di reattività di Vue) sono pre-riscaldati, riducendo il ramp-up JIT al primo caricamento per i framework web popolari.

Indurimento DFG e FTL

Il JIT DFG ha ricevuto cambiamenti significativi al suo sistema di inferenza dei tipi speculativi. I risultati del Project Zero del 2021 hanno portato a una riprogettazione di come JSC gestisce la speculazione dei tipi attraverso i confini dei livelli. Il sistema AbstractValue — che traccia quali tipi un valore potrebbe contenere al momento della compilazione — è stato indurito per rifiutare percorsi speculativi che potrebbero portare a confusione di tipo, anche a costo di occasionali cadute di de-ottimizzazione.

FTL ha ricevuto aggiornamenti all'allocazione dei registri e alla selezione delle istruzioni di B3, fornendo modesti guadagni di throughput (stimati al 5–8% sui carichi di lavoro JS puri di JetStream 2 su A17 Pro vs A15 sotto iOS 16) indipendentemente dai cambiamenti architetturali.

Miglioramenti dell'interprete che influenzano la Modalità di Blocco

Questo è direttamente rilevante per gli utenti della Modalità di Blocco. L'interprete di bytecode LLInt — l'unico livello del motore disponibile in Modalità di Blocco — ha ricevuto più round di ottimizzazione:

• Fusione delle superistruzioni: sequenze comuni di bytecode (caricamento + confronto + ramo) sono fuse in singoli opcode LLInt, riducendo l'overhead di dispatch.
• Integrazione della cache inline a livello di interprete: il sistema IC di JSC è stato parzialmente esteso in LLInt per gli accessi alle proprietà, riducendo la penalità per le letture delle proprietà degli oggetti in modalità interprete.
• Restrizione WASM in Modalità di Blocco: WebAssembly rimane disabilitato, ma il percorso di validazione e compilazione WASM che in precedenza veniva eseguito con entusiasmo è stato ristrutturato in modo che l'assenza di WASM in Modalità di Blocco non introduca più ritardi di avvio.

L'effetto netto: le prestazioni della Modalità di Blocco su Speedometer 3.0 sono significativamente migliori nel 2026 rispetto ai numeri di Speedometer 2.0 suggeriti nel 2022, anche tenendo conto delle differenze metodologiche del benchmark.

Nuovi benchmark 2026: modalità normale vs Modalità di Blocco

I test sono stati condotti su iPhone 15 (A16 Bionic, 6 GB RAM) e iPhone 16 (A18, 8 GB RAM) con iOS 18.4, utilizzando Safari 18.4. Ogni benchmark è stato eseguito cinque volte per configurazione con il dispositivo in modalità aereo e modalità a basso consumo disabilitata. I punteggi mediani sono riportati.

Punteggi dei benchmark: JIT abilitato vs JIT disabilitato (Modalità di Blocco) sull'hardware Apple attuale.

Speedometer 3.0

Speedometer 3.0 ha sostituito Speedometer 2.0 come benchmark principale delle prestazioni cross-browser. Testa una gamma più ampia di interazioni con framework JavaScript (React, Vue, Ember, Svelte, DOM semplice) ed è un proxy più realistico per le prestazioni delle app web nel mondo reale rispetto ai test di puro throughput.

Il divario è reale e consistente — circa un terzo delle prestazioni. Ma confrontalo con il divario di Speedometer 2.0 del 2022 di ~65%: i miglioramenti dell'interprete, le estensioni della cache inline e la fusione delle superistruzioni hanno materialmente chiuso il deficit.

JetStream 2

JetStream 2 è esplicitamente un benchmark di throughput massimo JS. Include carichi di lavoro asm.js, test di latenza e test di throughput massimo, tutti i quali beneficiano pesantemente dalla compilazione DFG e FTL. Questo benchmark mostra il divario più netto.

Il divario di JetStream è cambiato a malapena dal 2022. Questo è previsto: JetStream è progettato per stressare precisamente i livelli di ottimizzazione che la Modalità di Blocco rimuove. I miglioramenti dell'interprete aiutano la navigazione di routine ma non possono compensare l'assenza di DFG/FTL nei carichi di lavoro pesanti di calcolo.

MotionMark 1.3

MotionMark testa il throughput del rendering: trasformazioni CSS, animazione SVG, compositing canvas ed effetti filtro. La maggior parte di questo carico di lavoro viene eseguito sulla pipeline di compositing GPU, non sul motore JS.

Il divario di ~16% è più piccolo rispetto al 2022 (che era ~20%), suggerendo che i miglioramenti della pipeline GPU beneficiano entrambi i modi in egual misura. Per gli utenti la cui navigazione principale coinvolge pagine ricche di media ma leggere di JS, la Modalità di Blocco comporta un costo di rendering tollerabile.

Caricamento delle pagine nel mondo reale (media geometrica, top 50 siti Alexa)

I punteggi puri dei benchmark non sempre si traducono direttamente in velocità percepita dall'utente. Un test supplementare di caricamento delle pagine utilizzando una metodologia equivalente a WebPageTest sui primi 50 siti web per traffico ha mostrato:

Nella navigazione reale, il divario si traduce in un ritardo percepibile ma non debilitante — circa mezzo secondo sul Tempo per Interattivo. Per gli utenti critici per la privacy, questo è probabilmente un costo accettabile. Per l'uso quotidiano, è un punto di attrito costante.

Confronto: V8, SpiderMonkey, JavaScriptCore 2026

WebKit non opera in isolamento. Altri due principali motori JavaScript competono sugli stessi suite di benchmark e mirano a hardware sovrapposto.

Confronto dell'architettura del motore JavaScript: JSC, V8 e SpiderMonkey ciascuno fa scelte diverse tra velocità di avvio, throughput massimo e indurimento della sicurezza.

V8 (Chrome, Edge)

V8 utilizza un'architettura JIT a due livelli: Sparkplug (Baseline, avvio rapido) e TurboFan (ottimizzante, alto throughput), con Maglev come livello intermedio aggiunto nel 2023. Su hardware Android (Snapdragon 8 Gen 3), V8 con Maglev mostra punteggi Speedometer 3.0 competitivi con JSC su Apple Silicon, ma il throughput massimo di JetStream 2 favorisce JSC su hardware A18 di circa 10–15%.

La postura di sicurezza di V8 si è evoluta: il sandbox di V8 (finalizzato nel 2024) isola l'heap JIT dall'heap del processo del browser, creando un livello di contenimento analogo al Gigacage di JSC. V8 non offre una modalità "JIT disabilitata" per gli utenti finali paragonabile alla Modalità di Blocco di iOS.

SpiderMonkey (Firefox)

SpiderMonkey utilizza un approccio a tre livelli: un interprete di base, Baseline JIT e IonMonkey (ottimizzante). Mozilla ha investito pesantemente nell'indurimento della sicurezza — Warp (l'attuale sistema di inferenza dei tipi che sostituisce IonIR) è stato progettato con la sicurezza come obiettivo co-uguale alle prestazioni dopo una serie di CVE JIT nel 2019–2021.

Firefox su desktop non espone un interruttore di disabilitazione JIT agli utenti. javascript.options.jit.content può essere impostato su false in about:config, e SpiderMonkey tornerà all'interprete di base — analogo all'effetto della Modalità di Blocco su JSC. Il degrado delle prestazioni su quel percorso rispecchia il quadro di JSC: grave su JetStream, moderato su Speedometer.

Riepilogo Speedometer 3.0 cross-engine (desktop, hardware comparabile)

JSC su Apple Silicon è in testa su Speedometer 3.0, probabilmente perché i carichi di lavoro del benchmark si sovrappongono con i modelli che Apple ha specificamente ottimizzato per in FTL e nel motore di layout WebKit. SpiderMonkey di Firefox è in ritardo di un margine maggiore in parte a causa delle differenze del motore di layout oltre al puro throughput JS.

Su iOS specificamente, solo i punteggi JSC sono rilevanti — Chrome e Firefox su iOS 18 utilizzano ancora WebKit sotto il cofano, quindi le loro prestazioni JS sono uguali a quelle di Safari in pratica.

Il caso per la navigazione senza JIT

Dopo quattro anni, la questione di chi dovrebbe eseguire la Modalità di Blocco è diventata più sfumata — non meno.

Il caso di sicurezza rimane forte. I CVE JIT di WebKit continuano ad apparire nel 2025–2026. Il mercato degli exploit commerciali valuta gli exploit full-chain di WebKit su iOS a sette cifre, indicando un investimento sostenuto degli attaccanti. Disabilitare il JIT rimuove la superficie di attacco di maggior valore nello stack del browser. Per chiunque nel modello di minaccia descritto da Apple nel 2022 — giornalisti, operatori dei diritti umani, dissidenti politici, dirigenti con accesso a sistemi sensibili — quel compromesso è chiaro.

Il costo delle prestazioni è diminuito ma non scomparso. Il divario di Speedometer 2.0 del 2022 di ~65% si è ridotto a ~33% su Speedometer 3.0 nel 2026. Nella navigazione reale, il divario è più vicino a 0.5–0.7 secondi sul Tempo per Interattivo. I miglioramenti dell'interprete di WebKit sono reali. Ma i carichi di lavoro di classe JetStream ancora scendono ~88% — le applicazioni web pesanti di calcolo (giochi WebAssembly, editor video in-browser, dashboard di dati complessi) rimangono significativamente degradate.

Il quadro della compatibilità è stabile, non risolto. La Modalità di Blocco disabilita ancora WebAssembly, una proporzione crescente della funzionalità delle applicazioni web. I siti che utilizzano WASM per l'elaborazione delle immagini, i worklet audio o i compiti computazionali falliranno o ricadranno su percorsi più lenti. Questa è una decisione di sicurezza deliberata, non un bug, ma significa che gli utenti della Modalità di Blocco incontreranno occasionalmente esperienze interrotte su app web moderne.

Il quadro decisionale

Considera la Modalità di Blocco se:

• Sei un obiettivo di alto profilo per la sorveglianza di grado governativo o lo spionaggio aziendale.
• Accedi regolarmente a comunicazioni sensibili, sistemi finanziari o documenti riservati dal tuo iPhone.
• Le app e i siti che usi di più sono compatibili — la maggior parte dei casi d'uso di lettura di contenuti funziona bene in Modalità di Blocco.

Rimanda la Modalità di Blocco se:

• Usi applicazioni web complesse (strumenti dipendenti da WASM, IDE in-browser, piattaforme di dati interattive).
• Non sei in un modello di minaccia elevato per attacchi mirati.
• Il costo delle prestazioni sul tuo flusso di lavoro specifico è proibitivo.

La traiettoria futura è verso un divario più piccolo. L'investimento continuo di Apple nell'indurimento di LLInt, nell'estensione IC a livello di interprete e nel co-design hardware-software su Apple Silicon suggeriscono che il divario di Speedometer potrebbe chiudersi ulteriormente entro il 2027–2028. Il divario di JetStream rimarrà strutturale fino a quando il benchmark stesso o i carichi di lavoro che rappresenta non diventeranno meno dipendenti dal JIT.

Per una visione più ampia di dove si trova la privacy del browser su tutte le piattaforme, vedi il rapporto pilastro Stato della privacy del browser 2026. Per le misurazioni originali del 2022 che hanno stabilito il punto di riferimento, vedi L'impatto della Modalità di Blocco di iOS 16 in Safari. Per la retrospettiva più ampia di quattro anni su ciò che la Modalità di Blocco ha cambiato su iOS, vedi Modalità di Blocco di iOS — quattro anni dopo. E per un confronto cross-browser che copre Brave, Tor Browser, Mullvad e LibreWolf, vedi Browser per la privacy 2026.

FAQ

Quanto è più lento Safari in Modalità di Blocco nel 2026? Su Speedometer 3.0, la Modalità di Blocco segna circa il 30–35% in meno rispetto a Safari standard su hardware iPhone 15/16. Questo è un miglioramento significativo rispetto al divario di ~65% di Speedometer 2.0 misurato nel 2022 — grazie soprattutto all'indurimento dell'interprete di WebKit e al lavoro più veloce del livello di base in iOS 17–18.

Il JIT di WebKit viene ancora sfruttato nel 2026? Sì. I CVE relativi al JIT di WebKit continuano ad apparire nel 2025–2026, anche se il tasso è rallentato. Gli sforzi di indurimento di Apple (Gigacage, BoundsChecking, controllo delle autorizzazioni JIT) hanno alzato l'asticella degli exploit, ma il JIT rimane una superficie di attacco primaria negli exploit mobili mirati.

Cos'è il JIT spray e come influisce su WebKit? Il JIT spray è una tecnica di attacco che incorpora shellcode all'interno del codice compilato JIT creando JavaScript con valori costanti specifici. Le mitigazioni di WebKit come Gigacage e il posizionamento casuale del codice rendono più difficile il JIT spray classico, ma varianti creative appaiono ancora nella ricerca avanzata sulle minacce.

Qual è la differenza di punteggio JetStream 2 tra modalità normale e Modalità di Blocco? JetStream 2 è fortemente sensibile al JIT. La Modalità di Blocco tipicamente segna 85–90% in meno su hardware iPhone 15, poiché la maggior parte dei carichi di lavoro JetStream si basa sulla compilazione dei livelli DFG e FTL. Speedometer 3.0 mostra un divario più piccolo perché include lavoro DOM e layout oltre al puro throughput JS.

Puoi abilitare il JIT in Modalità di Blocco su iOS 18? No. A partire da iOS 18, la Modalità di Blocco continua a disabilitare il JIT su tutti i browser basati su WebKit. Apple non ha introdotto una lista di autorizzazioni JIT per sito in Modalità di Blocco.

JavaScriptCore è più veloce di V8 nel 2026? Su benchmark di throughput massimo (JetStream 2, carichi di lavoro di classe Octane), V8 con TurboFan generalmente è in testa su hardware Android. Su Apple Silicon (iPhone 15/16 con A17/A18 Pro), JSC mantiene risultati competitivi o leader grazie al co-design hardware-software stretto, specialmente su carichi di lavoro realistici di Speedometer 3.0.

Quale benchmark riflette meglio le prestazioni di navigazione nel mondo reale? Speedometer 3.0 è il miglior predittore delle prestazioni nel mondo reale oggi. Simula un ampio set di interazioni con framework JavaScript e operazioni DOM. JetStream 2 testa il throughput massimo JS, che è importante per le app web pesanti di calcolo. MotionMark si concentra sulla fedeltà del rendering.

Dovrei usare la Modalità di Blocco per la navigazione quotidiana? La Modalità di Blocco è progettata per individui ad alto rischio — giornalisti, attivisti, dirigenti che affrontano attacchi mirati. Per gli utenti quotidiani, impone costi di prestazioni e compatibilità notevoli (app web interrotte, API disabilitate) che superano il modello di minaccia. Abilitala solo se hai una ragione credibile per credere di essere un obiettivo di attacchi sofisticati.