เทคนิค Zenbleed
(lock.cmpxchg8b.com)- Zenbleed เป็นช่องโหว่ในตระกูล AMD Zen 2 ที่ใช้ประโยชน์จากการกู้คืน
vzeroupperที่คาดการณ์ผิด ทำให้อ่านข้อมูลที่เหลืออยู่ในไฟล์เวกเตอร์รีจิสเตอร์ของคอร์จริงเดียวกันได้ - ถูกบันทึกเป็น CVE-2023-20593 และผลิตภัณฑ์ตระกูล Zen 2 เช่น Ryzen 3000/4000/5000 with Radeon Graphics/7020 with Radeon Graphics, Ryzen PRO, Threadripper 3000, EPYC “Rome” อยู่ในขอบเขตที่ได้รับผลกระทบ
- การโจมตีจะเกิดขึ้นเมื่อ XMM Register Merge Optimization, register renaming และ
vzeroupperที่คาดการณ์ผิดเกิดขึ้นต่อเนื่องกันภายในกรอบเวลาที่แคบ โดยแม้แต่การดำเนินการพื้นฐานอย่างstrlen,memcpy,strcmpก็อาจถูกสังเกตได้ - รูปแบบโจมตีที่ปรับแต่งแล้วสามารถรั่วไหลข้อมูลได้ประมาณ 30KB ต่อวินาทีต่อคอร์ และการแชร์ไฟล์รีจิสเตอร์บนคอร์จริงเดียวกันข้ามขอบเขต VM, sandbox, container และ process กลายเป็นปัญหา
- แนะนำให้ติดตั้งอัปเดตไมโครโค้ดของ AMD และอาจตั้งค่า chicken bit
DE_CFG[9]ชั่วคราวได้ แต่อาจมีต้นทุนด้านประสิทธิภาพ และ การปิดใช้งาน SMT เพียงอย่างเดียวไม่เพียงพอ
หน่วยการทำงานที่ Zenbleed เล็งโจมตี
- CPU x86-64 มีเวกเตอร์รีจิสเตอร์ XMM ขนาด 128 บิต และ CPU รุ่นใหม่ขยายสิ่งนี้ไปถึง YMM ขนาด 256 บิต และ ZMM ขนาด 512 บิต
- เวกเตอร์รีจิสเตอร์ไม่ได้ใช้เฉพาะการคำนวณเชิงตัวเลขเท่านั้น แต่ยังใช้ในฟังก์ชันไลบรารี C มาตรฐานของ glibc เช่น
strcmp,memcpy,strlenด้วย strlenที่ปรับแต่งด้วย AVX2 ของ glibc ผสมผสานคำสั่งเวกเตอร์หลายคำสั่งเพื่อค้นหาตำแหน่งของไบต์ nul ตัวแรกในสตริง- ใช้
vpxor xmm0,xmm0,xmm0เพื่อทำให้ส่วนล่างของymm0เป็น 0 - ใช้
vpcmpeqb ymm1,ymm0,[rdi]เพื่อเปรียบเทียบไบต์ของสตริงกับไบต์ 0 - ใช้
vpmovmskb eax,ymm1เพื่อย้ายผลการเปรียบเทียบไปยังรีจิสเตอร์ทั่วไป - ใช้
tzcnt eax,eaxเพื่อคำนวณตำแหน่งของไบต์ nul ตัวแรก
- ใช้
vzeroupper และไฟล์รีจิสเตอร์
vzeroupperเป็นคำสั่งที่ทำให้บิตส่วนบนของเวกเตอร์รีจิสเตอร์เป็น 0- เมื่อใช้รีจิสเตอร์
XMMและYMMปะปนกัน รีจิสเตอร์XMMจะถูกยกระดับเป็นความกว้างเต็ม และในกระบวนการนี้อาจเกิด dependency กับบิตส่วนบนได้ - glibc ใช้
vzeroupperเพื่อหลีกเลี่ยง stall ที่ไม่จำเป็น และทำให้ผลลัพธ์ถัดไปไม่ขึ้นกับบิตส่วนบน - CPU ไม่ได้วางแต่ละรีจิสเตอร์ไว้ในตำแหน่งทางกายภาพคงที่ แต่จัดการการจัดสรรรีจิสเตอร์ทางกายภาพด้วย Register File และ Register Allocation Table
- เมื่อทำให้รีจิสเตอร์
XMMเป็น 0 CPU อาจไม่บันทึกบิตจริง แต่ตั้งแฟล็ก z-bit ใน RAT แทน- แฟล็กนี้สามารถใช้กับส่วนบนและส่วนล่างของรีจิสเตอร์
YMMได้อย่างอิสระ vzeroupperสามารถตั้งค่า z-bit แล้วปล่อยทรัพยากรที่เกี่ยวข้องออกจากไฟล์รีจิสเตอร์ได้
- แฟล็กนี้สามารถใช้กับส่วนบนและส่วนล่างของรีจิสเตอร์
ช่องโหว่ที่เกิดจากการกู้คืนในการทำงานแบบคาดเดา
- CPU สมัยใหม่ใช้ speculative execution ดังนั้นการดำเนินการที่ถูกรันใน branch ที่คาดการณ์ผิดต้องถูกย้อนกลับ
- ปัญหาคือเมื่อ
vzeroupperที่คาดการณ์ผิดถูกรันแล้วมีการกู้คืน การย้อนกลับเฉพาะ z-bit ไม่สามารถกู้คืนสถานะทรัพยากรไฟล์รีจิสเตอร์ที่ถูกปล่อยไปแล้วได้อย่างถูกต้อง - ด้วยการจัดตารางเวลาอย่างแม่นยำ สามารถทำให้โปรเซสเซอร์บางรุ่นกู้คืนจาก
vzeroupperที่คาดการณ์ผิดได้อย่างไม่ถูกต้อง - เทคนิคนี้คือ CVE-2023-20593 และส่งผลกระทบต่อทั้งตระกูล Zen 2
- AMD Ryzen 3000 Series Processors
- AMD Ryzen PRO 3000 Series Processors
- AMD Ryzen Threadripper 3000 Series Processors
- AMD Ryzen 4000 Series Processors with Radeon Graphics
- AMD Ryzen PRO 4000 Series Processors
- AMD Ryzen 5000 Series Processors with Radeon Graphics
- AMD Ryzen 7020 Series Processors with Radeon Graphics
- AMD EPYC “Rome” Processors
เงื่อนไขการโจมตีและขอบเขตการรั่วไหล
- เพื่อกระตุ้นบั๊ก จำเป็นต้องให้ XMM Register Merge Optimization, register renaming และ
vzeroupperที่คาดการณ์ผิดเกิดขึ้นต่อเนื่องกันในกรอบเวลาที่แม่นยำ - ลำดับคำสั่งตัวอย่างใช้โครงสร้างดังนี้
- ใช้
vcvtsi2s{s,d}เพื่อกระตุ้น merge optimization - ใช้
vmovdqaเพื่อกระตุ้น register renaming - หาก conditional branch เป็น taken แต่ CPU คาดการณ์เส้นทาง not-taken จะทำให้
vzeroupperถูกรันแบบคาดการณ์ผิดและเกิดบั๊ก
- ใช้
- การดำเนินการพื้นฐานอย่าง
strlen,memcpy,strcmpก็ใช้เวกเตอร์รีจิสเตอร์ ดังนั้นไม่ว่าจะรันที่ใดในระบบก็อาจตกเป็นเป้าการสังเกตได้ - เนื่องจาก ไฟล์รีจิสเตอร์ ถูกแชร์บนคอร์จริงเดียวกัน VM, sandbox, container และ process อื่นก็อยู่ในขอบเขตที่ได้รับผลกระทบด้วย
- ไฮเปอร์เธรดทั้งสองแชร์ไฟล์รีจิสเตอร์ทางกายภาพเดียวกัน
- รูปแบบโจมตีที่ปรับแต่งแล้วสามารถรั่วไหลข้อมูลได้ประมาณ 30KB ต่อวินาทีต่อคอร์ ซึ่งเร็วพอสำหรับเฝ้าติดตามคีย์เข้ารหัสและรหัสผ่านของผู้ใช้ที่กำลังล็อกอินอยู่
- คำแนะนำทางเทคนิคและโค้ดที่เกี่ยวข้องเผยแพร่ใน security research repository ของ Google
- โค้ดสำหรับทดสอบมีให้สำหรับ Linux แต่บั๊กไม่ได้ขึ้นกับระบบปฏิบัติการเฉพาะ จึงส่งผลกระทบต่อทุกระบบปฏิบัติการ
วิธีค้นพบ: CPU fuzzing และ Oracle Serialization
- ช่องโหว่นี้ถูกค้นพบด้วย fuzzing
- อุตสาหกรรม CPU ก็ทำการตรวจสอบหลังการผลิตซิลิคอน (Post-Silicon Validation) เพื่อค้นหาข้อบกพร่องของฮาร์ดแวร์เช่นกัน
- ต่างจาก coverage-based fuzzing ทั่วไป CPU ไม่มีตัวชี้วัดที่เทียบตรงกับ code coverage
- จึงใช้ performance counters แทน เพื่อป้อนเหตุการณ์ทางสถาปัตยกรรมที่น่าสนใจกลับไปให้ fuzzer
- วิธีนี้ช่วยสำรวจลำดับคำสั่งที่ยากจะพบโดยบังเอิญได้
- สามารถค้นพบฟีเจอร์อย่าง merge optimization ได้โดยอัตโนมัติ
- ซอฟต์แวร์ fuzzing มักมองหา crash แต่ในโปรแกรม CPU ที่สร้างแบบสุ่ม crash เองก็อาจเป็นพฤติกรรมที่ถูกต้องได้
- แนวทางเดิมอย่างหนึ่งคือ reversi ซึ่งสร้าง operation ย้อนกลับสำหรับคำสั่งสุ่มแต่ละคำสั่ง แล้วตรวจสอบว่าสถานะสุดท้ายต่างจากสถานะเริ่มต้นหรือไม่
- ในสถาปัตยกรรม CISC อย่าง x86 การสร้าง testcase จะซับซ้อนขึ้น
- อีกวิธีคือใช้ oracle เพื่อเปรียบเทียบผลลัพธ์ของ CPU ที่ทดสอบกับ CPU อื่นหรือ simulator
- Oracle Serialization ผสานสองแนวคิดนี้เข้าด้วยกัน
- หลังจากสร้างโปรแกรมแบบสุ่มแล้ว จะแปลงเป็นรูปแบบที่ถูก serialize โดยอัตโนมัติ
- เพิ่มองค์ประกอบ serialization เช่น store/load barrier, speculation fence, cache line flush
- โปรแกรมต้นฉบับและโปรแกรมที่ถูก serialize ควรให้ผลลัพธ์เดียวกัน แม้มีลักษณะด้านประสิทธิภาพต่างกัน
- หากสถานะสุดท้ายไม่ตรงกัน ก็อาจเป็นข้อผิดพลาดในการทำงานระดับไมโครสถาปัตยกรรม และความไม่ตรงกันนี้นำไปสู่การค้นพบ Zenbleed
การรับมือและข้อจำกัดในการตรวจจับ
- ช่องโหว่นี้ถูกรายงานต่อ AMD เมื่อวันที่ 15 พฤษภาคม 2023
- AMD เผยแพร่ อัปเดตไมโครโค้ด สำหรับโปรเซสเซอร์ที่ได้รับผลกระทบ
- ผู้จำหน่าย BIOS หรือระบบปฏิบัติการอาจมีแพตช์ที่รวมอัปเดตดังกล่าวไว้แล้ว
- แนวทางรับมือที่แนะนำคือการติดตั้ง อัปเดตไมโครโค้ด
- เมื่อไม่สามารถติดตั้งอัปเดตได้ สามารถตั้งค่า chicken bit
DE_CFG[9]เป็นวิธีเลี่ยงผ่านทางซอฟต์แวร์ได้- อาจมีต้นทุนด้านประสิทธิภาพ
- บน Linux สามารถตั้งค่ากับทุกคอร์ได้ด้วย
msr-tools - บน FreeBSD ใช้
cpucontrol(8) - หากไม่ทราบวิธีตั้งค่า MSR บนระบบปฏิบัติการอื่น จำเป็นต้องขอการสนับสนุนจากผู้จำหน่าย
- การปิดใช้งาน SMT เพียงอย่างเดียวไม่เพียงพอ
- ยังไม่มีเทคนิคตรวจจับการโจมตีที่เชื่อถือได้ซึ่งเป็นที่รู้จัก
- เพราะไม่ต้องใช้ system call หรือสิทธิ์พิเศษใด ๆ
- การตรวจจับการใช้
vzeroupperที่ไม่เหมาะสมแบบ static ก็ทำไม่ได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
นี่เจ๋งมาก และน่าจะเป็น กรณีตัวอย่างชั้นดีว่าการรันใน VM ไม่ได้แปลว่าปลอดภัยเสมอไป
การหนีออกจาก VM เป็นเรื่องที่รู้กันมานานแล้ว แต่กรณีนี้เป็นช่องโหว่ขนาดใหญ่ที่ทำได้ง่ายและผลตอบแทนสูง แม้ไม่ต้องหนีออกจาก VM เลยก็ตาม
การที่บั๊กนี้ถูกแก้ด้วยไมโครโค้ด ไม่ได้แปลว่าไม่มีบั๊กคล้ายกันอยู่อีก 0-day จำนวนมากมักเป็นสิ่งที่พวก blackhat รับจ้างรู้กันมานานก่อนจะถูกเปิดเผยสู่สาธารณะมาก
ช่องโหว่ CPU ที่ถูกค้นพบในช่วงไม่กี่ปีที่ผ่านมา:
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
https://aepicleak.com/
https://en.wikipedia.org/wiki/Software_Guard_Extensions#SGAxe
https://en.wikipedia.org/wiki/Software_Guard_Extensions#LVI
https://en.wikipedia.org/wiki/Software_Guard_Extensions#Plundervolt
https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
https://en.wikipedia.org/wiki/Software_Guard_Extensions#Enclave_attack
https://en.wikipedia.org/wiki/Software_Guard_Extensions/…
https://www.vusec.net/projects/crosstalk/
https://en.wikipedia.org/wiki/Hertzbleed
https://securityweek.com/amd-processors-expose-sensitive-data-new-squi…
มันไม่ได้ตีความคำสั่งด้วย
switchก้อนใหญ่ แต่รันคำสั่งบน CPU จริง และอาศัย hardware flags บางตัวที่รับประกันว่าข้อมูลหรือคำสั่งจะไม่ทับซ้อนกัน CPU ให้สัญญาแบบนั้นไว้ แต่ในโลกจริงการรักษาสัญญาแบบนั้นเป็นเรื่องยากฝั่งนั้นคือ CPU ทำสิ่งที่มันควรทำอย่างถูกต้อง แต่กลับเปิดทางให้เกิดการโจมตีรูปแบบใหม่ผ่าน การจับเวลา (timing-based) ส่วน Zenbleed ครั้งนี้ใกล้เคียงกับบั๊กแบบดั้งเดิมมากกว่า คือมีข้อมูลที่ไม่ควรอยู่ค้างอยู่ในรีจิสเตอร์
ช่องโหว่ลักษณะนี้หลายอย่างน่าจะเกิดจาก ฝั่งซอฟต์แวร์กับฝั่งฮาร์ดแวร์สื่อสารกันได้ไม่ดีพอ ฝั่งซอฟต์แวร์ตั้งสมมติฐานเรื่องการแยกกั้นไว้ ส่วนฝั่งฮาร์ดแวร์ก็ไม่ได้เตือนให้ชัดพอเมื่อมีการตั้งสมมติฐานแบบนั้น
รู้สึกว่า branch prediction มีความซับซ้อนโดยเนื้อแท้จนเลี่ยงการเปิดช่องให้เกิดช่องโหว่แบบนี้ได้ยากเสมอ หรือไม่ก็เพราะมันต่างจากวิธีที่เราเข้าใจเส้นทางโค้ดและการรันคำสั่งแบบสัญชาตญาณมากเกินไป จนยากจะนึกถึงเงื่อนไขขอบเขตก่อนที่จะสายเกินไป
ความซับซ้อนของสถาปัตยกรรม CPU จะไปถึงจุดที่ยากเกินกว่าจะให้เหตุผลกับมันได้ จนเรายอมรับการสูญเสียประสิทธิภาพเพื่อให้มันเรียบง่ายขึ้นหรือไม่?
เคยชี้ประเด็นนี้และแนะนำว่าควร air-gap ด้วย hypervisor แยกต่างหาก แต่ก็มักถูกเมินตลอด สุดท้ายก็คงเป็นปัญหาของพวกเขาเอง
ในไฟล์ README ของ tar สำหรับ exploit มีรายละเอียดเพิ่มเติมและ กำหนดการเปิดเผย อยู่ด้วย
2023-05-09องค์ประกอบหนึ่งใน pipeline ตรวจสอบ CPU สร้างผลลัพธ์ที่ผิดปกติ2023-05-12แยกปัญหาออกมาและทำซ้ำได้สำเร็จ ดำเนินการสืบสวนต่อ2023-05-14ระบุขอบเขตและความร้ายแรงของปัญหา2023-05-15เขียนรายงานสถานะอย่างย่อและแชร์ให้ AMD PSIRT2023-05-17AMD ยืนยันรายงานและยอมรับว่าสามารถทำซ้ำได้2023-05-17พัฒนา PoC ที่เชื่อถือได้เสร็จและแชร์ให้ AMD2023-05-19เริ่มแจ้งผู้พัฒนาเคอร์เนลและไฮเปอร์ไวเซอร์รายหลัก2023-05-23ได้รับอัปเดตไมโครโค้ดเบต้าสำหรับ Rome จาก AMD2023-05-24ยืนยันว่าอัปเดตนี้แก้ปัญหาได้และแจ้ง AMD2023-05-30AMD แจ้งว่าได้ส่งประกาศด้านความปลอดภัยให้พาร์ตเนอร์แล้ว2023-06-12ประชุมกับ AMD เพื่อหารือสถานะและรายละเอียด2023-07-20AMD เผยแพร่แพตช์โดยไม่ประกาศล่วงหน้า เร็วกว่าวัน embargo ที่ตกลงกันไว้2023-07-21เนื่องจากมีการเผยแพร่ตัวแก้ไขแล้ว จึงมีข้อเสนอให้แจ้งดิสทริบิวชันหลักแบบไม่เปิดเผยต่อสาธารณะเพื่อเตรียมอัปเดตแพ็กเกจเฟิร์มแวร์2023-07-24เปิดเผยสู่สาธารณะพวกเขาเผยแพร่แพตช์เร็วกว่าช่วง embargo ที่ตกลงกันไว้ แล้วหลังจากนั้นค่อยมีการพูดกันว่าจะต้องแจ้งดิสทริบิวชันหลักแบบไม่เปิดเผยต่อสาธารณะให้เตรียมแพ็กเกจเฟิร์มแวร์
amd-ucode 20230625.ee91452d-5ของ Arch Linux รวม อัปเดตไมโครโค้ด ที่แก้ปัญหานี้หรือไม่https://archlinux.org/packages/core/any/amd-ucode/ ถูกอัปเดตล่าสุดเมื่อ 2023-07-25 11:48 UTC และใน https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin... ระบุว่าเวอร์ชันที่แก้ไขแล้วคือ 2023-07-18
ตอนแรกคิดว่ายังใช้เฟิร์มแวร์ 20230625 อยู่ เพราะมี
_tag=20230625และsource=("git+[https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...](<https://git.kernel.org/pub/scm/…;)")ใน PKGBUILDแต่ในอาร์เรย์
_backportsมี cherry-pick commit สองตัวที่แก้ไขเมื่อ 20 ชั่วโมงก่อน และb250b32ab1d044953af2dc5e790819a7703b7ee6ใน https://gitlab.archlinux.org/archlinux/packaging/packages/li... ก็คือ commit จาก kernel.org ที่ลิงก์ไว้ก่อนหน้านี้ จึงหวังว่า Arch เวอร์ชันล่าสุดจะไม่เปราะบางต่อ Zenbleedนี่น่ากลัวมาก บน เครื่อง Zen 2 ของฉันอย่าง Ryzen 3600 ฉันรัน exploit ในฐานะผู้ใช้ที่ไม่มีสิทธิ์ แล้วคัดลอกและวางสตริงลงในโปรแกรมแก้ไขข้อความเบื้องหลัง (Kate) ภายในไม่กี่วินาที เศษของสตริงนั้นก็ถูกบันทึกไว้ในเอาต์พุตของ zenbleed
โชคดีที่ exploit นี้พึ่งพา assembly routine เฉพาะอย่างมาก จึงดูเหมือนว่าจะนำไปใช้ผ่าน JS หรือ WASM ในเบราว์เซอร์ได้ยากมาก ไม่เช่นนั้นแค่เปิดแท็บอันตรายทิ้งไว้เบื้องหลังไม่กี่ชั่วโมงก็คงทำข้อมูลรั่วไหลได้ง่าย
ตอนนี้กำลังรอให้ผู้ดูแล Fedora ปล่อยไมโครโค้ดใหม่ เพื่อให้เคอร์เนลอัปเดตได้ระหว่างกระบวนการบูต
พร้อมกันนั้นก็หวังว่า software patch ของ V8 และ SpiderMonkey จะออกมาเร็วและช่วยบรรเทาเพิ่มเติม
แต่ exploit บน JS ก็น่าจะต้องมีวิธีขโมยข้อมูลออกไปด้วย ซึ่งคงซ่อนให้มิดชิดได้ค่อนข้างยาก
"No such file or directory"และ error 127รู้สึกว่าการที่ OpenBSD เพิ่งเพิ่ม การโหลด AMD ไมโครโค้ด ภายใน 3 วันที่ผ่านมาไม่น่าใช่เรื่องบังเอิญ
https://news.ycombinator.com/item?id=36838511
ดูเหมือนว่าคำกล่าวที่ว่า AMD ออกอัปเดตไมโครโค้ดสำหรับโปรเซสเซอร์ที่ได้รับผลกระทบแล้ว จะไม่ค่อยแม่นยำนัก
AMD ได้ออก อัปเดตไมโครโค้ด[0] สำหรับ family 17h รุ่น
0x31และ0xa0และตาม WikiChip[1] นี่ตรงกับ Rome, Castle Peak และ Mendocinoจนถึงตอนนี้ดูเหมือนว่ายังไม่มีอัปเดตไมโครโค้ดสำหรับ Renoir, Grey Hawk, Lucienne, Matisse และ Van Gogh โชคดีที่เคอร์เนลใหม่สามารถตั้งค่า chicken bit ให้กับพวกนี้ได้แบบตรงไปตรงมา และก็ทำแบบนั้นจริง[2]
[0] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
[1] https://en.wikichip.org/wiki/amd/cpuid#Family_23_.2817h.29
[2] https://github.com/torvalds/linux/commit/522b1d69219d8f08317...
good_revsฝั่งเคอร์เนลอยู่ตรงนี้: https://github.com/torvalds/linux/commit/522b1d69219d8f08317...รีวิชัน (
Patch) ที่เปิดเผยในตอนนี้ดูได้ที่นี่ตาม git HEAD: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...ณ เวลาที่เขียนนี้ จาก
good_revทั้งห้ารายการ มีเปิดเผยแค่สองรายการCeleron ตัวนั้นดังเรื่อง โอเวอร์คล็อกได้ 50%: https://ark.intel.com/content/www/us/en/ark/products/codenam...
ถ้าดูส่วนที่เกี่ยวข้อง เทคนิคนี้คือ CVE-2023-20593 และใช้งานได้กับโปรเซสเซอร์ระดับ Zen 2 ทั้งหมด ซึ่งอย่างน้อยก็รวมถึงผลิตภัณฑ์ต่อไปนี้
AMD Ryzen 3000 Series Processors
AMD Ryzen PRO 3000 Series Processors
AMD Ryzen Threadripper 3000 Series Processors
AMD Ryzen 4000 Series Processors with Radeon Graphics
AMD Ryzen PRO 4000 Series Processors
AMD Ryzen 5000 Series Processors with Radeon Graphics
AMD Ryzen 7020 Series Processors with Radeon Graphics
AMD EPYC “Rome” Processors
เป็นไปได้ไหมว่าเทคนิคเดียวกันหรือเทคนิคคล้ายกันอาจใช้ได้กับ Zen/Zen+ รุ่นก่อนหน้า หรือคอร์ Zen 3 รุ่นถัดมา เพียงแต่ยังพิสูจน์ไม่ได้?
AMD Ryzen 9 5950x Desktop Processorของฉันก็ดูเป็น Zen 3 เลยน่าจะโอเคไม่ได้รันงานที่ไม่น่าเชื่อถือหรอก แต่ก็อย่างว่า คนที่เตรียมพร้อมย่อมได้เปรียบ
เว็บโดนทราฟฟิกถล่มจนแทบล่มอยู่: https://web.archive.org/web/20230724143835/https://lock.cmpx...
โดยมากแล้วทราฟฟิกจาก HN แทบไม่ถึง 100 pageview ต่อวินาทีด้วยซ้ำ
https://www.amd.com/en/resources/product-security/bulletin/a...
ตามประกาศความปลอดภัยของ AMD อัปเดตเฟิร์มแวร์สำหรับ CPU ที่ไม่ใช่ EPYC จะยังไม่ออกจนกว่าจะถึงปลายปี ระหว่างนี้ผู้ใช้ต้องปิด chicken bit แล้วรับผลกระทบด้านประสิทธิภาพไปก่อนหรือ?
ทั้งเจ๋งทั้งน่ากลัว รันตัวอย่าง 10MB แค่ 1 นาที ก็สามารถ “รั่ว” เอาบางส่วนของ รหัสผ่าน Bitwarden ของฉัน รหัสผ่านล็อกอิน ssh และชิ้นส่วนข้อมูลยืนยันตัวตนธนาคารออกมาได้ และประกอบกลับได้ไม่ยาก
บทความดีมาก ชอบเป็นพิเศษตรงที่อธิบายว่าจะตัดสินได้อย่างไรว่าโปรแกรมที่สร้างแบบสุ่มทำงานได้ถูกต้องหรือไม่
แนวทางที่เห็นได้ชัดคือรันบน oracle อย่างโปรเซสเซอร์ตัวอื่นหรือซิมูเลเตอร์ แล้วดูว่าทำงานเหมือนกันหรือไม่
แต่ถ้าจะตรวจสอบผลกระทบระดับไมโครสถาปัตยกรรมในช่วงเวลาที่แคบมาก ก็สามารถเขียนโปรแกรมเดียวกันโดยแทรก stall, fence, nop เป็นต้น ได้ ในโค้ดเธรดเดี่ยวสิ่งเหล่านี้ไม่ควรมีผลต่อเอาต์พุต แต่ภายใน CPU จะทำงานที่แตกต่างกันพอสมควรในเชิงไมโครสถาปัตยกรรม แบบนี้ CPU ก็สามารถเป็น oracle ให้ตัวเองได้
ชอบ chicken bit ด้วย