ZenHammer: การโจมตี Rowhammer ที่มุ่งเป้าแพลตฟอร์มที่ใช้ AMD Zen

 (comsec.ethz.ch)
1 คะแนน โดย GN⁺ 2024-03-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้ใน ระบบ AMD Zen 2·Zen 3 DDR4 ที่มีการบรรเทา TRR ก็ยังเกิด bit flip จาก Rowhammer ได้ แสดงว่าแพลตฟอร์ม AMD ก็อาจเป็นพื้นผิวโจมตีที่ใช้งานได้จริงเช่นกัน
  • ทีมวิจัยใช้เทคนิค DRAMA ที่ปรับให้เหมาะกับ AMD เพื่อวิศวกรรมย้อนกลับ ฟังก์ชันที่อยู่ DRAM ลับ และยืนยันว่าจำเป็นต้องจัดการออฟเซ็ตของที่อยู่กายภาพเนื่องจากการรีแมปที่อยู่ของระบบ
  • ZenHammer fuzzer ทำให้เกิด bit flip ได้ในอุปกรณ์ DDR4 10 ตัวที่รวม Samsung, Micron และ SK Hynix โดยเกิดกับ 7 ตัวบน Zen 2 และ 6 ตัวบน Zen 3 และอุปกรณ์ Zen 3 แสดงผลว่าเปราะบางกว่า Intel Coffee Lake
  • การโจมตีเดิมต่อ page table, การทำให้กุญแจสาธารณะ RSA-2048 เสียหาย และการโจมตี sudoers.so สามารถจัดทำได้ในอุปกรณ์ 7/6/4 ตัว ตามลำดับ และเวลาเฉลี่ยในการหา bit flip ที่ใช้โจมตีได้คือ 164/267/209 วินาที
  • ในการประเมิน DDR5 บน Zen 4 พบ bit flip ประมาณ 42,000 ครั้ง ในอุปกรณ์ 1 ตัวจาก 10 ตัว แต่ล้มเหลวในอีก 9 ตัวที่เหลือ จึงต้องศึกษารูปแบบเพิ่มเติมสำหรับ DDR5

bit flip จาก Rowhammer ที่เกิดขึ้นบน AMD Zen ด้วย

  • ZenHammer ทำให้เกิด bit flip จาก Rowhammer บนระบบ AMD Zen 2 และ Zen 3 ใน อุปกรณ์ DDR4 ที่มีการบรรเทา TRR
  • ยืนยันได้ว่าระบบ AMD ก็อาจมี ช่องโหว่ Rowhammer เช่นเดียวกับระบบ Intel
  • เมื่อพิจารณาว่าส่วนแบ่งตลาด CPU เดสก์ท็อป x86 ของ AMD อยู่ที่ประมาณ 36% พื้นผิวโจมตีจึงไม่เล็ก
  • อุปกรณ์ DRAM แก้ไขได้ยากหลังจากถูกนำไปใช้งานแล้ว และงานวิจัยก่อนหน้านี้แสดงให้เห็นว่าการโจมตี Rowhammer สามารถใช้ได้จริงในหลายสภาพแวดล้อม

วิศวกรรมย้อนกลับฟังก์ชันที่อยู่ DRAM ของ AMD และการปรับการ hammering ให้เหมาะสม

  • นำเทคนิค DRAMA มาปรับใช้กับระบบ AMD เพื่อวิศวกรรมย้อนกลับ ฟังก์ชันที่อยู่ DRAM ลับ
  • ปรับเปลี่ยนรูทีนการจับเวลาเพื่อให้ได้ผลลัพธ์ที่เสถียรกว่าเดิม
  • เนื่องจากการรีแมปที่อยู่ของระบบ จำเป็นต้องใช้ ออฟเซ็ตของที่อยู่กายภาพ ก่อนกู้คืนฟังก์ชันที่อยู่ DRAM และด้วยวิธีนี้จึงกู้คืนฟังก์ชันที่อยู่ได้ครบถ้วน
  • วิธีที่ใช้เฉพาะฟังก์ชันที่อยู่ที่กู้คืนมาได้ ทำให้จำนวน bit flip ค่อนข้างจำกัด
    • บน Zen 2 พบ bit flip เพียง 5 ตัวจากอุปกรณ์ 10 ตัว
    • บน Zen 3 พบ bit flip 0 ตัวจากอุปกรณ์ 10 ตัว

การซิงโครไนซ์ refresh และลำดับคำสั่ง

  • เช่นเดียวกับงานวิจัยก่อนหน้าอย่าง SMASH และ Blacksmith การซิงโครไนซ์ refresh เป็นปัจจัยสำคัญในการทำให้เกิด bit flip
  • บน AMD วิธีวัดเวลาอย่างต่อเนื่องกับแถวที่ไม่ซ้ำกันมีประสิทธิภาพสำหรับการซิงโครไนซ์ refresh ที่แม่นยำและเชื่อถือได้
  • ในระบบ AMD Zen+/3 อัตราการเปิดใช้งานของ รูปแบบ Rowhammer แบบไม่สม่ำเสมอ ต่ำกว่า Intel Coffee Lake อย่างมาก
  • ลำดับคำสั่ง hammering ที่เหมาะที่สุดคือการใช้โหลดทั่วไป MOV และ CLFLUSHOPT เพื่อ flush aggressor ออกจากแคช และเป็นสไตล์ “scatter” ที่ flush ทันทีหลังเข้าถึง aggressor
  • ต่างจาก Zen 2 บน Zen 3 ไม่จำเป็นต้องมี fence แบบชัดเจนหลัง flush
  • ประเภทของ fence และนโยบายการจัดตาราง fence ก็ส่งผลต่อผลลัพธ์เช่นกัน ทีมวิจัยจึงเสนอรูปแบบการรู้จำแพตเทิร์นและนโยบายหลีกเลี่ยงแคช 6 แบบ และทดสอบแบบละ 6 ชั่วโมงต่ออุปกรณ์
    • ในอุปกรณ์ส่วนใหญ่ของ Zen 2 SP_none เหมาะที่สุด
    • ในกรณีส่วนใหญ่ของ Zen 3 SP_pair เหมาะสมกว่า

ผลการประเมิน DDR4 และความเป็นไปได้ในการนำไปโจมตี

  • การประเมินทำกับ อุปกรณ์ DDR4 DRAM 10 ตัว ซึ่งรวม Samsung, Micron และ SK Hynix
  • ZenHammer fuzzer ถูกเรียกใช้อย่างละ 3 ชั่วโมงสำหรับการผสมผสานของ fence แต่ละประเภท ได้แก่ mfence, sfence และนโยบายการจัดตาราง fence แต่ละแบบ
  • หลังการรันแต่ละครั้ง จะทำ minisweep ในช่วง 4MiB ด้วยแพตเทิร์นทั้งหมดที่พบ เพื่อกำหนดแพตเทิร์นที่ดีที่สุด แล้ว sweep แพตเทิร์นที่ดีที่สุดของนโยบายที่ดีที่สุดบนพื้นที่หน่วยความจำต่อเนื่อง 256MB
  • ผลคือเกิด bit flip ในอุปกรณ์ DDR4 DRAM 10 ตัว โดยเกิดกับ 7 ตัวบน Zen 2 และ 6 ตัวบน Zen 3
  • ความเป็นไปได้ในการใช้ bit flip โจมตีถูกประเมินด้วยการโจมตีสามแบบจาก งานวิจัยก่อนหน้า
    • การโจมตี page frame number ของ page table entry เพื่อ pivot ไปยังหน้า page table ที่ผู้โจมตีควบคุม
    • การโจมตี กุญแจสาธารณะ RSA-2048 ที่ทำให้สามารถกู้คืนกุญแจส่วนตัวที่เกี่ยวข้องซึ่งใช้ในการยืนยันตัวตนโฮสต์ SSH ได้
    • การโจมตีตรรกะการตรวจสอบรหัสผ่านของไลบรารี sudoers.so ซึ่งทำให้ได้สิทธิ์ root
  • การโจมตีเดิมสามารถจัดทำได้ในอุปกรณ์ 7/6/4 ตัว ตามลำดับ และเวลาเฉลี่ยในการหา bit flip ที่ใช้โจมตีได้คือ 164/267/209 วินาที

การประเมิน DDR5, โค้ดสาธารณะ และกำหนดการนำเสนอ

  • วิศวกรรมย้อนกลับฟังก์ชัน DDR5 DRAM บน AMD Zen 4 และประเมิน อุปกรณ์ DDR5 10 ตัว ด้วย
  • ZenHammer ทำให้เกิด bit flip ประมาณ 42,000 ครั้ง ในอุปกรณ์ DDR5 1 ตัวจาก 10 ตัว
  • นี่เป็นรายงานสาธารณะครั้งแรกของ bit flip บน DDR5 ในระบบเชิงพาณิชย์ทั่วไป
  • ในอุปกรณ์ DDR5 อีก 9 ตัวที่เหลือไม่เกิด bit flip จึงต้องมีการวิจัยเพิ่มเติมเพื่อหารูปแบบที่มีประสิทธิภาพมากขึ้นสำหรับอุปกรณ์ DDR5
  • รายละเอียดทั้งหมดจะรวมอยู่ใน 论文 ที่จะนำเสนอใน USENIX Security 2024 เดือนสิงหาคม 2024
  • โค้ด ZenHammer fuzzer มีให้บน GitHub และใช้ประเมินได้ว่าอุปกรณ์ DRAM บน CPU AMD Zen 2/3/4 มี bit flip หรือไม่
  • เนื่องจาก Rowhammer เป็นปัญหาที่รู้จักกันในวงกว้างของอุตสาหกรรม จึงเห็นว่าไม่จำเป็นต้องใช้กระบวนการเปิดเผยทั่วไป แต่ได้แจ้ง AMD เมื่อ 26 กุมภาพันธ์ 2024 และตามคำขอของ AMD จึงไม่เปิดเผยจนถึง 25 มีนาคม 2024
  • หน้านี้ถูกเผยแพร่ทางออนไลน์ชั่วคราวโดยไม่ได้ตั้งใจเมื่อ 21 มีนาคม 2024

ข้อจำกัดเชิงปฏิบัติจาก FAQ

  • เหตุผลที่ระบบ AMD ถูกกล่าวถึงน้อยก่อนหน้านี้ คือในงานวิจัย Rowhammer ดั้งเดิม จำนวน bit flip บนระบบ Intel สูงกว่ามาก งานวิจัยต่อมาก็มุ่งเน้น Intel เป็นหลัก และข้อมูลไมโครสถาปัตยกรรม CPU ของ Intel เป็นที่รู้จักมากกว่า AMD
  • ในอุปกรณ์ DDR4 10 ตัว บน Zen 2 มี 3 ตัว และบน Zen 3 มี 4 ตัวที่ไม่เกิด bit flip แต่เนื่องจากบน Intel Coffee Lake อุปกรณ์เหล่านี้ก็มีจำนวน bit flip ต่ำเช่นกัน จึงมองว่าหากปรับ fuzzer เพิ่มเติมอาจเผยให้เห็น bit flip ได้
  • เหตุผลที่อุปกรณ์ประเมินจำกัดไว้ที่ 10 ตัว คือจำนวนเครื่อง AMD Zen 2/3 ในห้องแล็บมีจำกัด และบางการทดลองใช้เวลานาน โดยชุดย่อยที่สุ่มมานั้นรวมอุปกรณ์จากผู้ผลิต DRAM ทั้ง 3 รายไว้ครบ
  • เกี่ยวกับเหตุผลที่ JEDEC ยังแก้ปัญหาไม่ได้ อธิบายว่าการแก้ Rowhammer นั้นยากแต่ไม่ใช่เป็นไปไม่ได้ และงานวิจัยก่อนหน้าอย่าง ProTRR และ REGA ได้แสดงให้เห็นเรื่องนี้แล้ว
  • งานวิจัยก่อนหน้า เกี่ยวกับ DDR3 แสดงให้เห็นว่า ECC ไม่สามารถป้องกัน Rowhammer ได้ และเนื่องจากจำนวน bit flip ของอุปกรณ์ DDR4 ปัจจุบันมากกว่า จึงประเมินว่า ECC ไม่ใช่การป้องกันที่สมบูรณ์ แต่เป็นเพียงระดับที่ทำให้การโจมตียากขึ้น
  • วิธีเพิ่ม refresh rate เป็นสองเท่ามี overhead ด้านประสิทธิภาพและการใช้พลังงานเพิ่มขึ้น และในงานวิจัยก่อนหน้า เช่น Mutlu et al. และ Frigo et al. พบว่าเป็นแนวทางแก้ที่อ่อนและไม่สามารถให้การป้องกันได้อย่างสมบูรณ์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-26
ความคิดเห็นจาก Hacker News

  • เป็นผู้ร่วมเขียน Rowhammer exploit ต้นฉบับ ECC ยังคงมีประสิทธิภาพมากในการเปลี่ยนปัญหานี้จากประเด็นด้านความปลอดภัยให้กลายเป็นประเด็นด้านความน่าเชื่อถือ
    ถ้าคุณเป็นเจ้าของเซิร์ฟเวอร์ส่วนตัว และคาดหวังได้ว่าเซิร์ฟเวอร์มี ECC และคุณจะสังเกตเห็นการหยุดทำงานของเครื่องที่เกิดจากข้อผิดพลาด ECC ที่แก้ไขไม่ได้ ผลกระทบด้านความปลอดภัยก็ไม่มากนัก
    แต่ถ้าเป็นผู้ให้บริการคลาวด์ที่ให้บริการ VM บนโฮสต์แบบหลายผู้เช่า โมเดลภัยคุกคามอาจเปลี่ยนไป
    ไม่ว่าอย่างไร ก็ควรหลีกเลี่ยงเครื่องที่ไม่มี ECC TRR เป็นการป้องกันที่ล้มเหลวมาตั้งแต่ตอนที่ Rowhammer เพิ่งเป็นที่รู้จักแล้ว และตราบใดที่เศรษฐศาสตร์การผลิต DRAM ไม่เปลี่ยนไป การพลิกบิตของ DRAM ก็จะไม่หายไป

    • ถ้าเป็นไปได้ก็อยากใช้ หน่วยความจำ ECC เมื่อก่อนใช้ TR 2920x ที่มี ECC แต่ตอนนี้ใช้ Ryzen 7950x แบบไม่ใช่ ECC อยู่
      สิ่งที่ Ryzen รองรับมีเพียง ECC แบบ unbuffered ซึ่งช้ากว่าหรือแพงกว่าหน่วยความจำ non-ECC ที่ความจุเท่ากัน หรือไม่ก็ทั้งสองอย่าง
      Threadripper รุ่นล่าสุดรองรับ Registered ECC แต่สำหรับผู้ใช้ตามบ้านแบบผมแล้ว ทั้งราคา จำนวนเธรด และเลน PCIe ล้วนเกินความจำเป็น
    • ถ้า “ตราบใดที่เศรษฐศาสตร์การผลิต DRAM ไม่เปลี่ยนไป การพลิกบิตของ DRAM ก็จะไม่หายไป” นั่นก็ดูเป็นเหตุผลเพียงพอที่จะต้อง บังคับใช้หน่วยความจำ ECC ในคอมพิวเตอร์ทุกเครื่อง
      ความเสี่ยงด้านความปลอดภัยสูงเกินไป และทุกอย่างก็ผสานรวมกันมากเกินไปจนยากจะเลื่อนการเปลี่ยนแปลงนี้ออกไป แม้แต่เกมเมอร์ที่ใช้คอมพิวเตอร์เพื่อเล่นเกมอย่างเดียวก็น่าจะเก็บข้อมูลสำคัญไว้ในเครื่องนั้นด้วย ผมไม่เข้าใจว่าทำไมจนถึงตอนนี้จึงยังไม่มีการเปลี่ยนแปลงนี้
    • ได้ยินมาว่า DDR2 ภูมิคุ้มกันต่อ Rowhammer เลยสงสัยว่าจริงไหม หรือเป็นเพราะยังไม่มีใครตรวจสอบอย่างจริงจัง
      และก็สงสัยด้วยว่าสิ่งที่ภูมิคุ้มกันจริง ๆ มีแค่ SRAM หรือเปล่า
    • ตอนนี้ AMD ก็เริ่มเดินตาม การแบ่งเซกเมนต์ตลาด แบบ Intel แล้ว โดยปิดใช้งาน ECC ใน Ryzen CPU ส่วนใหญ่
      มีเพียง Pro และ Threadripper ที่รับประกัน ส่วน Ryzen เดสก์ท็อปบางรุ่นทำได้เฉพาะกับเมนบอร์ดบางตัวเท่านั้น
    • มีคำถามที่ยังหาคำตอบที่น่าพอใจไม่ได้จากงานวิจัยก่อน ๆ เครื่องมือ patrol read สมัยใหม่ได้รับการชี้นำด้วยรูปแบบการเข้าถึงหน่วยความจำเพื่อรับมือกับการโจมตีแบบ Rowhammer หรือไม่?
      เพื่อไล่ให้ทันการพลิกบิตที่เกิดจาก Rowhammer อย่างปลอดภัย เครื่องมือ patrol read ต้องสแกน DRAM อย่างดุดันแค่ไหน?
      ถ้ามี ECC word ที่ใหญ่กว่า 64+8 แบบดั้งเดิมและการแก้ไขข้อผิดพลาดหลายบิต จะเปลี่ยนสถานการณ์จนสามารถสร้างระบบที่น่าเชื่อถือยิ่งขึ้นได้แม้ใช้ DRAM ที่มีความเปราะบางด้านรูปแบบหรือไม่?

  • คำพูดทำนองว่า “ECC ป้องกัน Rowhammer ไม่ได้” ทำให้เข้าใจผิดอย่างมาก งานวิจัยที่อ้างถึงเองก็กล่าวว่า “แม้เมื่อใช้การตรวจจับ ECC อย่างถูกต้อง 0.65%~7.42% ของการพลิกบิตทั้งหมดก่อให้เกิดความเสียหายแบบเงียบ… ในคอนฟิก AMD-1 ข้อผิดพลาดที่แก้ไขไม่ได้จะทำให้ระบบแครช”
    ผู้โจมตีต้องทำให้เครื่องหยุดทำงานหลายสิบครั้งเพื่อให้ได้การพลิกบิตหนึ่งครั้งที่นำไปใช้โจมตีได้ การที่เครื่องหยุดทำงานหลายสิบครั้งไม่ใช่เรื่องที่จะไม่ถูกจับสังเกตได้
    การชี้ให้เห็นว่าการรับมือ Rowhammer ของ JEDEC แย่มากนั้นเป็นเรื่องดี แต่ไม่ควรประเมิน ECC ต่ำเกินไปในฐานะทางแก้ระยะสั้น

    • สงสัยว่าทีมปฏิบัติการที่ดูแลระบบมีขั้นตอนที่จะตัดสินได้ไหมว่าปรากฏการณ์นั้นไม่ใช่แค่ฮาร์ดแวร์ไม่เสถียร แต่เป็น การโจมตี
    • ถ้าเป็นการเล็งเป้าเครื่องเฉพาะก็คงใช่ แต่ถ้าหว่าน exploit แบบปืนลูกซองใส่เครื่องหลายพันเครื่อง ก็ยังได้ บอตเน็ต อยู่ดี แค่ขนาดเล็กลงหน่อยเท่านั้น
    • หนึ่งในเหตุผลที่ซื้อ ECC มาใส่เดสก์ท็อปที่บ้านคือเพื่อป้องกัน Rowhammer
      เป็นแพลตฟอร์ม Zen2 TR พอเห็นถ้อยคำนั้นแล้วใจหล่นวูบเลย เป็นข้อความที่ชวนให้เข้าใจผิดพอสมควร
    • สงสัยว่ามีคำแนะนำสำหรับอุปกรณ์ไคลเอนต์ที่มี หน่วยความจำ ECC ไหม

  • สงสัยว่าสำหรับคนทั่วไป ปัญหาความปลอดภัยของฮาร์ดแวร์ อย่าง Rowhammer, Spectre, Meltdown เป็นความเสี่ยงจริงหรือไม่
    เท่าที่เข้าใจ Spectre กับ Meltdown เป็นปัญหาสำหรับการโจมตีอย่างการหลุดออกจาก VM ซึ่งดูเหมือนเป็นเรื่องที่วิศวกร AWS ต้องกังวล ไม่ใช่ผู้ใช้ส่วนตัว

    • วิธีแก้คือปิด JavaScript และไม่รันแอปที่ไม่น่าเชื่อถือ
      จากนั้นก็แยกตัวจากสังคมสมัยใหม่ ย้ายไปกระท่อมในป่าแล้วพึ่งพาตัวเองก็พอ
    • ในมุมของนักวิจัยความปลอดภัยฮาร์ดแวร์ที่พูดตามตรง ช่องโหว่ที่ถูกนำไปใช้โจมตีจริงและส่งผลต่อผู้ใช้ทั่วไปนั้นธรรมดากว่านี้มาก และส่วนใหญ่เป็น ซอฟต์แวร์
    • ทุกคนควรติดตั้งส่วนขยาย รายการอนุญาตสคริปต์ ในรูปแบบใดรูปแบบหนึ่ง และรัน JavaScript เฉพาะจากเว็บไซต์ที่เชื่อถือจริง ๆ เท่านั้น
      โดยส่วนตัวชอบ NoScript ส่วนบน Chrome ไม่ค่อยแน่ใจว่าควรเลือกอะไร
      นอกเหนือจากนั้น… ปกติเราก็ไม่ได้รันโปรแกรมสุ่ม ๆ จากอินเทอร์เน็ตบ่อยนักไม่ใช่หรือ?
      บั๊กประเภทนี้เพิ่งถูกขุดค้นแค่ผิวเผินเท่านั้น ฮาร์ดแวร์สมัยใหม่ซับซ้อนเกินไปจนยากจะเชื่อว่าจะหาเจอได้ทั้งหมด
    • Rowhammer มี implementation ใน JavaScript ที่รันในเบราว์เซอร์ได้ด้วย: https://github.com/IAIK/rowhammerjs
    • ในมุมมองด้านความปลอดภัย เว็บเบราว์เซอร์ ก็เป็นเหมือน VM hypervisor แบบหนึ่ง และแต่ละเว็บไซต์ก็เหมือนมี VM ของตัวเอง
      ดังนั้นทุกคนจึงอาจได้รับผลกระทบ

  • ผมเคยเข้าใจการโจมตีแบบบิตพลิกใน DDR แค่แบบเลือนรางมาก ๆ แต่พอไปดูเปเปอร์ Hammertime ต้นฉบับแล้วพบว่าอ่านง่ายจริง ๆ
    ยังอ่านไม่จบทั้งหมด แต่เขาอธิบายได้เข้าใจง่ายดี เคยได้ยินคำว่าบิตพลิกมานับครั้งไม่ถ้วนแต่ไม่เคยเข้าใจจริง ๆ พอได้อ่านอันนี้แล้วเริ่มจับทางได้
    https://comsec.ethz.ch/wp-content/files/hammertime_raid18.pd...
    รู้สึกเหมือนได้เรียนคาบพื้นฐานไฟฟ้าอิเล็กทรอนิกส์หนึ่งคาบเลย ไม่เคยรู้มาก่อนว่าสิ่งนี้เกี่ยวข้องกับ ข้อบกพร่องในการผลิตฮาร์ดแวร์ จริง ๆ
    ชื่อ Rowhammer ก็เพิ่งอธิบายตัวเองได้ตอนนั้นเอง อาจเป็นเพราะผมตามไม่ทันเอง และอาจเป็นเรื่องที่ทุกคนรู้อยู่แล้วก็ได้
    “เนื่องจากความหนาแน่นสุดขั้วของอาร์เรย์ DRAM สมัยใหม่ ข้อบกพร่องเล็ก ๆ ในการผลิตอาจสร้างการเชื่อมโยงทางไฟฟ้าที่อ่อนระหว่างเซลล์ข้างเคียงได้ เมื่อประกอบกับค่าความจุไฟฟ้าที่เล็กมากของเซลล์เหล่านี้ ทุกครั้งที่มีการอ่านแถว DRAM ในแบงก์ เซลล์หน่วยความจำในแถวข้างเคียงจะสูญเสียประจุไปเล็กน้อย หากเกิดขึ้นบ่อยพอระหว่างรอบรีเฟรชสองครั้ง เซลล์ที่ได้รับผลกระทบอาจสูญเสียประจุมากพอจนค่าบิตที่เก็บไว้กลับด้าน ซึ่งเรียกว่า ‘disturbance error’ หรือในช่วงหลังเรียกว่า Rowhammer”

    • ถ้าดูแค่คำอธิบายนี้ อาจฟังเหมือนเป็นคุณสมบัติพื้นฐานที่หลีกเลี่ยงไม่ได้เมื่อผลิต DRAM แต่ไม่ใช่แบบนั้น
      เป็นเพราะ ผู้ผลิต DRAM ผลักขีดจำกัดไปจนสุดโต่งต่างหาก เป็นเรื่องการแสวงหากำไร
      ไม่ต่างจาก Ford ที่ตัดสินว่าค่าใช้จ่ายในการยอมความคดี Pinto ที่เกี่ยวกับการบาดเจ็บและเสียชีวิต ต่ำกว่าค่าใช้จ่ายในการแก้แบบรถ

  • สงสัยว่า Secure Memory Encryption จะช่วยเรื่องนี้ได้ไหม
    https://www.amd.com/en/developer/sev.html

    • ช่วยได้บ้าง แต่ก็อาจเสียเสถียรภาพไปมาก
      แค่บิตพลิกหนึ่งบิตก็อาจกลายเป็นข้อผิดพลาดร้ายแรงได้

  • ผมไม่ค่อยรู้เรื่องความปลอดภัยฮาร์ดแวร์ เลยสงสัยว่านี่เป็นหนึ่งในช่องโหว่จำนวนมากที่หลีกเลี่ยงไม่ได้จากการทำ CPU optimization และในโลกจริงเป็นประเภทที่แทบทำได้ยากหรือเปล่า

    • อาจมองว่าแย่กว่านั้นด้วยซ้ำ สิ่งนี้เกิดจาก ฟิสิกส์ของ DRAM
      มันเกิดในระดับที่ต่ำกว่ากรณีขอบเขตของฟีเจอร์ที่ทำให้ข้อมูลรั่วผ่าน side channel มาก
      ข้อมูลถูกเก็บเป็นประจุเล็ก ๆ ในตารางกริด และถ้าสลับจุดกริดใกล้ ๆ จำนวนมาก ก็สามารถทำให้ประจุบางส่วนรั่วไปทางประจุเป้าหมายได้
      ยิ่งประจุเล็กและอยู่ใกล้กันเท่าไร การโจมตี Rowhammer ก็ยิ่งง่ายขึ้นเท่านั้น ขณะเดียวกัน ยิ่งประจุเล็กและใกล้กัน RAM ก็ยิ่งเร็ว ถูก หนาแน่น และมีประสิทธิภาพมากขึ้น
      มีมาตรการบรรเทาอยู่ แต่ก็ถูกผลักจนถึงขีดจำกัดแล้ว
    • นี่เป็น ปัญหาของ RAM ไม่ใช่ปัญหาของ CPU

  • สงสัยว่าถ้าเปิดการเข้ารหัสหน่วยความจำทั้งระบบ, poisoning และ address XOR แล้ว สิ่งนี้ยังทำงานได้ไหม

    • ถ้ามี การเข้ารหัสหน่วยความจำ ก็จะไม่ลุกลามไปถึงการยึดระบบ แต่จะทำให้ระบบแครชเท่านั้น
      ดังนั้นถ้าใช้การเข้ารหัสหน่วยความจำก็จะปลอดภัยขึ้น

  • ถ้า “ZenHammer ไม่สามารถทำให้เกิดการพลิกบิตได้ในอุปกรณ์ 9 จาก 10 เครื่อง… จำเป็นต้องมีการวิจัยเพิ่มเติมเพื่อหารูปแบบที่มีประสิทธิภาพกว่าสำหรับอุปกรณ์ DDR5” ก็เหมือนว่า DDR5 ยังพอมีเวลาเหลืออยู่บ้าง
    สงสัยว่ามีใครรู้ไหมว่าสิ่งนี้ส่งผลต่อ LPDDR5x ด้วยหรือเปล่า

    • อินเทอร์เฟซ DRAM แยกออกจากอาร์เรย์หน่วยความจำจริงค่อนข้างดี
      ดังนั้นคำถามหลักจึงไม่ใช่ว่าเป็น DDR5, LPDDR5(x), GDDR6(x) หรือ HBM3(e)
      สิ่งสำคัญคือ รายละเอียดการใช้งานจริง ที่ขึ้นอยู่กับดุลยพินิจของผู้ผลิต เช่น on-die ECC

  • มีการพูดถึง Zen 2 และ 3 แต่สงสัยว่ามีข้อมูลเกี่ยวกับ Zen 1 ไหม
    หรือว่าใช้ได้เหมือนกันเฉย ๆ?