Android รองรับเครื่องมือหลายอย่างสำหรับการแก้ไขข้อบกพร่องของข้อผิดพลาดด้านหน่วยความจำ แต่ละวิธีก็มีข้อดีข้อเสียแตกต่างกันไป โปรดอ่านข้อมูลด้านล่างเพื่อตัดสินใจว่าวิธีใดเหมาะกับกรณีการใช้งานของคุณมากที่สุด เอกสารนี้จะให้ภาพรวมของเครื่องมือที่มีอยู่เพื่อให้คุณตัดสินใจได้ว่าจะตรวจสอบเครื่องมือใดเพิ่มเติม แต่เราตั้งใจที่จะให้ข้อมูลอย่างกระชับ ดังนั้นโปรดอ่านเอกสารเฉพาะของเครื่องมือเพื่อดูรายละเอียด
สรุป
- ใช้ภาษาที่ปลอดภัยต่อหน่วยความจำทุกครั้งที่ทำได้เพื่อป้องกันไม่ให้เกิดข้อผิดพลาดเกี่ยวกับหน่วยความจำ
- ใช้ PAC/BTI เสมอเพื่อลดการโจมตีแบบ ROP/JOP
- ใช้ GWP-ASan เสมอเพื่อตรวจหาข้อผิดพลาดด้านหน่วยความจําที่เกิดขึ้นไม่บ่อยใน การใช้งานจริง
- ใช้ HWASan เพื่อตรวจหาข้อผิดพลาดด้านหน่วยความจําในระหว่างการทดสอบ
- MTE พร้อมให้บริการเป็นตัวเลือกในอุปกรณ์บางรุ่น
- ใช้ ASan ระหว่างการทดสอบเป็นทางเลือกสุดท้ายเท่านั้น
ภาษาที่ปลอดภัยด้านหน่วยความจำ
ภาษาที่ปลอดภัยด้านหน่วยความจำเป็นวิธีเดียวที่จะหลีกเลี่ยงและลดข้อผิดพลาดเกี่ยวกับหน่วยความจำได้ทั้งหมด เครื่องมืออื่นๆ ในหน้านี้ช่วยให้โค้ดที่ไม่ปลอดภัยของหน่วยความจำมีความปลอดภัยและน่าเชื่อถือมากขึ้นได้ แต่การใช้ภาษาที่ปลอดภัยของหน่วยความจำจะช่วยขจัดปัญหาทั้งชุดได้
ภาษาที่รองรับอย่างเป็นทางการซึ่งมีความปลอดภัยด้านหน่วยความจำสำหรับ Android คือ Java และ Kotlin แอปพลิเคชัน Android ส่วนใหญ่พัฒนาได้ง่ายกว่าในภาษาใดภาษาหนึ่ง
อย่างไรก็ตาม มีนักพัฒนาแอปที่จัดส่งโค้ดที่เขียนด้วย Rust และหากคุณกำลังอ่านหน้านี้ คุณอาจมีเหตุผลที่ดีที่ต้องใช้โค้ดเนทีฟ (ความสามารถในการพกพา ประสิทธิภาพ หรือทั้ง 2 อย่าง) Rust เป็นตัวเลือกที่ดีที่สุดสำหรับโค้ดเนทีฟที่ปลอดภัยด้านหน่วยความจำ ใน Android ทีม NDK อาจไม่สามารถช่วยคุณแก้ปัญหาที่คุณพบหากคุณเลือกใช้เส้นทางดังกล่าว แต่เราสนใจที่จะรับฟังปัญหาเหล่านั้น
PAC/BTI
การตรวจสอบสิทธิ์พอยน์เตอร์และการระบุเป้าหมายของกิ่งก้าน หรือที่เรียกว่า PAC/BTI เป็นเครื่องมือลดความเสี่ยงที่เหมาะสำหรับการใช้งานจริง แม้ว่าจะเป็นเทคโนโลยีที่แยกกัน แต่จะควบคุมด้วยแฟล็กคอมไพเลอร์เดียวกัน จึง ใช้ร่วมกันเสมอ
ฟีเจอร์เหล่านี้เข้ากันได้แบบย้อนหลังกับอุปกรณ์ที่ไม่รองรับ
เนื่องจากคำสั่งใหม่ที่ใช้จะไม่มีผลในอุปกรณ์รุ่นก่อนหน้า นอกจากนี้ คุณยังต้องมีเคอร์เนลและระบบปฏิบัติการเวอร์ชันใหม่ด้วย
การค้นหา paca และ bti ใน /proc/cpuinfo จะแสดงให้เห็นว่าคุณมีฮาร์ดแวร์และเคอร์เนลที่ใหม่พอหรือไม่
Android 12 (API 31) มี
การรองรับในพื้นที่ผู้ใช้ที่จำเป็น
ข้อดี:
- เปิดใช้ได้ในทุกบิลด์โดยไม่ก่อให้เกิดปัญหาในอุปกรณ์หรือเคอร์เนลรุ่นเก่า (แต่โปรดตรวจสอบว่าคุณได้ทดสอบในอุปกรณ์/เคอร์เนล/การผสมผสานระบบปฏิบัติการที่รองรับฟีเจอร์นี้แล้ว)
ข้อเสีย:
- ใช้ได้กับแอป 64 บิตเท่านั้น
- ไม่ช่วยลดข้อผิดพลาดในอุปกรณ์ที่ไม่รองรับ
- ค่าใช้จ่ายขนาดโค้ด 1%
GWP-Asan
GWP-ASan ใช้เพื่อตรวจหาข้อผิดพลาดด้านหน่วยความจําใน ฟิลด์ได้ แต่มีอัตราการสุ่มตัวอย่างต่ำเกินไปที่จะเป็นการลดความเสี่ยงที่มีประสิทธิภาพ
ข้อดี:
- ไม่มีค่าใช้จ่ายเพิ่มเติมที่สำคัญของ CPU หรือหน่วยความจำ
- ติดตั้งใช้งานได้ง่าย: ไม่ต้องสร้างโค้ดเนทีฟใหม่
- ใช้ได้กับแอป 32 บิต
ข้อเสีย:
- อัตราการสุ่มตัวอย่างต่ำต้องใช้ผู้ใช้จำนวนมากเพื่อค้นหาข้อบกพร่องอย่างมีประสิทธิภาพ
- ตรวจหาเฉพาะข้อผิดพลาดของฮีป ไม่ใช่ข้อผิดพลาดของสแต็ก
HWASan
Hardware Address Sanitizer หรือที่เรียกว่า HWASan เป็นเครื่องมือที่ เหมาะที่สุดสำหรับการตรวจหาข้อผิดพลาดเกี่ยวกับหน่วยความจำระหว่างการทดสอบ โดยจะมีประโยชน์มากที่สุดเมื่อใช้ กับการทดสอบอัตโนมัติ โดยเฉพาะอย่างยิ่งหากคุณทำการทดสอบแบบฟัซ แต่ก็อาจใช้ได้ในโทรศัพท์ระดับไฮเอนด์ในการตั้งค่า แบบด็อกฟู้ดด้วย ทั้งนี้ขึ้นอยู่กับความต้องการด้านประสิทธิภาพของแอป
ข้อดี:
- ไม่มีผลบวกลวง
- ตรวจหาข้อผิดพลาดเพิ่มเติมที่ ASan ตรวจหาไม่ได้ (การใช้สแต็กหลังจากกลับ)
- มีอัตราผลลบลวงต่ำกว่า MTE (1 ใน 256 เทียบกับ 1 ใน 16)
- มีค่าใช้จ่ายด้านหน่วยความจำต่ำกว่า ASan ซึ่งเป็นทางเลือกที่ใกล้เคียงที่สุด
ข้อเสีย:
- ค่าใช้จ่ายที่สำคัญของ CPU (~100%), ขนาดโค้ด (~50%) และหน่วยความจำ (10% - 35%)
- จนกว่าจะถึง API 34 และ NDK r26 จะต้องแฟลชอิมเมจที่เข้ากันได้กับ HWASan
- ใช้ได้กับแอป 64 บิตเท่านั้น
MTE
Memory Tagging Extension หรือที่เรียกว่า MTE เป็นทางเลือกที่มีต้นทุนต่ำกว่า HWASan นอกจากความสามารถในการแก้ไขข้อบกพร่องและการทดสอบแล้ว ยังใช้เพื่อตรวจหาและลดการเสียหายของหน่วยความจำในเวอร์ชันที่ใช้งานจริงได้ด้วย หากคุณมีฮาร์ดแวร์สำหรับทดสอบบิลด์ MTE คุณควรเปิดใช้
ข้อดี:
- มีค่าใช้จ่ายต่ำพอที่จะยอมรับได้ในเวอร์ชันที่ใช้งานจริงสำหรับแอปจำนวนมาก
- ไม่มีผลบวกลวง
- ไม่ต้องสร้างโค้ดใหม่เพื่อตรวจหาข้อผิดพลาดของฮีป (แต่ต้องสร้างใหม่เพื่อตรวจหาข้อผิดพลาดของสแต็ก)
ข้อเสีย:
- ไม่มีอุปกรณ์ที่พร้อมจำหน่ายในเชิงพาณิชย์ซึ่งเปิดใช้ MTE โดยค่าเริ่มต้นในปี 2024 แต่เอกสารประกอบของ Arm อธิบายวิธีเปิดใช้ MTE สำหรับการทดสอบใน Pixel 8/Pixel 8 Pro
- อัตราผลลบลวง 1 ใน 16 เทียบกับ 1 ใน 256 ของ HWASan
- ใช้ได้กับแอป 64 บิตเท่านั้น
- ต้องสร้างไลบรารีแยกต่างหากเพื่อกำหนดเป้าหมายทั้งอุปกรณ์ที่เปิดใช้ MTE และอุปกรณ์ที่ไม่ได้เปิดใช้ MTE
ASan
Address Sanitizer หรือที่เรียกว่า ASan เป็นเครื่องมือที่เก่าแก่ที่สุดและพร้อมให้ใช้งานอย่างแพร่หลายที่สุดในบรรดาเครื่องมือที่มี ซึ่งมีประโยชน์ในการตรวจหาข้อผิดพลาดเกี่ยวกับหน่วยความจำ ระหว่างการทดสอบและแก้ไขข้อบกพร่องที่ส่งผลกระทบต่ออุปกรณ์รุ่นเก่าเท่านั้น ในกรณีที่ไม่มีเครื่องมืออื่นๆ ใช้ HWASan หากเป็นไปได้
ข้อดี:
- พร้อมให้บริการในวงกว้าง อาจใช้งานได้ในอุปกรณ์ที่เก่าถึง KitKat
- ไม่มีผลบวกลวงหรือผลลบลวงเมื่อใช้อย่างถูกต้อง
ข้อเสีย:
- สร้างและแพ็กเกจอย่างถูกต้องได้ยาก
- ค่าใช้จ่ายสูงสุดของตัวเลือกทั้งหมด: CPU ประมาณ 100%, ขนาดโค้ดประมาณ 50%, การใช้หน่วยความจำประมาณ 100%
- ไม่รองรับอีกต่อไป
- มีข้อบกพร่องที่ทราบแล้วว่าจะไม่แก้ไข