Arm v9 ขอแนะนำ Arm Memory Tagging Extension (MTE) ซึ่งเป็นการใช้งานหน่วยความจำที่มีการติดแท็กในฮาร์ดแวร์
ในระดับสูง MTE จะติดแท็กการจัดสรร/การยกเลิกการจัดสรรหน่วยความจำแต่ละรายการด้วย ข้อมูลเมตาเพิ่มเติม MTE กำหนดแท็กให้กับตำแหน่งหน่วยความจำ ซึ่งจากนั้นจะเชื่อมโยงกับพอยน์เตอร์ที่อ้างอิงตำแหน่งหน่วยความจำนั้นได้ ในเวลาที่รัน CPU จะตรวจสอบว่าพอยน์เตอร์และแท็กข้อมูลเมตาตรงกันในการโหลดและจัดเก็บแต่ละครั้ง
ใน Android 12 ตัวจัดสรรหน่วยความจำฮีปของเคอร์เนลและพื้นที่ผู้ใช้สามารถเพิ่ม ข้อมูลเมตาในการจัดสรรแต่ละรายการได้ ซึ่งจะช่วยตรวจหาข้อบกพร่องในการใช้หน่วยความจำหลังจากที่ยกเลิกการจัดสรรไปแล้วและ ข้อบกพร่องของบัฟเฟอร์ล้น ซึ่งเป็นแหล่งที่มาที่พบบ่อยที่สุดของข้อบกพร่องด้านความปลอดภัยของหน่วยความจำใน ฐานของโค้ด
โหมดการทำงานของ MTE
MTE มีโหมดการทำงาน 3 โหมด ได้แก่
- โหมดซิงโครนัส (SYNC)
- โหมดอะซิงโครนัส (ASYNC)
- โหมดไม่สมมาตร (ASYMM)
โหมดซิงโครนัส (SYNC)
โหมดนี้ได้รับการปรับให้เหมาะกับความถูกต้องของการตรวจหาข้อบกพร่องมากกว่าประสิทธิภาพ และ
ใช้เป็นเครื่องมือตรวจหาข้อบกพร่องที่แม่นยำได้เมื่อยอมรับโอเวอร์เฮดประสิทธิภาพที่
สูงขึ้นได้ เมื่อเปิดใช้ MTE SYNC จะทำหน้าที่เป็นการลดความเสี่ยงด้านความปลอดภัย
หากแท็กไม่ตรงกัน โปรเซสเซอร์จะยกเลิกการดำเนินการทันทีและ
สิ้นสุดกระบวนการด้วย SIGSEGV (โค้ด
SEGV_MTESERR) พร้อมข้อมูลทั้งหมดเกี่ยวกับการเข้าถึงหน่วยความจำและที่อยู่ที่มี
ข้อผิดพลาด
เราขอแนะนำให้ใช้โหมดนี้ระหว่างการทดสอบเพื่อเป็นทางเลือกแทน HWASan/KASAN หรือในเวอร์ชันที่ใช้งานจริงเมื่อกระบวนการเป้าหมายแสดงถึงการโจมตีที่อาจเกิดขึ้นได้ นอกจากนี้ เมื่อโหมด ASYNC ระบุว่ามีข้อบกพร่อง คุณจะได้รับรายงานข้อบกพร่องที่ถูกต้องโดยใช้ API ของรันไทม์เพื่อเปลี่ยนการดำเนินการเป็นโหมด SYNC
เมื่อทำงานในโหมด SYNC ตัวจัดสรรของ Android จะบันทึกสแต็กเทรซสำหรับการจัดสรรและการยกเลิกการจัดสรรทั้งหมด และใช้สแต็กเทรซเหล่านั้นเพื่อจัดทำรายงานข้อผิดพลาดที่ดีขึ้น ซึ่งรวมถึงคำอธิบายข้อผิดพลาดของหน่วยความจำ เช่น การใช้หน่วยความจำหลังจากที่ยกเลิกการจัดสรรไปแล้วหรือบัฟเฟอร์ล้น และสแต็กเทรซของเหตุการณ์หน่วยความจำที่เกี่ยวข้อง รายงานดังกล่าวให้ข้อมูลตามบริบทมากขึ้นและ ทำให้ติดตามและแก้ไขข้อบกพร่องได้ง่ายขึ้น
โหมดอะซิงโครนัส (ASYNC)
โหมดนี้ได้รับการปรับให้เหมาะกับประสิทธิภาพมากกว่าความแม่นยำของรายงานข้อบกพร่อง และใช้เป็นการตรวจหาข้อบกพร่องด้านความปลอดภัยของหน่วยความจำที่มีโอเวอร์เฮดต่ำได้
หากแท็กไม่ตรงกัน โปรเซสเซอร์จะดำเนินการต่อไปจนกว่าจะถึงรายการเคอร์เนลที่ใกล้ที่สุด (เช่น Syscall หรือการขัดจังหวะของตัวจับเวลา) ซึ่งจะยุติ
กระบวนการด้วย SIGSEGV (โค้ด SEGV_MTEAERR) โดยไม่
บันทึกที่อยู่ที่มีข้อผิดพลาดหรือการเข้าถึงหน่วยความจำ
เราขอแนะนำให้ใช้โหมดนี้ในเวอร์ชันที่ใช้งานจริงกับฐานของโค้ดที่ผ่านการทดสอบมาอย่างดีซึ่งทราบว่ามีข้อบกพร่องด้านความปลอดภัยของหน่วยความจำต่ำ ซึ่งทำได้โดยใช้ โหมด SYNC ระหว่างการทดสอบ
โหมดไม่สมมาตร (ASYMM)
โหมด MTE ไม่สมมาตรซึ่งเป็นฟีเจอร์เพิ่มเติมใน Arm v8.7-A จะมีการตรวจสอบแบบซิงโครนัส ในการอ่านหน่วยความจำ และการตรวจสอบแบบอะซิงโครนัสในการเขียนหน่วยความจำ โดยมีประสิทธิภาพคล้ายกับโหมด ASYNC ในสถานการณ์ส่วนใหญ่ โหมดนี้ จะดีกว่าโหมด ASYNC และเราขอแนะนำให้ใช้โหมดนี้แทน ASYNC ทุกครั้งที่ทำได้
ด้วยเหตุนี้ API ที่อธิบายไว้ด้านล่างจึงไม่มีการกล่าวถึงโหมดไม่สมมาตร แต่คุณสามารถกำหนดค่าระบบปฏิบัติการให้ใช้โหมดไม่สมมาตรเสมอเมื่อ มีการขอใช้โหมดอะซิงโครนัส ดูข้อมูลเพิ่มเติมได้ที่ กำหนดค่า ระดับ MTE ที่ต้องการซึ่งเฉพาะเจาะจงกับ CPU
MTE ในพื้นที่ผู้ใช้
ส่วนต่อไปนี้จะอธิบายวิธีเปิดใช้ MTE สำหรับกระบวนการของระบบ และแอป MTE จะปิดใช้โดยค่าเริ่มต้น เว้นแต่จะมีการตั้งค่าตัวเลือกใดตัวเลือกหนึ่งด้านล่างสำหรับกระบวนการที่เฉพาะเจาะจง (ดูคอมโพเนนต์ที่เปิดใช้ MTE สำหรับด้านล่าง)
เปิดใช้ MTE โดยใช้ระบบบิลด์
MTE เป็นพร็อพเพอร์ตี้ระดับกระบวนการ จึงควบคุมโดยการตั้งค่าเวลาบิลด์ของ ไฟล์ปฏิบัติการหลัก ตัวเลือกต่อไปนี้ช่วยให้คุณเปลี่ยนการตั้งค่านี้สำหรับ ไฟล์ปฏิบัติการแต่ละรายการหรือสำหรับไดเรกทอรีย่อยทั้งหมดในแผนผังแหล่งที่มา ระบบจะละเว้นการตั้งค่าในไลบรารีหรือเป้าหมายใดก็ตามที่ไม่ใช่ไฟล์ปฏิบัติการหรือการ ทดสอบ
1. การเปิดใช้ MTE ใน Android.bp (ตัวอย่าง)
สำหรับโปรเจ็กต์ที่เฉพาะเจาะจง:
| โหมด MTE | การตั้งค่า |
|---|---|
| MTE แบบอะซิงโครนัส | sanitize: {
memtag_heap: true,
} |
| MTE แบบซิงโครนัส | sanitize: {
memtag_heap: true,
diag: {
memtag_heap: true,
},
} |
หรือใน Android.mk:
| โหมด MTE | การตั้งค่า |
|---|---|
Asynchronous MTE |
LOCAL_SANITIZE := memtag_heap |
Synchronous MTE |
LOCAL_SANITIZE := memtag_heapLOCAL_SANITIZE_DIAG := memtag_heap |
2. การเปิดใช้ MTE ในไดเรกทอรีย่อยในแผนผังแหล่งที่มาโดยใช้ตัวแปรผลิตภัณฑ์
| โหมด MTE | รายการการรวม | รายการการยกเว้น |
|---|---|---|
| ไม่พร้อมกัน | PRODUCT_MEMTAG_HEAP_ASYNC_INCLUDE_PATHS
MEMTAG_HEAP_ASYNC_INCLUDE_PATHS |
PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS
MEMTAG_HEAP_EXCLUDE_PATHS |
| ซิงค์ | PRODUCT_MEMTAG_HEAP_SYNC_INCLUDE_PATHS
MEMTAG_HEAP_SYNC_INCLUDE_PATHS |
หรือ
| โหมด MTE | การตั้งค่า |
|---|---|
| MTE แบบอะซิงโครนัส | MEMTAG_HEAP_ASYNC_INCLUDE_PATHS |
| MTE แบบซิงโครนัส | MEMTAG_HEAP_SYNC_INCLUDE_PATHS |
หรือโดยการระบุเส้นทางการยกเว้นของไฟล์ปฏิบัติการ
| โหมด MTE | การตั้งค่า |
|---|---|
| MTE แบบอะซิงโครนัส | PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS
MEMTAG_HEAP_EXCLUDE_PATHS |
| MTE แบบซิงโครนัส |
ตัวอย่าง (การใช้งานคล้ายกับ PRODUCT_CFI_INCLUDE_PATHS)
PRODUCT_MEMTAG_HEAP_SYNC_INCLUDE_PATHS=vendor/$(vendor)
PRODUCT_MEMTAG_HEAP_EXCLUDE_PATHS=vendor/$(vendor)/projectA \
vendor/$(vendor)/projectBเปิดใช้ MTE โดยใช้พร็อพเพอร์ตี้ของระบบ
คุณสามารถลบล้างการตั้งค่าบิลด์ข้างต้นได้ในเวลาที่รันโดยการตั้งค่าพร็อพเพอร์ตี้ของระบบต่อไปนี้
arm64.memtag.process.<basename> = (off|sync|async)
โดยที่ basename หมายถึงชื่อฐานของไฟล์ปฏิบัติการ
ตัวอย่างเช่น หากต้องการตั้งค่า /system/bin/ping หรือ /data/local/tmp/ping
ให้ใช้ MTE แบบอะซิงโครนัส ให้ใช้ adb shell setprop arm64.memtag.process.ping async
เปิดใช้ MTE โดยใช้ตัวแปรสภาพแวดล้อม
อีกวิธีหนึ่งในการลบล้างการตั้งค่าบิลด์สำหรับกระบวนการแบบเนทีฟ (ที่ไม่ใช่แอป)
คือการกำหนดตัวแปรสภาพแวดล้อม: MEMTAG_OPTIONS=(off|sync|async)
หากกำหนดทั้งตัวแปรสภาพแวดล้อมและพร็อพเพอร์ตี้ของระบบไว้ ตัวแปรจะมีลำดับความสำคัญสูงกว่า
เปิดใช้ MTE สำหรับแอป
หากไม่ได้ระบุไว้ MTE จะปิดใช้โดยค่าเริ่มต้น แต่
แอปที่ต้องการใช้ MTE สามารถทำได้โดยการตั้งค่า android:memtagMode
ภายใต้แท็ก <application> หรือ
<process> ใน
AndroidManifest.xml
android:memtagMode=(off|default|sync|async)
เมื่อตั้งค่าในแท็ก <application> แอตทริบิวต์จะมีผลกับกระบวนการทั้งหมดที่แอปใช้ และคุณสามารถลบล้างกระบวนการแต่ละรายการได้โดยการตั้งค่าแท็ก <process>
สำหรับการทดลอง คุณสามารถใช้การเปลี่ยนแปลงความเข้ากันได้
เพื่อตั้งค่าเริ่มต้นของ
แอตทริบิวต์memtagMode สำหรับแอปที่ไม่ได้
ระบุค่าใดๆ ในไฟล์ Manifest (หรือระบุ default)
การเปลี่ยนแปลงเหล่านี้จะอยู่ในส่วนระบบ > ขั้นสูง > ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์
> การเปลี่ยนแปลงความเข้ากันได้ของแอป ในเมนูการตั้งค่าส่วนกลาง การตั้งค่า
NATIVE_MEMTAG_ASYNC หรือ NATIVE_MEMTAG_SYNC จะเปิดใช้ MTE
สำหรับแอปที่เฉพาะเจาะจง หรือคุณจะตั้งค่านี้โดยใช้คำสั่ง am
ดังนี้ก็ได้
$ adb shell am compat enable NATIVE_MEMTAG_[A]SYNC my.app.name
สร้างอิมเมจระบบ MTE
เราขอแนะนำอย่างยิ่งให้เปิดใช้ MTE ในไบนารีแบบเนทีฟทั้งหมดระหว่างการพัฒนา และการเริ่มต้นระบบ ซึ่งจะช่วยตรวจหาข้อบกพร่องด้านความปลอดภัยของหน่วยความจำได้ตั้งแต่เนิ่นๆ และให้ความครอบคลุมของผู้ใช้ที่สมจริง หากเปิดใช้ในการบิลด์ทดสอบ
เราขอแนะนำอย่างยิ่งให้เปิดใช้ MTE ในโหมดซิงโครนัสในไบนารีแบบเนทีฟทั้งหมดระหว่างการพัฒนา
SANITIZE_TARGET=memtag_heap SANITIZE_TARGET_DIAG=memtag_heap m
เช่นเดียวกับตัวแปรอื่นๆ ในระบบบิลด์ SANITIZE_TARGET สามารถใช้เป็น
ตัวแปรสภาพแวดล้อมหรือการตั้งค่า make (เช่น ใน
ไฟล์ product.mk)
การดำเนินการนี้จะเปิดใช้ MTE สำหรับกระบวนการแบบเนทีฟทั้งหมด แต่ไม่ใช่สำหรับ
แอป (ซึ่งแยกออกมาจาก zygote64) ซึ่งคุณสามารถเปิดใช้ MTE ได้โดยทำตามวิธีการในหัวข้อเปิดใช้ MTE สำหรับแอป
กำหนดค่าระดับ MTE ที่ต้องการซึ่งเฉพาะเจาะจงกับ CPU
ใน CPU บางรุ่น ประสิทธิภาพของ MTE ในโหมด ASYMM หรือแม้แต่โหมด SYNC อาจคล้ายกับ โหมด ASYNC ดังนั้นจึงคุ้มค่าที่จะเปิดใช้ การตรวจสอบที่เข้มงวดมากขึ้นใน CPU เหล่านั้นเมื่อมีการขอใช้โหมดการตรวจสอบที่เข้มงวดน้อยกว่า เพื่อให้ได้รับประโยชน์จากการตรวจหาข้อผิดพลาดของการตรวจสอบที่เข้มงวดมากขึ้นโดยไม่มีข้อเสียด้านประสิทธิภาพ
โดยค่าเริ่มต้น กระบวนการที่กำหนดค่าให้ทำงานในโหมด ASYNC จะทำงานในโหมด ASYNC
ใน CPU ทั้งหมด หากต้องการกำหนดค่าเคอร์เนลให้เรียกใช้กระบวนการเหล่านี้ในโหมด SYNC ใน
CPU ที่เฉพาะเจาะจง คุณต้องเขียนค่า sync ลงใน
รายการsysfs /sys/devices/system/cpu/cpu<N>/mte_tcf_preferred ในเวลาบูต
ซึ่งทำได้ด้วยสคริปต์ init ตัวอย่างเช่น หากต้องการกำหนดค่า CPU 0-1
ให้เรียกใช้กระบวนการโหมด ASYNC ในโหมด SYNC และกำหนดค่า CPU 2-3 ให้ใช้โหมด ASYMM
คุณอาจเพิ่มข้อมูลต่อไปนี้ลงในอนุประโยค init ของสคริปต์ init ของผู้ให้บริการ
write /sys/devices/system/cpu/cpu0/mte_tcf_preferred sync write /sys/devices/system/cpu/cpu1/mte_tcf_preferred sync write /sys/devices/system/cpu/cpu2/mte_tcf_preferred asymm write /sys/devices/system/cpu/cpu3/mte_tcf_preferred asymm
Tombstone จากกระบวนการโหมด ASYNC ที่ทำงานในโหมด SYNC จะมี สแต็กเทรซที่แม่นยำของตำแหน่งที่เกิดข้อผิดพลาดของหน่วยความจำ แต่จะไม่มีสแต็กเทรซการจัดสรรหรือการยกเลิกการจัดสรร สแต็กเทรซเหล่านี้จะใช้ได้ก็ต่อเมื่อกำหนดค่ากระบวนการให้ทำงานในโหมด SYNC
int mallopt(M_THREAD_DISABLE_MEM_INIT, level)
โดยที่ level คือ 0 หรือ 1
ปิดใช้การเริ่มต้นหน่วยความจำใน malloc และหลีกเลี่ยงการเปลี่ยนแท็กหน่วยความจำ เว้นแต่จะจำเป็นเพื่อความถูกต้อง
int mallopt(M_MEMTAG_TUNING, level)
โดยที่ level คือ
M_MEMTAG_TUNING_BUFFER_OVERFLOWM_MEMTAG_TUNING_UAF
เลือกกลยุทธ์การจัดสรรแท็ก
- การตั้งค่าเริ่มต้นคือ
M_MEMTAG_TUNING_BUFFER_OVERFLOW M_MEMTAG_TUNING_BUFFER_OVERFLOWช่วยให้ตรวจหาข้อบกพร่องของบัฟเฟอร์ล้นและบัฟเฟอร์ขาดแบบเชิงกำหนดได้โดยการกำหนดค่าแท็กที่แตกต่างกันให้กับการจัดสรรที่อยู่ติดกัน โหมดนี้มีโอกาสตรวจหาข้อบกพร่องในการใช้หน่วยความจำหลังจากที่ยกเลิกการจัดสรรไปแล้วลดลงเล็กน้อย เนื่องจากมีค่าแท็กที่เป็นไปได้เพียงครึ่งเดียวสำหรับตำแหน่งหน่วยความจำแต่ละตำแหน่ง MTE ไม่สามารถตรวจหา บัฟเฟอร์ล้นภายในแกรนูลแท็กเดียวกัน (Chunk ที่จัดแนว 16 ไบต์) และอาจพลาดบัฟเฟอร์ล้นขนาดเล็ก แม้ในโหมดนี้ บัฟเฟอร์ล้นดังกล่าวไม่สามารถเป็นสาเหตุของหน่วยความจำ เสียหายได้ เนื่องจากระบบจะไม่ใช้หน่วยความจำภายในแกรนูลเดียวสำหรับการจัดสรรหลายรายการM_MEMTAG_TUNING_UAFจะเปิดใช้แท็กแบบสุ่มแยกกัน เพื่อให้มีโอกาสตรวจหาข้อบกพร่องทั้งเชิงพื้นที่ (บัฟเฟอร์ล้น) และ เชิงเวลา (การใช้หน่วยความจำหลังจากที่ยกเลิกการจัดสรรไปแล้ว) ได้อย่างสม่ำเสมอประมาณ 93%
นอกจาก API ที่อธิบายไว้ข้างต้นแล้ว ผู้ใช้ที่มีประสบการณ์อาจต้องการทราบข้อมูลต่อไปนี้
- การตั้งค่ารีจิสเตอร์ฮาร์ดแวร์
PSTATE.TCOสามารถระงับการตรวจสอบแท็กชั่วคราวได้ (ตัวอย่าง) เช่น เมื่อคัดลอกช่วงหน่วยความจำที่มีเนื้อหาแท็กที่ไม่รู้จัก หรือ แก้ไขปัญหาคอขวดด้านประสิทธิภาพในลูปที่ใช้งานบ่อย - เมื่อใช้
M_HEAP_TAGGING_LEVEL_SYNCตัวจัดการการขัดข้องของระบบ จะให้ข้อมูลเพิ่มเติม เช่น สแต็กเทรซการจัดสรรและการยกเลิกการจัดสรร ฟังก์ชันนี้ต้องมีสิทธิ์เข้าถึงบิตแท็กและเปิดใช้โดยการส่งแฟล็กSA_EXPOSE_TAGBITSเมื่อตั้งค่าตัวแฮนเดิลสัญญาณ เราขอแนะนำให้โปรแกรมใดก็ตามที่ตั้งค่าตัวจัดการสัญญาณของตัวเอง และมอบหมายการขัดข้องที่ไม่รู้จักให้กับตัวจัดการสัญญาณของระบบดำเนินการเช่นเดียวกัน
MTE ในเคอร์เนล
หากต้องการเปิดใช้ KASAN ที่เร่งความเร็วด้วย MTE สำหรับเคอร์เนล ให้กำหนดค่าเคอร์เนลด้วย
CONFIG_KASAN=y, CONFIG_KASAN_HW_TAGS=y การกำหนดค่าเหล่านี้
จะเปิดใช้โดยค่าเริ่มต้นในเคอร์เนล GKI โดยเริ่มจาก Android
12-5.10
คุณสามารถควบคุมการกำหนดค่านี้ในเวลาบูตได้โดยใช้อาร์กิวเมนต์บรรทัดคำสั่งต่อไปนี้
kasan=[on|off]- เปิดหรือปิดใช้ KASAN (ค่าเริ่มต้น:on)kasan.mode=[sync|async]- เลือกระหว่างโหมดซิงโครนัสและอะซิงโครนัส (ค่าเริ่มต้น:sync)kasan.stacktrace=[on|off]- เลือกว่าจะรวบรวม สแต็กเทรซหรือไม่ (ค่าเริ่มต้น:on)- การรวบรวมสแต็กเทรซต้องใช้
stack_depot_disable=offด้วย
- การรวบรวมสแต็กเทรซต้องใช้
kasan.fault=[report|panic]- เลือกว่าจะพิมพ์รายงานเท่านั้น หรือจะทำให้เคอร์เนลเกิด Panic ด้วย (ค่าเริ่มต้น:report) ไม่ว่าตัวเลือกนี้จะเป็นอย่างไร ระบบจะปิดใช้การตรวจสอบแท็กหลังจากรายงานข้อผิดพลาดครั้งแรก
การใช้งานที่แนะนำ
เราขอแนะนำอย่างยิ่งให้ใช้โหมด SYNC ระหว่างการเริ่มต้นระบบ การพัฒนา และ การทดสอบ คุณควรเปิดใช้ตัวเลือกนี้ทั่วโลกสำหรับกระบวนการทั้งหมดโดยใช้ ตัวแปรสภาพแวดล้อม หรือด้วย ระบบบิลด์ ในโหมดนี้ ระบบจะตรวจหาข้อบกพร่องได้ ตั้งแต่เนิ่นๆ ในกระบวนการพัฒนา ฐานของโค้ดจะเสถียรเร็วขึ้น และ หลีกเลี่ยงค่าใช้จ่ายในการตรวจหาข้อบกพร่องในภายหลังในเวอร์ชันที่ใช้งานจริงได้
เราขอแนะนำอย่างยิ่งให้ใช้โหมด ASYNC ในเวอร์ชันที่ใช้งานจริง โหมดนี้เป็นเครื่องมือที่มีโอเวอร์เฮดต่ำสำหรับการตรวจหาข้อบกพร่องด้านความปลอดภัยของหน่วยความจำในกระบวนการ รวมถึงการป้องกันเชิงลึกเพิ่มเติม เมื่อตรวจพบข้อบกพร่อง นักพัฒนาซอฟต์แวร์สามารถ ใช้ประโยชน์จาก API ของรันไทม์เพื่อเปลี่ยนเป็นโหมด SYNC และรับสแต็กเทรซที่ถูกต้อง จากชุดผู้ใช้ที่สุ่มเลือก
เราขอแนะนำอย่างยิ่งให้กำหนดค่าระดับ MTE ที่ต้องการซึ่งเฉพาะเจาะจงกับ CPU สำหรับ SoC โดยโหมด ASYMM มักมีลักษณะด้านประสิทธิภาพเหมือนกับโหมด ASYNC และเกือบจะดีกว่าโหมด ASYNC เสมอ คอร์ขนาดเล็กแบบเรียงลำดับมักแสดงประสิทธิภาพที่คล้ายกัน ในทั้ง 3 โหมด และกำหนดค่าให้ใช้โหมด SYNC เป็นค่าเริ่มต้นได้
นักพัฒนาซอฟต์แวร์ควรตรวจสอบการขัดข้องโดยดูที่
/data/tombstones,
logcat หรือโดยการตรวจสอบไปป์ไลน์ DropboxManager
ของผู้ให้บริการเพื่อดูข้อบกพร่องของผู้ใช้ปลายทาง ดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ไขข้อบกพร่องของโค้ดแบบเนทีฟของ Android ได้ที่
ข้อมูล นี่
คอมโพเนนต์แพลตฟอร์มที่เปิดใช้ MTE
ใน Android 12 คอมโพเนนต์ของระบบที่สำคัญต่อความปลอดภัยจำนวนมากใช้ MTE ASYNC เพื่อตรวจหาการขัดข้องของผู้ใช้ปลายทางและทำหน้าที่เป็นชั้นการป้องกันเชิงลึกเพิ่มเติม คอมโพเนนต์เหล่านี้ ได้แก่
- ดีมอนและยูทิลิตีเครือข่าย (ยกเว้น
netd) - Bluetooth, SecureElement, NFC HAL และแอปของระบบ
- ดีมอน
statsd system_serverzygote64(เพื่อให้แอปเลือกใช้ MTE ได้)
ระบบเลือกเป้าหมายเหล่านี้ตามเกณฑ์ต่อไปนี้
- กระบวนการที่มีสิทธิ์ (กำหนดเป็นกระบวนการที่มีสิทธิ์เข้าถึงสิ่งที่ ที่โดเมน SELinux ของ unprivileged_app ไม่มี)
- กระบวนการที่รับอินพุตที่ไม่น่าเชื่อถือ (กฎ 2 ข้อ)
- การชะลอประสิทธิภาพที่ยอมรับได้ (การชะลอไม่ทำให้เกิดเวลาในการตอบสนองที่ผู้ใช้มองเห็นได้ )
เราขอแนะนำให้ผู้ให้บริการเปิดใช้ MTE ในเวอร์ชันที่ใช้งานจริงสำหรับคอมโพเนนต์เพิ่มเติม โดยทำตามเกณฑ์ที่กล่าวถึงข้างต้น ระหว่างการพัฒนา เราขอแนะนำให้ทดสอบ คอมโพเนนต์เหล่านี้โดยใช้โหมด SYNC เพื่อตรวจหาข้อบกพร่องที่แก้ไขได้ง่าย และประเมินผลกระทบของ โหมด ASYNC ต่อประสิทธิภาพของคอมโพเนนต์
เราวางแผนที่จะขยายรายการคอมโพเนนต์ของระบบที่เปิดใช้ MTE โดยพิจารณาจากลักษณะด้านประสิทธิภาพของการออกแบบฮาร์ดแวร์ที่จะเปิดตัวในอนาคต