การได้สิทธิ์รันโค้ดในเคอร์เนลบน Pixel 8 ที่เปิดใช้ MTE

 (github.blog)
1 คะแนน โดย GN⁺ 2024-03-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • CVE-2023-6241 เป็นบั๊กเชิงตรรกะในหน่วยจัดการหน่วยความจำของ Arm Mali GPU ที่ทำให้แอป Android อันตรายสามารถไปถึงการรันโค้ดในเคอร์เนลตามอำเภอใจและได้สิทธิ์ root แม้บน Pixel 8 ที่เปิดใช้ kernel MTE
  • อุปกรณ์ที่ได้รับผลกระทบคืออุปกรณ์ Arm Mali GPU รุ่นใหม่ที่ใช้ Command Stream Frontend(CSF) โดยรวมถึง Google Pixel 7 และ Pixel 8
  • ช่องโหว่นี้ทำงานโดยอาศัยช่วงเวลาสั้น ๆ ระหว่างการขยายหน่วยความจำ JIT ที่มีการปลดล็อก ทำให้เกิดความไม่สอดคล้องกันระหว่าง GPU mapping กับอาร์เรย์ backing page
  • เอ็กซ์พลอยต์ใช้ GPU mapping ที่ยังคงอยู่ของ backing page ที่ถูกปล่อยแล้ว จากนั้นทำให้เพจนั้นถูกนำกลับมาใช้เป็น PGD ของ GPU context แล้วแมปหน่วยความจำเคอร์เนลและโค้ดเคอร์เนล
  • MTE สามารถตรวจจับความไม่ตรงกันของแท็กระหว่าง pointer กับหน่วยความจำได้ แต่ลำดับการโจมตีนี้เกิดขึ้น นอกขอบเขตการป้องกันของ MTE เพราะ GPU เข้าถึง physical address โดยตรง

ขอบเขตของช่องโหว่และสถานะแพตช์

  • CVE-2023-6241 เป็นช่องโหว่ของ Arm Mali GPU ที่ทำให้แอป Android อันตรายสามารถรันโค้ดในเคอร์เนลตามอำเภอใจและได้สิทธิ์ root บนอุปกรณ์
  • มีการรายงานให้ Arm ทราบเมื่อวันที่ 15 พฤศจิกายน 2023 และได้รับการแก้ไขใน Arm Mali driver r47p0 ที่เผยแพร่เมื่อวันที่ 14 ธันวาคม 2023
  • การแก้ไขฝั่ง Android รวมอยู่ใน อัปเดตความปลอดภัยเดือนมีนาคม 2024
  • อุปกรณ์ที่ได้รับผลกระทบคืออุปกรณ์ Arm Mali GPU รุ่นใหม่ที่ใช้ฟีเจอร์ CSF(Command Stream Frontend) โดยยก Google Pixel 7 และ Pixel 8 เป็นตัวอย่าง
  • ยืนยันแล้วว่าเอ็กซ์พลอยต์ทำงานได้แม้ใน Pixel 8 ที่เปิดใช้ kernel MTE

โมเดลการป้องกันของ Arm64 MTE

  • MTE(Memory Tagging Extension) เป็นฟีเจอร์ฮาร์ดแวร์ของโปรเซสเซอร์ Arm รุ่นใหม่ที่เปรียบเทียบแท็กของ pointer กับบล็อกหน่วยความจำเพื่อตรวจจับ memory corruption
  • pointer ของ Arm64 มีขนาด 64 บิต แต่ address space ของแอปพลิเคชันจริงมักใช้ไม่เกิน 52 บิต จึงสามารถนำบิตส่วนบนบางส่วนมาใช้เก็บแท็กได้
  • ในกรณี linear overflow แท็กของบล็อกหน่วยความจำข้างเคียงอาจไม่ตรงกับแท็กของ pointer และในกรณี use-after-free ก็อาจเกิดความไม่ตรงกันได้จากการเปลี่ยนแท็กระหว่างการปล่อยและจัดสรรใหม่
  • ต่างจากมาตรการบรรเทาปลายทางอย่าง kCFI, MTE เป็น มาตรการบรรเทาระยะต้น ที่พยายามตรวจจับตั้งแต่จุดที่ memory corruption เกิดขึ้นครั้งแรก
  • เนื่องจากจำนวนบิตของแท็กมีจำกัด จึงหลีกเลี่ยงการชนกันไม่ได้ แต่แม้ใช้แท็ก 4 บิตก็ยังลดโอกาสสำเร็จแบบสุ่มลงเหลือ 1/16
  • หากมีการรั่วไหลของค่า pointer และบล็อกหน่วยความจำผ่าน side-channel attack อย่าง Spectre ก็อาจเดาแท็กที่ถูกต้องเพื่อหลบ MTE ได้ แต่การรั่วไหลดังกล่าวมักทำได้โดยผู้โจมตีภายในเครื่อง
  • ปัจจุบันมีเพียง Google Pixel 8 ที่อนุญาตให้เปิดใช้ MTE ผ่าน developer options และ MTE ถูกปิดไว้เป็นค่าเริ่มต้น
  • การเปิดใช้ MTE ในเคอร์เนลต้องมีขั้นตอนเพิ่มเติม

race ที่เกิดขึ้นในหน่วยความจำ JIT ของ Mali

  • แอปผู้ใช้ที่ใช้ไดรเวอร์ Mali GPU จะเปิดไฟล์ไดรเวอร์และสร้าง/เริ่มต้นออบเจ็กต์เคอร์เนล kbase_context ผ่านการเรียก ioctl
  • kbase_context จัดการหน่วยความจำหลายประเภทที่ใช้ร่วมกันระหว่างอุปกรณ์ GPU กับแอปพลิเคชันใน user space
  • พื้นที่หน่วยความจำของ Mali GPU ถูกแทนด้วย kbase_va_region โดย nr_pages หมายถึงขนาดเสมือน และ gpu_alloc->nents หมายถึงจำนวน backing page จริง
  • หน่วยความจำ JIT เป็น native memory ที่เคอร์เนลไดรเวอร์จัดการอายุการใช้งาน โดยแอปสามารถจัดสรรหรือปล่อยหน่วยความจำ JIT ผ่านคำสั่ง GPU
  • บน CSF GPU คำสั่งซอฟต์แวร์และคำสั่งฮาร์ดแวร์จะอยู่คนละคิว
    • สามารถสร้าง kbase_kcpu_command_queue ได้ด้วย KBASE_IOCTL_KCPU_QUEUE_CREATE
    • สามารถใส่คำสั่งเข้าคิวได้ด้วย KBASE_IOCTL_KCPU_QUEUE_ENQUEUE
    • BASE_KCPU_COMMAND_TYPE_JIT_ALLOC และ BASE_KCPU_COMMAND_TYPE_JIT_FREE ใช้สำหรับจัดสรร/ปล่อย JIT
  • kbase_jit_allocate จะค้นหาพื้นที่ที่นำกลับมาใช้ได้จากพูลหน่วยความจำ JIT ที่ถูกปล่อยแล้ว และถ้าขนาดทางกายภาพไม่พอจะเพิ่ม backing page ด้วย kbase_jit_grow
  • kbase_jit_grow อาจปลด kctx->reg_lock และ kctx->mem_partials_lock ชั่วคราวระหว่างการเรียก kbase_mem_pool_grow
  • kctx->reg_lock ใช้ป้องกันการเข้าถึงพร้อมกันของพื้นที่หน่วยความจำ ดังนั้นช่วงที่ปลดล็อกจึงกลายเป็นหน้าต่าง race

ลำดับการ trigger ของ CVE-2023-6241

  • หาก GPU เข้าถึงที่อยู่ของพื้นที่หน่วยความจำที่ยังไม่มี backing เป็น physical page จะเกิด GPU memory access fault
  • kbase_mmu_page_fault_worker สามารถตรวจสอบได้ว่าพื้นที่นั้นขยายได้หรือไม่ แล้วจัดสรรและแมป backing page ที่ต้องใช้ได้ทันที
  • เมื่อสร้างพื้นที่ JIT จะตรงตามเงื่อนไข GROWABLE_FLAGS_REQUIRED ซึ่งรวม KBASE_REG_PF_GROW และ KBASE_REG_GPU_WR
  • แฟลก KBASE_REG_DONT_NEED ที่ถูกใส่ตอนปล่อยพื้นที่ JIT จะถูกลบออกใน kbase_mem_evictable_unmake ช่วงต้นของ kbase_jit_grow
  • ผลคือหากทำให้เกิด GPU page fault กับพื้นที่ JIT เดิมในหน้าต่าง race ระหว่างที่ kbase_mem_pool_grow กำลังทำงาน fault handler จะสามารถขยายพื้นที่นั้นได้
  • หาก fault handler เปลี่ยนค่า reg->gpu_alloc->nents ค่า old_size และ delta ที่ kbase_jit_grow บันทึกไว้ก่อนหน้าจะไม่ตรงกับสถานะจริง
  • หลังจากนั้น kbase_alloc_phy_pages_helper_locked และ kbase_mem_grow_gpu_mapping จะจัดสรร backing page และทำ GPU mapping ด้วยค่าที่ stale ทำให้เกิดความไม่สอดคล้องกันระหว่าง GPU mapping กับอาร์เรย์ pages
  • race นี้ชนะได้ง่ายเพราะ kbase_mem_pool_grow มีการจัดสรรหน่วยความจำขนาดใหญ่รวมอยู่ด้วย

วิธีโจมตีที่เปลี่ยนไปหลังแพตช์ GHSL-2023-005

  • ในช่องโหว่ก่อนหน้า GHSL-2023-005 เธรดอื่นสามารถย่อพื้นที่ JIT ด้วย KBASE_IOCTL_MEM_COMMIT ทำให้ old_size และ delta ใช้ไม่ได้
  • หลังแพตช์ GHSL-2023-005 จะไม่สามารถเปลี่ยนขนาดหน่วยความจำ JIT ผ่าน KBASE_IOCTL_MEM_COMMIT ioctl ได้อีก
  • ใน CVE-2023-6241 จึงไม่สามารถย่อพื้นที่ในหน้าต่าง race ได้ และทำได้เพียง ขยายเท่านั้น
  • ถ้าขยายอย่างเดียว เพียงแต่ backing page บางส่วนท้ายสุดจะไม่ถูกแมปบน GPU โดยรูปแบบการแมปแบบต่อเนื่องตั้งแต่ต้นยังคงอยู่ จึงยังไม่ก่อปัญหาทันที
  • เอ็กซ์พลอยต์จะสร้างแมปใหม่หลัง unmapped gap ด้วย GPU fault เพิ่มเติม แล้วค่อยใช้การปล่อย JIT เพื่อจัดตำแหน่ง shrink ให้ตกอยู่ใน gap นั้นจนเกิดสภาพที่นำไปใช้โจมตีได้

สมมติฐานที่เปราะบางในการยกเลิก GPU mapping

  • kbase_mmu_teardown_pgd_pages จะไล่ดู GPU page table แล้วทำเครื่องหมายเอนทรีเป็น invalid เพื่อลบ GPU address mapping
  • ฟังก์ชันนี้ตั้งสมมติฐานว่า ถ้า PTE ระดับสูงเป็น invalid แปลว่าช่วง address ขนาดใหญ่ทั้งหมดที่เอนทรีนั้นครอบอยู่ถูก unmap ไปแล้ว จึงข้ามได้
  • PTE ระดับ 2 หนึ่งตัวครอบคลุมช่วง 512 เพจ
  • ใน kbase_va_region ปกติ virtual address ที่ถูกแมปจะต่อเนื่องตั้งแต่ต้นพื้นที่เสมอและไม่มี gap ตรงกลาง ดังนั้นพฤติกรรมการข้ามนี้จึงปลอดภัย
  • เอ็กซ์พลอยต์ของ CVE-2023-6241 สร้าง unmapped gap ระหว่างการแมป แล้ววางจุดเริ่ม shrink ไว้ใน gap นั้น
  • kbase_mmu_teardown_pgd_pages จะพบ PTE ระดับ 2 ที่ invalid แล้วข้ามไป 512 เพจ แต่ address บางส่วนหลังจากนั้นอาจยังถูกแมปอยู่จริง
  • GPU address ที่ถูกข้ามผิดพลาดจะยังคงเข้าถึง physical page เดิมได้แม้ backing page จะถูกปล่อยไปแล้ว

ลำดับที่นำไปสู่การรันโค้ดในเคอร์เนล

  • เมื่อปล่อยพื้นที่ JIT backing page จะถูกคืนกลับ แต่ GPU mapping ที่ค้างอยู่อย่างผิดพลาดยังเข้าถึงเพจที่ถูกปล่อยแล้วได้ต่อไป
  • backing page ที่ถูกปล่อยแล้วอาจถูกนำกลับมาใช้เป็นหน้าเคอร์เนลอื่นในภายหลัง
  • หนึ่งในเทคนิคที่ใช้คือทำให้ backing page ที่ถูกปล่อยแล้วถูกนำกลับมาใช้เป็น PGD(page table global directory) ของ GPU kbase_context
  • การจัดสรร backing page ของไดรเวอร์ Mali ทำแบบเป็นลำดับชั้น
    • ขั้นแรกจะดึงเพจจาก kbase_mem_pool ของ kbase_context ปัจจุบัน
    • ถ้าไม่พอจะใช้ pool->next_pool
    • ถ้ายังไม่พอจะจัดสรรเพจโดยตรงผ่าน kernel buddy allocator
  • pool->next_pool เป็นพูลหน่วยความจำที่ไดรเวอร์ Mali จัดการและใช้ร่วมกันโดยทุก kbase_context รวมถึงใช้จัดสรร PGD ของ GPU context ด้วย
  • ถ้าเพจที่ถูกปล่อยแล้วถูกนำกลับมาใช้เป็น PGD ก็จะสามารถเขียน PGD นั้นจาก GPU ได้อีกครั้งผ่าน GPU address ที่ยังคงอยู่
  • เมื่อเขียน PGD ใหม่ ก็จะสามารถแมปหน่วยความจำเคอร์เนลและโค้ดเคอร์เนลตามอำเภอใจให้ GPU เห็นได้
  • ในสภาวะนี้จึงสามารถเขียนทับโค้ดเคอร์เนลเพื่อรันโค้ดในเคอร์เนลตามอำเภอใจ และอ่าน/เขียนข้อมูลเคอร์เนลเพื่อเปลี่ยน credential ของโปรเซสและปิด SELinux ได้ด้วย
  • เอ็กซ์พลอยต์สำหรับ Pixel 8 และบันทึกการตั้งค่าเผยแพร่อยู่ใน GitHub Security Lab repository

เหตุผลที่สามารถ bypass MTE ได้

  • ลำดับเอ็กซ์พลอยต์นี้ไม่ต้องมีขั้นตอน bypass MTE โดยเฉพาะแยกต่างหาก
  • MTE เป็นฟังก์ชันที่ตรวจว่าหน่วยความจำบล็อกที่ pointer อ้างถึงมีแท็กตรงกันหรือไม่ เพื่อจับการ dereference ที่ไม่ถูกต้อง
  • ตอน trigger CVE-2023-6241 จะเกิดความไม่สอดคล้องกันระหว่างอาร์เรย์ pages กับ GPU mapping แต่หากมองแยกกันแต่ละส่วนก็ไม่ได้มี invalid entry อยู่
  • เมื่อ kbase_mmu_teardown_pgd_pages ข้ามการลบ GPU mapping physical address ของเพจหน่วยความจำที่ถูกปล่อยแล้วจะยังคงอยู่ใน GPU page table
  • ตอนที่ GPU เข้าถึงเพจที่ถูกปล่อยแล้วนี้ จะเป็นการเข้าถึง physical address โดยตรง จึงไม่ผ่านการตรวจ dereference ของ pointer
  • ผลกระทบของ MTE ต่อการเข้าถึงหน่วยความจำของ GPU เองก็ยังไม่ชัดเจน
  • สรุปคือบั๊กนี้ bypass การป้องกันของ MTE ได้โดยอาศัยเส้นทางที่ coprocessor อย่าง GPU เข้าถึง physical memory โดยตรง

พื้นที่โจมตีที่ยังคงอยู่แม้มี MTE

  • CVE-2023-6241 แสดงให้เห็นว่าแม้บน Pixel 8 ที่เปิดใช้ kernel MTE ก็ยังสามารถไปถึงการรันโค้ดในเคอร์เนลตามอำเภอใจได้ด้วยบั๊กเดียว
  • MTE เป็นความก้าวหน้าสำคัญในการบรรเทา memory corruption และอาจทำให้ช่องโหว่ประเภทนี้จำนวนมากนำไปใช้โจมตีไม่ได้ แต่ไม่ใช่มาตรการป้องกันสารพัดนึก
  • ในกรณีนี้มีการ bypass MTE โดยอาศัยวิธีที่ GPU เข้าถึง physical memory โดยตรง
  • ยิ่งมีมาตรการบรรเทาทั้งฮาร์ดแวร์และซอฟต์แวร์ฝั่ง CPU มากขึ้นเท่าไร coprocessor และเคอร์เนลไดรเวอร์ของมันก็ยิ่งอาจยังเป็นพื้นผิวการโจมตีที่ทรงพลังต่อไป

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

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

 
GN⁺ 2024-03-20
ความคิดเห็นบน Hacker News

  • ประเด็นสำคัญตรงนี้คือ GPU เป็นตัวปัญหาของ Android มานานแล้ว
    GPU มีสิทธิ์เข้าถึง AP ที่สูงมาก จึงสามารถเลี่ยงมาตรการบรรเทาที่วางไว้ก่อนหน้าได้แทบทั้งหมด บั๊กในโค้ดแมปปิงของไดรเวอร์นำไปสู่ primitive สำหรับการโจมตีที่ทรงพลัง และก็ถูกนำไปใช้ซ้ำ ๆ ใน exploit ที่ใช้โจมตีจริงมาโดยตลอด สุดท้ายแล้ว ถ้ายังไม่ออกแบบสถาปัตยกรรมใหม่ ก็คงยากที่จะเปลี่ยนแปลงได้มาก

    • ผมคิดว่า mobile GPU ที่ทำมาแบบกึ่ง ๆ ทั้งหลายควรเลิกใส่ MMU ของตัวเอง แล้วหันไปใช้ I/O MMU มาตรฐาน
    • AP ในที่นี้หมายถึงอะไรครับ?

  • สิ่งที่น่าสนใจในช่องโหว่นี้คือเป็น บั๊กเชิงตรรกะ ในหน่วยจัดการหน่วยความจำของ Arm Mali GPU และสามารถบายพาส Memory Tagging Extension ได้
    แต่ส่วนที่เหลือของบทความกลับดูเหมือนอธิบายว่าต้นเหตุจริง ๆ คือ race condition และ use-after-free เป็นผลที่ตามมา

  • เครื่องที่ติดตั้ง GrapheneOS ก่อนอัปเดตเดือนมีนาคมได้รับผลกระทบด้วยหรือเปล่า?

    • หนึ่งในเป้าหมายหลักของ GrapheneOS คือปล่อยอัปเดตความปลอดภัยให้เร็วที่สุดเท่าที่ทำได้ ดังนั้นถ้ามีการแพตช์ใน upstream แล้ว ก็น่าจะแทบแน่นอนว่า GrapheneOS รวมไว้ด้วย
      บางครั้งยังใช้ระดับแพตช์ความปลอดภัยของ AOSP ก่อนวันออกจริง หรือแบ็กพอร์ตการแก้ไขด้านความปลอดภัยจาก AOSP หรือซอร์สเคอร์เนลที่ยังไม่เปิดเผยด้วย
    • ผมคิดว่านี่ดูเป็นปัญหาที่ใกล้เคียงกับฮาร์ดแวร์ภายใน GPU หรืออาจเกี่ยวกับเฟิร์มแวร์ด้วย เลยคิดว่าน่าจะยังได้รับผลแม้หลังอัปเดตเดือนมีนาคม เพราะอัปเดตนั้นเกี่ยวกับ Bluetooth stack
      แก้ไข: ข้ามความเห็นนี้ได้เลย ผมสับสนกับโพสต์ล่าสุดในบล็อกของ GrapheneOS เรื่อง “พบปัญหาที่ MTE ถูกนำไปใช้กับแอประบบทั้งหมดด้วย” GrapheneOS นำ “ระดับแพตช์ความปลอดภัย 2024-03-05 แบบครบถ้วน” มาใช้ในรีลีส 2024030600 ดังนั้นแพตช์นี้ก็น่าจะรวมอยู่ด้วย

  • ความปลอดภัยของหน่วยความจำ Arm MTE แบบความน่าจะเป็นเป็นก้าวสำคัญไปสู่ฮาร์ดแวร์ CHERI แบบกำหนดแน่นอน, https://saaramar.github.io/memory_safety_blogpost_2022/ และ https://news.ycombinator.com/item?id=39668053
    มาตรการบรรเทาที่ถูกต้องควรมุ่งไปที่ primitive ของการโจมตีขั้นต้น กล่าวคือสาเหตุรากของบั๊กเอง ทางแก้ฝั่งฮาร์ดแวร์มี CHERI (Morello, CheriIoT), MTE และมาตรการบรรเทาฝั่งซอฟต์แวร์มี kalloc_type+dataPAC, AUTOSLAB, Firebloom, GuardedMemcpy, CastGuard, การลดพื้นผิวการโจมตี ส่วนภาษาการเขียนโปรแกรมที่ปลอดภัยมี Rust และ Swift MTE และ CHERI ทำงานสอดประสานกันได้ดี ช่วยกำจัดบั๊กในลักษณะนี้จากสาเหตุรากได้ MSR, MSRC, Azure Silicon ได้ผลักดันการย่อ CHERI ลงไปจนถึงสเปกคอร์ RISC-V ที่เล็กที่สุดอย่าง RISC-V32E
    Microsoft Research ได้เปิดซอร์สสแตกฮาร์ดแวร์/ซอฟต์แวร์ CHERI สำหรับอุปกรณ์ IoT, https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheri...
    ไมโครคอนโทรลเลอร์ที่อิง CHERI มีเป้าหมายเพื่อให้ได้หลักประกันด้านความปลอดภัยที่แข็งแกร่งมาก โดยออกแบบสถาปัตยกรรมชุดคำสั่ง (ISA), application binary interface (ABI), โมเดลการแยกกักกัน และแกนกลางของซอฟต์แวร์สแตกไปพร้อมกัน ไมโครคอนโทรลเลอร์นี้บรรลุการบรรเทาแบบกำหนดแน่นอนของความปลอดภัยเชิงพื้นที่ผ่านความสามารถของ CHERI-ISA, การบรรเทาแบบกำหนดแน่นอนของความปลอดภัยเชิงเวลาสำหรับฮีปและสแตกข้าม compartment ผ่าน load barrier, zeroing, revocation และการควบคุมการไหลของข้อมูล 1 บิต รวมถึงการแยก compartment อย่างละเอียดผ่านความสามารถ CHERI-ISA เพิ่มเติมและมอนิเตอร์ขนาดเล็ก
    David Chisnall, U of Cambridge, https://lobste.rs/s/gnjx2n/c_can_be_memory_safe#c_9ohzku via https://eclypsium.com/blog/a-faster-path-to-memory-safety-ch...
    “มีโค้ด C/C++ โอเพนซอร์สอยู่ราว 1.3 หมื่นล้านบรรทัดในฐานคอมพิวติ้งที่เชื่อถือได้หลายแห่ง และถ้ารวมโค้ดปิดเข้าไปก็จะมากกว่านี้ ต่อให้ทุกคนหยุดเขียน C/C++ ตอนนี้ และวิศวกรซอฟต์แวร์ทุกคนหันไปโฟกัสที่การเขียนโค้ดเก่าขึ้นใหม่ด้วยภาษาที่ปลอดภัย ก็น่าจะยังใช้เวลา 5–10 ปีกว่าจะทดแทนทั้งหมดได้ และยังมีโอกาสสูงที่จะเกิดบั๊กเชิงตรรกะจำนวนมากจากการแทนที่โค้ดที่ผ่านการพิสูจน์มาอย่างยาวนานด้วยโค้ดใหม่ที่ต้องใช้อัลกอริทึมและโครงสร้างข้อมูลอื่นเพื่อให้เข้ากับรูปแบบที่ภาษาปลอดภัยอนุญาต”
    “ถ้าไม่เขียนขึ้นใหม่ แค่หยุดเขียน C/C++ อย่างเดียว ด้วยอัตราการเปลี่ยนโค้ดตามปกติ ฐานคอมพิวติ้งที่เชื่อถือได้จะใช้เวลาราว 50 ปีกว่าจะปลอดภัยทั้งหมด หากทุกคนไม่สามารถตกลงกันได้ว่าจะเลิก C/C++ อย่างน้อยก็ 100 ปี”
    “ในทางกลับกัน ถ้าผู้ผลิต CPU รายใหญ่เริ่มออก CHERI CPU ภายใน 5 ปี เครื่องส่วนใหญ่ โดยเฉพาะเครื่องที่มีมูลค่าสูง จะมีความปลอดภัยของหน่วยความจำภายใน 15 ปีนับจากวันนี้ โดยที่โปรแกรมเมอร์ไม่ต้องเปลี่ยนพฤติกรรมเลย”

    • หากสนใจ CHERI สำหรับการใช้งานคล้าย embedded/IoT, lowRISC กำลังสร้างแพลตฟอร์มประเมินผลแบบใช้ FPGA สำหรับ CHERIoT อยู่หลายแบบ: https://www.sunburst-project.org/
      ตัวแรกคือระบบ Sonata: https://github.com/lowRISC/sonata-system ประกอบด้วย FPGA และ PCB เฉพาะทางที่มีอุปกรณ์ต่อพ่วงและเฮดเดอร์ต่าง ๆ ตอนนี้การออกแบบ PCB เสร็จแล้ว และน่าจะหาซื้อได้ผ่าน Mouser อีกทั้งยังโอเพนซอร์สถึงระดับเลย์เอาต์บอร์ด จึงประกอบเองได้หากต้องการ ขณะนี้กำลังทำ RTL สำหรับ FPGA อยู่ เมื่อเสร็จแล้วก็จะได้ระบบลักษณะไมโครคอนโทรลเลอร์ที่อิง CHERIoT พร้อมเอกสารและเครื่องมือครบ
      นอกจากนี้ยังมีการพัฒนาระบบ Symphony ที่รวม Sonata เข้ากับ OpenTitan Earl Grey root of trust: https://github.com/lowRISC/symphony-system
    • ยังมี Solaris SPARC ADI ด้วย แม้คนส่วนใหญ่จะลืมไปแล้วเพราะสถานะปัจจุบันของ Oracle และ Solaris SPARC ก็น่าเสียดายอยู่
    • นี่เป็นบั๊กฮาร์ดแวร์นอก CPU เลยไม่แน่ใจว่า CHERI จะช่วยได้อย่างไร
      อีกอย่าง เท่าที่จำได้ครั้งล่าสุด CHERI ยังไม่ sound แม้ใช้อยู่บนมันก็ยังเขียนเมมโมรีบั๊กได้ เรื่องนั้นแก้แล้วหรือยัง?
    • “5–10 ปีเพื่อแทนที่ทุกอย่าง” ถ้าหมายถึงปีจริง ๆ ก็ดูมองโลกในแง่ดีเกินไป
      แค่เถียงกันเรื่องโรงจอดจักรยานก็น่าจะกินเวลาเท่านั้นแล้ว
    • ดูเหมือนปัญหาที่แท้จริงคือผู้ใช้รันโค้ดอันตรายแล้วไปใช้ประโยชน์จาก MMU hash collision บางอย่าง
      เอ็กซ์พลอยต์นี้น่าจะเขียนได้ด้วยภาษาส่วนใหญ่ รวมถึง Rust ด้วย

  • ฮาร์ดแวร์มันแย่ได้ขนาดนั้นเลยเหรอ? โอ้โห...

    • ฮาร์ดแวร์ GPU เต็มไปด้วยบั๊ก จะ re-spin ฮาร์ดแวร์ก็ต่อเมื่อเป็นปัญหาที่เลี่ยงในไดรเวอร์ด้วยต้นทุนที่ยอมรับได้ไม่ได้จริง ๆ
      ที่ทำแบบนี้ได้เพราะ GPU ไม่เปิดให้เข้าถึงฮาร์ดแวร์แบบตรง ๆ มากนักเหมือน CPU
    • นี่คือ บั๊กของไดรเวอร์ ที่รันบน CPU เอง

  • เป็นงานวิจัยและบทความที่ยอดเยี่ยม แต่ก็ทั้งน่าแปลกใจและน่ายินดีเล็กน้อยที่มันไปลงบนบล็อกของ GitHub
    มีใครรู้ไหมว่า “เหตุผลทางธุรกิจ” ของ GitHub ในการทำวิจัยแบบนี้คืออะไร? ไม่ได้หมายความว่าจำเป็นต้องมีเหตุผลทางธุรกิจเสมอไป แต่พอมาเห็นที่นี่แล้วก็ค่อนข้างแปลกใจ

    • Man Yue Mo เคยทำงานที่ Semmle ก่อนที่บริษัทจะถูก GitHub เข้าซื้อกิจการ (https://blog.sonatype.com/steps-to-responsible-disclosure, https://github.blog/2019-09-18-github-welcomes-semmle/)
      ความสามารถด้านการวิจัยนั้นต่อยอดมาเป็น GitHub Security Lab โดย Semmle เป็นผู้สร้าง CodeQL และตอนนี้ GitHub เป็นผู้ให้บริการ (https://docs.github.com/en/code-security/code-scanning/intro...). GitHub และ Microsoft ต้องการเชื่อม CodeQL เข้ากับ “ข้อมูลเชิงลึกด้านความปลอดภัยระดับลึก” (https://www.microsoft.com/en-us/security/blog/2023/11/02/ann...)
      ดังนั้นพวกเขาจึงยังคงให้ทุนกับงานวิจัยความปลอดภัยที่แปลกใหม่แบบนี้ต่อไป และผู้ปฏิบัติงานด้านความปลอดภัยในอุตสาหกรรมก็ซาบซึ้งกับเรื่องนี้
    • งานนี้มาจาก Security Lab ของ GitHub: https://securitylab.github.com/
    • หลังจากถูก Microsoft เข้าซื้อกิจการ ก็มีทรัพยากรมากพอที่จะสนับสนุนงานวิจัยประเภทนี้
      GitHub ก็มีแอปอยู่ด้วย และความปลอดภัยของแอปนั้นก็ไม่ใช่เรื่องที่อยู่นอกขอบเขตของ GitHub หากผู้โจมตีสามารถติดตั้งแอปที่ซ่อนตัวอยู่ในโทรศัพท์ได้ ก็อาจทำหลายอย่างได้ราวกับเป็นผู้ใช้เอง หากเป็นคนที่มีอิทธิพลบน GitHub ความเสียหายก็อาจมากพอสมควร ดังนั้นการค้นหาช่องโหว่แบบนี้จึงเป็นประโยชน์กับ GitHub เช่นกัน
    • GitHub ยังมี Actions runner แบบโฮสต์สำหรับ Arm ด้วย
      ดังนั้นจึงอาจสนใจตรวจสอบและยืนยันฟีเจอร์ความปลอดภัยของฮาร์ดแวร์ Arm เพื่อทำ sandboxing โดยใช้ MTE
    • มองได้ว่าใกล้เคียงกับ การวิจัยพื้นฐาน มาก [0]
      หากมองแบบตรงไปตรงมา ในฐานะผลิตภัณฑ์แล้ว GitHub อาจไม่ได้จำเป็นต้องมีผู้เชี่ยวชาญด้านความปลอดภัย Android โดยตรง แต่ในระยะยาวก็มีประโยชน์ที่เป็นไปได้
      [0]: https://en.wikipedia.org/wiki/Basic_research

  • น่าแปลกใจที่จนถึงตอนนี้ยังไม่มีใครทำ CPU และโทรศัพท์ที่แทบไม่มี GPU หรือไม่มีเลย แล้วเรียกมันว่า โทรศัพท์ธุรกิจ
    มันดูมีข้อดีที่ชัดเจนทั้งในแง่ความปลอดภัย ต้นทุน และการใช้พลังงาน

    • ข้อเสียที่ชัดเจนคือจะไม่มี หน้าจอสัมผัสความละเอียดสูง ทำให้ต้องย้อนกลับไปเป็น Blackberry หรือ Palm Treo ซึ่งจริง ๆ แล้วอุปกรณ์พวกนั้นก็เคยถูกขายในฐานะโทรศัพท์ธุรกิจ