Uma nova vulnerabilidade de hardware batizada de VMSCAPE acaba de entrar no radar do Linux. A falha é da família Spectre-v2: um guest (máquina virtual) malicioso consegue “treinar” o preditor de desvios da CPU para influenciar o comportamento do host — em especial o userspace do hypervisor, como o QEMU. Em termos simples, o atacante usa especulação para fazer o hospedeiro executar trechos que não deveria e, com isso, inferir dados por canal lateral. O detalhe que assusta? O ataque quebra a barreira de virtualização sem precisar de gadgets ROP customizados no host, e já chega com mitigação a caminho no kernel.
Se parece abstrato, pense no preditor de desvios como o “GPS” do processador: ele chuta o próximo caminho para ganhar velocidade. O VMSCAPE polui esse GPS dentro da VM para que, ao ocorrer um VM-exit, as previsões contaminadas afetem o processo do hypervisor no host (ex.: QEMU). Em plataformas onde dispositivos são emulados em userspace, esses saltos para o QEMU acontecem com frequência — o que amplia a superfície de ataque.
Como o Linux está se protegendo
O kernel implementa uma estratégia direta e de amplo alcance: usar IBPB (Indirect Branch Prediction Barrier) para “zerar” o histórico do preditor antes de sair para o userspace após um VM-exit. A lógica é condicional — o kernel marca a CPU que acabou de rodar um guest e só então dispara o IBPB na primeira volta ao userspace; se não houve userspace entre um VM-exit e o próximo VM-entry, não há flush desnecessário. Esse desenho evita o custo de fazer IBPB em todo VM-exit e, ao mesmo tempo, protege o caminho sensível em que o QEMU volta a rodar. Em sistemas que já emitem IBPB em VM-exit por causa de outras correções (como Retbleed ou SRSO), o kernel reaproveita essa barreira.
Por que IBPB — e não IBRS/eIBRS — como base? Porque o IBPB funciona de forma universal entre Intel e AMD para o cenário em questão: ele coloca uma barreira explícita que impede que um software influencie a predição de desvios de outro que roda depois, no mesmo core lógico. Já o IBRS/eIBRS tem nuances (especialmente no userspace e nas transições guest/host), e nem sempre isola adequadamente o que o VMSCAPE explora; daí a preferência por uma parede bem clara no ponto exato da transição que importa.
SMT (hyper-threading) e stibp
Há uma observação importante para quem mantém SMT ligado: em ambientes com threads irmãs no mesmo core, o kernel passa a avisar quando não houver STIBP suficiente, porque a proteção completa contra VMSCAPE com SMT requer esse isolamento extra entre threads. Sistemas com Intel eIBRS já implicam STIBP ativo, mas em outras combinações vale revisar sua política de Spectre-v2 para garantir que STIBP esteja realmente ligado.
Quem é afetado
A documentação adicionada ao kernel lista como vulneráveis, em linhas gerais:
- Intel: a geração Skylake (partes sem Enhanced-IBRS); Cascade Lake (afetadas por ITS guest/host separation); e Alder Lake e mais novas (afetadas por BHI). Partes Ice Lake que usam a limpeza de BHB por software não são vulneráveis a VMSCAPE.
- AMD: famílias Zen (0x17, 0x19, 0x1a).
- Hygon: família 0x18.
Em paralelo, reportagens públicas citam impacto em diversos chips Zen e em linhas Intel como Coffee Lake; o ponto central é que o escopo atinge gerações populares em servidores e desktops modernos — razão pela qual a mitigação padrão no upstream é conservadora.
Como verificar e ajustar no seu sistema
O kernel expõe o status pelo sysfs em:
/sys/devices/system/cpu/vulnerabilities/vmscapeOs estados típicos incluem “Not affected”, “Vulnerable”, “Mitigation: IBPB before exit to userspace” e “Mitigation: IBPB on VMEXIT” (este último aparece quando outra mitigação já força IBPB em toda saída de VM). Para administração, há a opção de boot vmscape= com três valores: off (desativa), ibpb (ativa a mitigação condicional — padrão quando o recurso está compilado) e force (força detecção/mitigação mesmo em CPUs não reconhecidas). Esses controles seguem a tradição do Linux de tornar Spectre-v2 configurável via linha de comando e sysfs, junto com a família de parâmetros para IBRS/IBPB/STIBP.
E o impacto de performance?
Como em toda defesa contra Spectre, há custo. O overhead depende do perfil de VM-exits para o userspace: cenários com muita emulação (o QEMU tocando dispositivos virtuais inteiros) tendem a pagar mais; quando o caminho é majoritariamente kernel-only (menos saídas para o QEMU), o impacto cai. Medições públicas indicam algo na casa de ~10% com dispositivos emulados e cerca de 1% em plataformas modernas, mas isso varia — avalie no seu workload. O importante é que a mitigação do Linux VMSCAPE vulnerability foi desenhada para disparar apenas quando e onde importa, preservando performance sempre que possível.
