우분투에서 KPTI가 활성화되어 있는지 확인하는 방법은 무엇입니까?


64

현재 Meltdown Intel 프로세서 취약점은 페이지 테이블 격리를 활성화하여 해결됩니다. 이것을 끄는 방법에 대한 의문이 있습니다 : Intel CPU 보안 취약점으로 인해 성능 손실을 다시 얻기 위해 Page Table Isolation을 비활성화하는 방법은 무엇입니까?

내 질문은 반대입니다. 실행중인 시스템에서 PTI 메커니즘이 시스템에서 효과적이며 시스템이 보호되는지 여부를 확인하는 방법이 있습니까? 내가 특별히 찾고 있어요 cat /proc/something또는 cat /sys/something하지 커널 버전이나 설정 매개 변수 등을 확인.

답변:


4

아래 명령을 실행하여 사용 가능한 모든 완화 방법을 확인할 수 있습니다 (PTI뿐 아니라 다른 취약점도).

$ 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

굉장한 대답-짧고 요점. 감사합니다.
마틴 비 시니

63
  • Raniz 의 제안 대로 커널 구성에서 CONFIG_PAGE_TABLE_ISOLATION을 가져 오는 것은 데스크톱 우분투에는 도움이되지 않지만 클라우드 인스턴스에는 도움이 될 수 있습니다.

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

  • JonasCz가 제안한/proc/cpuinfo 대로 확인할 수 있습니다 .

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

  • 또는 dmesg( Jason Creighton 에게 감사드립니다 ) :

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

  • Meltdown 탐지를 위해 Raphael Carvalho 에서 테스트 프로그램을 컴파일 할 수 있습니다 .

    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
    

패치 시스템에서는 출력으로 끝나야합니다.

...
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).

패치 된 시스템에서 다음을 표시해야합니다.

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)

Xenial에 4.4.0-108-generic을 설치하지 마십시오! 그것은 부팅 / 재부팅 / 종료를 나누기 / 기능을 중지 !

4.4.0-109-generic을 설치 하십시오 ( 자세한 내용은 USN-3522-3 참조)!


Robie Basak이 이미 쓴 것처럼 우분투의 Specter and Meltdown 취약점 상태에 대한 페이지가 있습니다.

또한 있습니다 :


3
Ubuntu에 대한 업데이트는 Januari 9로 예정되어 있습니다. 더 일찍 도착할 수도 있지만 저는 그것에 의지하지 않습니다. insights.ubuntu.com/2018/01/04/…
Raniz

4
"dmesg | grep isolation"유형의 대답이 IMO보다 선호됩니다. 일부 배포판 (적어도 데비안 스트레치, 아마도 다른 배포판)은 PTI를 이전 커널로 포팅했지만 / proc / cpuinfo의 cpu_insecure 플래그는 포팅하지 않았습니다. 이러한 시스템에서는 dmesg 로그를 보는 것이 AFAICT를 확인하는 유일한 방법입니다.
Jason Creighton

3
dmesg | grep isolation && echo "patched :)" || echo "unpatched :("나열된 명령은 불필요하게 위험 하다고 생각합니다 . 실제로 어떤 행이 실제로 일치했는지 표시하지 않으며 임의의 다른 "격리"인스턴스가 일치하면 "patched :)"를 행복하게 인쇄합니다 ...
Jaap Eldering

2
두 번째 제안에 반대하는 것이 좋습니다 ( /proc/cpuinfocpu_insecure에 대한 grepping ). 당신이 스크립트에 그것을 넣어 당신은 문제가 마이크로 아키텍처에서 해결 된 미래의 CPU가있는 경우, /proc/cpuinfo더 이상 말을하지 않습니다 cpu_insecure및 스크립트는 커널이라고 생각합니다 패치 가 되더라도 패치 . 이 단어가있을 수 있습니다 것을 너무 높습니다 나는 또한, 세 번째 제안에 대해 추천 할 것입니다 isolation에서 dmesg이 페이지 테이블 분리 커널을 참조하지 않고 어떤 시점에서 출력.
blubberdiblub

4
추가 조사를 수행하면이 세 가지 제안이 모두 해결됩니다. 대한 Grepping은 isolation모두 일치 Kernel/User page tables isolation: enabledKernel/User page tables isolation: disabled on command line.
Mark

18

다음 명령을 실행하십시오.

dmesg | grep 'page tables isolation'

enabled로 표시되면 PTI가 활성화 된 것입니다. 아무것도 표시되지 않거나 터미널에 '비활성화 됨'이 표시되면 PTI가 비활성화 된 것입니다. 우분투는 아직 패치를 게시하지 않았으므로 아무런 메시지도 표시하지 않습니다.


... 나중에 커널 메시지가 부팅 메시지를 커널 로그 버퍼에서 밀어 냈습니다. 커널이 이상한 네트워크 패킷과 같은 심각도가 낮은 항목에 대한 알림을 인쇄하는 경우 부팅 시간 메시지가 dmesg출력의 일부가 아닌 것이 일반적입니다 . /var/log/kern.log*부팅 메시지를 표시 할 수있을 정도로 되돌아 가는지 확인 하십시오 . 우분투는 부팅 시간 dmesg출력을 에 기록 /var/log/dmesg했지만 더 이상 그렇게하지는 않습니다.
Peter Cordes

14.04에 나는 얻었다 dmesg: invalid option -- 'w'. -H또한 유효하지 않습니다. 플래그를 제거하면 같이 나를 위해 잘 작동 이 답변
wjandrea

/var/log/kern.log on 14.04
eckes

12

당신은 확인 할 수 cat /proc/cpuinfo가보고하는 경우, cpu_insecure"버그"에서, 다음 PTI 사용할 수 있습니다.

비어 있거나 (만 나열 cpu_insecure되지 않은 경우) 아직 패치되지 않은 커널을 실행 중이거나 (Ubuntu 가하지 않은) AMD 프로세서가 있습니다 (AMD 프로세서가 있음). 취약하지 않습니다).

현재 모든 CPU는 최신 4.15 커널에서 취약한 것으로 취급됩니다 .


4.15가 아직 공개되지 않았습니다
Aadhil RF

kernel.org 에서 최신 릴리스 후보를 다운로드하여 직접 컴파일하는 경우입니다. @Mohammedaadhil
JonasCz

1
릴리스 후보는 릴리스가 아닙니다.
Ruslan


2
커널 4.14.11은 cpu_insecure모든 x86 CPU에 대해 설정 됩니다. 4.14.12 이상은 Intel CPU에 대해서만 설정합니다 (너무 오래되었거나 너무 원시적 인 CPU 포함) KPTI가 비활성화되어 있어도 둘 다 설정합니다
Mark


2

확인할 수 있습니다 /proc/config.gz 에 대한 CONFIG_PAGE_TABLE_ISOLATION=y커널 KPTI로 컴파일 된 것을 의미한다.

이것은 4.14.11-1을 실행하는 패치 된 Arch Linux 시스템에 있습니다.

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

3
불행히도 현재 실행중인 커널의 구성은 /proc/우분투 커널에서 기본적으로 활성화되어 있지 않습니다. (훨씬 덜 우아한) 해결 방법은 /boot/config-$( uname -r )대신 grepping 입니다.
blubberdiblub

5
커널이 KPTI로 컴파일되었는지 여부 만 알려줍니다. KPTI가 활성화되어 있지 않은 경우 (부팅시 또는 런타임에 끌 수 있음).
Mark

커널 명령 줄 매개 변수를 통해 KPTI를 명시 적으로 비활성화 한 경우 활성화되어 있는지 여부를 확인할 필요가 없습니다.
Raniz

1

AWS Ubuntu 14.04.5 LTS EC2 인스턴스에서

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

다음과 같이 말해야합니다.

CONFIG_PAGE_TABLE_ISOLATION=y

업데이트를 위해 나는 :

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

나는 또한 이것도 괜찮다고 생각한다.

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

커널 버전을 확인하려면

uname -r

할 필요가 3.13.0-139 제네릭 이상.


이 방법은 이미 최고 답변
wjandrea
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.