ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP

หน้านี้ได้รับการแปลโดย Cloud Translation API

กลับมาทำงานต่อเมื่อรีบูต
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

ใน Android 11 คุณจะอัปเดต OTA ได้โดยใช้กลไกการอัปเดต A/B หรือการอัปเดต A/B เสมือนจริงร่วมกับเมธอดของคลาส RecoverySystem หลังจากอุปกรณ์รีบูตเพื่อใช้การอัปเดต OTA แล้ว ฟีเจอร์กลับมาทำงานต่อเมื่อรีบูต (RoR) จะปลดล็อกพื้นที่เก็บข้อมูลที่มีการเข้ารหัสข้อมูลเข้าสู่ระบบ (CE) ของอุปกรณ์

แม้ว่าพาร์ทเนอร์จะจับคู่กระบวนการนี้กับฟีเจอร์ระบบ OTA ที่ใช้การอัปเดตเมื่อคาดว่าอุปกรณ์จะไม่ได้ใช้งานใน Android 11 ได้ แต่พาร์ทเนอร์ไม่จำเป็นต้องใช้ฟีเจอร์ระบบ OTA เพิ่มเติมใน Android 12 กระบวนการ RoR เพิ่มความปลอดภัยและความสะดวกให้กับผู้ใช้ เนื่องจากสามารถอัปเดตได้ในช่วงเวลาที่อุปกรณ์ไม่ได้ใช้งาน ขณะที่ฟังก์ชันการอัปเดตแบบไคลเอ็นต์หลายรายและแบบเซิร์ฟเวอร์ของ Android 12 ร่วมกันมอบความปลอดภัยระดับฮาร์ดแวร์ให้กับอุปกรณ์

แม้ว่าจะต้องให้สิทธิ์อุปกรณ์สำหรับandroid.hardware.reboot_escrowฟีเจอร์เพื่อรองรับ RoR ใน Android 11 แต่คุณไม่จำเป็นต้องดำเนินการนี้เพื่อเปิดใช้ RoR ที่อิงตามเซิร์ฟเวอร์ใน Android 12 ขึ้นไป เนื่องจากไม่ใช้ HAL

ฉากหลัง

ตั้งแต่ Android 7 เป็นต้นไป Android รองรับการบูตโดยตรง ซึ่งช่วยให้แอปในอุปกรณ์เริ่มทำงานได้ก่อนที่ผู้ใช้จะปลดล็อกพื้นที่เก็บข้อมูล CE การใช้การรองรับการบูตโดยตรงช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีขึ้นก่อนที่จะต้องป้อนปัจจัยความรู้ของหน้าจอล็อก (LSKF) หลังจากการบูต

RoR ช่วยให้สามารถปลดล็อกพื้นที่เก็บข้อมูล CE ของแอปทั้งหมดในอุปกรณ์ได้ ซึ่งรวมถึงแอปที่ไม่รองรับการบูตโดยตรง เมื่อเริ่มการรีบูตหลังจากการอัปเดต OTA ฟีเจอร์นี้ช่วยให้ผู้ใช้ได้รับการแจ้งเตือนจากแอปที่ติดตั้งไว้ทั้งหมดหลังจากรีบูต

รูปแบบภัยคุกคาม

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

กล่าวโดยละเอียดคือ ผู้โจมตีที่มีอุปกรณ์อยู่จริงต้องไม่อ่านพื้นที่เก็บข้อมูล CE และสามารถดำเนินการต่อไปนี้ได้

ความสามารถ

ใช้คีย์การรับรองของผู้ให้บริการหรือบริษัทใดก็ได้เพื่อลงนามในข้อความที่กำหนดเอง
อาจทําให้อุปกรณ์ได้รับการอัปเดต OTA
แก้ไขการทํางานของฮาร์ดแวร์ได้ (เช่น โปรเซสเซอร์แอปพลิเคชัน หรือหน่วยความจําแฟลช) ยกเว้นตามที่ระบุไว้ในข้อจํากัดด้านล่าง (อย่างไรก็ตาม การแก้ไขดังกล่าวจะมีความล่าช้าอย่างน้อย 1 ชั่วโมงและต้องมีการปิด/เปิดเครื่องซึ่งจะทำลายเนื้อหาใน RAM)

ข้อจำกัด

แก้ไขการทํางานของฮาร์ดแวร์ที่ป้องกันการงัดแงะไม่ได้ (เช่น ชิป Titan M)
อ่าน RAM ของอุปกรณ์ที่ใช้งานอยู่ไม่ได้
ไม่สามารถคาดเดาข้อมูลเข้าสู่ระบบของผู้ใช้ (PIN, รูปแบบ, รหัสผ่าน) หรือทำให้ผู้ใช้ป้อนข้อมูลเข้าสู่ระบบ

โซลูชัน

ระบบการอัปเดต RoR ของ Android 12 มอบความปลอดภัยจากผู้โจมตีที่มีความซับซ้อนสูง และดำเนินการในขณะที่รหัสผ่านและ PIN ในอุปกรณ์ยังคงอยู่ในอุปกรณ์ โดยไม่มีการส่งหรือจัดเก็บข้อมูลดังกล่าวไว้ในเซิร์ฟเวอร์ของ Google ต่อไปนี้เป็นภาพรวมของกระบวนการที่ช่วยให้มั่นใจว่าระดับการรักษาความปลอดภัยที่ระบุจะคล้ายกับระบบ RoR ระดับอุปกรณ์ที่อิงตามฮาร์ดแวร์

Android ใช้การป้องกันด้วยวิทยาการเข้ารหัสกับข้อมูลที่จัดเก็บไว้ในอุปกรณ์
ข้อมูลทั้งหมดได้รับการปกป้องโดยคีย์ที่จัดเก็บไว้ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE)
TEE จะปล่อยคีย์ก็ต่อเมื่อระบบปฏิบัติการที่ทำงานอยู่ผ่านการตรวจสอบสิทธิ์การเข้ารหัส (การบูตที่ได้รับการยืนยัน)
บริการ RoR ที่ทำงานบนเซิร์ฟเวอร์ของ Google จะรักษาความปลอดภัยให้กับข้อมูล CE โดยการกําหนดค่าลับไว้ซึ่งสามารถเรียกดูได้เป็นระยะเวลาจํากัดเท่านั้น ซึ่งใช้ได้กับระบบนิเวศของ Android
ระบบจะใช้คีย์การเข้ารหัสที่ได้รับการปกป้องโดย PIN ของผู้ใช้เพื่อปลดล็อกอุปกรณ์และถอดรหัสพื้นที่เก็บข้อมูล CE
- เมื่อตั้งเวลารีบูตข้ามคืนไว้ Android จะแจ้งให้ผู้ใช้ป้อน PIN จากนั้นจะคำนวณรหัสผ่านสังเคราะห์ (SP)
- จากนั้นจะเข้ารหัส SP 2 ครั้ง โดยการเข้ารหัสครั้งแรกจะใช้คีย์ K_s ที่เก็บไว้ใน RAM และการเข้ารหัสครั้งที่ 2 จะใช้คีย์ K_k ที่เก็บไว้ใน TEE
- ระบบจะจัดเก็บ SP ที่เข้ารหัส 2 ชั้นไว้ในดิสก์ และลบ SP ออกจาก RAM คีย์ทั้ง 2 รายการจะสร้างขึ้นใหม่และนำไปใช้รีบูตเพียงครั้งเดียวเท่านั้น
เมื่อถึงเวลารีบูต Android จะมอบหมาย K_s ให้กับเซิร์ฟเวอร์ ระบบจะเข้ารหัสใบเสร็จที่มี K_k ก่อนที่จะจัดเก็บไว้ในดิสก์
หลังจากรีบูต Android จะใช้ K_k เพื่อถอดรหัสใบเสร็จ จากนั้นส่งใบเสร็จไปยังเซิร์ฟเวอร์เพื่อเรียกข้อมูล K_s
- K_k และ K_s ใช้เพื่อถอดรหัส SP ที่เก็บไว้ในดิสก์
- Android ใช้ SP เพื่อปลดล็อกพื้นที่เก็บข้อมูล CE และอนุญาตให้แอปเริ่มต้นทำงานตามปกติ
- K_k และ K_s ถูกทิ้ง

การอัปเดตที่รักษาความปลอดภัยให้โทรศัพท์อาจเกิดขึ้นในเวลาที่คุณสะดวก เช่น ขณะนอนหลับ

สำคัญ: ฟังก์ชัน RoR ที่ใช้เซิร์ฟเวอร์จะทํางานโดยที่เซิร์ฟเวอร์จะไม่ล่วงรู้ PIN ของผู้ใช้เลย โดยคีย์ K_s จะเป็นความลับเพียงอย่างเดียวที่ไว้วางใจให้เซิร์ฟเวอร์ และระบบจะสร้างคีย์นี้แบบสุ่มทุกครั้ง รหัสผ่านและ PIN ในอุปกรณ์จะอยู่ในอุปกรณ์เท่านั้น โดยระบบจะไม่ส่งรหัสผ่านและ PIN ไปยังเซิร์ฟเวอร์และจะไม่จัดเก็บรหัสผ่านและ PIN ไว้ในเซิร์ฟเวอร์

การเล่น PIN ของซิมซ้ำ

ในบางกรณี ระบบจะยืนยันรหัส PIN ของซิมการ์ดจากแคช ซึ่งเป็นกระบวนการที่เรียกว่าการเล่นซ้ำ PIN ของซิม

ซิมการ์ดที่เปิดใช้ PIN จะต้องผ่านการตรวจสอบรหัส PIN อย่างราบรื่น (การเล่นซ้ำ PIN ของซิม) หลังจากการรีบูตแบบไม่มีผู้ดูแลเพื่อกู้คืนการเชื่อมต่อมือถือ (จำเป็นสำหรับการโทร ข้อความ SMS และบริการข้อมูล) ระบบจะจัดเก็บ PIN ของซิมการ์ดและข้อมูลซิมการ์ดที่ตรงกัน (ICCID และหมายเลขช่อง SIM) ไว้ด้วยกันอย่างปลอดภัย คุณจะเรียกดูและใช้ PIN ที่เก็บไว้เพื่อยืนยันได้หลังจากที่รีบูตโดยอัตโนมัติสำเร็จเท่านั้น หากอุปกรณ์มีการรักษาความปลอดภัย PIN ของซิมจะจัดเก็บไว้พร้อมกับคีย์ที่ได้รับการปกป้องโดย LSKF หากซิมเปิดใช้ PIN การโต้ตอบกับเซิร์ฟเวอร์ RoR ต้องใช้การเชื่อมต่อ Wi-Fi สำหรับการอัปเดต OTA และ RoR บนเซิร์ฟเวอร์ ซึ่งจะช่วยให้มั่นใจได้ว่าฟังก์ชันพื้นฐาน (ที่มีการเชื่อมต่อเครือข่ายมือถือ) จะทำงานได้หลังจากรีบูต

ระบบจะเข้ารหัส PIN ของซิมอีกครั้งและจัดเก็บทุกครั้งที่ผู้ใช้เปิดใช้ ยืนยัน หรือแก้ไข PIN สำเร็จ ระบบจะทิ้ง PIN ของซิมหากเกิดเหตุการณ์อย่างใดอย่างหนึ่งต่อไปนี้

มีการนำซิมออกหรือรีเซ็ต
ผู้ใช้ปิดใช้ PIN
เกิดรีบูตที่ไม่ได้เริ่มโดย RoR

PIN ของซิมที่เก็บไว้จะใช้ได้ครั้งเดียวหลังจากการรีบูตที่ RoR เริ่มต้นขึ้น และใช้ได้เพียงระยะเวลาสั้นๆ (20 วินาที) เท่านั้นหากรายละเอียดของซิมการ์ดตรงกัน PIN ของ SIM ที่เก็บไว้จะไม่ออกจากแอป TelephonyManager และโมดูลภายนอกจะเรียกข้อมูล PIN ดังกล่าวไม่ได้

หลักเกณฑ์การใช้งาน

ใน Android 12 ฟังก์ชัน RoR แบบหลายไคลเอ็นต์และแบบเซิร์ฟเวอร์จะช่วยลดภาระให้กับพาร์ทเนอร์เมื่อมีการพุชการอัปเดต OTA การอัปเดตที่จำเป็นอาจเกิดขึ้นในช่วงที่อุปกรณ์หยุดทำงานชั่วคราวในช่วงเวลาที่สะดวก เช่น ในช่วงที่กําหนดไว้สำหรับการนอนหลับ

ใช้โหมดมืดเพื่อลดการปล่อยแสงเพื่อให้การอัปเดต OTA ในช่วงเวลาดังกล่าวไม่รบกวนผู้ใช้ โดยให้ Bootloader ของอุปกรณ์ค้นหาสตริงเหตุผล unattended หาก unattended เป็น true ให้ตั้งค่าอุปกรณ์เป็นโหมดมืด โปรดทราบว่า OEM แต่ละรายมีหน้าที่รับผิดชอบในการลดการปล่อยเสียงและแสง

หากอัปเกรดเป็น Android 12 หรือเปิดใช้อุปกรณ์ Android 12 คุณก็ไม่ต้องดำเนินการใดๆ เพื่อใช้ฟังก์ชัน RoR ใหม่

มีการเรียกใช้ใหม่ 1 รายการในขั้นตอนสำหรับลูกค้าหลายราย isPreparedForUnattendedUpdate ดังที่แสดงด้านล่าง

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

คุณไม่จำเป็นต้องใช้วิธีนี้เนื่องจาก HAL ถูกเลิกใช้งานแล้วใน Android 12

TelephonyManager

ไคลเอ็นต์ OTA จะเรียกใช้ TelephonyManager System API เมื่อใกล้ถึงเวลารีบูตใน Android 12 API นี้จะย้ายรหัส PIN ที่แคชไว้ทั้งหมดจากสถานะ AVAILABLE ไปยังสถานะ REBOOT_READY API ของระบบ TelephonyManager ได้รับการปกป้องโดยสิทธิ์ Manifest ของ REBOOT ที่มีอยู่

 /**
    * The unattended reboot was prepared successfully.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;

   /**
    * The unattended reboot was prepared, but the user will need to manually
    * enter the PIN code of at least one SIM card present in the device.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;

   /**
    * The unattended reboot was not prepared due to generic error.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;

   /** @hide */
   @Retention(RetentionPolicy.SOURCE)
   @IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
           value = {
                   PREPARE_UNATTENDED_REBOOT_SUCCESS,
                   PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
                   PREPARE_UNATTENDED_REBOOT_ERROR
           })
   public @interface PrepareUnattendedRebootResult {}

   /**
    * Prepare TelephonyManager for an unattended reboot. The reboot is
    * required to be done shortly after the API is invoked.
    *
    * Requires system privileges.
    *
    * <p>Requires Permission:
    *   {@link android.Manifest.permission#REBOOT}
    *
    * @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
    * {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
    * at least one SIM card for which the user needs to manually enter the PIN
    * code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
    * of error.
    * @hide
    */
   @SystemApi
   @RequiresPermission(android.Manifest.permission.REBOOT)
   @PrepareUnattendedRebootResult
   public int prepareForUnattendedReboot()

APK ที่มีสิทธิ์จะใช้ TelephonyManager System API

การทดสอบ

หากต้องการทดสอบ API ใหม่ ให้ใช้คําสั่งนี้

    adb shell cmd phone unattended-reboot

คำสั่งนี้จะใช้งานได้เมื่อเชลล์ทำงานเป็นรูท (adb root) เท่านั้น

Android 11 เท่านั้น

ส่วนที่เหลือของหน้านี้ใช้กับ Android 11

การติดตั้งใช้งาน RoR HAL แบ่งออกเป็น 2 หมวดหมู่ดังนี้

หากฮาร์ดแวร์ SoC รองรับการคงข้อมูลใน RAM ไว้ระหว่างการรีบูต OEM จะใช้การใช้งานเริ่มต้นใน AOSP (Default RAM Escrow) ได้
หากฮาร์ดแวร์หรือ SoC ของอุปกรณ์รองรับ Enclave ฮาร์ดแวร์ที่ปลอดภัย (ตัวประมวลผลร่วมด้านความปลอดภัยแบบแยกต่างหากที่มี RAM และ ROM ของตัวเอง) อุปกรณ์จะต้องดำเนินการต่อไปนี้ด้วย
- ตรวจจับการรีบูต CPU หลักได้
- มีแหล่งที่มาของตัวจับเวลาฮาร์ดแวร์ที่ยังคงอยู่หลังจากรีบูต กล่าวคือ Enclave ต้องตรวจพบการรีบูตและทำให้ตัวจับเวลาที่ตั้งไว้ก่อนการรีบูตหมดอายุ
- รองรับการจัดเก็บคีย์ที่ฝากไว้ใน Enclave RAM/ROM เพื่อไม่ให้กู้คืนได้จากการโจมตีแบบออฟไลน์ โดยต้องจัดเก็บคีย์ RoR ในลักษณะที่ทําให้ผู้ที่อยู่ภายในหรือผู้โจมตีไม่สามารถกู้คืนได้

วงเงินประกัน RAM เริ่มต้น

AOSP มีการใช้งาน RoR HAL โดยใช้การคงข้อมูลใน RAM OEM ต้องตรวจสอบว่า SoC รองรับการคงข้อมูลใน RAM ไว้เมื่อรีบูตเพื่อให้ฟีเจอร์นี้ทำงานได้ SoC บางรุ่นไม่สามารถเก็บเนื้อหา RAM ไว้ได้เมื่อรีบูต ดังนั้น OEM จึงควรปรึกษาพาร์ทเนอร์ SoC ก่อนเปิดใช้ HAL เริ่มต้นนี้ ข้อมูลอ้างอิงตามหลักเกณฑ์สําหรับเรื่องนี้ในส่วนต่อไปนี้

ขั้นตอนการอัปเดต OTA โดยใช้ RoR

แอปไคลเอ็นต์ OTA ในโทรศัพท์ต้องมีสิทธิ์ Manifest.permission.REBOOT และ Manifest.permission.RECOVERY เพื่อเรียกใช้เมธอดที่จำเป็นในการใช้งาน RoR เมื่อเตรียมข้อมูลเบื้องต้นแล้ว ขั้นตอนอัปเดตจะเป็นไปตามลำดับต่อไปนี้

แอปไคลเอ็นต์ OTA ดาวน์โหลดการอัปเดต
แอปไคลเอ็นต์ OTA จะเรียกใช้ RecoverySystem#prepareForUnattendedUpdate ซึ่งจะทริกเกอร์ให้ระบบแจ้ง PIN, รูปแบบ หรือรหัสผ่านให้ผู้ใช้ทราบบนหน้าจอล็อกเมื่อปลดล็อกครั้งถัดไป
ผู้ใช้ปลดล็อกอุปกรณ์ที่หน้าจอล็อก และอุปกรณ์ก็พร้อมที่จะใช้การอัปเดต
แอปไคลเอ็นต์ OTA โทรหา RecoverySystem#rebootAndApply ซึ่งจะทริกเกอร์การรีบูตทันที

เมื่อขั้นตอนนี้เสร็จสิ้น อุปกรณ์จะรีบูตและกลไก RoR จะปลดล็อกพื้นที่เก็บข้อมูลที่เข้ารหัสข้อมูลเข้าสู่ระบบ (CE) การดำเนินการนี้จะปรากฏในแอปเป็นการปลดล็อกของผู้ใช้ตามปกติ แอปจึงได้รับสัญญาณทั้งหมด เช่น ACTION_LOCKED_BOOT_COMPLETED และ ACTION_BOOT_COMPLETED ตามที่ควรจะเป็น

แก้ไขการกำหนดค่าผลิตภัณฑ์

ผลิตภัณฑ์ที่ทำเครื่องหมายว่ารองรับฟีเจอร์ RoR ใน Android 11 ต้องมีการใช้งาน RebootEscrow HAL และไฟล์ XML ของเครื่องหมายฟีเจอร์ การใช้งานเริ่มต้นจะทํางานได้ดีในอุปกรณ์ที่ใช้การรีบูตแบบอุ่น (เมื่อ DRAM เปิดอยู่ตลอดระหว่างการรีบูต)

รีบูตเครื่องหมายฟีเจอร์การระงับ

ต้องมีเครื่องหมายจุดสังเกตด้วย

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

การใช้งาน HAL ของรีบัวส์เริ่มต้น

หากต้องการใช้การติดตั้งใช้งานเริ่มต้น คุณต้องจอง 65536 (0x10000) ไบต์ อย่าเขียนไบต์เหล่านี้ลงในพื้นที่เก็บข้อมูลแบบไม่ผันแปรเพื่อให้แน่ใจว่าพร็อพเพอร์ตี้ความปลอดภัยจะยังคงอยู่

การเปลี่ยนแปลงแผนผังอุปกรณ์เคอร์เนล Linux

ใน Device Tree ของเคอร์เนล Linux คุณต้องจองหน่วยความจำสำหรับภูมิภาค pmem ตัวอย่างต่อไปนี้แสดงการจอง 0x50000000

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

ยืนยันว่าคุณมีอุปกรณ์ใหม่ในไดเรกทอรีบล็อกที่มีชื่อเหมือน /dev/block/pmem0 (เช่น pmem1 หรือ pmem2)

การเปลี่ยนแปลง Device.mk

สมมติว่าอุปกรณ์ใหม่จากขั้นตอนก่อนหน้ามีชื่อว่า pmem0 คุณต้องตรวจสอบว่าได้เพิ่มรายการใหม่ต่อไปนี้ลงใน vendor/<oem>/<product>/device.mk แล้ว

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default

กฎ SELinux

เพิ่มรายการใหม่เหล่านี้ลงใน file_contexts ของอุปกรณ์

/dev/block/pmem0  u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default  u:object_r:hal_rebootescrow_default_exec:s0