AVSS Report: iOS vs. Android vs. HarmonyOS Security Resistance Capability Initial Evaluation Report – Kernel Edition

Five smartphones from different brands and models are placed in front of us as consumers, but which one is better at protecting our privacy from being stolen? What about ten different smart cars? Which one is better at preventing malicious actors from obtaining our location or listening to our in-car conversations?

As ordinary consumers, we currently have no way of knowing. As technical experts who have been researching advanced persistent threats for a long time, we know that these smartphones and cars can ultimately be compromised when faced with advanced persistent attacks.

The goal of all security efforts is to increase the cost of attacks as much as possible: time, computing power, capabilities, etc. This is why we are promoting the Adversarial Vulnerability Scoring System (AVSS) evaluation framework. We hope to achieve scientific and fair quantification of security through AVSS, making security value measurable and perceptible, and encouraging companies that prioritize user protection to be recognized. Consumers should also have the right to make more secure choices more conveniently.

AVSS Report

This report is based on the AVSS concept and evaluates the security resistance of the following device systems from the perspective of advanced persistent adversarial attacks, focusing on five stages of mobile operating system kernel security resistance:

1. Locating attack entry points;

2. Constructing exploit primitives;

3. Bypassing kernel monitoring;

4. Spreading malicious behavior;

5. Complete system control.

The operating systems of the tested devices are all the latest versions as of May 2024. Among them, HarmonyOS NEXT Developer Preview 2 refers to Huawei’s self-developed kernel of the Harmony operating system, also known as HarmonyOS Star River Edition or Purebred Harmony. In the following text, it will be referred to as HarmonyOS NEXT.

AVSS Conclusion

  • HarmonyOS 4.2 has a slightly better overall security than native Android 14, ONE UI 6, and other operating system kernels, and its capabilities are close to or equivalent to iOS 17 in several dimensions.
  • HarmonyOS NEXT uses a new microkernel architecture, and its security has significantly improved in some dimensions, such as the impact of post-exploitation, but there is still room for improvement in traditional security.

The above quantitative indices are based on the evaluation of the following five major categories of kernel security defense capabilities (with over 50 sub-item defense dimensions and indicators):

  1. Kernel and user-mode attack surface defense capabilities
  2. Kernel memory corruption vulnerability defense capabilities
  3. Kernel arbitrary read and write exploitation defense capabilities
  4. Post-exploitation impact propagation defense capabilities
  5. In-depth defense capabilities

Stage One: Locating Attack Entry Points and Finding Vulnerabilities – Kernel and User-Mode Attack Surface Defense Capability Index

Attackers need to first determine the kernel resources they can access and find vulnerabilities in them. The fewer non-essential resources the kernel exposes, the fewer potential vulnerabilities there are.

Stage Two: “Doing Bad Things” with Vulnerabilities – Kernel Memory Corruption Vulnerability Defense Capability Index

The vulnerabilities found by attackers are usually coding flaws, and attackers need to construct them carefully to turn these coding flaws into harmful kernel sensitive data access. The kernel adds checks during design, implementation, and compilation to prevent code from behaving unexpectedly and turning into harmful operations.

Stage Three: Bypassing “Patrolling Guards” in the Kernel – Kernel Arbitrary Read and Write Exploitation Defense Capability Index

Some kernels set up special, real-time guards for some critical code and data – runtime integrity monitoring. Attackers need to bypass these guards or use other methods to complete the attack.

Stage Four: Spreading Malicious Behavior – Post-Exploitation Impact Propagation Defense Capability Index

Attackers have compromised a functional module by exploiting a kernel resource. The kernel separates and isolates different functional modules to prevent the module compromised by the attacker from affecting other functional modules that are still functioning normally.

Stage Five: Persistent Residence and Information Theft – In-depth Defense Capability Index

In some systems, the kernel is the bottom layer that manages user data. If the kernel is compromised, all user data can be controlled by the attacker. Some advanced operating systems still have multiple measures to protect important user sensitive data under the kernel.

AVSS Overview

Kernel and User-Mode Attack Surface Defense Capability Index

This index corresponds to the defense capability against locating attack entry points and finding vulnerabilities.

HarmonyOS 4.2 version’s kernel defense capability against user-mode attack surfaces is equivalent to native Android 14, One UI 6, and iOS 17 operating system kernels, with mature security defense mechanisms deployed.

HarmonyOS NEXT version’s defense against user-mode attack surfaces is better than other operating system kernels, as its microkernel architecture can significantly reduce the amount of code running at privileged levels, thus lowering the risk of vulnerabilities.

The primary threats to operating system kernels come from user-mode programs. For attackers, the degree of restriction on user-mode accessible kernel resources and the amount of code running at high privilege levels are important factors affecting the difficulty of attacks.

  • The kernel provides rich resource access interfaces to user-mode programs, such as system calls, drivers, procfs, sysfs, etc. All interfaces exposed to user-mode can become attack surfaces. The kernel can reduce the attack surface exposed to untrusted applications by controlling access to user-mode programs and isolating user-mode system programs from untrusted applications, thereby increasing the attacker’s cost and difficulty.
  • The number of high-privilege vulnerabilities is proportional to the amount of code running at high privilege levels. Choosing different kernel architectures results in different levels of kernel-mode code, leading to significant differences in the number of vulnerabilities in kernel-mode.

HarmonyOS 4.2 version uses relatively mature security defense mechanisms such as SElinux, Seccomp, Namespace, Capability (iOS 17 uses SandBox, entitlement to achieve similar effects), and HarmonyOS NEXT has designed an independent CAPABILITY SYSTEM mechanism to limit access to kernel functions and IPC permission verification.

HarmonyOS NEXT uses kernel objects as data carriers for IPC communication, and the CAPABILITY SYSTEM ensures that only those with the capability to read (or write) kernel objects can receive (or send) messages from kernel objects. Therefore, the message content cannot be accessed by malicious processes.

HarmonyOS NEXT adopts a microkernel architecture, effectively reducing the Trusted Code Base (TCB) of the kernel. Compared with traditional monolithic kernels, the kernel code volume is less than 1/4, effectively reducing the production of vulnerabilities. The following is a comparison of the TCB size of the evaluated operating system kernels:

Kernel Memory Corruption Vulnerability Defense Capability Index

This index corresponds to the defense capability against “doing bad things” with vulnerabilities.

Regarding memory corruption vulnerabilities, HarmonyOS 4.2 version’s kernel has better defense capabilities than conventional mobile kernels, with common kernel defense mechanisms enabled and PAC and CFI mechanisms for more comprehensive defense; HarmonyOS NEXT has not applied PAC and CFI defense mechanisms, making it difficult to prevent attackers from disrupting the execution logic of kernel code in this regard. It is recommended to refer to mature defense mechanisms to further enhance kernel security.

Currently, the primary method of kernel privilege escalation attacks is still to use memory corruption vulnerabilities for kernel data read/write and code execution to gain privileges. Therefore, the kernel’s defense capability against memory corruption vulnerabilities is an essential component of kernel security.

  • The occurrence of vulnerabilities is inevitable, but after long-term development, some types of vulnerabilities can be eliminated from the source by relying on compilers, heap managers, and various parameter settings. The use of these defense strategies can prevent attackers from discovering such vulnerabilities.
  • The degree of security defense mechanism activation is closely related to the difficulty of attacks by attackers. For example, the difficulty of attacking a target with the canary defense mechanism enabled is much greater than that of a target without the canary defense mechanism enabled for the same stack overflow vulnerability.
  • The reasons for vulnerabilities are diverse, but the methods of exploiting them are relatively traceable. Discovering and blocking such exploitation methods in time during the exploitation process will increase the attacker’s cost and difficulty.

HarmonyOS 4.2 version has enabled mature kernel defense mechanisms such as NX/DEP, PXN/PAN, Canary, and uses CFI to protect indirect jumps and PAC to protect non-leaf node return addresses, making the defense range more comprehensive compared to native Android 14 and One UI 6.

DARKNAVY found during testing that HarmonyOS NEXT has not used PAC and CFI defense mechanisms that have been deployed in HarmonyOS 4.2 version.

PAC (Pointer Authentication Code) is a security feature introduced in the ARM architecture. It inserts additional code into pointers for signing to verify the integrity of pointers, thus defending against JOP, ROP, and other attacks.

HarmonyOS 4.2 version uses PAC to protect non-leaf node return addresses, implemented as follows:

The kernel code contains the ptrauth\_keys\_kernel structure, which has the ptrauth\_key structure. When each process is created, the kernel executes the ptrauth\_keys\_init\_kernel function, which uses get\_ramdom\_bytes to write 16 random bytes to the key\_kernel field of the thread structure in the task\_struct. When the process calls the kernel system call, switch\_to writes the key\_kernel of task\struct to \\_pki\v.lo and \\_pki\v.hi, and the PACIASP and AUTIASP instructions use the \\_pki\_v register to compute the value written to the stack to ensure that the return address is not tampered with.

HarmonyOS 4.2 version achieves user-mode and kernel-mode key separation in the PAC mechanism, but the user-mode and kernel-mode algorithms are the same. If an attacker can modify the user-mode key to the kernel-mode key, it may lead to controlling the kernel execution flow. It is recommended to isolate user-mode and kernel-mode algorithms.

struct ptrauth_keys_kernel {
    struct ptrauth_key apia;

static __always_inline void ptrauth_keys_init_kernel(struct ptrauth_keys_kernel *keys)
    if (system_supports_address_auth())
        get_random_bytes(&keys->apia, sizeof(keys->apia));

static __always_inline void ptrauth_keys_switch_kernel(struct ptrauth_keys_kernel *keys)
    if (!system_supports_address_auth())

    __ptrauth_key_install_nosync(APIA, keys->apia);

Today’s kernel attack methods have greatly diverged from traditional methods, as the integrity of control flow has been significantly improved due to the introduction of Stack Canary, PAC, and CFI. It is now rare to see attacks that directly compromise the kernel through control flow hijacking.

In recent years, Data Oriented Attacks (DOA) have become more common for kernel privilege escalation. By exploiting UAF or OOB vulnerabilities to modify data pointers in the kernel, attackers can achieve arbitrary kernel address read/write and modify critical data structures in the kernel to escalate privileges. iOS 17 has implemented Data PAC based on its processor’s hardware security capabilities, and Pixel 8 has used ARM MTE on native Android to significantly improve defense capabilities against Data Oriented Attacks. However, HarmonyOS has not yet applied the above mechanisms.

Kernel Arbitrary Read and Write Exploitation Defense Capability Index

This index corresponds to the defense capability against bypassing “patrolling guards” in the kernel.

HarmonyOS 4.2 version has better protection of kernel code and critical data than HarmonyOS NEXT and significantly leads native Android 14. It uses the self-developed HKIP mechanism (similar to RKP) to protect kernel critical data. iOS’s SPTM, based on hardware features, has a smaller attack surface.

The continuous improvement of defense mechanisms such as PAC and CFI has led to better protection of kernel control flow integrity, and attacks by hijacking kernel control flow have become less common. In recent years, a more common method is to use Data Oriented Attacks (DOA) to obtain arbitrary data read/write capabilities in the kernel, modify kernel critical data, and carry out privilege escalation attacks. Therefore, how the operating system defends against further attacks after the attacker obtains arbitrary read/write capabilities in the kernel is a core capability of kernel security.

The kernel contains a large amount of sensitive data and segments, such as the kernel code segment, which is the primary target for attackers. Once an attacker can modify the kernel code segment data, they can gain arbitrary execution permissions in the kernel. By protecting kernel data integrity from a higher level, the operating system can effectively increase the difficulty of exploitation for attackers.

RKP stands for “Real-time Kernel Protection” and is the name of Samsung’s EL2-level defense mechanism implementation. It is a component of Samsung KNOX. The appearance of the RKP mechanism has significantly increased the difficulty of attacks, and traditional vulnerability exploitation methods are less effective against RKP. The following is a diagram of page table address translation in RKP:


HarmonyOS 4.2 version also uses the HKIP mechanism to protect the integrity of kernel code segments and read-only data segments from the EL2 level. It creates read-only memory using mmap to store important structure data and pointers in the kernel and uses HKIP to protect the integrity of this memory. The principle is similar to RKP, with an additional layer of page table mapping at the EL2 level to ensure that modifications to the page table at the EL1 level can be captured and intercepted by the EL2 level.

The HKIP mechanism in HarmonyOS 4.2 version has protection capabilities equivalent to RKP, protecting code segments, read-only data segments, and important kernel structures from being modified. However, there is a lack of protection for application program page tables, and attackers can arbitrarily read and write physical addresses not protected by HKIP by modifying the application program page tables. This exploitation method has also been verified to be feasible on Pixel and Samsung Galaxy devices.

In HarmonyOS NEXT, while HKIP provides multiple protection mechanisms, it was found during the research process that apart from code segments, read-only data segments, and kernel page tables, other important structures are not protected.

The following is a comparison of the defense capability coverage range of some HKIP and RKP mechanisms:

(o Covered, x Uncovered, | Not Fully Covered)

Post-Exploitation Impact Spread Defense Capability Index

This index corresponds to the defense capability against the spread of malicious behavior.

The kernel composition of HarmonyOS 4.2 version is similar to that of native Android 14 and ONE UI 6, and there is no strict permission isolation between major modules. iOS uses a hybrid kernel architecture based on Mach and BSD.

HarmonyOS NEXT adopts a microkernel architecture with finer-grained kernel module isolation. It divides kernel resources into multiple types, with corresponding modules managing different types and communicating through IPC mechanisms, making it more difficult for attackers to extend their attacks horizontally.

Traditional operating system kernels are responsible for scheduling all resources of the system. Once an attacker gains permission to any module of the kernel, it will lead to the compromise of the entire operating system. With the birth of microkernels, the permission division of kernel modules has become more fine-grained. Therefore, how to reduce the spread of post-exploitation impact has become a new measurement index of kernel security.

Network modules, file management modules, memory management modules, and driver modules are the primary targets for attackers. By dividing their permissions in a fine-grained manner, attackers can be effectively prevented from spreading their attacks from one point to the entire system.

HarmonyOS NEXT divides permissions between modules in a fine-grained manner, and modules communicate through IPC, making it difficult for attackers to evolve the attack results of one module into system-wide attack results.

HarmonyOS NEXT loads driver programs in user mode, making attacks against driver programs only able to gain EL0 layer permissions, which are difficult to convert into attacks against the EL1 layer of the kernel.

In-Depth Defense Capability Index

This index corresponds to the defense capability against persistent residence and information theft.

HarmonyOS 4.2 and HarmonyOS NEXT both have in-depth defense designs below the kernel. Even if an attacker compromises the kernel, consumer biometric information, critical keys, and other sensitive information can still be protected.

HarmonyOS NEXT has also enhanced file system protection, using different keys for different contexts to protect the confidentiality and integrity of code and data files, and using Secure Enclave (TrustZone, security chips) isolated from the kernel for key management.

In-depth defense has been widely practiced on mobile devices, and manufacturers and system developers can achieve higher security privilege levels by utilizing processor-provided hardware security primitives and chip designs. Even if an attacker compromises the kernel, user-sensitive data can still be safeguarded by relying on hypervisors, Secure monitors, TrustZone, and security chips that have smaller TCBs and are isolated from the kernel.

Statement and Prelude

This report provides an initial adversarial analysis of the security defense mechanisms of various mobile operating system kernels but has not yet conducted the best quantitative evaluation operations of AVSS. Therefore, the current report version does not include evaluation scores and comprehensive scores for all sub-item indicators.

Furthermore, DARKNAVY has obtained root access to the HarmonyOS NEXT system based on the DAF (DarkNavy Adversarial Framework) and made an initial quantitative analysis of its horizontal and vertical security.

source: Zhihu