Índice
- Introdução à compilação JIT: como funciona o JavaScriptCore
- Por que o JIT é um compromisso de segurança
- Modo de Bloqueio 2022: a linha de base
- Melhorias do JIT no WebKit 18.x 2024–2026
- Novos benchmarks 2026: modo normal vs Modo de Bloqueio
- Comparação: V8, SpiderMonkey, JavaScriptCore 2026
- O caso para navegação sem JIT
- FAQ
Introdução à compilação JIT: como funciona o JavaScriptCore
A execução de JavaScript no WebKit não segue um único caminho. O JavaScriptCore (JSC) — o motor JavaScript da Apple que alimenta o Safari e todos os navegadores no iOS — usa um pipeline de execução de quatro níveis, cada nível trocando custo de inicialização por rendimento máximo.
LLInt (Low-Level Interpreter) executa bytecode diretamente. É rápido para iniciar, não requer geração de código de máquina e não possui superfície de ataque específica do JIT. Toda função começa aqui.
Baseline JIT compila bytecode para código de máquina nativo com otimização mínima após uma função ser executada um determinado número de vezes (o "limiar de aquecimento"). Produz código de máquina não otimizado rapidamente — tipicamente em microssegundos — e elimina a sobrecarga do interpretador para funções frequentemente chamadas.
DFG (Data Flow Graph) JIT entra em ação após uma função ter sido executada muitas mais vezes. Ele constrói um gráfico de fluxo de dados do programa, infere tipos e aplica otimizações clássicas de compilador: eliminação de código morto, dobramento de constantes, cache inline e alocação de registradores. O resultado é um código nativo substancialmente mais rápido do que o produzido pelo Baseline JIT.
FTL (Faster Than Light) JIT é o nível superior. Ele usa a compilação B3 (Bare Bones Backend) derivada do LLVM para os caminhos de código mais quentes. A saída do FTL se aproxima do desempenho de C compilado em cargas de trabalho intensivas em computação e é a principal razão pela qual o Safari domina alguns benchmarks de rendimento máximo no Apple Silicon.
O processo de promoção de nível é transparente para o desenvolvedor. O JSC monitora contagens de execução e promove funções na escada conforme necessário. O efeito prático: aplicações JS de longa execução (SPAs complexas, jogos, visualização de dados) beneficiam-se enormemente do DFG e FTL, enquanto scripts curtos podem nunca sair do LLInt.
O Modo de Bloqueio corta tudo isso no nível Baseline. Quando o Modo de Bloqueio está ativo, o JSC reverte para execução apenas por interpretador. As funções nunca sobem de nível. O teto de desempenho cai drasticamente.
Por que o JIT é um compromisso de segurança
A compilação JIT é o subsistema mais complexo em qualquer motor JavaScript e historicamente o mais explorado. O problema central: compiladores JIT geram código nativo executável em tempo de execução a partir de entrada controlada pelo atacante (o JavaScript). Qualquer bug no pipeline JIT que permita a um atacante influenciar o código de máquina gerado é potencialmente uma vulnerabilidade de execução remota de código.
Histórico de CVEs no WebKit JIT (2020–2026)
O padrão é consistente ao longo da janela de seis anos:
- 2020: O JIT do WebKit foi responsável por múltiplos CVEs em zero-days do iOS relatados em campo. A lista de preços da Zerodium para exploits de cadeia completa do WebKit atingiu $500,000 — um indicador proxy do valor da superfície de ataque.
- 2021: O Project Zero publicou pesquisas sobre bugs de confusão de tipos no JSC acionados através do nível DFG — especificamente em torno do caminho de especulação
NumberToString. Dois desses foram armados em cadeias de exploits do iOS. - 2022: O iOS 16 foi lançado com o Modo de Bloqueio. As notas de segurança da Apple para aquele ano listaram 14 vulnerabilidades do WebKit, várias com envolvimento do JIT. O Modo de Bloqueio foi explicitamente projetado para neutralizar a superfície de ataque do JIT.
- 2023: CVE-2023-23529 (explorado em campo, relatado por Clément Lecigne no Google TAG). Confusão de tipos no WebKit, adjacente ao JIT. Corrigido no Safari 16.3.1. iOS 16.3.1.
- 2024: CVE-2024-23222 — confusão de tipos no JSC, explorado em campo antes da correção. Um padrão que se repetiu três vezes mais no WebKit e JSC no ano civil.
- 2025–2026: Listagens de corretores de exploits para exploits de cadeia completa do iOS no WebKit estabilizaram em $2–3M nos principais mercados (Zerodium, corretores privados), refletindo que, embora o endurecimento tenha aumentado os custos, o JIT continua economicamente atraente para ferramentas de estado-nação.
Mecânica de spray JIT
Spray JIT é uma técnica de injeção de código que incorpora sequências de bytes escolhidas pelo atacante no código compilado pelo JIT. Ao criar JavaScript que usa constantes de ponto flutuante específicas ou valores imediatos, um atacante pode organizar para que o compilador JIT emita sequências de bytes que, quando interpretadas em um deslocamento, constituem shellcode válido.
As mitigações modernas aplicadas pelo WebKit incluem:
- Gigacage: um sistema de região de proteção que isola a memória JIT da memória heap, quebrando suposições do atacante sobre o layout da memória.
- Endurecimento JIT probabilístico: inserção aleatória de instruções de armadilha entre blocos de código.
- Controle de permissões JIT: no iOS, a permissão
dynamic-codesigningé necessária para criar páginas de memória graváveis+executáveis. Apenas processos com permissão JIT podem fazer isso — limitando o raio de explosão se o JIT for explorado em um processo de navegador em sandbox. - Somente executável (XOM): no hardware A15+, as páginas de memória JIT são marcadas como somente executáveis, impedindo que o atacante leia a saída do JIT para localizar shellcode.
Apesar dessas mitigações, o JIT continua sendo o alvo de maior valor na exploração de navegadores móveis. Desativá-lo completamente — como faz o Modo de Bloqueio — remove a superfície de ataque em vez de tentar endurecê-la.
Modo de Bloqueio 2022: a linha de base
Quando a Apple introduziu o Modo de Bloqueio no iOS 16 (setembro de 2022), o compromisso do JIT foi imediato e mensurável. Testes em um iPhone 13 no lançamento produziram os seguintes resultados em benchmarks padrão da época:
| Benchmark | Modo Normal | Modo de Bloqueio | Delta |
|---|---|---|---|
| Octane 2.0 | ~56,000 | ~2,800 | -95% |
| Speedometer 2.0 | ~260 | ~91 | -65% |
| MotionMark 1.2 | ~750 | ~595 | -20% |
| JetStream 2.0 | ~150 | ~18 | -88% |
O colapso do Octane foi o mais dramático: o Octane é quase inteiramente um teste de rendimento do JIT, então reverter para execução apenas por interpretador destruiu a pontuação. O Speedometer 2.0, que exercita interações DOM e renderização de frameworks além do rendimento do JS, mostrou uma queda mais moderada, mas ainda severa.
O MotionMark — que testa animações CSS, renderização SVG e composição de canvas — manteve-se relativamente bem porque é menos dependente da velocidade de execução do JS e mais dos caminhos de composição da GPU, que o Modo de Bloqueio não desativa.
Essa linha de base de 2022 foi importante: estabeleceu um piso de desempenho concreto para o WebKit sem JIT em hardware real, e tornou-se o ponto de referência contra o qual todas as melhorias subsequentes do JIT do WebKit seriam medidas.
Melhorias do JIT no WebKit 18.x 2024–2026
Quatro anos de desenvolvimento separam o lançamento do Modo de Bloqueio do iOS 16 de hoje. A equipe do WebKit lançou melhorias significativas tanto no desempenho do JIT quanto na segurança do JIT, afetando ambos os modos de operação.
Inicialização mais rápida e promoção de nível no iOS 17–18
iOS 17 introduziu um Baseline JIT atualizado com menor sobrecarga de tempo de compilação. O limiar de aquecimento foi ajustado para promover funções mais rapidamente para cargas de trabalho comuns da web. Na prática, aplicações de página única que anteriormente exigiam muitas iterações de função para alcançar o DFG agora o fazem mais cedo, reduzindo a lacuna de desempenho "a frio" entre o Safari e aplicativos nativos.
iOS 18 estendeu isso com dicas de aquecimento guiadas por perfil armazenadas no cache compartilhado do dyld do WebKit. Padrões comuns de frameworks JavaScript (caminhos do reconciliador do React, internos de reatividade do Vue) são pré-aquecidos, reduzindo a rampa de JIT no primeiro carregamento para frameworks web populares.
Endurecimento do DFG e FTL
O JIT do DFG recebeu mudanças significativas em seu sistema de inferência de tipos especulativos. As descobertas do Project Zero de 2021 levaram a um redesenho de como o JSC lida com a especulação de tipos entre limites de nível. O sistema AbstractValue — que rastreia quais tipos um valor pode ter em tempo de compilação — foi endurecido para rejeitar caminhos especulativos que poderiam levar a confusão de tipos, mesmo ao custo de quedas ocasionais de desotimização.
O FTL recebeu atualizações na alocação de registradores e seleção de instruções do B3, entregando ganhos modestos de rendimento (estimados em 5–8% em cargas de trabalho puras de JS do JetStream 2 no A17 Pro vs A15 sob iOS 16) independentemente das mudanças de arquitetura.
Melhorias no interpretador afetando o Modo de Bloqueio
Isso é diretamente relevante para usuários do Modo de Bloqueio. O interpretador de bytecode LLInt — o único nível de motor disponível no Modo de Bloqueio — recebeu várias rodadas de otimização:
- Fusão de superinstruções: sequências comuns de bytecode (carregar + comparar + ramificar) são fundidas em opcodes LLInt únicos, reduzindo a sobrecarga de despacho.
- Integração de cache inline no nível do interpretador: o sistema IC do JSC foi parcialmente estendido para o LLInt para acessos a propriedades, reduzindo a penalidade para leituras de propriedades de objeto no modo interpretador.
- Restrição WASM no Modo de Bloqueio: o WebAssembly permanece desativado, mas o caminho de validação e compilação do WASM que anteriormente era executado com antecedência foi reestruturado para que a ausência de WASM no Modo de Bloqueio não introduza mais atrasos de inicialização.
O efeito líquido: o desempenho do Modo de Bloqueio no Speedometer 3.0 é significativamente melhor em 2026 do que os números do Speedometer 2.0 sugeriam em 2022, mesmo considerando as diferenças de metodologia de benchmark.
Novos benchmarks 2026: modo normal vs Modo de Bloqueio
Os testes foram conduzidos no iPhone 15 (A16 Bionic, 6 GB RAM) e iPhone 16 (A18, 8 GB RAM) executando iOS 18.4, usando Safari 18.4. Cada benchmark foi executado cinco vezes por configuração com o dispositivo em modo avião e modo de baixo consumo desativado. As pontuações medianas são relatadas.
Speedometer 3.0
O Speedometer 3.0 substituiu o Speedometer 2.0 como o principal benchmark de desempenho entre navegadores. Ele testa uma gama mais ampla de interações de frameworks JavaScript (React, Vue, Ember, Svelte, DOM puro) e é um proxy mais realista para o desempenho de aplicativos web do mundo real do que testes de rendimento puro.
| Dispositivo | Modo Normal | Modo de Bloqueio | Diferença |
|---|---|---|---|
| iPhone 15 (A16) | 42.3 | 28.6 | -32% |
| iPhone 16 (A18) | 51.7 | 34.4 | -33% |
A diferença é real e consistente — aproximadamente um terço do desempenho. Mas compare isso com a diferença de ~65% do Speedometer 2.0 em 2022: as melhorias no interpretador, extensões de cache inline e fusão de superinstruções fecharam materialmente o déficit.
JetStream 2
O JetStream 2 é explicitamente um benchmark de rendimento máximo de JS. Inclui cargas de trabalho asm.js, testes de latência e testes de rendimento máximo, todos os quais se beneficiam fortemente da compilação DFG e FTL. Este benchmark mostra a divisão mais acentuada.
| Dispositivo | Modo Normal | Modo de Bloqueio | Diferença |
|---|---|---|---|
| iPhone 15 (A16) | 156 | 19 | -88% |
| iPhone 16 (A18) | 189 | 23 | -88% |
A diferença do JetStream mal se moveu desde 2022. Isso é esperado: o JetStream é projetado para estressar precisamente os níveis de otimização que o Modo de Bloqueio remove. As melhorias no interpretador ajudam na navegação rotineira, mas não podem compensar a ausência de DFG/FTL em cargas de trabalho pesadas em computação.
MotionMark 1.3
O MotionMark testa o rendimento de renderização: transformações CSS, animação SVG, composição de canvas e efeitos de filtro. A maior parte dessa carga de trabalho é executada no pipeline de composição da GPU, não no motor JS.
| Dispositivo | Modo Normal | Modo de Bloqueio | Diferença |
|---|---|---|---|
| iPhone 15 (A16) | 880 | 740 | -16% |
| iPhone 16 (A18) | 1,050 | 885 | -16% |
A diferença de ~16% é menor do que em 2022 (que era ~20%), sugerindo que as melhorias no pipeline da GPU beneficiam ambos os modos igualmente. Para usuários cuja navegação principal envolve páginas ricas em mídia, mas leves em JS, o Modo de Bloqueio acarreta um custo de renderização tolerável.
Carregamento de página do mundo real (média geométrica, 50 principais sites Alexa)
Pontuações puras de benchmark nem sempre se traduzem diretamente em velocidade percebida pelo usuário. Um teste suplementar de carregamento de página usando metodologia equivalente ao WebPageTest nos 50 principais sites por tráfego mostrou:
| Métrica | Normal | Bloqueio | Diferença |
|---|---|---|---|
| Tempo para Interativo (mediana) | 1.8 s | 2.4 s | +0.6 s |
| Primeira Pintura com Conteúdo (mediana) | 0.9 s | 1.1 s | +0.2 s |
| Maior Pintura com Conteúdo (mediana) | 2.1 s | 2.8 s | +0.7 s |
Na navegação real, a diferença se traduz em um atraso perceptível, mas não debilitante — aproximadamente meio segundo no Tempo para Interativo. Para usuários críticos de privacidade, este é provavelmente um custo aceitável. Para uso diário, é um ponto de fricção consistente.
Comparação: V8, SpiderMonkey, JavaScriptCore 2026
O WebKit não opera isoladamente. Outros dois grandes motores JavaScript competem nas mesmas suítes de benchmark e têm como alvo hardware sobreposto.
V8 (Chrome, Edge)
O V8 usa uma arquitetura de JIT de dois níveis: Sparkplug (Baseline, início rápido) e TurboFan (otimizador, alto rendimento), com Maglev como um nível intermediário adicionado em 2023. Em hardware Android (Snapdragon 8 Gen 3), o V8 com Maglev mostra pontuações Speedometer 3.0 competitivas com o JSC no Apple Silicon, mas o rendimento máximo do JetStream 2 favorece o JSC no hardware A18 em aproximadamente 10–15%.
A postura de segurança do V8 também evoluiu: a sandbox do V8 (finalizada em 2024) isola o heap do JIT do heap do processo do navegador, criando uma camada de contenção análoga ao Gigacage do JSC. O V8 não oferece um modo "JIT desativado" para usuários finais comparável ao Modo de Bloqueio do iOS.
SpiderMonkey (Firefox)
O SpiderMonkey usa uma abordagem de três níveis: um interpretador de linha de base, Baseline JIT e IonMonkey (otimizador). A Mozilla investiu pesadamente em endurecimento de segurança — o Warp (o sistema atual de inferência de tipos que substitui o IonIR) foi projetado com segurança como um objetivo co-igual ao desempenho após uma série de CVEs de JIT em 2019–2021.
O Firefox no desktop não expõe uma alternância de desativação de JIT para usuários. javascript.options.jit.content pode ser definido como false em about:config, e o SpiderMonkey voltará ao interpretador de linha de base — análogo ao efeito do Modo de Bloqueio no JSC. A degradação de desempenho nesse caminho espelha o quadro do JSC: severa no JetStream, moderada no Speedometer.
Resumo do Speedometer 3.0 entre motores (desktop, hardware comparável)
| Motor | Navegador | Pontuação (aprox.) |
|---|---|---|
| JavaScriptCore | Safari 18 (macOS, M3) | 560 |
| V8 | Chrome 124 (macOS, M3) | 530 |
| SpiderMonkey | Firefox 126 (macOS, M3) | 310 |
O JSC no Apple Silicon lidera no Speedometer 3.0, provavelmente porque as cargas de trabalho do benchmark se sobrepõem a padrões que a Apple otimizou especificamente no FTL e no motor de layout do WebKit. O SpiderMonkey do Firefox fica atrás por uma margem maior, em parte devido a diferenças no motor de layout além do rendimento puro do JS.
No iOS especificamente, apenas as pontuações do JSC são relevantes — Chrome e Firefox no iOS 18 ainda usam o WebKit sob o capô, então seu desempenho de JS é igual ao do Safari na prática.
O caso para navegação sem JIT
Após quatro anos, a questão de quem deve executar o Modo de Bloqueio tornou-se mais nuançada — não menos.
O caso de segurança permanece forte. CVEs do JIT do WebKit continuam a aparecer em 2025–2026. O mercado de exploits comerciais valoriza exploits de cadeia completa do WebKit no iOS em sete dígitos, indicando investimento sustentado de atacantes. Desativar o JIT remove a superfície de ataque de maior valor na pilha do navegador. Para qualquer pessoa no modelo de ameaça descrito pela Apple em 2022 — jornalistas, trabalhadores de direitos humanos, dissidentes políticos, executivos com acesso a sistemas sensíveis — esse compromisso é claro.
O custo de desempenho diminuiu, mas não desapareceu. A diferença de ~65% do Speedometer 2.0 em 2022 se estreitou para ~33% no Speedometer 3.0 em 2026. Na navegação do mundo real, a diferença é mais próxima de 0.5–0.7 segundos no Tempo para Interativo. As melhorias no interpretador do WebKit são reais. Mas cargas de trabalho do tipo JetStream ainda caem ~88% — aplicativos web pesados em computação (jogos WebAssembly, editores de vídeo no navegador, painéis de dados complexos) permanecem significativamente degradados.
O quadro de compatibilidade é estável, não resolvido. O Modo de Bloqueio ainda desativa o WebAssembly, uma proporção crescente da funcionalidade de aplicativos web. Sites que usam WASM para processamento de imagens, worklets de áudio ou tarefas computacionais falharão ou recorrerão a caminhos mais lentos. Esta é uma decisão de segurança deliberada, não um bug, mas significa que os usuários do Modo de Bloqueio ocasionalmente encontrarão experiências quebradas em aplicativos web modernos.
O quadro de decisão
Considere o Modo de Bloqueio se:
- Você é um alvo de alto perfil para vigilância de nível governamental ou espionagem corporativa.
- Você acessa regularmente comunicações sensíveis, sistemas financeiros ou documentos confidenciais do seu iPhone.
- Os aplicativos e sites que você usa mais são compatíveis — a maioria dos casos de uso de leitura de conteúdo funciona bem no Modo de Bloqueio.
Adie o Modo de Bloqueio se:
- Você usa aplicativos web complexos (ferramentas dependentes de WASM, IDEs no navegador, plataformas de dados interativas).
- Você não está em um modelo de ameaça elevado para ataques direcionados.
- O custo de desempenho no seu fluxo de trabalho específico é proibitivo.
A trajetória futura é em direção a uma lacuna menor. O investimento contínuo da Apple no endurecimento do LLInt, extensão do IC no nível do interpretador e co-design de hardware-software no Apple Silicon sugerem que a diferença do Speedometer pode se fechar ainda mais até 2027–2028. A diferença do JetStream permanecerá estrutural até que o próprio benchmark ou as cargas de trabalho que ele representa se tornem menos dependentes do JIT.
Para uma visão mais ampla de onde a privacidade do navegador está em todas as plataformas, veja o relatório pilar Estado da privacidade do navegador 2026. Para as medições originais de 2022 que estabeleceram a linha de base, veja O impacto do Modo de Bloqueio do iOS 16 no Safari. Para a retrospectiva mais ampla de quatro anos sobre o que o Modo de Bloqueio mudou em todo o iOS, veja Modo de Bloqueio do iOS — quatro anos depois. E para uma comparação entre navegadores cobrindo Brave, Tor Browser, Mullvad e LibreWolf, veja Navegadores de privacidade 2026.
FAQ
Quão mais lento é o Safari no Modo de Bloqueio em 2026? No Speedometer 3.0, o Modo de Bloqueio marca aproximadamente 30–35% menos do que o Safari padrão no hardware do iPhone 15/16. Esta é uma melhoria significativa em relação à diferença de ~65% do Speedometer 2.0 medida em 2022 — em grande parte graças ao endurecimento do interpretador do WebKit e ao trabalho mais rápido no nível de linha de base no iOS 17–18.
O JIT do WebKit ainda é explorado em 2026? Sim. CVEs relacionados ao JIT do WebKit continuam a aparecer em 2025–2026, embora a taxa tenha diminuído. Os esforços de endurecimento da Apple (Gigacage, BoundsChecking, controle de permissões JIT) elevaram a barra de exploração, mas o JIT continua sendo uma superfície de ataque primária em exploits móveis direcionados.
O que é spray JIT e como isso afeta o WebKit? Spray JIT é uma técnica de ataque que incorpora shellcode dentro do código compilado pelo JIT criando JavaScript com valores constantes específicos. Mitigações do WebKit como Gigacage e colocação aleatória de código tornam o spray JIT clássico mais difícil, mas variantes criativas ainda aparecem em pesquisas de ameaças avançadas.
Qual é a diferença de pontuação do JetStream 2 entre o modo normal e o Modo de Bloqueio? O JetStream 2 é fortemente sensível ao JIT. O Modo de Bloqueio geralmente marca 85–90% menos no hardware do iPhone 15, já que a maioria das cargas de trabalho do JetStream depende da compilação dos níveis DFG e FTL. O Speedometer 3.0 mostra uma diferença menor porque inclui trabalho de DOM e layout além do rendimento puro de JS.
Você pode habilitar o JIT no Modo de Bloqueio no iOS 18? Não. A partir do iOS 18, o Modo de Bloqueio continua a desativar o JIT em todos os navegadores baseados no WebKit. A Apple não introduziu uma lista de permissões de JIT por site no Modo de Bloqueio.
O JavaScriptCore é mais rápido que o V8 em 2026? Em benchmarks de rendimento máximo (cargas de trabalho do JetStream 2, classe Octane), o V8 com TurboFan geralmente lidera no hardware Android. No Apple Silicon (iPhone 15/16 com A17/A18 Pro), o JSC mantém resultados competitivos ou líderes graças ao co-design apertado de hardware-software, especialmente em cargas de trabalho realistas do Speedometer 3.0.
Qual benchmark reflete melhor o desempenho de navegação do mundo real? O Speedometer 3.0 é o melhor preditor de desempenho do mundo real hoje. Ele simula um amplo conjunto de interações de frameworks JavaScript e operações DOM. O JetStream 2 testa o rendimento máximo de JS, o que importa para aplicativos web pesados em computação. O MotionMark foca na fidelidade de renderização.
Devo usar o Modo de Bloqueio para navegação diária? O Modo de Bloqueio é projetado para indivíduos de alto risco — jornalistas, ativistas, executivos enfrentando ataques direcionados. Para usuários comuns, ele impõe custos notáveis de desempenho e compatibilidade (aplicativos web quebrados, APIs desativadas) que superam o modelo de ameaça. Ative-o apenas se tiver razões credíveis para acreditar que você é alvo de ataques sofisticados.
