Como verificar se o KPTI está ativado no meu Ubuntu?


64

Atualmente, a vulnerabilidade do processador Intel Meltdown é corrigida com o isolamento da tabela de páginas ativado. Há uma pergunta sobre como desativar isso: Como desativar o isolamento da tabela de páginas para recuperar o desempenho perdido devido ao patch da falha de segurança da CPU Intel?

Minha pergunta é oposta: existe uma maneira de verificar em um sistema em execução se o mecanismo PTI é eficaz no sistema e, portanto, o sistema está protegido? Estou procurando especificamente cat /proc/somethingou cat /sys/somethingnão verificando a versão do kernel ou o parâmetro de configuração ou algo semelhante.

Respostas:


4

Você pode executar o comando abaixo para ver todas as atenuações disponíveis (não apenas para a PTI, mas também para outras vulnerabilidades):

$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion
Mitigation: Clear CPU buffers; SMT vulnerable
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling

Resposta impressionante - curta e direta. Obrigado.
Martin Vysny

63
  • Grepping CONFIG_PAGE_TABLE_ISOLATION na configuração do kernel, como sugerido por Raniz, não ajuda no Ubuntu de desktop, mas pode ajudar nas instâncias da nuvem:

    grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \
    echo "patched :)" || echo "unpatched :("
    

  • Você pode verificar /proc/cpuinfocomo o JonasCz sugeriu :

    grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" \
    || echo "unpatched :("
    

  • Ou de dmesg(graças a Jason Creighton ):

    dmesg | grep -q "Kernel/User page tables isolation: enabled" \
    && echo "patched :)" || echo "unpatched :("
    

  • Você pode compilar o programa de teste de Raphael Carvalho para detectar Meltdown:

    sudo apt-get install git build-essential
    cd /tmp
    git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
    cd Am-I-affected-by-Meltdown
    make
    sudo sh -c "echo 0  > /proc/sys/kernel/kptr_restrict"
    ./meltdown-checker
    

no sistema corrigido, deve terminar com saída

...
so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).

No sistema corrigido, ele deve mostrar o seguinte:

Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Não instale o 4.4.0-108-generic no Xenial! Ele interrompe a funcionalidade de inicialização / reinicialização / desligamento / suspensão !

Instale 4.4.0-109-generic ( consulte USN-3522-3 para obter detalhes)!


Como Robie Basak já escreveu , há uma página sobre o status das vulnerabilidades Spectre e Meltdown no Ubuntu .

Também existem:


3
As atualizações para o Ubuntu estão agendadas para o Januari 9. Elas podem chegar mais cedo, mas eu não contaria com isso. Insights.ubuntu.com/2018/01/04/…
Raniz

4
As respostas do tipo "dmesg | grep isolamento" são preferíveis a isso, IMO. Algumas distribuições (pelo menos o Debian stretch, talvez outras) portaram a PTI para o kernel antigo, mas não o sinalizador cpu_insecure em / proc / cpuinfo. Nesses sistemas, procurar no log dmesg é a única maneira de verificar, AFAICT.
21418 Jason Jason

3
Acho que o dmesg | grep isolation && echo "patched :)" || echo "unpatched :("comando listado é desnecessariamente perigoso : não mostra qual linha foi realmente correspondida e também imprimia "patched :)" felizmente se uma outra instância aleatória de "isolamento" fosse correspondida ...
Jaap Eldering

2
Eu recomendaria contra a segunda sugestão (grepping /proc/cpuinfopara cpu_insecure). Se você colocar isso em um script e você tem uma CPU no futuro, onde o problema é corrigido na sua microarquitetura, /proc/cpuinfodeixarão de dizer cpu_insecuree seu script vai acreditar o kernel é não corrigida mesmo que seja corrigido . Eu também recomendaria contra a terceira sugestão, pois é muito provável que possa haver a palavra isolationna dmesgsaída em algum momento sem ela se referir ao isolamento da tabela de páginas do kernel.
precisa saber é o seguinte

4
Após uma investigação mais aprofundada, todas as três dessas sugestões são quebradas. Grepping para isolationcorresponderá a ambos Kernel/User page tables isolation: enablede Kernel/User page tables isolation: disabled on command line.
Mark

18

Execute o seguinte comando:

dmesg | grep 'page tables isolation'

Se exibir ativado, o PTI está ativado. Se nada for exibido ou você vir 'desativado' no terminal, o PTI estará desativado. O Ubuntu ainda não publicou o patch, portanto não exibirá nenhuma mensagem.


... ou mensagens do kernel posteriores expulsaram as mensagens de inicialização do buffer de log do kernel. Se o seu kernel imprime avisos para coisas de baixa gravidade, como pacotes de rede estranhos, é comum que as mensagens no momento da inicialização não façam parte da dmesgsaída. Veja /var/log/kern.log*se ele volta o suficiente para receber as mensagens de inicialização. O Ubuntu costumava gravar a dmesgsaída no momento da inicialização /var/log/dmesg, mas parece não fazer mais isso.
Peter Cordes

Em 14.04, consegui dmesg: invalid option -- 'w'. -Htambém é inválido. Removendo as bandeiras funcionou bem para mim, como em esta resposta
wjandrea

/ var
log

12

Você pode verificar com cat /proc/cpuinfo, se reportar cpu_insecureem "bugs", o PTI está ativado.

Se estiver em branco (ou simplesmente não cpu_insecureestiver listado ), provavelmente você está executando um kernel que ainda não foi corrigido (o Ubuntu não tem) ou possui um processador AMD (para o qual isso não será habilitado, visto que eles não é vulnerável).

Atualmente, todas as CPUs são tratadas como vulneráveis no kernel 4.15 mais recente.


4.15 ainda não está liberado para o público
Aadhil RF

Ou seja, se você baixar o último candidato a versão do kernel.org e compilá-lo você mesmo. @Mohammedaadhil
JonasCz diz Reinstate Monica 4/18/18

11
Um candidato a lançamento não é um lançamento.
Ruslan

O artigo que você vinculou foi atualizado
nixpower

2
O kernel 4.14.11 será definido cpu_insecurepara qualquer CPU x86; 4.14.12 e mais recentes só irá definir-lo para Intel CPUs (incluindo os muito velhos ou muito primitiva a ser vulnerável Ambos irão configurá-lo mesmo se KPTI está desativado..
Mark

8

Encontrei este ótimo script sh para testar as vulnerabilidades de fusão / espectro no seu sistema:

https://github.com/speed47/spectre-meltdown-checker

O script verifica se o seu sistema possui patches conhecidos de fusão e espectro no seu sistema para informar se essas vulnerabilidades agora foram mitigadas pelo seu sistema operacional.


2

Você pode verificar /proc/config.gz para CONFIG_PAGE_TABLE_ISOLATION=yo que significa que o kernel foi compilado com KPTI.

Este está no meu sistema Arch Linux corrigido, executando 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
CONFIG_PAGE_TABLE_ISOLATION=y

3
Infelizmente, a configuração do kernel atualmente em execução no /proc/não é ativada por padrão nos kernels do Ubuntu. A solução alternativa (muito menos elegante) é a grepping /boot/config-$( uname -r ).
precisa saber é o seguinte

5
Isso informa apenas se o kernel foi compilado com o KPTI, e não se o KPTI está ativo (ele pode ser desativado no momento da inicialização e, possivelmente, no tempo de execução).
Mark

Se você desabilitou explicitamente o KPTI através dos parâmetros da linha de comando do kernel, não é necessário verificar se está ativo ou não.
Raniz 16/01/19

1

Na minha instância do AWS Ubuntu 14.04.5 LTS EC2, executei

grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)

Deveria dizer:

CONFIG_PAGE_TABLE_ISOLATION=y

Para atualização, fiz:

sudo apt-get update && sudo apt-get install linux-image-generic

Eu também acho que isso é bom:

sudo apt-get update
sudo apt-get dist-upgrade

Para verificar a versão do kernel:

uname -r

Precisa ser 3.13.0-139-genérico ou mais recente.


Este método já é mencionado no topo resposta
wjandrea
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.