การบังคับใช้ความสมบูรณ์ของหน่วยความจำของ Apple (Memory Integrity Enforcement)

 (security.apple.com)
4 คะแนน โดย GN⁺ 2025-09-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Apple เปิดตัว Memory Integrity Enforcement (MIE) เพื่อสร้างระบบความปลอดภัยของหน่วยความจำแบบใหม่ โดยผสานฮาร์ดแวร์ Apple Silicon เข้ากับความปลอดภัยของระบบปฏิบัติการขั้นสูง
  • MIE ทำงานในสถานะ เปิดใช้งานตลอดเวลา เพื่อปกป้องพื้นผิวการโจมตีหลัก และถูกนำไปใช้กับอุปกรณ์ iPhone 17 และ iPhone Air ทุกเครื่องโดยไม่ทำให้ประสิทธิภาพลดลง
  • ด้วยการผสาน Enhanced Memory Tagging Extension (EMTE), secure memory allocator และนโยบายการรักษาความลับของแท็กเข้าด้วยกัน ทำให้เพิ่ม ความทนทาน ต่อการโจมตีที่เป็นอันตรายได้อย่างชัดเจน
  • จากการตรวจสอบแท็กแบบซิงโครนัสและการผสานระบบปฏิบัติการกับฮาร์ดแวร์อย่างประณีต ทำให้การป้องกัน ช่องโหว่ buffer overflow และ use-after-free มีประสิทธิภาพสูงสุด
  • ผ่านการวิจัยเชิงรุกและการประเมินภายในตลอดหลายปี Apple สามารถ จำกัดอิสระของผู้โจมตี และบรรลุความปลอดภัยของหน่วยความจำที่แข็งแกร่งที่สุดในปัจจุบัน

บทนำ

  • Memory Integrity Enforcement (MIE) ของ Apple เป็นเทคโนโลยีป้องกันความปลอดภัยของหน่วยความจำที่เปิดใช้งานอยู่เสมอ โดยรวมฮาร์ดแวร์ Apple Silicon เข้ากับความปลอดภัยของระบบปฏิบัติการที่ยกระดับขึ้น
  • พัฒนาขึ้นโดยมีเป้าหมายเพื่อมอบ ระบบความปลอดภัยของหน่วยความจำในวงกว้าง ที่เกิดขึ้นเป็นครั้งแรกในอุตสาหกรรมสำหรับอุปกรณ์ Apple หลายประเภท โดยไม่มี ผลกระทบต่อประสิทธิภาพ เพิ่มเติม
  • Apple ประเมินว่านี่คือความก้าวหน้าที่สำคัญที่สุดในประวัติศาสตร์ด้านความปลอดภัยของหน่วยความจำบนระบบปฏิบัติการสำหรับผู้บริโภค

ภูมิหลังของภัยคุกคามด้านความปลอดภัยและวิวัฒนาการของความปลอดภัยของหน่วยความจำ

  • เหตุผลที่ iPhone ยังไม่มีกรณีความสำเร็จของ การโจมตีมัลแวร์ในวงกว้าง เพราะภัยคุกคามที่พบจริงมีเพียงห่วงโซ่การโจมตีที่ซับซ้อนซึ่งเน้น mercenary spyware เป็นหลัก
  • การโจมตีขั้นสูงเหล่านี้ซึ่งมีต้นทุนหลายล้านดอลลาร์และมุ่งเป้าไปยังเป้าหมายจำนวนน้อย มักอาศัยการโจมตีผ่าน ช่องโหว่ด้านความปลอดภัยของหน่วยความจำ ร่วมกัน
  • Apple ปรับปรุงความปลอดภัยของหน่วยความจำอย่างต่อเนื่องผ่านการพัฒนาภาษาแบบปลอดภัยอย่าง Swift การนำ secure memory allocator มาใช้ และมาตรการบรรเทาความเสี่ยงขนาดใหญ่ทั่วทั้งระบบ
  • Apple เป็นรายแรกของโลกที่นำ Pointer Authentication Code (PAC) มาใช้ใน A12 Bionic และทำให้แนวทางความปลอดภัยแบบผสานฮาร์ดแวร์กับซอฟต์แวร์กลายเป็นมาตรฐานหลัก

เทคโนโลยี memory tagging บนฮาร์ดแวร์ (MTE/EMTE) และการก้าวข้ามข้อจำกัด

  • Memory Tagging Extension (MTE) ที่ Arm เสนอ เป็นวิธีการกำหนดแท็กลับให้กับการจัดสรรหน่วยความจำแต่ละครั้ง และอนุญาตให้เข้าถึงได้เฉพาะเมื่อใช้แท็กที่ถูกต้อง
  • Apple พบข้อเสียของดีไซน์ต้นฉบับของ MTE เช่น การทำงานแบบอะซิงโครนัส และได้ร่วมมือกับ Arm เพื่อปรับปรุงเป็น Enhanced Memory Tagging Extension (EMTE)
  • หัวใจสำคัญคือการออกแบบให้การตรวจสอบแท็กทำงานในรูปแบบ ซิงโครไนซ์ตลอดเวลา เพื่อมอบการป้องกันอย่างต่อเนื่อง

โครงสร้างแบบหลายชั้นของ MIE และกลไกการป้องกันหลัก

  • MIE ประกอบด้วยสามองค์ประกอบ ได้แก่ type-aware secure allocator อย่าง kalloc_type, xzone malloc และ libpas ของ WebKit, EMTE และนโยบาย Tag Confidentiality Enforcement
  • ตัว allocator มอบการป้องกันในระดับ หน้าเพจหน่วยความจำ ระหว่างชนิดข้อมูลที่แตกต่างกัน ขณะที่ EMTE รับมือกับช่องโหว่ในการจัดสรรหน่วยความจำขนาดเล็กภายในบักเก็ตชนิดเดียวกัน
  • สำหรับการโจมตีทำลายหน่วยความจำทั่วไป เช่น buffer overflow และ use-after-free ฮาร์ดแวร์และระบบปฏิบัติการจะใช้การติดแท็กและการติดแท็กใหม่เพื่อตรวจจับและบล็อกได้ทันที

การรักษาความลับของแท็กและกลยุทธ์รับมือการโจมตีแบบ side-channel

  • เพื่อป้องกันไม่ให้ผู้โจมตีมุ่งเป้าไปที่พื้นที่เก็บข้อมูลของ allocator และการเปิดเผยแท็ก Apple จึงนำกลไกป้องกันที่เข้มแข็งอย่าง Secure Page Table Monitor มาใช้
  • เพื่อรับมือการโจมตีแบบ side-channel ที่อาศัย speculative execution นั้น Apple Silicon ถูกออกแบบให้ ตัดผลกระทบจากข้อมูลแท็กต่อ speculative execution ตั้งแต่ต้นทาง
  • ยังสามารถป้องกันช่องโหว่ Spectre V1 ได้อย่างมีประสิทธิภาพ และในกรณีส่วนใหญ่สามารถตัดห่วงโซ่การโจมตีที่ใช้งานได้จริงออกไปได้

การรับมือแบบบูรณาการระหว่างซอฟต์แวร์และฮาร์ดแวร์ และการใช้งานอย่างกว้างขวาง

  • ในการออกแบบชิป A19/A19 Pro รุ่นใหม่ Apple ได้เพิ่มทรัพยากรฮาร์ดแวร์จำนวนมากเพื่อรองรับการเก็บและตรวจสอบแท็ก
  • MIE ใช้ secure allocator เป็นด่านหน้าเพื่อครอบคลุมส่วนที่ซอฟต์แวร์สามารถป้องกันได้ก่อน ส่วน EMTE จะถูกนำไปใช้กับพื้นที่ที่ซอฟต์แวร์ไม่สามารถป้องกันได้อย่างแม่นยำ
  • Apple ยังปรับแต่งแนวทางการกระจายใช้งานอย่างละเอียด เพื่อให้อุปกรณ์ iPhone รุ่นเก่าได้รับประโยชน์จากการปรับปรุงความปลอดภัยของหน่วยความจำให้มากที่สุดเท่าที่จะเป็นไปได้

การประเมินด้านความปลอดภัยในสถานการณ์จริงและการวิเคราะห์ประสิทธิผล

  • ทีม วิจัยการโจมตี ของ Apple ได้สร้างสถานการณ์โจมตีหลากหลายแบบตั้งแต่ช่วงวางแผน MIE ระหว่างปี 2020–2025 และพยายามเจาะระบบจริงซ้ำแล้วซ้ำเล่าแม้กระทั่งกับต้นแบบฮาร์ดแวร์
  • ทั้งในห่วงโซ่เอ็กซ์พลอยต์แบบเก่าและแบบใหม่ Apple ยืนยันได้ว่าเมื่อใช้ MIE แล้ว ขั้นตอนส่วนใหญ่ของการโจมตีถูกปิดกั้นตั้งแต่รากฐาน
  • แม้จะมีช่องโหว่เพียงส่วนน้อยที่ยังหลงเหลืออยู่ ก็ไม่สามารถนำไปสู่การโจมตีที่มีเสถียรภาพได้ ทำให้ความเป็นไปได้ของความเสียหายในทางปฏิบัติลดลงอย่างมาก

บทสรุป

  • ความปลอดภัยระดับแนวหน้าของอุตสาหกรรมบน iPhone ช่วย จำกัดการเปิดรับการโจมตีระดับระบบ สำหรับผู้ใช้ส่วนใหญ่ตั้งแต่ต้น
  • MIE ทำให้กลยุทธ์การโจมตีที่ซับซ้อนและมีต้นทุนสูงที่สุดของ mercenary spyware ใช้งานไม่ได้ พร้อมทั้งปกป้อง กระบวนการใน user space หลักราว 70 รายการ รวมถึงเคอร์เนล แบบเปิดใช้งานตลอดเวลา
  • ผลการประเมินยืนยันว่า MIE เพิ่มต้นทุนและความยากในการโจมตีช่องโหว่จาก memory corruption อย่างมาก และช่วยสกัดกั้นเทคนิคการโจมตีหลักตลอด 25 ปีที่ผ่านมาได้อย่างแข็งแกร่ง
  • MIE จึงกลายเป็น การเปลี่ยนแปลงครั้งใหญ่ที่สุด ในประวัติศาสตร์ความปลอดภัยของหน่วยความจำบนระบบปฏิบัติการสำหรับผู้บริโภคของ iOS และอุปกรณ์ Apple

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

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

 
GN⁺ 2025-09-11
ความคิดเห็นจาก Hacker News
  • ทั้งสองแนวทางต่างก็ไปถึงข้อสรุปเดียวกัน Memory Integrity Enforcement (MIE) ปิดกั้นกลยุทธ์ exploit ส่วนใหญ่ที่ผู้โจมตีจะใช้ได้ในระดับพื้นฐาน บั๊ก memory corruption เดิมทีสามารถสลับทดแทนกันได้ แต่ MIE ปิดเส้นทาง exploit ไปมากเกินไปตั้งแต่ขั้นพื้นฐาน จนแม้จะเปลี่ยนไปใช้บั๊กใหม่ก็ไม่สามารถกู้ chain กลับมาได้ ต่อให้พยายามแค่ไหนก็ประกอบ chain เพื่อ bypass ขึ้นมาใหม่ไม่ได้ ผลกระทบที่ยังเหลืออยู่ไม่กี่อย่างก็ไม่น่าเชื่อถือเกินกว่าที่ผู้โจมตีจะนำไปใช้ได้สำเร็จ นี่เป็นข่าวที่ดีมาก และเป็นจุดสำคัญที่อาจมองข้ามได้ง่าย โครงสร้างเศรษฐกิจของสปายแวร์รับจ้างบางส่วนพึ่งพา chain ที่สลับทดแทนกันได้ ดังนั้นมาตรการป้องกันที่เล็งตรงไปยังคุณสมบัตินี้จึงน่าสนใจเป็นพิเศษ
    • ชวนสงสัยว่ายุทธศาสตร์ของ Apple เป็นก้าวสู่ memory safety แบบ capability-based อย่างเต็มรูปแบบเช่น CHERI (ดู: Capability Hardware Enhanced RISC Instructions) หรือควรมองว่าเป็นสัญญาณว่า Apple เห็นว่ามากพอแล้วแม้ไม่มีระบบแบบนั้น
    • อยากแนะนำแนวทางด้าน memory safety ของ Google ที่สอดคล้องกับกรณีของ Apple ด้วย Google เอาจริงกับ memory safety มาตั้งแต่ยุคแรกของ Chrome/Android และยังเป็นผู้นำในการนำ ASAN, syzkaller และ Hardware MTE มาใช้ ผมเคยเป็นผู้รับผิดชอบนำทีมลักษณะนี้ จึงได้สัมผัสข้อดีข้อเสียหลายอย่างโดยตรง สิ่งที่ Google พยายามทำคือทำให้การตรวจสอบระดับ ASAN สามารถเปิดปิดได้ตามความจำเป็น การเปิดไว้ตลอดในฐานะมาตรการความปลอดภัยมีปัญหาหลายอย่างนอกจาก overhead ด้านหน่วยความจำ เช่น จะเกิด crash ที่ผู้ใช้มองเห็นได้จำนวนมากอย่างไม่สม่ำเสมอในทุกอุปกรณ์ และในมุมของนักพัฒนา ก็หลีกเลี่ยงไม่ได้ที่จะบ่นเพราะต้องทดสอบจริงจังเฉพาะบนอุปกรณ์ที่รองรับ MTE ซึ่งมีเพียงราวหนึ่งล้านเครื่อง MTE จับได้ทั้ง exploit ด้านความปลอดภัยและบั๊กที่ไม่เป็นอันตรายอีกจำนวนมาก แต่ในฐานะ runtime mitigation ยังไม่ชัดว่าเป็นตัวเลือกที่ดีที่สุดเสมอไป ผมคิดว่า Google Security, Project Zero และทีมอื่น ๆ ทุ่มเทอย่างมากกับการรับมือ CSVs แต่สำนักงานใหญ่ยังทำได้ไม่ดีนักในการทำ MTE ให้เป็นผลิตภัณฑ์ (ลิงก์)
    • อาจไม่ใช่ข่าวดีสำหรับ Vigilant Labs แต่ก็ไม่แน่ชัดว่าได้รับผลกระทบจริงมากแค่ไหน
  • ผมคิดว่าคำกล่าวของ Apple ที่ว่า "การป้องกัน memory safety ต้องทำงานแบบ synchronous ตลอดเวลา เปิดเป็นค่าเริ่มต้น และทำงานต่อเนื่องเสมอ" น่าจะมาจากประสบการณ์มากกว่าความเป็นพวกยึดหลักการ สิ่งนี้ต่างจากการป้องกันเคอร์เนลในยุคแรก Kernel Patch Protection (KPP) ที่นำมาใช้ใน iOS 9 ปี 2015 ใช้วิธีตรวจแบบ asynchronous ทุก ๆ สองสามนาทีตอนอุปกรณ์ว่าง ว่าเคอร์เนลถูกแก้ไขหรือไม่ วิธีนี้ไม่น่าเชื่อถือในเชิงความปลอดภัยมากนัก และมีข้อบกพร่องด้านการออกแบบจนมีการเผยแพร่การแฮ็กที่ bypass ได้ทั้งหมด KPP ไม่ได้ป้องกันการ patch เคอร์เนลตั้งแต่ต้น แต่เพียงทำให้เกิด panic เมื่อถูกตรวจพบ กล่าวคือ ถ้าผู้โจมตีทำงานให้เสร็จและย้อนคืนได้เร็วพอ KPP ก็ตรวจไม่พบ (ดู writeup)
    • จากข้อมูลวงใน KPP ถูกทำขึ้นอย่างเร่งด่วนในช่วงที่ A11 มี KTRR เข้ามา เพื่อจงใจทำให้ระดับความปลอดภัยบน SoC ก่อน A11 ใกล้เคียงกัน มันถูกทำออกมาอย่างดีที่สุดเท่าที่จะทำได้ภายใต้กรอบเวลาระยะสั้นแบบนั้น และหลังจากนั้นก็ไม่ได้ทำซ้ำแนวทางนี้อีก
    • ดูเหมือนว่าไม่ได้เตรียมไว้ตามหลักการมาตั้งแต่ต้น แต่เป็นข้อสรุปที่ไปถึงตั้งแต่การวางแผนครั้งแรกเพื่อเอา MTE มาใช้ ระดับความปลอดภัยของ Apple ดีขึ้นอย่างต่อเนื่อง และเบื้องหลังส่วนใหญ่ก็มาจากบทเรียนที่ถูกบังคับให้เรียนรู้จากเรื่องอย่าง jailbreak
    • เห็นด้วยว่าระบบแบบนี้ทำให้สมบูรณ์แบบตั้งแต่แรกได้ยาก
  • Apple บอกว่า “ไม่มีการโจมตีด้วยมัลแวร์ที่สำเร็จและแพร่หลายต่อ iPhone” แต่ผมคิดว่าโค้ดสปายแวร์ที่มีอยู่เดิมถ้าแก้เพียงเล็กน้อยก็เอาไปใช้โจมตีในวงกว้างได้ทันที ความแตกต่างนี้ในความเป็นจริงไม่ได้ชัดเจนขนาดนั้น
    • ความจริงคือทั้ง Apple และ Google ต่างก็ไม่สามารถรู้ขนาดของการโจมตีจริงได้ครบถ้วน ตามเอกสารรั่วที่ GrapheneOS เปิดเผย นักพัฒนา exploit รับมือการโจมตีอุปกรณ์และการอัปเดตได้เก่งกว่าที่คนทั่วไปคิด ยังมีข้อมูลเพิ่มเติมที่ไม่เปิดเผย และจะมีการแชร์เพียงบางส่วนเพื่อหลีกเลี่ยงการเปิดเผยช่องทางการรั่วไหล เว้นแต่จะได้รับการยืนยันจากหลายแหล่งอิสระ เครื่องมือ exploit เหล่านี้ถูกใช้งานอย่างกว้างขวาง และยังแยกได้ยากด้วยซ้ำว่าเป็นการดึงข้อมูลตามปกติหรือเป็นการโจมตีระยะไกล ในโลกจริง exploit มักถูกตรวจพบได้น้อยมาก และส่วนใหญ่สามารถใช้ในวงกว้างได้โดยไม่ถูกตรวจจับ ทำให้แม้แต่ chain เดียวก็มีมูลค่าในระยะยาว หน่วยงานบังคับใช้กฎหมายทั่วโลกกำลังใช้เครื่องมืออย่าง Cellebrite Premium กับผู้คนจำนวนมากตามชายแดน พื้นที่ชุมนุมประท้วง ฯลฯ ซึ่งนับเป็นการใช้งานในวงกว้างอยู่แล้ว สำหรับ remote exploit ต่อให้ใช้อย่างกว้างขวางก็ไม่จำเป็นต้องกระจายตัวมันอย่างกว้างขวางด้วยซ้ำ
    • XcodeGhost เป็นตัวอย่างสำคัญของการโจมตีมัลแวร์ต่อ iPhone ในวงกว้าง ตอนนั้น WeChat และแอปอื่น ๆ ติดเชื้อ ดูข้อมูลอ้างอิง: วิกิพีเดีย XcodeGhost
    • จะใช้ในการโจมตีวงกว้างจริงได้หรือไม่ยังไม่แน่ชัด แต่ถ้ามีระดับการเปิดรับแบบ Windows ก็น่าจะมีกรณีแบบนี้มากกว่านี้
    • ข้อความนั้นอาจมีเจตนาหลักเพื่อเน้นข้อดีของโมเดลการควบคุมของตนเมื่อเทียบกับ Android
    • แม้จะเป็นถ้อยคำแบบนักกฎหมาย แต่การที่ Apple เผยแพร่ข้อมูลอย่างละเอียดและสื่อสารอย่างมั่นใจเกี่ยวกับเทคโนโลยีใหม่อย่าง MIE ครั้งนี้ ก็เป็นเรื่องดีสำหรับพวกเราทุกคน
  • ระบบครั้งนี้น่าประทับใจอย่างชัดเจน อย่างไรก็ตาม หากผู้โจมตีสามารถลองใหม่ได้หลายครั้ง การป้องกันอาจยังไม่เพียงพอ เช่น หากสามารถเข้าถึงเลยขอบเขตไปถึง object ที่ไม่ติดกัน หรือบังเอิญ tag ตรงกันหลังจากจัดการการจัดสรรหน่วยความจำจำนวนมาก ก็อาจ bypass ได้ ความน่าจะเป็นที่ tag จะตรงกันคือ 1/16 แต่ในบทความไม่ได้อธิบายรายละเอียดมากพอ จึงไม่แน่ใจว่าที่คาดไว้ถูกหรือไม่ หากนำไปใช้ได้สำเร็จ exploit ที่เหลือก็จะต้องพึ่งพา logic bug ทำให้ยากขึ้นมากสำหรับผู้โจมตี
    • ใน Android MTE ก็คล้ายกัน คือมีการโจมตีเชิงความน่าจะเป็นที่อาศัยปัญหาขนาด tag ที่เล็กโดยลองซ้ำหลายครั้งได้ แต่ความต่างสำคัญตรงนี้คือ enforcement แบบ synchronous ที่สม่ำเสมอ นั่นคือมี trap ทันทีทุกครั้งที่มีการเขียนหน่วยความจำผิดปกติ ไม่ใช่รอถึงตอน context switch
    • นอกเหนือจากโอกาส 1/16 แล้ว อีก 15/16 ของความพยายามทั้งหมดจะทำให้เกิด crash บั๊กที่ไม่เสถียรแบบนี้จึงเปิดเผยต่อผู้ใช้หรือระบบวินิจฉัยได้ง่าย และถ้าต้องเชื่อมหลายขั้นตอนให้สำเร็จต่อเนื่องกัน ในทางสถิติแล้วแทบเป็นไปไม่ได้ที่จะนำไปใช้โจมตีจริง
    • การโจมตีระดับรัฐชาติที่ค่อย ๆ แทรกซึมเป็นเวลานาน เช่น supply chain attack อาจไม่อยู่ในขอบเขตที่มาตรการป้องกันนี้ช่วยได้
  • โมเดลของ Apple/ARM น่าจะซับซ้อนกว่ามาก แต่ก็ทำให้นึกถึงสถาปัตยกรรม memory tagging ของ Burroughs large system (อ้างอิง)
  • จากคำอธิบายที่ว่า “ผู้โจมตีต้องไม่สามารถคาดเดาค่า tag ที่ระบบเลือกได้ เพื่อให้เป็นเช่นนั้นจึงมีการ reseed PRNG บ่อย ๆ เพื่อสร้าง tag ใหม่” ปัญหารากฐานคือ entropy ของ tag ต่ำมาก มีเพียง 4 บิตเท่านั้น หากผู้โจมตีเดาสุ่ม โอกาสสำเร็จก็ยังเป็น 1/16 และการ reseed PRNG ไม่ได้เปลี่ยนความน่าจะเป็นนี้ ดูเหมือนว่าต้องมีคำอธิบายเพิ่มเติม
    • ผู้โจมตีมีโอกาสเดาได้เพียงครั้งเดียว ถ้าเดาผิด process จะถูกยุติหรือเคอร์เนลจะ panic ครั้งถัดไปที่ลองก็ต้องเดาใหม่ด้วย tag ใหม่ จึงไม่สามารถลองต่อเนื่องได้
    • 4 บิตมีจำนวนกรณีที่เป็นไปได้น้อยเกินไป การจัดสรรหน่วยความจำเกิดขึ้นระดับหลายล้านครั้งต่อวินาที ต่อให้ reseed บ่อย ความเป็นไปได้ของการชนกันก็เพิ่มขึ้นเร็วมาก
  • จุดแข็งที่สุดของอุปกรณ์ซีรีส์นี้คือฟีเจอร์ใหม่นี้เอง
  • หากนโยบายอย่าง chat control ของ EU ถูกบังคับใช้ รัฐก็อาจเข้าถึงทุกอย่างที่ต้องการบนอุปกรณ์ของฉันได้ และถ้า Google บังคับใช้ WEI เว็บทั้งเว็บก็อาจถูกปิดกั้น เมื่อมี secure boot และ MIE แล้ว ผู้ใช้อาจกู้เสรีภาพเดิมกลับมาได้ยากขึ้น
    • กล่าวคือ หากจะรักษาเสรีภาพเหล่านี้ไว้ ก็คงต้องแยกระบบกับบริการออกจากกันให้มากขึ้น
    • อยากรู้ว่าการเสริม MIE ตรงนี้รวมถึงความไม่พอใจที่ว่ามันจำกัดเสรีภาพของผู้ใช้ เช่น การ jailbreak ด้วยหรือไม่
    • สงสัยว่า WEI คืออะไร
  • การที่ Google ให้ MTE แบบ opt-in เมื่อปีที่แล้วเป็นก้าวแรกที่ดี แต่ยังขาดการบูรณาการแบบเต็มรูปแบบ จึงต่างจาก MIE บนฐาน EMTE ที่ Apple เน้นย้ำ น่าประทับใจที่การเปิดตัว iPhone 17 และ Air ของ Apple นำระบบ memory safety แบบครบวงจรและเปิดตลอดเวลาเป็นรายแรกของอุตสาหกรรมมาใช้ แม้น่าเสียดายที่ความพยายามบุกเบิกของ GrapheneOS (ตัวอย่างรีลีส, การสร้างการรับรู้) ไม่ได้รับการยกย่องอย่างเหมาะสม แต่ก็หวังว่าความจริงจังของ Apple จะขยายไปสู่ Google, Pixel OS และระบบปฏิบัติการด้านความปลอดภัยอื่น ๆ อย่างรวดเร็ว และยืนยันอีกครั้งว่า GrapheneOS เป็นผู้นำด้านระบบที่ป้องกันได้แม้กระทั่งภัยคุกคามที่ยังไม่เป็นที่รู้จัก
    • Apple เตรียมตัวในด้านนี้มานานแล้ว ไม่ได้เพิ่งเริ่มตั้งแต่ตอนที่ GrapheneOS เปิดใช้ฟีเจอร์นี้
  • มีข้อความว่า “Apple เป็นรายแรกของอุตสาหกรรมที่นำ Pointer Authentication Codes (PAC) มาใช้ในชิป A12 Bionic ปี 2018 เพื่อปกป้อง code flow integrity” แต่หลังจากนำ PAC มาใช้แล้วก็ยังมีกรณีการโจมตีแบบ full chain หลายครั้ง PAC ไม่ใช่มาตรการยับยั้งการโจมตีที่มีนัยสำคัญ ผู้โจมตียังคงหาวิธี bypass PAC ได้เรื่อย ๆ จุดนี้ต้องนำมาพิจารณาเวลาประเมินประสิทธิผลของ MIE
    • จริง ๆ แล้ว Apple ไม่ได้บอกว่า PAC เป็นมาตรการยับยั้งการโจมตี แต่บอกว่าความสำเร็จอยู่ที่ “เพิ่มความซับซ้อนของ exploit” ประโยคนี้อาจคลุมเครืออยู่บ้าง แต่เท่าที่ผมอ่าน มันดูเป็นการยอมรับว่า PAC อย่างเดียวไม่พอ และต้องใช้แนวทางผสมผสานทั้งซอฟต์แวร์และฮาร์ดแวร์ PAC เองก็เป็นฟีเจอร์ฮาร์ดแวร์ที่ต้องมีการเปลี่ยนแปลงฝั่งซอฟต์แวร์ แต่ EMTE เป็นเทคโนโลยีที่ต้องใช้พื้นที่และการประสานงานกว้างกว่ามาก
    • ไม่ใช่ว่า PAC ไร้ความหมาย แต่กลับกัน มันทำหน้าที่เป็นตัวเร่งให้ผู้โจมตีจำเป็นต้องหาวิธี bypass PAC ให้ได้ และวิธี bypass PAC ก็ไม่ได้มีอยู่ไม่จำกัด
    • การที่ PAC ถูก bypass มาแล้วหลายครั้ง ไม่ได้หมายความว่ามันใช้ไม่ได้ผล ตรงกันข้าม มันกำลังทำงานได้อย่างมีประสิทธิภาพ