Security enhancements in hierarchical protection domains

Abstract

Methods and systems for allowing software components operating at particular exception levels (e.g., EL-3 to EL-1, etc.) to repeatedly or continuously observe or assess the integrity of software components operating at low exception levels (e.g., EL-2 to EL-0) to ensure that the software components have not been compromised or compromised (e.g., subjected to malware, cyber attacks, etc.) include a computing device that identifies, by a component operating at a high exception level ("HEL component"), at least one of a current vector base address (VBA), an exception raise instruction (ERI) address, or control and system register values associated with a component operating at a low exception level ("LEL component"). The computing device can perform a responsive action in response to determining that the current VBA, ERI address, or control and system register values do not match corresponding reference data.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of priority to U.S. Patent Application No. 16 / 897,959, filed June 10, 2020, entitled "Security Enhancement in Hierarchical Protection Domains," the entire contents of which are incorporated herein by reference. Background Technology

[0003] Modern software systems are typically divided into multiple modules / components, each with different levels of privileges or access to computing resources (e.g., system resources, processor resources, memory resources, etc.). An example of this division is between the operating system (OS) kernel and user applications, where user applications are granted more limited access levels to system resources than the OS kernel.

[0004] To facilitate similar partitioning at the chip level, some processors and computing architectures (e.g., ARM, RISC-V, HexagonDSP, etc.) include features that support hierarchical protection domains and / or implement different levels of privilege. Such systems typically operate at only one privilege level at a time, and the privilege level (“current privilege level”) can change only when the device processor encounters or returns from an exception. For this purpose, privilege levels are often referred to as exception levels (EL). These exception levels can be numbered (e.g., EL-0 to EL-3), with higher privilege levels having higher numbers. For example, software with the lowest privilege level (e.g., user applications, etc.) can operate at EL-0, while software with the highest privilege level (system monitors, etc.) can operate at EL-3. Summary of the Invention

[0005] Various aspects may include devices and methods for evaluating software operating at a low exception level on a computing device. Various aspects may include a component operating at a high exception level (“HEL component”) identifying at least one of a current vector base address (VBA), exception raising instruction (ERI) address, or control and system register (CSR) value associated with a component operating at a low exception level (“LEL component”), determining whether at least one of the current VBA, ERI address, or CSR value matches corresponding reference data, and performing a response action in response to determining that the current VBA, ERI address, or CSR value does not match the corresponding reference data.

[0006] Some aspects may further include the HEL component scanning at least at a low anomaly level to collect data, marking portions of the collected data as key data to be used as reference data, generating a hash of the reference data, and storing the generated hash as reference data in a portion of memory accessible to the HEL component but inaccessible to the LEL component. In such an aspect, the HEL component scanning at least at a low anomaly level to collect data may include the HEL component collecting LEL component data as reference data during the loading of the LEL component.

[0007] Some aspects may also include identifying critical data currently in working memory, calculating a hash of the identified critical data, and comparing the calculated hash with corresponding reference data to determine whether at least one of the current VBA, ERI address, or system register value matches the corresponding reference data. In such an aspect, identifying critical data currently in working memory may include identifying critical read-execute (RX) code or critical read-only (RO) data currently present in working memory, and comparing the calculated hash with the corresponding reference data may include comparing the calculated hash with a reference data hash stored in memory by the HEL component.

[0008] Some aspects may further include periodically invoking the HEL component to verify that the integrity of the LEL component has not been compromised. Some aspects may further include non-periodicly invoking the HEL component to verify that the integrity of the LEL component has not been compromised. Some aspects may further include periodically invoking the HEL component to verify that the integrity of the LEL component has not been compromised by invoking the HEL component based on at least one of the following: a machine interrupt triggered by cyclic execution; a random machine interrupt triggered by a pseudo-random table; or a user-triggered machine interrupt triggered by an event-based trigger.

[0009] Some aspects may further include detecting system calls or runtime events that could cause a change in the current level of anomaly of the computing device, and invoking the HEL component in response to the detection of system calls or runtime events that could cause a change in the current level of anomaly of the computing device to verify that the integrity of the LEL component has not been compromised.

[0010] In some respects, identifying at least one of the current VBA, ERI address, or CSR value associated with an LEL component may include identifying the current VBA by performing one or more of the following: reading the vector base address register (VBAR); reading the vector table base holder; reading the exception level vector base address register (ELx_VBAR); reading the machine trap value register (MTVAL); reading the event vector base (EVB); or an equivalent provision in an instruction set architecture based on hierarchical privilege levels.

[0011] In some respects, identifying at least one of the current VBA, ERI address, or CSR value associated with an LEL component may include identifying the ERI address by capturing an address from the highest exception level of one of the following: a Security Monitor Call (SMC) code segment; an Exception Link Register (ELR); a Machine Exception Program Counter (MEPC); the program counter (PC) value of the instruction executed when the exception occurs; or a processor CSR.

[0012] In some respects, determining whether at least one of the current VBA, ERI address, or CSR value matches the corresponding reference data may include using a reference data comparison set that includes: a hash of the critical segment; the VBA; a set of address ranges of the ERI captured from the Exception Link Register (ELR) or the Machine Exception Program Counter (MEPC); or the CSR value.

[0013] Various aspects include a computing device having memory storing processor-executable instructions and a processor configured to execute the processor-executable instructions to perform any of the methods outlined above. Various aspects include a processor for use in a computing device, the processor having memory and configured to perform any of the methods outlined above. Various aspects include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause the processor of the computing device to perform any of the methods outlined above. Attached Figure Description

[0014] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary aspects of various embodiments and, together with the general description given above and the specific embodiments given below, serve to interpret the features of the claims.

[0015] Figure 1 This is a component block diagram illustrating an example computing device suitable for implementing various embodiments.

[0016] Figure 2A and Figure 2B This is a block diagram illustrating a privileged or exception level (EL) in an example computing device suitable for implementing various embodiments.

[0017] Figure 3 This is a block diagram illustrating sample manager executable files and linkable format images suitable for implementing some embodiments.

[0018] Figure 4 This is a process flow diagram illustrating a method for verifying the integrity of software components of a computing device and collecting reference data from the verified components, according to some embodiments.

[0019] Figure 5 This is a process flow diagram illustrating a method for collecting reference data suitable for evaluating the integrity of software components, according to some embodiments.

[0020] Figure 6 This is a message flow diagram illustrating the operation, communication, and interaction of a system configured, according to some embodiments, to periodically, periodically, and / or based on user-defined events, determine whether a software component has been corrupted or damaged.

[0021] Figure 7 This is a message flow diagram illustrating operations, communications, and interactions for processing system calls in a system configured to determine at runtime whether a software component has been corrupted or damaged, according to some embodiments.

[0022] Figures 8-11 This is a process flow diagram illustrating methods for assessing the integrity of software components to determine whether they have been corrupted or damaged, according to various embodiments.

[0023] Figure 12 This is a component block diagram of a computing device suitable for implementing wireless communication devices in some embodiments.

[0024] Figure 13 This is a block diagram of components suitable for implementing a computing device in the form of a laptop computer in some embodiments.

[0025] Figure 14 This is a block diagram of components suitable for implementing some embodiments of a server computing device. Detailed Implementation

[0026] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0027] In general, various embodiments include methods for allowing software components operating at specific anomaly levels (e.g., EL-3 to EL-1, etc.) to repeatedly or continuously observe or evaluate the integrity of software components operating at lower anomaly levels (e.g., EL-2 to EL-0) to ensure that the software components have not been compromised or damaged (e.g., subjected to malware, cyberattacks, etc.), and computing devices configured to implement such methods. For example, various embodiments may allow monitor software operating at anomaly level 3 (EL-3) to observe or evaluate the integrity of a hypervisor operating at anomaly level 2 (EL-2) in a non-secure part of a computing system and / or the integrity of trusted zone components operating at anomaly level 1 (EL-1) in a secure part of a computing system. Similarly, various embodiments may allow the hypervisor to observe or evaluate the integrity of a guest operating system (OS) or virtual machine (VM) operating at anomaly level 1 (EL-1), allow the guest OS or VM to observe or evaluate the integrity of end-user software applications operating at anomaly level 0 (EL-0), allow trusted zone components to observe or evaluate the integrity of trusted applications operating at anomaly level 0 (EL-0) in the security section of the computing system, and so on.

[0028] For ease of reference and to focus the discussion on relevant features, some examples below can be discussed with reference to components operating at a low exception level (“LEL components”) and components operating at a high exception level (“HEL components”). It should be understood that LEL and HEL components can be implemented at any privileged or execution level discussed in this application (e.g., EL-0 and EL-1, EL-1 and EL-2, etc.) and / or on any processor or processor architecture containing hierarchical execution levels (e.g., ARM, Hexagon ST231, RISC-V, etc.).

[0029] In some embodiments, a processor in a computing device or computing system may be configured to collect reference data, mark / label portions of the collected reference data as key data, generate a hash of the key data, store the generated hash of the key data as reference data in memory, and transfer (or make available) the load address of the segment associated with the stored reference data to a high-privilege-level processor (e.g., a HEL component processor, an EL-3 processor, a monitor processor, etc.). The processor may periodically, periodically, and / or invoke the HEL component based on detected runtime events.

[0030] Upon invocation, the HEL component can perform various operations to verify that the integrity of the LEL component has not been compromised. For example, the HEL component can identify critical data currently in working memory (e.g., critical read-to-execute code and critical read-only data currently present in random access memory), calculate the hash of the identified critical data, and compare the calculated hash with corresponding reference data (e.g., the segment start address and / or reference hash stored in memory by the HEL component) to determine whether the calculated hash matches the stored reference data. In response to determining that the calculated hash does not match the stored reference data, the HEL component can determine that the integrity of the LEL component has been compromised and perform response actions (e.g., isolate the LEL component, notify security software, stop the system, etc.).

[0031] In some embodiments, the HEL component can be configured to obtain or determine the current Vector Base Address (VBA) used by the LEL component, detect or identify an Exception Raising Instruction (ERI), and / or read the LEL component control and system registers (LEL-CSR). The HEL component can compare the values ​​of the current VBA, ERI address (or ERI address range), and / or LEL-CSR register with corresponding reference data. The HEL component can determine whether the integrity of the LEL component has been compromised based on whether the current VBA, ERI address (or ERI address range), and / or LEL-CSR register values ​​match the corresponding reference data. The HEL component can determine that the integrity of the LEL component has been compromised and, in response to determining that the current VBA, ERI address (or ERI address range), and / or LEL-CSR register values ​​do not match the corresponding reference data, perform a response action (e.g., isolate the LEL component, notify security software, stop the system, etc.).

[0032] The term "computing device" is used herein to refer to any of a variety of computing devices, including smartphones, wireless or mobile computing devices (e.g., tablets, laptops, wearables, etc.), cellular-based wireless hotspots, IoT devices, eMTC devices, desktops, workstations, services, embedded systems of electromechanical systems (e.g., vehicles, industrial and agricultural machinery, medical devices, control systems, etc.), etc. Wireless communication devices are also commonly referred to as user equipment (UE), mobile devices, and cellular devices. Computing devices can receive and / or transmit communications via a variety of wired and / or wireless communication networks, including wide area networks (e.g., mobile communication networks), local area networks (e.g., Wi-Fi, Bluetooth, etc.), geolocation networks (e.g., Global Positioning System (“GPS”), personal area networks (e.g., wireless USB, Bluetooth, ZigBee, etc.), near field communication, etc.

[0033] The term "monitor" is used herein to refer to any hardware or software component that can support virtualization technologies and / or enable abstractions (or virtualization) of computing resources and operate across execution environments (e.g., across insecure or rich / normal execution environments and trusted / secure execution environments, etc.). This is used herein as the highest privilege level execution environment. A monitor can include any one or all of the following: a hardware monitor, dedicated hardware fabricated on a chip, a virtual machine monitor (VMM), monitor software running outside of an advanced operating system (HLOS), and a software monitor running as part of a device driver, which may be external to HLOS, its memory management system, and / or its allocator functions.

[0034] The term "hypervisor" is used herein to refer to any hardware or software component that supports virtualization technologies and / or enables the abstraction (or virtualization) of computing resources and operates within an execution environment (e.g., within a rich / normal execution environment). A hypervisor can create and operate virtual machines (VMs) and / or host multiple operating systems (referred to as guest operating systems) and can act as a virtual machine manager. The hypervisor presents a virtual operating platform to the guest operating systems and manages their execution. Each guest operating system communicates with the hypervisor / monitor in the same way it communicates with the physical hardware. This allows each guest operating system to operate under the illusion of exclusive access to the computing system's processor, peripherals, memory, and I / O.

[0035] Figure 1 The diagram illustrates components suitable for implementing a computing device 100 in various embodiments. Figure 1 In the illustrated example, computing device 100 includes a subscriber identity module (SIM) interface 102, an identity module SIM 104, a general-purpose processor 106 (e.g., a central processing unit (“CPU”), an encoder / decoder (CODEC) 108, a speaker 110, a microphone 112, memory 114, a baseband modem processor 116, radio frequency (RF) resources 118, an antenna 120, a system-on-a-chip (SOC) 122, physical buttons 124, a touchscreen display 126, peripheral devices 128 (e.g., a camera, etc.), and various controllers / microcontrollers 130. In some embodiments, the general-purpose processor 106, memory 114, baseband processor 116, and RF resources 118 may be included in the SOC 122. In some embodiments, the SIM 104 and its corresponding interface 102 may be external to the SOC 122.

[0036] In some embodiments, computing device 100 may further include a graphics processing unit (GPU), a modem digital signal processor (DSP), an application processor unit (APU), and / or other dedicated processors or hardware accelerators (not shown). Any or all processors in computing device 100 may include one or more homogeneous or heterogeneous processor cores. Homogeneous processor cores may be cores configured for the same purpose and / or having the same or similar performance characteristics. Heterogeneous processor cores may be cores configured for different purposes and / or having different performance characteristics. The heterogeneity of such heterogeneous processor cores may include different instruction set architectures, pipelines, operating frequencies, etc. Examples of such heterogeneous processor cores may include the so-called "big.LITTLE" architecture, in which slower, low-power processor cores may be coupled to more powerful and power-consuming processor cores.

[0037] SIM interface 102 can be configured to receive an identity module SIM 104 associated with a subscription to a mobile phone network. In some embodiments, computing device 100 may be a multi-subscription computing device including additional SIM interfaces, each of which can receive additional identity modules SIM associated with other subscriptions and / or other mobile phone networks.

[0038] The general-purpose processor 106 may be coupled to a CODEC 108, which may be coupled to a speaker 110 and a microphone 112. The general-purpose processor 106 may also be coupled to at least one memory 114. The memory 114 may be a non-transitory computer-readable storage medium storing processor-executable instructions. The memory 114 may also store operating system (OS) software, application data, user applications, software, and / or executable instructions, including instructions configured to cause the processor to perform operations according to various embodiments.

[0039] The baseband modem processor 116 can be an integrated chip capable of managing the protocol stack of SIM 104 or subscriptions and implementing coexistence manager software.

[0040] RF resource 118 may include communication circuitry or a transceiver performing transmit / receive functions for the associated SIM 104 of computing device 100. RF resource 118 may include communication circuitry comprising separate transmit and receive circuitry, or may include a transceiver combining transmitter and receiver functions. RF resource 118 may be configured to support multiple radio access technologies / wireless networks operating according to different wireless communication protocols. RF resource 118 may include or provide connections to different sets of amplifiers, digital-to-analog converters, analog-to-digital converters, filters, voltage-controlled oscillators, etc. Multiple antennas 120 and / or receiver blocks may be coupled to RF resource 118 to facilitate multimode communication with various combinations of antenna and receiver / transmitter frequencies and protocols (e.g., LTE, Wi-Fi, Bluetooth, NFC, etc.). RF resource 118 may also be coupled to baseband modem processor 116.

[0041] Computing device 100 can be configured to operate within various communication systems, such as mobile phone networks. Computing device 100 can communicate with mobile phone networks via a cellular connection to a base station of the mobile phone network. The cellular connection can be established via a two-way wireless communication link using various communication technologies, such as LTE, 5G, 4G, 3G, CDMA, TD-SCDMA, WCDMA, GSM, and other mobile phone communication technologies. Other connections may include various other wireless connections, including WLANs such as Wi-Fi based on the IEEE 802.11 standard, and wireless positioning services such as GPS; WPANs such as wireless USB, Bluetooth, and ZigBee; and / or near-field communication.

[0042] Figure 2A The illustration can be used in processors suitable for implementing various embodiments (e.g., Figure 1 An example software architecture of computing system 200 comprising software, firmware, and functional modules (also referred to herein as “components”) executed in 106). Figure 2A The illustration can be used in processors suitable for implementing various embodiments (e.g., Figure 1 An example software architecture of a computing system 200 comprising software, firmware, and functional modules (“components”) executed in (106).

[0043] exist Figure 2AIn the illustrated example, computing system 200 includes a monitor 202 component, a hypervisor 204 (or access control driver) component, virtual machines 206, 208, a trust zone (TZ) 210 component, and a security or trust application (TA) 212. Computing system 200 may also include various additional functional components configured to implement the various functions described herein, such as a host operating system, a DSP operating system, library modules, software applications, user processes, listener threads, execution hardware (e.g., application processor, DSP, etc.), input / output devices, memory, etc.

[0044] The computing system 200 may include various execution environments, including insecure or rich / normal execution environments 220 and trusted / secure execution environments 222 (e.g., trusted execution environment (TEE), ARM trusted zone execution environment, etc.). The rich / normal execution environment 220 may include a hypervisor 204 and virtual machines 206, 208 (e.g., virtual machine 1 and virtual machine 2). The trusted / secure execution environment 222 may include a TZ 210 component and a TA 212. The monitor 202 component can operate across various execution environments and can be configured to control access to the trusted / secure execution environment 222.

[0045] Figure 2A and Figure 2B The components in the illustrated computing system 200 can be configured to execute within various exception levels (EL) 230-236, where each exception level controls the execution privileges of the components executing within that level. Figure 2A In the illustrated example, software applications 216a-216d and TA 212 operate within exception level 0 (EL-0230). Guest operating systems 214a-214b and TZ 210 components operate within exception level 1 (EL-1 232). Hypervisor 204 operates within exception level 2 (EL-2 234). Monitor 202 operates within exception level 3 (EL-3 234). Figure 2B The diagram illustrates that exception level 0 (EL-0 230) can include application / user space components, exception level 1 (EL-1 232) can include the kernel, kernel driver and virtual machine (VM), exception level 2 (EL-2 234) can include hypervisor and access control (AC) driver, and exception level 3 (EL-3 236) can include monitor.

[0046] The exception levels are numbered (e.g., EL-0 to EL-3) so that higher privilege levels have higher numbers. For example, a hypervisor 204 operating at exception level 2 (EL-2 234) can have greater execution privileges than software applications 216a-216d executing at exception level 0 (EL-0 230).

[0047] The monitor 202 component may include hardware and / or software components configured to support virtualization technologies and / or enable abstractions (or virtualization) of computing resources, including any one or all of the following: hardware monitors, dedicated hardware fabricated on a chip, virtual machine monitors (VMMs), monitor software running outside of an advanced operating system (HLOS), and software monitors running as part of a device driver, which may be external to HLOS, its memory management system, and / or its allocator functions. The monitor 202 component may operate in both rich / normal execution environment 220 and trusted / secure execution environment 222, and the hypervisor 204 component.

[0048] The hypervisor 204 component can be a software control program between the operating system and the monitor 202 component. The hypervisor 204 component can host multiple operating systems (referred to as guest operating systems). Each guest operating system 214a-214b can be configured to interact with physical hardware (e.g., ...). Figure 1 The general-purpose processor 106 shown communicates with the hypervisor 204 and / or monitor 202 components in the same way, treating the combination of hypervisor 204, monitor 202, and hardware as a single virtual machine. This allows each guest operating system 214a-214b to operate under the illusion of exclusive access to the processor, peripherals, memory, and I / O.

[0049] Hypervisor component 204 can be configured to manage memory access requests for virtual machines 206 and 208. That is, the operating system is typically responsible for partitioning physical memory across multiple processes. However, in systems including guest operating systems 214a-214b running on top of virtual machines 206 and 208, the memory allocated by guest operating systems 214a-214b is not true physical memory, but rather intermediate physical memory. In such systems, hypervisor component 204 is responsible for the actual allocation of physical memory.

[0050] Virtual machines 206 and 208 can be software applications that execute software applications just like physical hardware machines. For example, virtual machines 206 and 208 can provide software applications 216a-216d with physical hardware (e.g., Figure 1 The interface between the general-purpose processor 106 shown in the diagram and other components allows software applications bound to a specific instruction set architecture (ISA) to execute on hardware implementing different instruction set architectures. By creating and managing virtual machines (VMs), the computing system 200 can create "sandboxes" (i.e., secure separation) around various features including operating systems, applications, processes, etc. The computing system 200 can use these sandboxes to implement access control between various features of the device.

[0051] Execution environments 220 and 222 can be loaded via a secure boot process. Typically, secure boot is a boot sequence in which each software image loaded and executed on computing system 200 is certified and / or authorized by previously certified / authorized software. The boot sequence can be configured to prevent unauthorized or modified code from running on the computing device by ensuring that each software image is checked before execution. The first image in the boot sequence is called the Master Boot Loader (PBL), which is typically stored in immutable read-only memory that cannot be physically altered. The PBL authorizes each software image loaded and executed on computing system 200 by cryptographically verifying the digital signatures on each software image it loads. Those software images cryptographically verify the digital signatures on the next set of images they load, etc. This ensures that the software images have not been altered.

[0052] In some embodiments, the PBL can be configured to load an Extensible Bootloader (XBL) image and a Trusted Secure Extensible Bootloader (XBL_SEC) image. The XBL image can be configured to coordinate the loading of an enriched / normal execution environment 220, which may include an OS kernel and peripheral firmware images. The XBL_SEC image can be configured to coordinate the loading of a Trusted / Secure Execution Environment 222, which may include a Trusted Execution Environment (TEE) and TEE-related images. Separation and isolation of the TEE image during the loading process can improve security by shortening the chain of images that must be loaded, authorized, and executed before the TEE image is operational. The XBL_SEC image can also be configured with a monitor 202 or access control system to isolate the memory used by the Trusted / Secure Execution Environment 222 from all other execution environments on the chip, and then execute the XBL image at a less privileged exception level.

[0053] Software images loaded by XBL and / or XBL_SEC can be executable and linkable format (ELF) software images, examples of which are shown in [link to example]. Figure 3 The diagram is shown in the image. An ELF software image can include multiple individual ELF fragments. Figure 3 In the example shown, the hypervisor ELF image 300 includes a vector table segment 302, a critical read-execute (RX) code segment 304, and critical read-only (RO) data. Each ELF segment may include code, data, or metadata about the software image. For example, the ELF software image file may include a hash segment containing data for authenticating the software image. The hash segment may include a table of cryptographic hash values ​​and a collection of metadata about the software image. The cryptographic hash values ​​in the table can be computed on other segments in the ELF image software and used to verify the correctness of these segments when they are loaded into memory. The metadata may include information about the type of image and the type of hardware on which the software image is designed to run.

[0054] exist Figure 2A In the illustrated example, hypervisor component 204 operates in rich / normal execution environment 220 at anomaly level 2 (EL-2 234), and host software applications 216a-216d operate in rich / normal execution environment 220 at anomaly level 0 (EL-0 230). A regular hypervisor lacks a dynamic mechanism that allows it to continuously check the integrity of virtual machines 206, 208 on which software applications 216a-216d operate. Therefore, a regular hypervisor may be unable to determine whether virtual machines 206, 208 are being operated by a deceptive or malicious actor (e.g., as part of a cyberattack) and / or whether virtual machines 206, 208 are performing undesirable activities that could negatively impact the security, performance, or functionality of computing system 200.

[0055] Furthermore, because the hypervisor 204 component hosts guest operating systems 214a-214b and operates within the rich / normal execution environment 220, both the conventional hypervisor 204 component and the guest operating systems 214a-214b may be vulnerable to malware and cyberattacks by deception or malicious actors. Since the hypervisor 204 component is hosted by monitor 202, an compromised hypervisor may compromise the integrity of trust / security components (e.g., Trust Zone (TZ) 210 component, Trusted Application (TA) 212, etc.) and trust / security content. Conventional trust / security components do not include mechanisms that allow them to determine whether the hypervisor has been compromised by deception or malicious actors (e.g., as part of a cyberattack) and / or is performing undesirable activities.

[0056] Various embodiments provide methods that enable software / components operating at specific anomaly levels (e.g., EL-3 to EL-1) to repeatedly or continuously observe and / or evaluate the integrity of software / components operating at low anomaly levels (e.g., EL-2 to EL-0). Using Figure 2A The architecture illustrated herein serves as an example. Various embodiments enable the monitor 202 component to observe and / or evaluate the integrity of the hypervisor 204 component, enable the hypervisor 204 component to observe and / or evaluate the integrity of the guest operating systems 214a-214b and / or virtual machines 206, 208, enable the guest operating systems 214a-214b to observe and / or evaluate the integrity of the software applications 216a-216d, enable the TZ 210 component to observe and / or evaluate the integrity of TA 212, and so on.

[0057] In some embodiments, a processor (and / or XBL_SEC, etc.) in a computing system can be configured to collect reference data, mark / label portions of the collected reference data as critical data, generate a hash of the critical data, store the generated hash of the critical data in memory as reference data, and transfer (or make available) the load address of the segment associated with the stored reference data to a high-privilege-level processor (e.g., HEL component processor, EL-3 processor, monitor processor, etc.). The processor can invoke the HEL component periodically, periodically, and / or based on detected runtime events. Upon invocation, the HEL component can perform various operations to verify that the integrity of the LEL component has not been compromised. For example, the HEL component can obtain or determine the current vector base address (VBA) used by the LEL component and compare the current VBA with the reference data. The HEL component can determine that the integrity of the LEL component has been compromised in response to determining that the current VBA does not match the reference data.

[0058] According to some embodiments, the processor (or XBL_SEC, etc.) in the computing system 200 can be configured to identify and mark critical data. For example, the processor can identify and mark any or all of the following critical sections as critical data: Access Control Driver (ACD) code, Hypervisor Vector Table, Operating System Vector Table, Hypervisor Vector Handler associated with exception vectors, Security Monitor Call (SMC) interface / caller code, SMC instruction code address, Access Control Data / Policy, Virtual Machine Policy Manager code / Resource, Hypervisor execution flow variables, and user-defined marked critical sections.

[0059] Simultaneously with loading the LEL component, the HEL component (or XBL_SEC, etc.) can generate a hash of the critical data associated with the LEL component. This generated hash is stored in a register or memory as reference data (or measurement parameters) for the LEL component, and the register / memory address of the stored LEL component hash is delivered (or made available) to a high-privilege handler (e.g., an EL-3 handler, a HEL component handler, etc.). Once stored, the HEL component (i.e., the high-privilege component) can access the stored reference data (e.g., the hash) to compare with the current critical data (or hash of the critical data) of the LEL component during monitoring to determine if the LEL component has been compromised, altered, or otherwise differs from the certified version loaded during the aforementioned boot sequence.

[0060] In some embodiments, a processor in the computing system 200 may be configured to invoke a HEL component to monitor one or more LEL components periodically, periodically, randomly, or based on predefined criteria, such as events that can indicate or be associated with an LEL component becoming corrupted or altered. For example, the processor may be configured to invoke the HEL component based on a system call or other real-time or runtime event. In some embodiments, the processor may be configured to invoke the HEL component based on a regular machine interrupt triggered by a cyclic execution. For example, the processor may invoke the HEL component periodically or at regular intervals based on the barking of a security watchdog (WD) acting as a cyclic execution procedure for interruption.

[0061] In some embodiments, the processor can be configured to invoke HEL components based on a random machine interrupt driven by a pseudo-random table. For example, the processor can use a timer interrupt registered at the highest privilege level (e.g., EL-3) that has a regular interval interrupt or a pseudo-random interval based on a previous timer interrupt that will invoke a normalized random number for the next interrupt interval. The timer interrupt can be used as a pseudo-randomized table (timer) driven scheduler to invoke the next interrupt.

[0062] In some embodiments, the processor may be configured to invoke HEL components based on user-triggered machine interrupts with event-based triggering. For example, the processor may invoke HEL components at periodic or regular intervals using client-request-based invocations, such as use case-triggered intervals, which act as event-driven scheduling of interrupts.

[0063] In some embodiments, the processor may be configured to invoke the HEL component based on system calls or other real-time or runtime events. For example, the processor may be configured to invoke the HEL component in response to detecting a system call or instruction execution associated with a change in the current exception level. For example, the processor may invoke the HEL component in response to detecting an SMC call from the hypervisor 204 component to the TZ 210 component, in response to detecting a Security Monitor Call (SMC) or Hypervisor Call (HVC) from the guest operating system 214a-214b to the hypervisor 204 component, in response to detecting a Phase 2 data abort operation, etc.

[0064] When invoked, the HEL component can perform various operations to determine whether the integrity of the LEL component has been compromised. For example, in some embodiments, the HEL component can identify critical data currently in the working memory used by the LEL component (e.g., critical RX code and critical RO data currently present in DDR SDRAM, etc.), calculate a hash of the identified critical data, compare the calculated hash with reference data (e.g., the start address of the ELF segment stored in memory by XBL_SEC and a reference hash, etc.), determine whether the calculated hash matches the reference data based on the comparison, verify that the integrity of the LEL component has not been compromised in response to determining that the calculated hash does not match the reference data, and determine that the integrity of the LEL component has been compromised in response to determining that the calculated hash does not match the reference data. In some embodiments, the HEL component can use the same hash function used to generate hash reference data during the LEL component load sequence to calculate the hash of the critical data currently in the working memory.

[0065] In some embodiments, the HEL component can be configured to determine whether the integrity of the LEL component has been compromised by: determining the current vector base address (VBA) used by the LEL component; comparing the current VBA with reference data for the VBA to determine whether the current VBA matches the reference data; determining that the integrity of the LEL component has not been compromised in response to determining that the current VBA matches the reference data; and / or determining that the integrity of the LEL component has been compromised in response to determining that the current VBA does not match the reference data. In some embodiments, the HEL component can determine the current VBA used by the LEL component by reading the vector base address register (VBAR). In some embodiments, the HEL component can determine the current VBA used by the LEL component by reading the vector table base holdor (e.g., ELx_VBAR on an ARM processor, MTVAL on a RISC-V processor, Event Vector Return (EVB) on a Hexagon DSP, etc.).

[0066] In some embodiments, the HEL component can identify an "exception triggering instruction", determine the address of the exception triggering instruction, compare the address of the exception triggering instruction with reference data, determine that the integrity of the LEL component has not been compromised in response to determining that the address of the exception triggering instruction matches the reference data, and / or determine that the integrity of the LEL component has been compromised in response to determining that the address of the exception triggering instruction does not match the reference data.

[0067] In some embodiments, the HEL component may determine the address of the “exception-raising instruction” by capturing the address in the highest exception level from the hypervisor SMC code segment or reading any or all of the exception link registers (ELR, ELRx, etc.), reading the machine exception program counter (MEPC), reading the program counter (PC) value of the instruction executed when the exception occurred, reading the processor system control register, etc.

[0068] In some embodiments, the HEL component can be configured to compare the captured SMC address in the highest exception link register with reference data and determine, based on the comparison result, whether the integrity of the LEL component has been compromised.

[0069] In some embodiments, the HEL component can be configured to determine the current vector base address (VBA) of the LEL component, determine whether the current VBA matches reference data, determine that the integrity of the LEL component has not been compromised in response to determining that the current VBA matches the reference data, and / or determine that the integrity of the LEL component has been compromised in response to determining that the current VBA does not match the reference data. In some embodiments, the HEL component can be configured to determine the current VBA of the LEL component by reading a core vector table base address register or a vector table base address holder, such as an exception level vector base address register (ELx_VBAR), a machine trap value register (MTVAL), or an event vector base (EVB).

[0070] In some embodiments, the HEL component can be configured to read the LEL Control and System (LEL-CSR) register and verify values ​​as required by the system. The HEL component can compare the value of the LEL-CSR register with reference data to determine whether the LEL-CSR register value matches the reference data, determine that the integrity of the LEL component has not been compromised in response to determining that the LEL-CSR register value matches the reference data, and / or determine that the integrity of the LEL component has been compromised in response to determining that the LEL-CSR register value does not match the reference data.

[0071] Figure 4 The illustration depicts a method 400, according to some embodiments, for verifying the integrity of software components of a computing device and collecting reference data from the verified components. (Reference) Figures 1-4 Method 400 can be executed by a processor in a computing device (e.g., a general-purpose processor 106, a GPU, a DSP, an APU, etc.).

[0072] In box 402, the processor may begin executing code at a high privilege / abnormal level (e.g., EL-3). For example, in box 402, the processor may load a software component (“HEL component”) operating at a high abnormal level into the runtime system of the computing device. In some embodiments, the HEL component may be a monitor component operating within both the rich / normal execution environment and the trusted / secure execution environment of the computing device and within abnormal level 3 (EL-3).

[0073] In box 404, the processor can load low-privilege / abnormality level (e.g., EL-2, etc.) image metadata and fragments at a high privilege / abnormality level (e.g., EL-3, etc.). In some embodiments, the processor can also perform boot image authentication by the HEL component for software components operating at a low abnormality level (“LEL component”).

[0074] In some embodiments, in block 404, the processor may load metadata and fragments of the operating software at a low privilege / abnormal level (e.g., EL-2, etc.). For example, the processor may load metadata and fragments of the LEL component in block 404. As another example, in block 404, the processor may cause the HEL component to load metadata and fragments of the LEL component. In some embodiments, the LEL component may be a hypervisor component operating in an enriched / normal execution environment at abnormal level 2 (EL-2).

[0075] In determination box 406, the processor (or the loader in the HEL component) can compare the pre-computed hash of the identified critical fragments with the loadable fragment data and determine whether the integrity of all identified critical fragments has been checked / evaluated. The hash can be computed using any of the various available hash algorithms (e.g., RSA256, RSA384, RSA512, DES, etc.).

[0076] In response to the determination that the integrity of all identified critical fragments has been checked / evaluated, the processor can complete or end the verification and / or data collection cycle in box 416. This can be the end of data collection and reference data authentication (from the pre-computed hash as described above). For example, hypervisor reference data (critical fragment) integrity verification can occur during secure boot (XBL_SEC). After performing the operations in box 416, the HEL component can be ready to invoke the LEL component, and the computing device can continue normal operation. Later, the processor / computing device can use the collected reference data for LEL component integrity verification.

[0077] In response to the determination that the integrity of all identified critical segments has not yet been checked / evaluated, the processor may select the next segment from the segment list in box 408. In determination box 410, the processor may determine whether the current segment is critical to the software image. For example, the HEL component may determine whether the current segment includes critical read-execute (RX) code or critical read-only (RO) data for the LEL component. As another example, the HEL component may determine whether the current segment LEL component includes critical segments of access control driver (ACD) code, hypervisor vector table, operating system vector table, hypervisor vector handler associated with exception vectors, security monitor call (SMC) interface / caller code, SMC instruction code addresses, access control data / policies, virtual machine policy manager code / resources, hypervisor execution flow variables, or user-defined annotations.

[0078] As part of the operations in boxes 408 and / or 410, the processor can use the name of a fragment to identify key fragments in a HEL component, such as those published in the hypervisor ELF image. The processor is also able to use a predefined pattern or arrangement of the fragment or any offline compile-time annotations within the fragment. The HEL component loader can detect those annotations and annotate the fragments to be evaluated.

[0079] In response to determining that a segment is critical to the software image (i.e., determining box 410 = "Yes"), the processor may store the start address, size, and hash of the critical segment in box 412. This data may be stored in a register or memory accessible to the HEL component but inaccessible to the LEL component. Reference data may be stored in DRAM / SRAM or any memory protected by and accessible to the HEL component. This ensures that the LEL component does not corrupt the reference data. The memory may also be protected by any other suitable techniques or skills known in the art, such as via a hardware protection unit, a memory management unit (MMU) protection unit, a hardware firewall, or any software mechanism accessible in the HEL component.

[0080] In response to determining that the selected fragment is not critical to the software image (i.e., determination box 410 = "No"), the processor can determine in determination box 406 whether the integrity of all marked critical fragments has been checked / evaluated. The operations of execution boxes 406-412 can be repeated until all identified critical fragments have been evaluated.

[0081] Figure 5 The illustration shows a method 500, according to some embodiments, for collecting reference data suitable for evaluating the integrity of software components. (Reference) Figures 1-5Method 500 can be executed by a HEL component operating on a processor (e.g., a general-purpose processor 106, GPU, DSP, APU, etc.) in a computing device.

[0082] In box 502, the HEL component can scan the system's low privilege / abnormal levels to collect reference data. For example, the HEL component can scan the software image for data, code, or fragments that can include Access Control Driver (ACD) code, LEL component vector tables (e.g., hypervisor vector tables), operating system vector tables, LEL component vector handlers associated with exception vectors, Security Monitor Call (SMC) interface / caller code, SMC instruction code addresses, access control data / policies, virtual machine policy manager code / resources, hypervisor execution flow variables, or user-defined labeled key sections. Components performing the functions of box 502 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0083] In box 504, the HEL component can store the collected reference data as critical data, which will be used as reference data in memory protected from access by the LEL component. For example, the HEL component can identify and label the collected data as critical data, including any or all of the following: Access Control Driver (ACD) code, Hypervisor Vector Table, Operating System Vector Table, Hypervisor Vector Handler associated with exception vectors, Security Monitor Call (SMC) interface / caller code, SMC instruction code addresses, access control data / policies, Virtual Machine Policy Manager code / resources, Hypervisor execution flow variables, and user-defined labeled critical sections. Components performing the functions of box 504 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0084] In box 506, the HEL component can generate a hash of the key / reference data. For example, the processor can perform a hash function or operation on the key data to generate a hash value, hash code, digest, or simply a hash that can be used to index into a hash table. Components for performing the functions of box 506 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0085] In block 508, the HEL component may store the generated hash as reference data (or measurement parameters) in a register or memory accessible to the HEL component but inaccessible to the LEL component. The data may be formatted and / or stored using any of the various techniques or skills known in the art that allow the reference data to be stored such that it is inaccessible to the LEL component at any given time, but accessible to the HEL component whenever needed. Components for performing the functions of block 508 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0086] In block 510, the HEL component may transfer (or make available) the load address of a segment associated with the stored reference data to a high-privilege level handler (or HEL component handler, EL-3 handler, monitor handler, or any software capable of performing runtime integrity checks at the HEL component level). That is, the HEL component handler and / or software running within the HEL component have the same high privilege level. While some embodiments use the HEL component handler as an example, it should be understood that any software performing runtime integrity checks at the HEL component level is equally applicable. Software design may invoke the handler / integrity software through any function call mechanism within the HEL component. Components for performing the functions of block 510 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0087] Figure 6 The illustration depicts the operation, communication, and interaction of a system configured to perform a predictive method 600 for observing and assessing whether software components have been damaged or compromised, according to some embodiments. Reference Figures 1-6 The prediction method 600 can be executed by a processor in a computing device (e.g., a general-purpose processor 106, GPU, DSP, APU, etc.).

[0088] In block 602, the processor may begin executing code at a low privilege / exception level (e.g., EL-2, etc.). For example, in block 602, the processor may load software components (“LEL components”) operating at a low exception level into the runtime system of the computing device. In some embodiments, the LEL component may be a hypervisor component operating in an abundant / normal execution environment at exception level 2 (EL-2).

[0089] In any or all of boxes 604, 606, and 608, the processor may invoke the HEL component based on an interrupt request (IRQ) that may be received from or detected on an idle or auxiliary component, the processor, or the core. For example, in box 604, the processor may invoke the HEL component based on a regular machine interrupt triggered by a cyclic execution, which may be used to invoke the HEL component at periodic or regular intervals based on the safety watchdog (WD) barking of the cyclic executor acting as the interrupt.

[0090] In box 606, the processor can invoke HEL components based on a random machine interrupt driven by a pseudo-random table. For example, the processor can use a timer interrupt registered at the highest privilege level (e.g., EL-3) with a regular interval interrupt or pseudo-random interval based on a previous timer interrupt that will invoke a normalized random number for the next interrupt interval. The timer interrupt can be used as a pseudo-randomized table (timer) driven scheduler to invoke the next interrupt.

[0091] In box 608, the processor may invoke the HEL component based on a user-triggered machine interrupt with event-based triggering. For example, the processor may invoke the HEL component at periodic or regular intervals using client-request-based invocations, such as intervals triggered by use cases that act as event-driven scheduling for interrupts (e.g., Content Protection (CPZ) use cases, DRM use cases, security displays, security cameras, etc.).

[0092] In block 610, the processor may generate hashes of key fragments of one or more low privilege / abnormality level components (i.e., LEL components). In some embodiments, the processor may generate hashes for each key fragment of one or more low privilege / abnormality level components. In some embodiments, such as in block 412 of method 400, the processor may use the same hash function as used during loading one or more low privilege / abnormality level components to generate one or more hashes.

[0093] In box 612, the processor can use the generated hash to check / verify the integrity of fragments associated with components operating at low privilege / abnormal levels (e.g., LEL components, etc.). For example, as in box 412 of method 400, the processor can compare the generated hash with hashes generated and stored during the loading of one or more low privilege / abnormal level components.

[0094] In some embodiments, the processor may repeatedly perform the operations in 610 and 612 for each critical segment (e.g., each segment determined as critical in determination block 410 of method 400).

[0095] In box 614, the processor can take actions in response to determining that an integrity check has failed, such as setting a system error flag. For example, if the integrity of any critical segment is not verified, such as if the hash generated in box 610 does not match the hash of the stored segment determined in box 612, the processor can issue / prompt a "system fatal" call / flag in box 614.

[0096] Figure 7 The illustration depicts operations, communications, and interactions within a system configured to perform a runtime method 700 for observing and evaluating whether software components have been corrupted or damaged, according to some embodiments. Reference Figure 1-7 The runtime method 700 can be executed by a processor in a computing device (e.g., a general-purpose processor 106, GPU, DSP, APU, etc.).

[0097] In Operation 702, an LEL component or code executing at a low privilege / abnormal level (e.g., EL-2, etc.) may issue a system call (e.g., SMC, HVC, etc.) to an HEL component or code executing at a high privilege / abnormal level (e.g., EL-3, etc.). The "system call" in Operation 702 may include part of a second-stage data / instruction abort and processor ISA instruction that changes control to a high abnormal level, or any core ISA mechanism used to switch privilege levels (e.g., a user-defined interrupt that can change privilege levels).

[0098] In box 704, the HEL component or code executing at a high privilege / exception level (e.g., EL-3, etc.) can determine whether the value in the vector base address register (VBAR), exception link register (ELR, ELRx, etc.), or another system register (e.g., the LEL control and system (LEL-CSR) register, of the LEL component or low privilege / exception level code matches the corresponding reference data.

[0099] If the values ​​in VBAR, ELR, and / or system registers do not match their corresponding reference data for the LEL component, the HEL component or code executing at a high privilege / exception level (e.g., EL-3, etc.) can issue a system stop request to the system stop component in box 706, which can cause the system stop component to stop the system in box 708.

[0100] If the values ​​in VBAR, ELR, and / or system registers match their corresponding reference data, the HEL component or code executing at a high privilege / exception level (e.g., EL-3, etc.) can handle the system call as normal in box 710.

[0101] In box 712, HEL components or code executed at a high privilege / exception level (e.g., EL-3, etc.) may respond to system calls and / or send the results of system calls to LEL components or code executed at a low privilege / exception level (e.g., EL-2, etc.).

[0102] Figure 8 The illustration illustrates a method 800, according to some embodiments, for evaluating the integrity of an LEL component to determine whether the LEL component has been damaged or compromised. Reference Figures 1-8 Method 800 can be executed by a HEL component operating on a processor (e.g., a general-purpose processor 106, GPU, DSP, APU, etc.) in a computing device.

[0103] In box 802, the HEL component can identify critical data currently in the working memory. For example, the process can determine whether any critical RX code segments or critical RO data segments are currently present in the DDR SDRAM of the computing device. Components used to perform the functions of box 802 may include a processor (e.g., 106) coupled to the memory (e.g., 114).

[0104] In box 804, the HEL component can compute a hash of the identified key data. For example, a processor can perform a hash function or operation on the key data to generate a hash value, hash code, digest, or simply a hash that can be used to index into a hash table. Components for performing the functions of box 804 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0105] In box 806, the HEL component can compare the calculated hash with reference data. For example, the processor can compare the calculated hash with the ELF segment start address and / or a reference hash previously stored in memory by XBL_SEC. Components for performing the functions of box 806 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0106] In determination block 808, the HEL component can use the comparison result to determine whether the calculated hash matches the corresponding reference data. For example, the core processor of a computing device can compare the hash of data in DDR with the reference data, or it can invoke a cryptographic engine to compare the message digest with the reference data. Components for performing the function of determination block 808 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0107] In response to determining that the calculated hash matches reference data (i.e., determining box 808 = "Yes"), the HEL component may infer, determine, or verify in box 810 that the integrity of the LEL component has not been compromised. In some embodiments, the HEL component may take no action, thereby allowing the LEL component to continue operating. In some embodiments, the HEL component may take action as part of the operation in box 810 in response to determining or verifying that the integrity of the LEL component has not been compromised, such as setting a flag bit in the LEL component's control and system registers that indicates to other functions (e.g., a hypervisor) that the LEL component has been verified and that it is safe to continue operating. Components for performing the functions of box 818 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0108] In response to determining that the calculated hash does not match the reference data (i.e., determining box 808 = "No"), the HEL component may infer or determine in box 812 that the integrity of the LEL component has been compromised and perform a response action (e.g., stopping the system, etc.) in box 814. For example, the HEL component may issue / prompt a "system fatal" call / flag (e.g., in box 614 of method 600). The component used to perform the function of box 812 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0109] Figure 9 The illustration depicts a method 900, according to some embodiments, for assessing the integrity of software components to determine whether they have been corrupted or damaged. References Figures 1-9 Method 900 can be executed by a HEL component operating on a processor (e.g., a general-purpose processor 106, GPU, DSP, APU, etc.) in a computing device.

[0110] In box 902, the HEL component can obtain or determine the current vector base address (VBA) used by the LEL component. That is, due to its inherent high privilege level attributes, the HEL component can access the LEL component. Thus, in box 902, the HEL component can identify the current VBA by reading the vector base address register (VBAR), reading the vector table base holder, reading the exception level vector base address register (ELx_VBAR), reading the machine trap value register (MTVAL), or reading the event vector base (EVB). Components used to perform the functions of box 902 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0111] In box 904, the HEL component can compare the current VBA with corresponding reference data stored in HEL-accessible memory during the loading of the LEL component. For example, in box 904, the HEL component can compare the value of VBAR, ELx_VBAR, MTVAL, or EVB with an address or address range (e.g., an ERI address range) in the reference data. The comparison operation can be a range check or an equality operation of the addresses contained in the VBAR. Components used to perform the functions of box 904 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0112] In determination box 906, the HEL component can determine whether the current VBA matches the corresponding reference data. Components used to perform the function of determination box 906 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0113] In response to determining that the current VBA matches the corresponding reference data (i.e., confirm box 906 = "Yes"), the HEL component can determine or verify in box 810 that the integrity of the LEL component has not been compromised, as described.

[0114] In response to determining that the current VBA does not match the corresponding reference data (i.e., determine box 906 = "No"), the HEL component can infer or determine, as described in box 812, that the integrity of the LEL component has been compromised, and perform a response action (e.g., stop the system, etc.) as described in box 814.

[0115] Figure 10 The illustration depicts a method 1000, according to some embodiments, for assessing the integrity of LEL software components to determine whether they have been corrupted or damaged. References Figures 1-10 Method 1000 can be executed by a HEL component operating on a processor (e.g., a general-purpose processor 106, GPU, DSP, APU, etc.) in a computing device.

[0116] In boxes 1002 and 1004, the HEL component can detect or identify an Exception Raising Instruction (ERI) and determine the address or range of the ERI. For example, the HEL component can capture addresses in the highest exception level from the Security Monitor Call (SMC) code segment in the LEL component via the Exception Link Register (ELR), the Machine Exception Program Counter (MEPC), or the program counter (PC) value of instructions executed in the LEL component when an exception occurs in the processor control and status register. It should be understood that a single address can be captured by the HEL component in boxes 1002 and 1004, and the reference data compared to it can include address ranges and / or sets of address ranges captured during a secure cold boot. Components used to perform the functions of boxes 1102 and 1104 can include a processor (e.g., 106) coupled to memory (e.g., 114).

[0117] In block 1006, the HEL component can compare the determined ERI address (or ERI address range) with reference data stored in the HEL-accessible memory during the loading of the LEL component. Components for performing the functions of block 1006 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0118] In determination block 1008, the HEL component can determine whether an ERI address (or ERI address range) matches the corresponding reference data. Components performing the function of determination block 1008 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0119] In response to determining that an ERI address (or ERI address range) matches the corresponding reference data (i.e., confirming box 1008 = "Yes"), the HEL component can determine or verify in box 810 that the integrity of the LEL component has not been compromised, as per the reference. Figure 8 As described.

[0120] In response to a determination that the ERI address (or ERI address range) does not match the corresponding reference data (i.e., confirmation box 1008 = "No"), the HEL component can, as referenced... Figure 8 The description in box 812 indicates that the integrity of the LEL component has been compromised, and as referenced... Figure 8 The described action is to perform a response (e.g., stop the system, etc.) in box 814.

[0121] Figure 11 The illustration depicts a method 1100, according to some embodiments, for assessing the integrity of software components to determine whether they have been corrupted or damaged. References Figures 1-11Method 1100 can be executed by a HEL component operating on a processor (e.g., a general-purpose processor 106, GPU, DSP, APU, etc.) in a computing device.

[0122] In box 1102, the HEL component can read system registers, such as the LEL Control and System (LEL-CSR) register. Components for performing the functions of box 1102 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0123] In box 1104, the HEL component can compare the values ​​of the LEL component's control register and system register (LEL-CSR) with corresponding reference data. Components for performing the functions of box 1104 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0124] In determination block 1106, the HEL component can determine whether a register value matches corresponding reference data. For example, the HEL component can perform a comparison operation to determine whether a captured address falls within a reference address range. Components used to perform the function of determination block 1106 may include a processor (e.g., 106) coupled to memory (e.g., 114).

[0125] In response to determining that the register value matches the corresponding reference data (i.e., determining box 1106 = "Yes"), the HEL component can determine or verify in box 810 that the integrity of the LEL component has not been compromised, as referenced. Figure 8 As described.

[0126] In response to a mismatch between the determination register value and the corresponding reference data (i.e., determination box 1106 = "No"), the HEL component can, as referenced... Figure 8 The description in box 812 indicates that the integrity of the LEL component has been compromised, and as referenced... Figure 8 The described action is to perform a response (e.g., stop the system, etc.) in box 814.

[0127] Various embodiments (including but not limited to those referenced above) Figures 1 to 11 The described embodiments can be implemented in a wide variety of computing systems, including wireless communication devices. Figure 12The diagram illustrates examples of computing systems suitable for use with various embodiments. Wireless communication device 1200 may include processor 1202 coupled to touchscreen controller 1204 and internal memory 1206. Processor 1202 may be one or more multi-core integrated circuits designated for general or specific processing tasks. Internal memory 1206 may be volatile or non-volatile memory, and may also be secure and / or encrypted memory, or insecure and / or unencrypted memory, or any combination thereof. Touchscreen controller 1204 and processor 1202 may also be coupled to touchscreen panel 1212, such as a resistive-sensing touchscreen, a capacitive-sensing touchscreen, an infrared-sensing touchscreen, etc. Additionally, the display of computing device 1200 does not need to have touchscreen capability.

[0128] The wireless communication device 1200 may have one or more radio transceivers 1208 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) and antennas 1210 for delivering and receiving communications, which are coupled to each other and / or coupled to the processor 1202. The transceivers 1208 and antennas 1210 can be used with the circuitry described above to implement various wireless transmission protocol stacks and interfaces. The wireless communication device 1200 may include a cellular network wireless modem chip 1216, which enables communication via a cellular network and is coupled to the processor.

[0129] Wireless communication device 1200 may include a peripheral device connection interface 1218 coupled to processor 1202. Peripheral device connection interface 1218 may be configured individually to accept one type of connection, or it may be configured to accept various types of public or proprietary physical and communication connections, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. Peripheral device connection interface 1218 may also be coupled to a similarly configured peripheral device connection port (not shown).

[0130] The wireless communication device 1200 may also include a speaker 1214 for providing audio output. The wireless communication device 1200 may also include a housing 1220 constructed of plastic, metal, or a combination of materials to house all or some of the components described herein. The wireless communication device 1200 may include a power supply 1222 coupled to the processor 1202, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to a peripheral device connection port to receive charging current from a source external to the wireless communication device 1200. The wireless communication device 1200 may also include a physical button 1224 for receiving user input. The wireless communication device 1200 may also include a power button 1226 for turning the wireless communication device 1200 on and off.

[0131] Various embodiments (including but not limited to the above references) Figures 1-11 The described embodiments can be implemented in a wide variety of computing devices, including a laptop computer 1300, examples of which are shown in Figure 13 The image is shown in the figure. Many laptop computers include a touchpad touch surface 1317 that serves as a pointing device for the computer and can therefore receive drag, scroll, and flick gestures similar to those implemented on computing devices equipped with touchscreen displays and as described above. Laptop computer 1300 typically includes a processor 1311 coupled to volatile memory 1312 and mass non-volatile memory, and a disk drive 1313 such as flash memory. Additionally, computer 1300 may have one or more antennas 1308 for delivering and receiving electromagnetic radiation, which may be connected to a wireless data link and / or cellular transceiver 1316 coupled to processor 1311. Computer 1300 may also include a floppy disk drive 1314 and a compact optical disc (CD) drive 1315 coupled to processor 1311. In a laptop configuration, the computer housing includes a touchpad 1317, a keyboard 1318, and a display 1319, all coupled to processor 1311. Other configurations of the computing device may include a computer mouse or trackball coupled to the processor (e.g., via USB input), as is well known, which may also be used in various embodiments.

[0132] Various embodiments (including but not limited to those referenced above) Figures 1 to 11 The described embodiments can also be implemented in fixed computing systems, such as any of a variety of commercially available servers. Example server 1400 in... Figure 14 As shown in the diagram. Such a server 1400 typically includes one or more multi-core processor components 1401 coupled to volatile memory 1402 and large-capacity non-volatile memory such as a disk drive 1404. (As shown in the diagram...) Figure 14 As shown, a multi-core processor component 1401 can be added to a server 1400 by inserting it into a component rack. The server 1400 may also include a floppy disk drive, compact optical disc (CD), or digital versatile optical disc (DVD) drive 1406 coupled to the processor 1401. The server 1400 may also include a network access port 1403 coupled to the multi-core processor component 1401 for establishing a network interface connection to a network 1405, such as a local area network, the Internet, a public switched telephone network, and / or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, or any other type of cellular data network) coupled to other broadcast system computers and servers.

[0133] As used herein, the terms “component,” “module,” “system,” “engine,” “generator,” “manager,” etc., are intended to include computer-related entities, such as, but not limited to, hardware, firmware, combinations of hardware and software, software, or software in execution, configured to perform specific operations or functions. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an executing thread, a program, and / or a computer. For illustration, both applications running on a computing device and the computing device itself can be referred to as components. One or more components may reside within a process and / or an executing thread, and components may reside on a single processor or core and / or be distributed across two or more processors or cores. Furthermore, these components can be executed from various non-transitory computer-readable media on which various instructions and / or data structures are stored. Components can communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory read / write, and other known network, computer, processor, and / or process-related communication methods.

[0134] Many different types of memory and memory technologies are available or anticipated in the future, any or all of which may be included in and used in systems and computing devices implementing various embodiments. Such memory technologies / types may include non-volatile random access memory (NVRAM), such as magnetoresistive RAM (M-RAM), resistive random access memory (ReRAM or RRAM), phase-change random access memory (PC-RAM, PRAM, or PCM), ferroelectric RAM (F-RAM), spin-transfer torque magnetoresistive random access memory (STT-MRAM), and 3D-XPOINT memory. Such memory technologies / types may also include non-volatile or read-only memory (ROM) technologies, such as programmable read-only memory (PROM), field-programmable read-only memory (FPROM), and one-time programmable non-volatile memory (OTP NVM). Such memory technologies / types may also include volatile random access memory (RAM) technologies, such as dynamic random access memory (DRAM), double data rate (DDR) synchronous dynamic random access memory (DDR SDRAM), static random access memory (SRAM), and pseudo static random access memory (PSRAM). Systems and computing devices implementing the various embodiments may also include or use electronic (solid-state) non-volatile computer storage media, such as flash memory. Each of the above-described memory technologies includes, for example, elements suitable for storing instructions, programs, control signals, and / or data used in or by a computer or other digital electronic device. Any references to terms and / or technical details relating to individual types of memory, interfaces, standards, or memory technologies are for illustrative purposes only and are not intended to limit the scope of the claims to a particular memory system or technology, unless specifically stated in the language of the claims.

[0135] Computer program code or "program code" for execution on a programmable processor to implement operations of various embodiments can be written in high-level programming languages ​​such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic, Structured Query Language (e.g., Transact-SQL), Perl, or in various other programming languages. As used herein, program code or program stored on a computer-readable storage medium can refer to machine language code (such as object code) in a format that is understandable by a processor.

[0136] The foregoing method descriptions and process flowcharts are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the presented order. As those skilled in the art will understand, the order of operations in the foregoing embodiments can be performed in any order. Words such as "afterwards," "then," and "next" are not intended to limit the order of operations; these words are only used to guide the reader through the description of the method. Furthermore, any reference, for example, to a noun in the singular form of a claim element should not be construed as limiting the element to the singular.

[0137] The various illustrative logic blocks, modules, circuits, and algorithmic operations described in conjunction with the various embodiments can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above in general terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of the claims.

[0138] The hardware used to implement the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the various embodiments disclosed herein may be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0139] In one or more exemplary aspects, the described functionality can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The steps of the methods or algorithms disclosed herein can be embodied in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium can be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable media can include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser optical discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while optical discs reproduce data optically using lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operation of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable medium and / or a computer-readable medium that may be incorporated into a computer program product.

[0140] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and implementations without departing from the scope of the claims. Therefore, the invention is not intended to be limited to the various embodiments and implementations described herein, but is to be given the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method for evaluating software operating at a low anomaly level on a computing device, comprising: Reference data is stored in a portion of the memory by the "HEL component" which operates at a high exception level. This reference data is accessible by the HEL component but not by the "LEL component" which operates at a low exception level. The HEL component identifies at least one of the current vector base address VBA or the control and system register CSR value associated with the LEL component; Determine whether at least one of the current VBA or CSR values ​​matches the stored reference data; and Execute a response action in response to determining that the current VBA or CSR value does not match the stored reference data.

2. The method according to claim 1, further comprising: The HEL component scans for at least low-level anomalies to collect data. The collected data is marked as key data to be used as reference data; Generate a hash of the reference data; as well as The generated hash is stored as a reference data in a portion of the memory that is accessible to the HEL component but inaccessible to the LEL component.

3. The method according to claim 2, wherein, The HEL component scans for at least low anomaly levels to collect data, including: the HEL component collects LEL component data as reference data during the loading of the LEL component.

4. The method according to claim 1, further comprising: Identify the key data currently in the working memory; Calculate the hash of the identified key data; as well as The calculated hash is compared with the corresponding reference data to determine whether at least one of the current VBA or system register values ​​matches the corresponding reference data.

5. The method according to claim 4, wherein: Identifying critical data currently in working memory includes identifying critical read-execute (RX) code or critical read-only (RO) data currently present in working memory; as well as Comparing the calculated hash with the corresponding reference data involves comparing the calculated hash with the reference data hash stored in memory by the HEL component.

6. The method according to claim 1, further comprising: Periodically call the HEL component to verify that the integrity of the LEL component has not been compromised.

7. The method according to claim 1, further comprising: The HEL component is called periodically to verify that the integrity of the LEL component has not been compromised.

8. The method of claim 1, further comprising periodically invoking the HEL component to verify that the integrity of the LEL component has not been compromised by invoking the HEL component based on at least one of the following: Machine interrupts that trigger cyclic execution; It features a random machine interrupt triggered by a pseudo-random table; or User-triggered machine interrupts with event-based triggering.

9. The method according to claim 1, further comprising: Detect system calls or runtime events that could cause a change in the current anomaly level of the computing device; as well as In response to the detection of a system call or runtime event that could cause a change in the current level of anomaly of the computing device, the HEL component is invoked to verify that the integrity of the LEL component has not been compromised.

10. The method according to claim 1, wherein, Identifying at least one of the current VBA or CSR values ​​associated with an LEL component includes identifying at least the current VBA by performing one or more of the following: Read the vector base address register VBAR; Read the vector table base holder; Read the exception level vector base address register ELx_VBAR; Read the machine trap value register MTVAL; or Read the event vector base EVB; or Equivalent provisions in instruction set architecture based on hierarchical privilege levels.

11. The method according to claim 1, wherein, Determining whether at least one of the current VBA or CSR values ​​matches stored reference data includes using a reference data comparison set, which includes: Hash of key segments; VBA; or CSR value.

12. A computing device, comprising: Memory, including processor-executable instructions; as well as The processor is configured to execute processor-executable instructions to perform operations including the following: Reference data is stored in a portion of the memory by the "HEL component" which operates at a high exception level. This reference data is accessible by the HEL component but not by the "LEL component" which operates at a low exception level. The HEL component identifies at least one of the current vector base address VBA or the control and system register CSR value associated with the LEL component; Determine whether at least one of the current VBA or CSR values ​​matches the stored reference data; and Execute a response action in response to determining that the current VBA or CSR value does not match the stored reference data.

13. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform operations, the operations further including: The HEL component scans for at least low-level anomalies to collect data. The collected data is marked as key data to be used as reference data; The hash of the generated reference data; and The generated hash is stored as a reference data in a portion of memory that is accessible to the HEL component but inaccessible to the LEL component.

14. The computing device according to claim 13, wherein, The processor is configured to execute processor-executable instructions to perform operations, such that scanning by the HEL component for at least a low anomaly level to collect data includes: the HEL component collecting LEL component data as reference data during the loading of the LEL component.

15. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform operations, the operations further including: Identify the key data currently in the working memory; Calculate the hash of the identified key data; and The calculated hash is compared with the corresponding reference data to determine whether at least one of the current VBA or system register values ​​matches the corresponding reference data.

16. The computing device according to claim 15, wherein, The processor is configured to execute processor-executable instructions to perform operations such that: Identifying critical data currently in working memory includes identifying critical read-execute (RX) code or critical read-only (RO) data currently present in working memory; as well as Comparing the calculated hash with the corresponding reference data involves comparing the calculated hash with the reference data hash stored in memory by the HEL component.

17. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform operations, the operations further including: Periodically call the HEL component to verify that the integrity of the LEL component has not been compromised.

18. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform operations, the operations further including: The HEL component is called periodically to verify that the integrity of the LEL component has not been compromised.

19. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform operations, the operations further including periodically invoking the HEL component based on at least one of the following to verify that the integrity of the LEL component has not been compromised: Machine interrupts that trigger cyclic execution; It features a random machine interrupt triggered by a pseudo-random table; or User-triggered machine interrupts with event-based triggering.

20. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform operations, the operations further including: Detect system calls or runtime events that could cause a change in the current anomaly level of the computing device; and In response to the detection of a system call or runtime event that could cause a change in the current level of anomaly of the computing device, the HEL component is invoked to verify that the integrity of the LEL component has not been compromised.

21. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform operations such that identifying at least one of the current VBA or CSR values ​​associated with an LEL component includes identifying at least the current VBA by performing one or more of the following: Read the vector base address register VBAR; Read the vector table base holder; Read the exception level vector base address register ELx_VBAR; Read the machine trap value register MTVAL; or Read the event vector base EVB; or Equivalent provisions in instruction set architecture based on hierarchical privilege levels.

22. The computing device according to claim 12, wherein, The processor is configured to execute processor-executable instructions to perform an operation such that determining whether at least one of the current VBA or CSR values ​​matches stored reference data includes using a reference data comparison set, which includes: Hash of key segments; VBA; or CSR value.

23. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of a computing device to perform operations, the operations including: Reference data is stored in a portion of the memory by the "HEL component" which operates at a high exception level. This reference data is accessible by the HEL component but not by the "LEL component" which operates at a low exception level. The HEL component identifies at least one of the current vector base address VBA or the control and system register CSR value associated with the LEL component; Determine whether at least one of the current VBA or CSR values ​​matches the stored reference data; and Execute a response action in response to determining that the current VBA or CSR value does not match the stored reference data.

24. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations, said operations further including: The HEL component scans for at least low-level anomalies to collect data. The collected data is marked as key data to be used as reference data; The hash of the generated reference data; and The generated hash is stored as a reference data in a portion of memory that is accessible to the HEL component but inaccessible to the LEL component.

25. The non-transitory processor-readable medium according to claim 24, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations such that the HEL component scans for at least a low level of anomalies to collect data, including: the HEL component collecting LEL component data as reference data during the loading of the LEL component.

26. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations, said operations further including: Identify the key data currently in the working memory; Calculate the hash of the identified key data; and The calculated hash is compared with the corresponding reference data to determine whether at least one of the current VBA or system register values ​​matches the corresponding reference data.

27. The non-transitory processor-readable medium according to claim 26, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations such that: Identifying critical data currently in working memory includes identifying critical read-execute (RX) code or critical read-only (RO) data currently present in working memory; as well as Comparing the calculated hash with the corresponding reference data involves comparing the calculated hash with the reference data hash stored in memory by the HEL component.

28. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations, said operations further including: Periodically call the HEL component to verify that the integrity of the LEL component has not been compromised.

29. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations, said operations further including: The HEL component is called periodically to verify that the integrity of the LEL component has not been compromised.

30. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations, said operations including periodically invoking the HEL component based on at least one of the following to verify that the integrity of the LEL component has not been compromised: Machine interrupts with loop execution triggers; It features a random machine interrupt triggered by a pseudo-random table; or User-triggered machine interrupts with event-based triggering.

31. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations, said operations further including: Detect system calls or runtime events that could cause a change in the current anomaly level of the computing device; and In response to the detection of a system call or runtime event that could cause a change in the current level of anomaly of the computing device, the HEL component is invoked to verify that the integrity of the LEL component has not been compromised.

32. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations such that identifying at least one of the current VBA or CSR values ​​associated with the LEL component includes identifying at least the current VBA by performing one or more of the following: Read the vector base address register VBAR; Read the vector table base holder; Read the exception level vector base address register ELx_VBAR; Read the machine trap value register MTVAL; or Read the event vector base EVB; or Equivalent provisions in instruction set architecture based on hierarchical privilege levels.

33. The non-transitory processor-readable medium according to claim 23, wherein, The stored processor-executable instructions are configured to cause the processor of the computing device to perform operations such that determining whether at least one of the current VBA or CSR values ​​matches corresponding reference data includes using a reference data comparison set, which includes: Hash of key segments; VBA; or CSR value.

Images