จะตรวจสอบได้อย่างไรว่าเปิดใช้งาน KPTI บน Ubuntu ของฉันแล้ว?


64

ช่องโหว่ของโปรเซสเซอร์ Meltdown Intel ในปัจจุบันได้รับการแก้ไขโดยเปิดใช้งานการแยกตารางหน้า มีคำถามว่าจะปิดการทำงานนี้ได้อย่างไร : จะปิดการใช้งาน Page Table Isolation เพื่อให้ได้ประสิทธิภาพที่หายไปเนื่องจากการแก้ไขช่องโหว่ความปลอดภัยของ CPU ของ Intel

คำถามของฉันอยู่ตรงข้าม: มีวิธีตรวจสอบระบบที่กำลังรันอยู่หรือไม่ว่ากลไก 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

คำตอบที่ยอดเยี่ยม - สั้นและตรงประเด็น ขอขอบคุณ.
Martin Vysny

63
  • Grepping CONFIG_PAGE_TABLE_ISOLATION ในเคอร์เนล config ตามที่Raniz แนะนำไม่ช่วยบนเดสก์ท็อป Ubuntu แต่อาจช่วยในกรณีอินสแตนซ์ของระบบคลาวด์:

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

  • คุณสามารถตรวจสอบด้วย/proc/cpuinfoตามที่JonasCz แนะนำ :

    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 :("
    

  • คุณสามารถรวบรวมโปรแกรมทดสอบจาก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).

  • ตรวจสอบด้วยเครื่องมือจากhttps://github.com/speed47/spectre-meltdown-checker :

    cd /tmp
    wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
    sudo sh /tmp/spectre-meltdown-checker.sh
    

ในระบบที่มีการติดตั้งควรแสดงสิ่งต่อไปนี้:

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)

อย่าติดตั้ง 4.4.0-108-generic บน Xenial! มันแบ่งฟังก์ชั่นการบูต / รีบูต / ปิด / หยุดชั่วคราว !

ติดตั้ง 4.4.0-109-generic ( ดู USN-3522-3สำหรับรายละเอียด)!


ในฐานะที่เป็นบิ Basak แล้วเขียนมีหน้าเกี่ยวกับผีและล่มสลายช่องโหว่สถานะในอูบุนตู

นอกจากนี้ยังมี:


3
อัปเดตสำหรับ Ubuntu นั้นมีกำหนดเวลาสำหรับ Januari 9 พวกเขาอาจลงจอดก่อนหน้านี้ แต่ฉันจะไม่นับมัน insights.ubuntu.com/2018/01/04/…
Raniz

4
คำตอบประเภท "dmesg | grep isolated" นั้นเหมาะสมกว่า IMO การแจกแจงบางอย่าง (อย่างน้อย Debian อาจเป็นอย่างอื่น) ส่งต่อ PTI ไปยังเคอร์เนลเก่า แต่ไม่ใช่แฟล็ก cpu_insecure ใน / proc / cpuinfo ในระบบเหล่านั้นการค้นหาในบันทึก dmesg เป็นวิธีเดียวที่จะตรวจสอบ AFAICT
Jason Creighton

3
ฉันคิดว่าdmesg | grep isolation && echo "patched :)" || echo "unpatched :("คำสั่งตามที่ระบุไว้เป็นอันตรายโดยไม่จำเป็น: มันไม่ได้แสดงว่าบรรทัดใดที่ตรงกับความจริงและจะพิมพ์ "patched :)" อย่างมีความสุขหากสุ่มตัวอย่างอื่น ๆ ของ "แยก" ถูกจับคู่ ...
Jaap Eldering

2
ฉันอยากจะแนะนำกับข้อเสนอแนะที่สอง (grepping /proc/cpuinfoสำหรับ cpu_insecure) หากคุณใส่มันลงในสคริปต์และคุณมีซีพียูในอนาคตซึ่งปัญหาได้รับการแก้ไขใน microarchitecture แล้วมัน/proc/cpuinfoจะไม่พูดอีกต่อไปcpu_insecureและสคริปต์ของคุณจะเชื่อว่าเคอร์เนลไม่ได้ถูกแก้ไขแม้ว่าจะได้รับการแก้ไขแล้วก็ตาม ฉันจะแนะนำต่อข้อเสนอแนะที่สามเนื่องจากมีโอกาสมากเกินไปที่อาจมีคำisolationในdmesgเอาต์พุตในบางจุดโดยที่ไม่ได้อ้างถึงการแยกตารางหน้าเคอร์เนล
blubberdiblub

4
เมื่อตรวจสอบเพิ่มเติมข้อเสนอแนะทั้งสามนี้จะใช้งานไม่ได้ grepping สำหรับisolationจะตรงกับทั้งสองและKernel/User page tables isolation: enabled Kernel/User page tables isolation: disabled on command line
ทำเครื่องหมาย

18

รันคำสั่งต่อไปนี้:

dmesg | grep 'page tables isolation'

หากแสดงว่าเปิดใช้งานแสดงว่ามีการเปิดใช้งาน PTI หากไม่มีสิ่งใดปรากฏขึ้นหรือคุณเห็น 'ปิดการใช้งาน' ในเทอร์มินัลแสดงว่า PTI ถูกปิดใช้งาน Ubuntu ยังไม่ได้เผยแพร่โปรแกรมแก้ไขดังนั้นจึงไม่แสดงข้อความใด ๆ


... หรือข้อความเคอร์เนลในภายหลังได้ผลักข้อความ bootup ออกจากบัฟเฟอร์บันทึกเคอร์เนล หากเคอร์เนลของคุณพิมพ์ประกาศสำหรับสิ่งที่มีความรุนแรงต่ำเช่นแพ็คเก็ตเครือข่ายแปลก ๆ เป็นเรื่องปกติที่ข้อความเวลาบูตจะไม่ได้เป็นส่วนหนึ่งของdmesgเอาต์พุต ดู/var/log/kern.log*ว่ามันกลับไปไกลพอที่จะรับข้อความการบู๊ตได้หรือไม่ Ubuntu เคยบันทึกdmesgเอาท์พุทเวลาบูทมา/var/log/dmesgแต่ดูเหมือนจะไม่ทำเช่นนั้นอีกแล้ว
Peter Cordes

เมื่อวันที่ 14.04 dmesg: invalid option -- 'w'ผมได้ -Hก็ไม่ถูกต้องเช่นกัน การลบธงทำงานได้ดีสำหรับฉันเช่นเดียวกับในคำตอบนี้
wjandrea

/var/log/kern.log เมื่อวันที่ 14.04
eckes

12

คุณสามารถตรวจสอบได้cat /proc/cpuinfoหากรายงานcpu_insecureภายใต้ "บั๊ก" แสดงว่า PTI เปิดใช้งานแล้ว

ถ้ามันว่างเปล่า (หรือไม่อยู่ในรายการcpu_insecure) แสดงว่าเป็นไปได้มากว่าคุณกำลังใช้เคอร์เนลซึ่งยังไม่ได้รับการแก้ไข (อูบุนตูยังไม่ได้) หรือคุณมีโปรเซสเซอร์ AMD (ซึ่งสิ่งนี้จะไม่เปิดใช้งานนานเกินไป ไม่เปราะบาง)

ปัจจุบันซีพียูทั้งหมดได้รับการปฏิบัติเหมือนมีความเสี่ยงในเคอร์เนล 4.15 ล่าสุด


4.15 ยังไม่ออกสู่สาธารณะ
Aadhil RF

ถ้าคุณดาวน์โหลดตัวเลือกรุ่นล่าสุดจากkernel.orgและรวบรวมด้วยตัวคุณเอง @Mohammedaadhil
JonasCz พูดว่า Reinstate Monica

1
ผู้สมัครรับการปล่อยตัวไม่ใช่การเปิดตัว
Ruslan

บทความที่คุณเชื่อมโยงได้รับการอัปเดตแล้ว
nixpower

2
เคอร์เนล 4.14.11 จะถูกตั้งค่าcpu_insecureสำหรับ x86 CPU ใด ๆ 4.14.12 และใหม่กว่าจะตั้งค่าเฉพาะสำหรับ Intel CPUs (รวมถึงรุ่นที่เก่าเกินไปหรือดั้งเดิมเกินไปที่จะมีช่องโหว่) ทั้งคู่จะตั้งค่าแม้ว่า KPTI จะถูกปิดใช้งาน
Mark

8

ฉันพบสคริปต์ sh ที่ยอดเยี่ยมนี้เพื่อทดสอบช่องโหว่ Meltdown / Spectre บนระบบของคุณ:

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

สคริปต์จะตรวจสอบระบบของคุณเพื่อทราบ Meltdown และ Spectre Patchs บนระบบของคุณเพื่อบอกคุณว่าช่องโหว่เหล่านี้ได้รับการแก้ไขโดยระบบปฏิบัติการของคุณแล้วหรือยัง


2

คุณสามารถตรวจสอบ/proc/config.gzสำหรับCONFIG_PAGE_TABLE_ISOLATION=yซึ่งหมายความว่าเมล็ดที่ถูกรวบรวมกับ KPTI

นี่คือในระบบ Arch Linux ที่แพตช์ของฉันใช้งาน 4.14.11-1:

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

3
น่าเสียดายที่การกำหนดค่าของเคอร์เนลที่กำลังทำงานอยู่/proc/นั้นไม่ได้เปิดใช้งานโดยค่าเริ่มต้นในเมล็ดของ Ubuntu วิธีแก้ปัญหา (หรูหราน้อยกว่า) กำลัง grepping /boot/config-$( uname -r )แทน
blubberdiblub

5
ซึ่งจะบอกคุณว่าเคอร์เนลถูกคอมไพล์ด้วย KPTI ไม่ใช่ถ้า KPTI แอ็คทีฟ (สามารถปิดได้ในเวลาบูตและอาจเป็นที่รันไทม์)
ทำเครื่องหมาย

หากคุณปิดใช้งาน 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-genericหรือใหม่กว่า


วิธีนี้ถูกกล่าวถึงแล้วในคำตอบด้านบน
wjandrea
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.