การโจมตี Downfall
(downfall.page)- ช่องโหว่ CVE-2022-40982 ในโปรเซสเซอร์ Intel ที่ใช้กันอย่างแพร่หลายในคอมพิวเตอร์ส่วนบุคคลและคลาวด์ ทำให้สามารถขโมยข้อมูลของผู้ใช้รายอื่นที่ใช้คอมพิวเตอร์เครื่องเดียวกันร่วมกันได้
- แก่นของช่องโหว่อยู่ที่ คำสั่ง Gather ในกระบวนการปรับแต่งหน่วยความจำ ซึ่งเปิดเผยเนื้อหาใน internal vector register file ระหว่าง speculative execution
- การโจมตีถูกนำไปใช้ด้วยเทคนิค GDS·GVI โดยเดโมแสดงการรั่วไหลข้ามขอบเขตการแยกส่วน เช่น กุญแจ AES, ข้อมูล Linux Kernel และการเฝ้าดูอักขระที่พิมพ์ออกมาได้
- ขอบเขตผลกระทบครอบคลุมตั้งแต่ Intel Core รุ่นที่ 6 Skylake ถึงรุ่นที่ 11 Tiger Lake และผู้ใช้คลาวด์อาจได้รับผลกระทบแม้ไม่ได้เป็นเจ้าของอุปกรณ์ Intel โดยตรง
- อัปเดตไมโครโค้ด ของ Intel จะบล็อกผลลัพธ์ transient ของ Gather แต่ workload บางส่วนอาจมี overhead สูงสุด 50% หลังใช้มาตรการบรรเทา
ช่องโหว่ที่ Downfall มุ่งโจมตี
- Downfall มุ่งเป้าไปที่ จุดอ่อนสำคัญ ของโปรเซสเซอร์สมัยใหม่ที่ใช้ในคอมพิวเตอร์ส่วนบุคคลและคอมพิวเตอร์คลาวด์
- ช่องโหว่นี้ถูกระบุเป็น CVE-2022-40982
- สามารถเข้าถึงและขโมยข้อมูลของผู้ใช้รายอื่นที่ใช้คอมพิวเตอร์เครื่องเดียวกันร่วมกันได้
- แอปอันตรายที่ดาวน์โหลดจาก app store อาจขโมยข้อมูลอ่อนไหว เช่น รหัสผ่าน กุญแจเข้ารหัส ข้อมูลธนาคาร อีเมลส่วนตัว และข้อความ
- บนคลาวด์ ลูกค้าที่เป็นอันตรายอาจขโมยข้อมูลและ credential ของลูกค้ารายอื่นที่ใช้คอมพิวเตอร์คลาวด์เครื่องเดียวกันร่วมกันได้
สาเหตุทางเทคนิคของช่องโหว่
- ฟังก์ชันปรับแต่งหน่วยความจำ ของโปรเซสเซอร์ Intel เปิดเผย internal hardware registers ให้ซอฟต์แวร์โดยไม่ได้ตั้งใจ
- ซอฟต์แวร์ที่ไม่น่าเชื่อถือสามารถเข้าถึงข้อมูลของโปรแกรมอื่นที่ตามปกติไม่ควรเข้าถึงได้
- คำสั่ง Gather สำหรับอ่านข้อมูลที่กระจัดกระจายในหน่วยความจำให้เร็วขึ้น ทำให้เนื้อหาใน internal vector register file รั่วไหลระหว่าง speculative execution
- เทคนิคที่ใช้โจมตีช่องโหว่นี้คือ Gather Data Sampling(GDS) และ Gather Value Injection(GVI)
- รายละเอียดทางเทคนิคสรุปไว้ใน เอกสารวิจัย Downfall
ตัวอย่างการรั่วไหลที่ยืนยันด้วยเดโม
- เดโม Downfall แสดงให้เห็นว่าข้อมูลอ่อนไหวสามารถรั่วไหลข้ามขอบเขตการแยกส่วนที่แตกต่างกันได้
ระบบที่ได้รับผลกระทบและเงื่อนไขการโจมตี
- อุปกรณ์ที่ได้รับผลกระทบคืออุปกรณ์คอมพิวเตอร์ที่ใช้โปรเซสเซอร์ตั้งแต่ Intel Core รุ่นที่ 6 Skylake ถึงรุ่นที่ 11 Tiger Lake
- รายชื่อโปรเซสเซอร์ที่ได้รับผลกระทบอย่างครอบคลุมกว่านี้จะมีให้ใน รายชื่อ affected processors ของ Intel
- ผู้ใช้คลาวด์อาจได้รับผลกระทบได้แม้ไม่มีอุปกรณ์ที่ใช้ Intel ทางกายภาพ
- ส่วนแบ่งตลาดเซิร์ฟเวอร์ของ Intel มากกว่า 70%
- ผู้โจมตีสามารถมุ่งเป้าไปที่ credential มูลค่าสูง เช่น รหัสผ่านและกุญแจเข้ารหัส
- การขโมย credential อาจนำไปสู่การโจมตีอื่นที่กระทบต่อ availability และ integrity ของคอมพิวเตอร์ นอกเหนือจากการละเมิด confidentiality
- GDS ค่อนข้างนำไปใช้เป็นการโจมตีจริงได้ง่าย
- ใช้เวลา 2 สัปดาห์ในการพัฒนาการโจมตีแบบ end-to-end เพื่อขโมยกุญแจเข้ารหัสจาก OpenSSL
- เพียงผู้โจมตีและเหยื่อต้องใช้แกนโปรเซสเซอร์ทางกายภาพเดียวกันร่วมกัน
- ในคอมพิวเตอร์สมัยใหม่ที่ใช้ preemptive multitasking และ simultaneous multithreading การใช้ร่วมกันลักษณะนี้เกิดขึ้นบ่อย
ขอบเขตการแยกส่วน, SGX และผลกระทบต่อเบราว์เซอร์
- Downfall ส่งผลกระทบต่อขอบเขตการแยกส่วนทั่วไปด้วย
- virtual machine
- process
- การแยก user-kernel
- Intel SGX ก็ได้รับผลกระทบเช่นกัน
- Intel SGX เป็นฟีเจอร์ความปลอดภัยระดับฮาร์ดแวร์ของ Intel CPU ที่ออกแบบมาเพื่อปกป้องข้อมูลผู้ใช้จากซอฟต์แวร์อันตราย
- การโจมตีจากระยะไกลผ่านเว็บเบราว์เซอร์เป็นไปได้ในเชิงทฤษฎี
- แต่การแสดงการโจมตีที่สำเร็จจริงในเบราว์เซอร์ยังต้องมีการวิจัยและงานวิศวกรรมเพิ่มเติม
ระยะเวลาที่เปิดรับความเสี่ยงและความยากในการตรวจจับ
- ผู้ใช้เปิดรับช่องโหว่นี้มาอย่างน้อย 9 ปี
- โปรเซสเซอร์ที่ได้รับผลกระทบมีมาตั้งแต่ปี 2014
- การโจมตี Downfall ตรวจจับได้ยาก
- รูปแบบการทำงานส่วนใหญ่ดูเหมือนแอปพลิเคชันปกติ
- ในทางทฤษฎี สามารถสร้างระบบที่ใช้ hardware performance counters เพื่อตรวจจับพฤติกรรมผิดปกติ เช่น cache miss ที่มากเกินไปได้
- ซอฟต์แวร์แอนติไวรัสเชิงพาณิชย์ทั่วไปไม่สามารถตรวจจับการโจมตีนี้ได้
มาตรการบรรเทาและ overhead ด้านประสิทธิภาพ
- Intel ได้เผยแพร่ อัปเดตไมโครโค้ด
- อัปเดตนี้บล็อกผลลัพธ์ transient ของคำสั่ง Gather
- ทำให้โค้ดของผู้โจมตีไม่สามารถสังเกตข้อมูลจาก speculative execution ที่มาจาก Gather ได้
- overhead ของมาตรการบรรเทาขึ้นอยู่กับว่า Gather อยู่ใน critical execution path ของโปรแกรมหรือไม่
- Intel ระบุว่า workload บางส่วนอาจมี overhead สูงสุด 50%
- การปิดมาตรการบรรเทาเพียงเพราะ workload ไม่ได้ใช้ Gather นั้นไม่ปลอดภัย
- CPU สมัยใหม่ใช้ vector register เพื่อปรับแต่งงานทั่วไป เช่น การคัดลอกหน่วยความจำและการสลับเนื้อหา register
- ในกระบวนการนี้ ข้อมูลอาจรั่วไหลไปยังโค้ดที่ไม่น่าเชื่อถือซึ่งใช้ Gather ในทางที่ผิดได้
กำหนดการเปิดเผยและโค้ดสำหรับทำซ้ำ
- ช่องโหว่นี้อยู่ภายใต้ embargo มาเกือบ 1 ปี
- มีการรายงานต่อ Intel เมื่อวันที่ 24 สิงหาคม 2022
- Downfall ถูกนำเสนอที่ BlackHat USA เมื่อวันที่ 9 สิงหาคม 2023 และที่ USENIX Security Symposium เมื่อวันที่ 11 สิงหาคม 2023
- โค้ดสำหรับทำซ้ำเผยแพร่ไว้ใน GitHub POC
สิ่งที่ผู้ออกแบบโปรเซสเซอร์รายอื่นควรระวัง
- โปรเซสเซอร์อื่นก็มี หน่วยความจำ SRAM ที่ใช้ร่วมกัน เช่น hardware register file และ fill buffer ภายในคอร์
- ผู้ผลิตควรออกแบบ shared memory unit อย่างระมัดระวังมากขึ้น เพื่อไม่ให้ข้อมูลรั่วไหลระหว่าง security domain ที่แตกต่างกัน
- ควรลงทุนมากขึ้นในการตรวจสอบยืนยันและการทดสอบด้านความปลอดภัย
ชื่อและช่องโหว่ที่เกี่ยวข้อง
- ชื่อ Downfall ตั้งขึ้นจากความหมายว่ามันทำลายขอบเขตความปลอดภัยพื้นฐานของคอมพิวเตอร์ส่วนใหญ่
- Downfall สามารถมองได้ว่าเป็นภาคต่อของช่องโหว่ข้อมูลรั่วไหลใน CPU ก่อนหน้าอย่าง Meltdown และ Fallout
- ในลำดับนี้ Downfall สามารถเลี่ยงมาตรการบรรเทาเดิมๆ ได้อีกครั้ง
คำแนะนำจาก vendor และเอกสารทางเทคนิค
- คำแนะนำด้านความปลอดภัย:
- MITRE: CVE-2022-40982
- Intel: INTEL-SA-00828
- AWS: AWS-2023-007
- GCP: GCP-2023-024
- Debian: CVE-2022-40982
- Ubuntu: CVE-2022-40982
- Red Hat: CVE-2022-40982
- VMware: การรับมือ Gather Data Sampling
- เอกสารทางเทคนิคของ Intel:
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
รู้สึกแปลกที่หลังจาก การโจมตี Spectre ในช่วงแรก นักวิจัยภายนอกก็ยังค้นพบการโจมตีลักษณะคล้ายกันอย่างต่อเนื่อง แล้วผู้ผลิตชิปค่อยออกแพตช์ตามมา
โดยหลักแล้ว ผู้ผลิตชิปควรเป็นผู้เชี่ยวชาญด้าน speculative execution รู้การทำงานของชิปอย่างแม่นยำ และยังมีชุดทดสอบตรวจสอบความถูกต้อง ซิมูเลเตอร์ ไปจนถึงสเปกภายในที่เครื่องอ่านได้ จึงน่าจะอยู่ในตำแหน่งที่ได้เปรียบที่สุดในการค้นพบปัญหา
นักวิจัยภายนอกต้องสำรวจกล่องดำ และต้องทำ reverse engineering จากข้อมูลที่ด้อยกว่ามาก เช่น สิทธิบัตร แต่แม้ผ่านมาหลายปีแล้ว บุคคลทั่วไปหรือกลุ่มภายนอกก็ยังค้นพบช่องโหว่เหล่านี้อยู่
ก่อน Spectre อาจเป็นไปได้ว่ายังไม่เคยพิจารณาเวกเตอร์การโจมตีแบบนี้ แต่หลังจากกลไกทั่วไปถูกเปิดเผยแล้ว ผู้ผลิตชิปก็น่าจะรวบรวมคนที่ฉลาดที่สุดแล้วบอกว่า “ค้นให้ทั่วและหาการโจมตีแบบ Spectre อื่น ๆ ให้เจอ” ไม่ใช่หรือ
หรือบางทีพวกเขาอาจรู้อยู่แล้วทั้งหมด แต่กลบไว้โดยหวังว่าจะไม่ถูกเปิดเผย เพื่อรักษาหน้าและหลีกเลี่ยงผลกระทบต่อประสิทธิภาพ
ถ้าเป็นสิ่งที่คนหลายพันล้านคนใช้งาน ก็ย่อมมีคนพบปัญหา ข้อบกพร่อง และ exploit ได้มากกว่าฝ่ายที่สร้างมันขึ้นมาอยู่แล้ว การที่ปัญหาเหล่านั้นมีอยู่จริงไม่ได้ช่วยสนับสนุนหรือหักล้างข้อสรุปเพิ่มเติมเกี่ยวกับสาเหตุของมัน
นักวิจัยด้านความปลอดภัยมีแรงจูงใจที่จะค้นพบบางอย่างเพื่อสร้างชื่อเสียง บ่อยครั้งพวกเขาอ้างว่าสิ่งนั้นเป็นช่องโหว่ด้านความปลอดภัยระดับเขย่าโลก ทั้งที่สำหรับผู้โจมตีจริงแล้วแทบไม่มีความหมาย
เคยพบ การโจมตีแบบ speculative execution ในสภาพแวดล้อมจริงหรือไม่? อาจจะไม่เคยก็ได้ ถ้าเป็นเช่นนั้น เหตุผลที่ผู้ขายชิปจะใช้เงินมหาศาลกับเรื่องนี้ก็อ่อนมาก
ลูกค้าจริงไม่ได้รับความเสียหาย ยกเว้นตอนที่นักวิจัยภายนอกบังคับให้ต้องดำเนินการจนต้องออกไมโครโค้ดใหม่ที่ทำให้ประสิทธิภาพช้าลง
อีกเรื่องที่น่าสังเกตคือ มาตรการบรรเทาการโจมตีแบบนี้มักมีสวิตช์ให้ปิดเสมอ ซึ่งไม่ใช่รูปแบบที่พบได้บ่อยในแพตช์ความปลอดภัย และในหลายกรณีก็เพราะการโจมตีเหล่านี้ไม่ได้สำคัญมากนัก
ซอฟต์แวร์ที่รันบนคอร์กายภาพเดียวกันหรือ CPU กายภาพเดียวกันมักมีระดับความเชื่อถือเท่ากัน หรือไม่ก็ถูก sandbox อย่างเข้มงวดจนไม่สามารถทำการโจมตีได้
Intel ทำให้ชิป “ฉลาดที่สุดเท่าที่เป็นไปได้” อย่างไม่ต้องสงสัย และดังนั้นโดยนิยามแล้วจึงไม่สามารถดีบักได้อย่างสมบูรณ์
สิ่งสำคัญอีกอย่างคือ เรื่องเหล่านี้ไม่ใช่บั๊ก การออกแบบทำงานตามที่ตั้งใจไว้ เราเข้าใจว่า CPU จะมีประสิทธิภาพแตกต่างกันไปตามโค้ดที่เคยรันมาก่อน และยอมรับมันเพราะประเมินว่าต้นทุนของทางเลือกอื่นสูงเกินไปในแง่พลังงาน ประสิทธิภาพ และพื้นที่ นั่นแหละคือวิศวกรรม เป็นการชั่งน้ำหนักทางเลือกแล้วตัดสินใจ
ในกรณีนี้ เมื่อ CPU เร็วพอ เศษเสี้ยวเล็ก ๆ ของบิตต่อการวนซ้ำก็กลายเป็นแบนด์วิดท์ที่โจมตีได้ แต่อุตสาหกรรมต้องมีใครสักคนแสดงให้เห็นก่อนจึงจะเข้าใจ สิ่งนั้นเปลี่ยนการตัดสินเชิงวิศวกรรม
ลิงก์เอกสารของ Intel ใช้งานไม่ได้แล้ว และลิงก์ที่ถูกต้องดูเหมือนจะเป็นอันนี้: https://www.intel.com/content/www/us/en/developer/articles/t...
ข้อควรระวังทั่วไปคือ ยังมีคลาวด์จำนวนมากที่รันเวิร์กโหลดของผู้ใช้ต่างกันบนคอร์กายภาพเดียวกันอยู่หรือ? คิดว่าส่วนใหญ่เปลี่ยน scheduler ไปเมื่อหลายปีก่อนแล้วเพื่อป้องกันการรั่วไหลข้ามโดเมนระหว่าง hyperthread
คำกล่าวที่ว่ามีผลกระทบต่อผู้ใช้ทุกคนบนอินเทอร์เน็ตดูเหมือนจะเกินจริงไปมาก ยังไม่เห็น exploit ที่ทำงานผ่านเบราว์เซอร์ และแม้จะมีอยู่จริง ก็น่าจะกระทบเฉพาะผู้ใช้จำนวนน้อยมากที่ถูกเล็งเป้าเท่านั้น นับตั้งแต่ Spectre ออกมาก็ผ่านมาหลายปีแล้ว ไม่แน่ใจว่าเคยพบการโจมตีแบบ speculative execution ในสภาพแวดล้อมจริงหรือไม่
สิ่งที่น่าสนใจกว่าคือ บั๊ก speculative execution เหล่านี้ดูเหมือนยังคง patch ด้วย microcode ได้เรื่อย ๆ ตอนที่มันปรากฏขึ้นครั้งแรก เคยมีความกลัวว่าอาจต้องทิ้งและเปลี่ยนชิปกายภาพจำนวนมาก แต่ในความเป็นจริงเคยมีครั้งไหนที่จำเป็นต้องทำแบบนั้นหรือไม่?
เท่าที่รู้ บั๊กทั้งหมดรับมือได้ด้วยการผสมผสานระหว่างการเปลี่ยนแปลงซอฟต์แวร์กับ microcode และในบางกรณีก็จ่ายต้นทุนด้านประสิทธิภาพไปบ้าง ไม่มีบั๊กไหนที่ต้องใช้ซิลิคอนใหม่ ข้อยกเว้นก็อาจเป็นกรณีที่ถูกเจาะจนหลุดออกจาก sandbox แบบที่ patch ไม่ได้จริง ๆ เช่น AMD SEV รุ่นแรก ๆ
แน่นอนว่ามีแบบแชร์อย่าง T series ของ AWS และคลาวด์อื่นก็น่าจะมีอะไรคล้ายกัน แต่คิดว่าน่าจะใส่ “flush” เพิ่มระหว่างผู้ใช้เพื่อป้องกันการรั่วไหลข้าม tenant ได้
แน่นอนว่าการรั่วไหลระหว่างโปรเซสภายใน tenant เดียวกันเป็นปัญหาไม่ว่าจะเป็นคลาวด์หรือ on-premises และสุดท้ายก็ต้องตัดสินใจว่าจะเชื่อมากแค่ไหนว่าโปรเซสบนเครื่องของตัวเองจะไม่กลายเป็นตัวร้าย
การรันโค้ดจากโดเมนความปลอดภัยต่างกันบนคอร์โปรเซสเซอร์กายภาพเดียวกันดูเหมือนทำให้ถูกต้องได้เป็นไปไม่ได้ และน่าจะถึงเวลาหยุดทำแล้ว
กรณีที่พบบ่อยจริง ๆ มีแค่สองอย่างคือ VM กับ JavaScript
VM ควรต้องยอมแพ้ ควรจัดคอร์เฉพาะให้กับ VM เฉพาะ หรืออย่างน้อยก็ให้กับลูกค้าเฉพาะราย
JavaScript ยากกว่านั้นหน่อย
ไม่ว่าจะทางไหน ก็ไม่ควรยอมเสียประสิทธิภาพในกรณีทั่วไป
IOPU ทำหน้าที่ควบคุมฮาร์ดแวร์อื่น ๆ ในระบบ และไม่จำเป็นต้องมีประสิทธิภาพสูงมาก
SPU ปรับให้เหมาะกับโค้ด scalar ที่ต้องรันเร็วและโค้ดที่มี branch เยอะ
SPU ต้องมีความปลอดภัยขั้นต่ำแค่ระดับที่ป้องกันไม่ให้อ่านหน่วยความจำสุ่มเมื่อดึงข้อมูลจาก RAM ก็พอ เพราะรันโปรแกรมเดียวในแต่ละครั้ง speculative execution ก็น่าจะไม่เป็นปัญหา
ในระบบของผม มีโปรแกรมที่ต้องใช้พลังประมวลผลมากน้อยมาก และแม้ต้องใช้ก็เป็นครั้งคราว จึงคิดว่าบน SPU คงไม่มีการสลับงานบ่อยนัก
การโจมตี CPU แบบนี้แสดงให้เห็นว่าระบบ time-sharing ที่ปลอดภัยซึ่งผู้ใช้รันโค้ดเครื่องตามใจได้ไม่ใช่สิ่งที่เป็นจริงได้อีกต่อไป
time-sharing ในกรณีที่ผู้ใช้เชื่อใจกัน เช่น คนในโปรเจกต์เดียวกันแชร์เครื่อง build ยังคงเหลืออยู่
ความคิดที่ว่าจะป้องกันไม่ให้สองโปรแกรมที่รันบนคอมพิวเตอร์แอบดูข้อมูลกันได้ ก็อยู่ในระดับนั้น
คำแนะนำด้านความปลอดภัยของ Intel: https://www.intel.com/content/www/us/en/developer/articles/t...
การ merge ใน Linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
บอกว่ากระทบแค่ถึงรุ่นที่ 11 เท่านั้น แต่ดูเหมือนช่วงเวลาที่ช่องโหว่นี้ถูกเปิดเผยต่อ Intel ไม่น่าจะเร็วพอให้แก้ในรุ่นที่ 12 ได้ ถ้าอย่างนั้นก็อาจเป็นว่าไปแก้อะไรอย่างอื่นแล้วบังเอิญแก้เรื่องนี้ได้ด้วยหรือเปล่า
ดูจากงานวิจัยแล้วมีข้อความว่า “Intel ระบุว่า CPU รุ่นใหม่อย่าง Alder Lake, Raptor Lake, Sapphire Rapids ไม่ได้รับผลกระทบ อย่างไรก็ตาม ดูเหมือนจะเป็นผลข้างเคียงจากสถาปัตยกรรมที่เปลี่ยนไปมาก มากกว่าจะเป็นเพราะการพิจารณาด้านความปลอดภัย”
สุดท้ายก็เหมือนถูกแก้ไปแบบสุ่ม ๆ หรืออย่างน้อยก็ทำให้เอ็กซ์พลอยต์ตัวนี้ใช้การไม่ได้
ตาม FAQ ผู้ใช้เปิดรับช่องโหว่นี้มาอย่างน้อย 9 ปีแล้ว เพราะโปรเซสเซอร์ที่ได้รับผลกระทบมีมาตั้งแต่ปี 2014
น่าทึ่งที่ช่องโหว่แบบนี้ไม่ถูกสังเกตเห็นมาหลายปี แต่พอมีคนมาเขียนเอ็กซ์พลอยต์กลับใช้เวลาแค่ 2 สัปดาห์
อ้างอิงบทความ LWN: https://lwn.net/Articles/940783/
บน Linux สำหรับ CPU ที่ไม่มีไมโครโค้ดอัปเดต AVX จะถูกปิดใช้งานทั้งหมด เพื่อเป็นมาตรการบรรเทาปัญหานี้ สำหรับผมถือว่าค่อนข้างรุนแรงและน่าจะรู้สึกได้ชัด ตอนนี้เลยอยากไปดูว่าจะรับไมโครโค้ดอัปเดตได้หรือไม่
gather_data_sampling=forceเท่านั้น ค่าเริ่มต้นคือปล่อย AVX ไว้เหมือนเดิมและทำเครื่องหมายว่าระบบมีช่องโหว่ดูได้จาก https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...:
เมื่อระบุ
gather_data_sampling=forceจะใช้มาตรการบรรเทาผ่านไมโครโค้ดหากเป็นไปได้ และบนระบบที่ได้รับผลกระทบซึ่งไมโครโค้ดยังไม่ได้อัปเดตให้มีมาตรการบรรเทานั้น จะปิดใช้งาน AVXหมายเหตุ ผมทำงานด้าน Linux ที่ Intel เอง เป็นไปได้สูงว่าผมเป็นคนเขียนหรือแก้เอกสารกับ changelog ที่ทำให้คนสับสนเหล่านั้น
[ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12ใช้ Haswell อยู่ มีรายการไหมว่า CPU รุ่นไหนจะได้ไมโครโค้ดอัปเดต น่าเสียดาย
อีกเรื่องที่น่าสังเกตคือ GCP ได้แพตช์ปัญหานี้แล้ว: https://cloud.google.com/support/bulletins#gcp-2023-024
ข้อมูลและอินสแตนซ์ของลูกค้า AWS ไม่ได้รับผลกระทบจากปัญหานี้ และลูกค้าไม่ต้องดำเนินการใด ๆ
AWS ได้ออกแบบและนำโครงสร้างพื้นฐานที่มีการป้องกันปัญหาประเภทนี้มาใช้แล้ว อินสแตนซ์ Amazon EC2 รวมถึง Lambda, Fargate และบริการคอมพิวต์/คอนเทนเนอร์ที่ AWS จัดการอื่น ๆ ปกป้องข้อมูลลูกค้าจาก GDS ผ่านไมโครโค้ดและมาตรการบรรเทาที่อิงซอฟต์แวร์
ผลกระทบต่อประสิทธิภาพหนักมาก มีการอ้างว่าสูงสุด 50% และว่าโปรเซสเซอร์ Intel รุ่นใหม่ 70% ได้รับผลกระทบ
https://access.redhat.com/solutions/7027704
ผลกระทบต่อประสิทธิภาพจำกัดอยู่ที่แอปพลิเคชันที่ใช้ คำสั่ง gather และคำสั่ง CLWB ที่ Intel Advanced Vector Extensions (AVX2 และ AVX-512) มีให้ ผลกระทบต่อประสิทธิภาพจริงขึ้นอยู่กับว่าแอปพลิเคชันใช้คำสั่งเหล่านั้นมากเพียงใด
หากผู้ใช้ตัดสินใจหลังจากวิเคราะห์ความเสี่ยงอย่างรอบคอบแล้วว่าจะปิดมาตรการบรรเทา เช่น ระบบไม่ได้เป็น multi-tenant และไม่ได้รันโค้ดที่ไม่น่าเชื่อถือ ก็สามารถปิดมาตรการบรรเทาได้
หลังจากใช้ไมโครโค้ดและอัปเดตเคอร์เนลแล้ว สามารถปิดมาตรการบรรเทาได้โดยเพิ่ม
gather_data_samping=offใน kernel command line หรือถ้าต้องการปิดมาตรการบรรเทา speculative execution ของ CPU ทั้งหมดรวมถึง GDS ให้ใช้mitigations=offควรสงสัยคำกล่าวอ้างที่มีคำว่า “สูงสุด” เสมอ
NES มีชิปเซ็ตที่ฝัง 6502 ไว้ทั้งตัว และด้วยเงินเท่าราคาพิซซ่าหนึ่งถาดก็ซื้อชิป Rockchip ARM ที่ใส่คอร์แบบผสมไว้บนไดได้ บางทีผู้ผลิตชิปอาจไม่จำเป็นต้องแก้ edge case ทุกอย่างไปตลอดกาล และอาจผลักภาระการ บรรเทาการโจมตีแบบ side-channel แบบนี้กลับมาให้พวกเราที่ใช้ชิปกันก็ได้
แทนที่จะทำให้เป็นตัวเลือกระหว่างเปิด SMT ทั้งหมดหรือปิด SMT ทั้งหมด ลองส่งโค้ดที่ไม่น่าเชื่อถือไปยัง “คอร์ห่วย ๆ” แล้วให้ลูกค้า “พิสูจน์” ว่าสามารถเลื่อนขึ้นไปรันบนคอร์ที่มี SMT ได้ดีไหม?
ไม่มีใครอยากทำให้ชิปที่ใช้รันงานเงินเดือนระดับสำคัญสุด ๆ ซึ่งเอาอย่างอื่นขึ้นบอร์ดไม่ได้เสียหาย แต่การถูกบังคับให้แท็กสิ่งที่รันบน SMT ได้อย่างปลอดภัย และถ้าไม่แท็กก็จะถูกผูกไว้กับคอร์ที่ปลอดภัยกว่า แบบนั้นก็พอรับได้
อินเทิร์นที่ไม่รู้เลยว่าสิ่งนี้คืออะไร อาจไปค้นหาแล้วได้เรียนรู้ว่าเวกเตอร์การโจมตีนี้จริง ๆ คืออะไร และวางแผนป้องกันได้ด้วย
ผมแปลกไปเองหรือเปล่า?
คอร์ประสิทธิภาพ × คอร์ประหยัดพลังงานนั้นทำได้
แต่คงไม่มีใครอยากเป็นคนเสนอคอร์ที่เชื่อถือได้ × คอร์ไม่น่าเชื่อถือแบบ “ห่วย ๆ” ต่อให้มีข้อดีมากแค่ไหน ก็จะถูกกลบอยู่ในวาทกรรมว่า “สร้างความหวาดกลัว” ชีวิตก็แบบนี้