Method and system for executing security critical applications

Abstract

A method of executing a security critical application (150) on a hardware platform (100) is presented. The method comprises: executing a virtual machine monitoring program (120) having a monitoring component (130) for a security critical application (150) on a hardware platform (100); instantiating at least one virtual machine (140) by a privilege level of the virtual machine monitoring program (120) hardware platform that is lower than the privilege level of the virtual machine monitoring program (120); a list of one or more predefined actions is provided that, when executed by the processor core (112a, 112b), have relevance to the integrity and / or operation of the safety critical application (150). The method further comprises instructing, by the virtual machine monitoring program (120), the processor core (112a, 112b) to divert the control flow towards a respective handler (132) in the monitoring component (130) for the action to be performed when the action to be performed is about to be performed on the list; and executing at least the security critical application (150) over the guest operating system (142) in the at least one virtual machine (140). Further, a check of whether the action is allowed or not allowed may be performed, and / or at least one preparation for the action to be performed may be performed.

Description

Technical Field

[0001] This invention generally relates to the field of safety-critical applications. More specifically, the invention relates to a method for executing a safety-critical application on a hardware platform including at least one processor and / or processor core. Further, the invention relates to a computing system configured to perform the steps of such a method, one or more computer programs for instructing the computing system to perform the steps of such a method, and a machine-readable data carrier and / or downloadable product storing such one or more computer programs. Background Technology

[0002] Safety-critical applications are generally defined or understood as software applications or programs whose failure or malfunction is, at least in principle, likely to cause serious damage or injury, particularly to one or more of machinery, equipment, human health, and environmental health. In other words, failure of a safety-critical application may result in an increased safety risk to people, the machinery used, and / or the environment involved.

[0003] For example, safety-critical applications can run or be executed on so-called safety-critical systems, which may include computing systems running one or more software-based safety-critical applications, as well as more complex systems involving additional components such as one or more sensors, one or more actuators, and / or other hardware components. Exemplary safety-critical systems and corresponding applications for controlling and / or monitoring one or more components can be found in vehicle control systems, power plant control systems, manufacturing or production control systems, chemical plant control systems, building or facility control systems, and many other systems.

[0004] Various standards and recommendations have been defined for safety-critical applications and systems to ensure their correct or proper operation. Typically, such standards or recommendations are related to specific use cases and / or the equipment involved. For example, ISO standard 26262, recommended by the International Organization for Standardization (ISO), relates to safety-critical or safety-related systems, including electrical and / or electronic systems installed in passenger cars or road vehicles. These standards and recommendations provide a set of guidelines and / or safety measures that safety-critical applications and corresponding systems should meet to ensure their proper operation. Safety-critical applications or systems that conform to standards or recommendations can also be referred to as safety-qualified applications or systems. On the other hand, software applications or computing systems that do not conform to such standards (e.g., because they handle processes or functions that are not safety-critical or related) can be referred to herein as non-safety-critical applications.

[0005] In many software applications and corresponding computing systems or environments, safety-critical applications may run or execute in parallel, sequentially, or alternately with non-safety-critical applications, or more generally, they may coexist with applications that do not meet the safety level required for safety-critical applications. Alternatively or additionally, safety-critical applications may run on an OS or OS kernel that is not safety-qualified. Such systems are often referred to as hybrid critical systems or hybrid critical software systems. A hybrid critical system can be a complex software-based system in which different critical software applications or software components (including OS software, such as the OS kernel) can run on common hardware (e.g., one or more common processors), and the different applications come from different quality or safety levels, including at least one safety-critical application. This means that not all applications in a hybrid critical system comply with the quality assurance measures required or recommended by standards such as ISO 26262 and the highest safety level that any application should meet.

[0006] To ensure the proper functioning of one or more safety-critical applications in such hybrid critical systems, it is essential to ensure that software components with different quality and / or safety levels are free from interference. This freedom is typically achieved overall by guaranteeing application isolation in one or both spatial and temporal aspects, and specifically by preventing the propagation of faults between software components with different safety levels, which can be achieved or monitored using dedicated features of the underlying hardware.

[0007] For example, the isolation of an application's private memory can be protected by memory protection or a memory management unit (MMU), which can be implemented in the processor and can deliver information about obvious access violations. Other security measures may relate to context switching between programs or applications, which refers to the process of storing the state of processes, programs, threads, and / or applications so that that state can be restored and execution resumed at a later point in time. For safety-critical applications and mixed-critical systems, proper context switching may mean, for example, that the state of a safety-critical application should not be erroneously corrupted during context switching between a safety-critical application and a non-safety-critical application.

[0008] Software used to make the processor's proprietary features accessible to a hardware platform or computing system is typically encapsulated in a specialized program known as the operating system kernel (also referred to herein as the OS kernel or kernel). Generally, the kernel, OS kernel, and / or system kernel referred to herein can be considered a supervisor program, which may have an elevated level of privilege compared to other software components, programs, or software executing on top of the kernel. The correctness of the hardware features used may require the operating system kernel to operate correctly on the hardware. Therefore, the correct operation of safety-critical applications may depend on or be dependent on the correct operation of the operating system kernel software. Furthermore, this dependency can involve not only the software unit or kernel software operating the hardware features under consideration, but also all software code that may potentially affect the software unit under consideration, such as the entire OS kernel. In the presence of support for a single safety-related function that should be ensured by executing safety-critical applications, this leads to the common understanding that the operating system kernel as a whole should be qualified for use in a security context or should be monitored. Summary of the Invention

[0009] Therefore, it may be desirable to provide an improved method for executing safety-critical applications that overcomes the aforementioned drawbacks, and in particular, that allows for the secure execution of safety-critical applications on any operating system and / or operating system kernel.

[0010] This is achieved through the subject matter of the independent claims, wherein further embodiments are included in the dependent claims and the description below.

[0011] Various aspects of this disclosure relate to a method for executing a safety-critical application on a hardware platform, a computing system configured to perform the steps of such a method, one or more computer programs for instructing the computing system to perform the steps of such a method, and a machine-readable data carrier and / or downloadable product for storing such one or more computer programs. It should be emphasized that any features, functions, elements, and advantages described herein with reference to one aspect of this disclosure are equally applicable to any other aspect of this disclosure described herein.

[0012] According to one aspect of this disclosure, a method is provided for executing a security-critical application on a hardware platform including at least one processor core. The method includes the following steps: • Execute a hypervisor on a hardware platform, which includes monitoring components for the security-critical application; • The hypervisor instantiates at least one virtual machine at a lower privilege level on the hardware platform than the hypervisor's privilege level. • Provide a list of one or more predefined actions that, when executed by the processor core, have integrity and / or operational relevance for safety-critical applications; • By the hypervisor instruction processor core: when an action is about to be performed on the list, the control flow is redirected toward the corresponding handler in the monitoring component for the action to be performed; • Execute at least one security-critical application on top of a guest operating system in at least one virtual machine; and • When control flow is redirected to the handler for the action to be performed: ○ The processor checks whether the action to be performed is allowed or not according to a predetermined set of rules, and if the action to be performed is allowed, causes the action to be performed; and / or The processor performs at least one preparation for the action to be performed, and then causes the action to be performed to be executed.

[0013] The features and steps of the above-described methods synergistically ensure or allow the secure execution of safety-critical applications on a hardware platform on any guest operating system (“OS”), which includes, for example, any guest OS kernel, kernel software, or kernel components. In other words, the features and steps of the above-described methods can interact synergistically to ensure that safety-critical applications are free from interference (FFI) in one or both of space and time. Specifically, the methods of this disclosure can allow the secure execution of safety-critical applications without requiring software components of the guest OS (such as the entire guest OS kernel) to be security-qualified. Furthermore, this can allow the secure execution of safety-critical applications on a variety of different hardware platforms, where software components, and optionally hardware components, may not be security-qualified.

[0014] It should be emphasized that the methods and computing systems according to this disclosure can be advantageously used in security-qualified systems and / or hybrid critical systems. Therefore, this disclosure is not limited to this aspect. Furthermore, the invention can be advantageously used in conjunction with any kernel, including both security-qualified and non-security-qualified kernels, such as, for example, Linux-based kernels.

[0015] As used herein, the term "application" may refer to or include software applications or programs. As used herein, the term "application" is not necessarily limited to purely software applications, but may include software-based applications that may optionally include one or more interfaces for receiving sensor signals from one or more sensors and / or for sending one or more control signals to one or more actuators and / or other hardware components (control signals are used interchangeably with actuation signals herein).

[0016] To improve readability without loss of generality, this document may describe detailed specific technical implementations. Specifically, this disclosure refers to an operating system architecture with a kernel. However, as stated above, the kernel, OS kernel, and / or system kernel referred to herein can be considered a supervisor program that may have an elevated level of privilege compared to other software components, programs, or software executing on top of the kernel. Therefore, it will be understood by those skilled in the art that the general concepts described herein can be applied to various architectures, provided that the exception levels and / or privilege levels mentioned in this disclosure can be utilized.

[0017] As described above, the term "safety-critical application" is generally understood to be a software (software-based) application or program whose failure or malfunction is, at least in principle, likely to cause damage or injury, particularly to one or more of machinery, equipment, human health, and environmental health. On the other hand, a safety-related application or system can be defined or understood to include aspects not controlled by the respective safety-critical application or system, such as personnel operating the application or system. Because this disclosure focuses on aspects related to software-based safety-critical applications and / or corresponding computing systems, the terms "safety-critical application or system" and "safety-related application or system" may be used interchangeably or synonymously herein. In other words, in the context of this disclosure, the term "safety-critical" may include or refer to "safety-related," and vice versa.

[0018] In various instances, this disclosure may refer to a processor, which can typically be implemented as a single-core or multi-core central processing unit (CPU) having one or more cores or processor cores, which can be used to run an operating system. However, this disclosure is not limited to this aspect, but can also be applied, for example, to multiprocessor hardware with shared memory. Therefore, the terms "processor," "processor core," and "core" may be used synonymously herein.

[0019] As used herein, a hardware platform may refer to or include a data processing platform or processing circuitry system, which may include or refer to, for example, a CPU having one or more processor cores for data processing, or it may refer to a multiprocessor architecture. Any reference to a single processor or processor core may include references to multiple processors or processor cores. Furthermore, this disclosure is not limited to a particular processor architecture but can be applied to processors of any type or architecture, such as ARM, x86, RISC, etc., including shared-memory multiprocessor architectures.

[0020] A hardware platform may include optional components and / or provide optional hardware resources for data processing, such as physical memory (e.g., random access memory), cache memory, and / or other components. A hardware platform may be implemented in, and / or may be part of, the computing system described herein. Therefore, the terms "hardware platform" and "computing system" may be used interchangeably or synonymously herein.

[0021] Executing a hypervisor on a hardware platform can refer to or include running a hypervisor on at least one processor core and optional other components or hardware resources of the hardware platform. Alternatively or additionally, executing a hypervisor can include activating the hypervisor on at least one processor core of the hardware platform.

[0022] A hypervisor can generally refer to or represent a supervisory software component that allows monitoring components to execute on a processor, processor core, and / or hardware platform. A monitoring component can refer to a supervisory software element or supervisory component of a hypervisor. A monitoring component can refer to or represent supervisory software or components configured to monitor the execution of security-critical applications. In other words, the term "monitoring component" can refer to a software component capable of implementing error detection and / or error indication. While this definition may correspond to an established understanding in security engineering, it can deviate from the understanding of the term "monitor software" in the context of an operating system as a component or program used to control or schedule processes and other programs.

[0023] Hypervisor and / or its monitoring components can be configured to monitor, identify, and / or validate the secure execution of security-critical applications. For example, hypervisor and / or its monitoring components can be configured to analyze the control flow of the processor (core) and / or one or more actions associated with or involving one or more hardware resources of the hardware platform, such as physical memory, cache, and / or processor buffers.

[0024] The hypervisor can be further configured to instantiate at least one virtual machine. In other words, the hypervisor can be configured to create at least one instance of at least one virtual machine, for example, according to one or more predefined specifications for one or more virtual machines. Optionally, instantiating at least one virtual machine may include, for example, providing one or more virtual hardware resources to at least one virtual machine according to one or more predefined specifications. Alternatively or additionally, instantiating at least one virtual machine may include mapping one or more physical hardware resources (such as physical memory of the hardware platform) of a hardware platform (e.g., at least one processor, processor core, and / or other resources) to one or more virtual hardware resources for the at least one virtual machine.

[0025] Alternatively or additionally, instantiating at least one virtual machine may include booting and / or executing a guest operating system or the operating system of the virtual machine. This may include running a guest operating system kernel or the kernel software of a guest operating system. Therefore, references to a guest operating system herein may include references to a guest operating system kernel, and vice versa.

[0026] It is important to emphasize that this disclosure is not limited to a specific type of guest operating system and / or guest operating system kernel, but can be used for any guest operating system and / or guest operating system kernel. Specifically, the guest OS and / or guest OS kernel can be security-qualified or security-unqualified. Alternatively or additionally, the guest OS kernel can be a monolithic kernel, a modular kernel, or a combination thereof. Alternatively or additionally, the guest OS and / or guest OS kernel can be proprietary or can be at least partially based on open source. For example, the guest OS can be Linux-based, and / or the guest OS kernel can be a Linux-based kernel.

[0027] One or more security-critical applications may run on top of a guest operating system. At least one virtual machine may provide a virtual computing environment with one or more virtual hardware and / or software resources, such as, for example, a guest OS and / or a guest OS kernel. The execution of one or more security-critical applications on top of the guest OS may refer to or include running the one or more security-critical applications within the guest OS provided by the virtual machine. Therefore, one or more functions of the security-critical applications may involve and / or be controlled by the guest OS and / or the guest OS kernel.

[0028] As is generally understood, different privilege levels can define different sets of permissions or actions allowed to be performed by the corresponding components, where a higher privilege level includes more permissions compared to a lower privilege level. By providing or executing a hypervisor with a higher privilege level than at least one virtual machine and therefore at least one security-critical application running therein, it can be ensured that the hypervisor and / or its monitoring components can take over control of at least one virtual machine, the guest OS, the guest OS kernel, and / or any processes or applications (including at least one security-critical application) running on top of its guest OS. For example, the hypervisor and / or its monitoring components can take over control of at least one virtual machine's access to resources or components of the hardware platform.

[0029] Typically, a virtual computing environment can be created and / or controlled by a hypervisor by instantiating at least one virtual machine and executing a security-critical application on its guest OS. This hypervisor maps the physical hardware resources of the hardware platform to and / or associates with the virtual resources of the virtual machine, the guest OS, the guest OS kernel, and the processes, programs, and applications running within them, including at least one security-critical application. Furthermore, due to the higher privilege level of the hypervisor, the monitoring component can comprehensively monitor and / or analyze any actions and / or events associated with the security-critical application, the guest OS, and / or the guest OS kernel. This, in turn, allows for the detection of one or more actions and / or events that may potentially affect the proper operation or secure execution of the security-critical application, and optionally, the execution of countermeasures to ensure the secure execution of the security-critical application.

[0030] Such actions (or, synonymously, events) that may potentially affect the proper functioning of a safety-critical application may be referred to herein as actions and / or events that are relevant to the integrity and / or operation (e.g., security execution) of the safety-critical application. This may include any action or event that may interfere with or affect the execution of the safety-critical application or a portion thereof, such as modifying virtual resources utilized by the safety-critical application and / or causing a destructive state of the safety-critical application.

[0031] One or more such actions and / or events may be defined and included in a “predefined action list.” In the context of this disclosure, the predefined action list may refer to a single action or multiple actions (respectively events) that may directly and / or indirectly affect the performance of a safety-critical application. This list may be provided in summary form, and providing this list may be intended or construed as defining one or more actions that may have relevance to the integrity and / or operation of a safety-critical application.

[0032] This list can be defined and / or stored as a data register or structure, for example, maintained and / or accessible by a hypervisor and / or its monitoring components. Alternatively or additionally, the list can be defined based on the configuration of at least one processor core (e.g., one or more MMUs or their registers).

[0033] As will be further discussed below, in exemplary and non-limiting embodiments, the predefined list of actions may be included in or associated with memory registers in or to the physical memory or memory address space of the hardware platform, and / or included in or associated with page table trees in or to the virtual memory or memory space used to map physical memory or memory space to at least one virtual machine. However, other data structures and / or control means may be used alternatively or otherwise.

[0034] A hypervisor and / or its monitoring components can be configured to analyze the control flow of a processor and / or processor core. The control flow of a processor and / or processor core can refer to the order in which individual statements, instructions, and function calls of one or more software components or applications are executed and / or evaluated by at least one processor and / or processor core of the hardware platform.

[0035] Furthermore, the hypervisor and / or its monitoring components can be configured to detect actions on a predefined list of actions and / or actions scheduled and / or about to be executed based on analysis of control flow. Therefore, in the context of this disclosure, an action "to be executed" on a list can be associated with an action defined according to or included in that list, which is scheduled for execution and / or evaluation by at least one processor core or hardware platform in general.

[0036] For example, one or more criteria or conditions for each action in an action can be defined by or based on a predefined list of actions, and based on determining whether one or more criteria or conditions for a single action are met, the hypervisor and / or monitoring component can identify or detect the action as an action to be executed on the list and redirect control flow toward the corresponding handler for that action. Redirecting control flow via the hypervisor can include taking over control of the control flow and directing it toward or toward the corresponding handler of the monitoring component associated with that action on the list.

[0037] A handler can refer to a software component including routines that can be specifically associated with one or more actions and / or events defined by a list, and can be configured to trigger a predefined response in response to the occurrence of the one or more actions and / or events. Therefore, once one or more actions and / or events defined by the predefined action list occur, the handler can specify a particular response or subsequent action or step to be triggered. It should be noted that a handler can be responsible for associating with a single action or multiple actions on the predefined action list and / or with a single action or multiple actions on the predefined action list. Therefore, a monitoring component can maintain or include one or more handlers associated with one or more actions defined in the predefined action list.

[0038] Based on redirecting control flow to the appropriate handler and based on a predetermined set of rules, the monitoring component and / or handler can be configured to determine whether to allow or disallow the execution of an action. For example, actions that can be performed without affecting safety-critical applications or incurring any risk of affecting them can be allowed, while actions that may affect the operation of safety-critical applications can be disallowed. Typically, the predetermined set of rules can define one or more criteria or conditions for each action. The handler can be configured to detect whether one or more conditions or criteria are met to determine and / or check whether the action should be allowed and permitted, or whether the action should be disallowed and whether execution should be blocked. Optionally, the handler of the monitoring component can be configured to cause the action to be performed or implemented. This can include the actual execution of the action on the hardware platform.

[0039] Alternatively or additionally, in addition to the processor checking whether the action to be performed is permitted or not according to a predetermined set of rules, the processor may also be configured to perform at least one preparatory step for the action to be performed, and then cause the action to be performed. Causing the action to be performed may include scheduling the action to be executed on at least one processor core. For example, such preparatory steps may involve preparing (computational) resources, such as virtual and / or physical computing resources, to ensure the secure execution of security-critical applications, as will be discussed in more detail below.

[0040] By executing a security-critical application on a guest OS within a virtual machine (instantiated by a hypervisor with a higher privilege level), the control flow of the processor (core) can be understoodably monitored and analyzed by the monitoring component and / or one or more of its handlers. This enables the monitoring component and / or one or more handlers to reliably detect and / or identify one or more actions (e.g., defined by or based on a predefined list of actions) that may be relevant to the security-critical application and / or may affect its execution. Furthermore, based on a predefined rule set of one or more handlers, it can be reliably determined whether a particular action can be performed without affecting the security-critical application. Alternatively or additionally, based on a predefined rule set of one or more handlers, it can be determined whether a particular action should be suppressed, for example, because the security-critical application might be compromised by the execution of that action. Alternatively or additionally, preparatory measures or preparatory steps can be initiated by the monitoring component and / or one or more handlers to ensure that a specific action to be performed can be safely performed (i.e., without affecting or compromising the security-critical application). In general, this concept provides a secure execution environment for running security-critical applications on a guest OS and / or guest OS kernel. Specifically, it ensures that security-critical applications are protected from interference from any processes or software components running in the guest OS (including the guest OS kernel) and from any processes that can be executed by the OS guest kernel. Thus, secure execution can be guaranteed or ensured without requiring the entire guest OS and / or guest OS kernel to be security-qualified.

[0041] Consequently, the effort and cost involved in qualifying the guest OS and / or guest OS kernel for security can be avoided, and secure applications can be executed securely without inferring further restrictions or requirements on the guest OS, guest OS kernel, and the underlying hardware of the hardware platform. Therefore, security-critical functionality can be integrated into generally available computing infrastructure, and such functionality can be retrofitted to existing systems. Thus, the methods disclosed herein can be particularly advantageous for hybrid-critical systems, but are not limited thereto.

[0042] In the following description, with reference to a hybrid critical system, some of the benefits achievable using the methods of this disclosure are illustrated and summarized by way of example, using an unqualified or security-unqualified guest OS and / or guest OS kernel that hosts security-critical applications. It should be emphasized that this disclosure is not limited to the use of hybrid critical systems and / or security-unqualified kernel software, but can be advantageously used, for example, in purely security-critical systems employing a security-qualified guest OS and / or guest OS kernel.

[0043] Typically, any (guest) OS kernel or guest OS used to host a safety-critical application can contribute to one or more safety-critical functions handled by that application. As mentioned above, to ensure the safe execution of a safety-critical application, it should be protected from interference between the guest OS, the kernel, and / or any other software components running on the guest OS or kernel.

[0044] Security qualification is already challenging and expensive for open-source software with a distributed and unspecified software development model. However, when it comes to open-source monolithic operating system kernels like the Linux kernel (which consists of millions of lines of code), qualification in the sense of the ISO 26262 standard may become practically infeasible, for example. Therefore, it is common sense that using arbitrary guest OS kernels in a security context is impractical, as this would require freezing the version and performing extensive qualification activities as recommended by standards like ISO 26262.

[0045] The methods described herein can ensure or guarantee protection against interference by providing comprehensive monitoring and control capabilities to one or more handlers of a hypervisor, monitoring, and / or monitoring components. For example, this can allow the isolation of computing resources (e.g., virtual / physical hardware resources, such as memory pages and / or software-based resources used by safety-critical applications) from the guest OS, the guest OS kernel, and / or other software processes executing within it. This, in turn, can allow unqualified OS kernel software (such as the Linux kernel) to be used on a guest OS in which safety-critical applications are executed.

[0046] Non-limiting examples of spatial isolation of computing resources may include, for instance, spatial isolation between memory used by security-critical applications (e.g., private virtual memory) and user processes running unsecured code, and / or between the underlying unsecured (guest) operating system or kernel. The latter property can be difficult to establish because the OS kernel typically has access to all resources usually used to isolate processes from other processes or even itself. To achieve this property, the methods of this disclosure leverage the benefits of virtual computing environments. For example, a virtualization mode of at least one processor core or hardware platform can be used for this purpose. Combined with a high privilege level of the hypervisor (exceeding the privilege level of any virtual machine in the virtual computing environment), the execution of the monitored components and the ability to redirect control flow to one or more processors can be ensured. Optionally, the hypervisor may be at least partially secure.

[0047] A hypervisor can be viewed as regulatory software, such as a meta-operating system or a hypervisor kernel, which is active on at least one processor core and allows the execution of monitoring components. In a non-limiting example, a hypervisor mode on at least one processor core can be used to execute the hypervisor, where the hypervisor code can be limited to, for example, a few thousand lines of code, making it accessible to any security or security qualifications. This ensures protection against interference from the OS kernel and one or more other processes based on or using the kernel.

[0048] Such immunity to interference cannot be achieved using any conventional system or security feature. For example, the Privileged Access Never (PAN) feature of modern ARM processors, or its software-based counterpart (SW-PAN) emulating the PAN feature, is available in mainline Linux with the ARM64_SW_TTBR0_PAN kernel configuration option. However, the goal of the PAN feature is to prevent unintended privileged access to non-privileged user memory, for example, from the Linux kernel running at exception level 1 (EL1) to secure applications running at exception level 0 (EL0). However, the PAN feature cannot isolate different user processes, and it will still allow the guest OS kernel to intentionally access user memory space using specialized instructions like LDTR and STTR. Therefore, the PAN and / or SW-PAN features of conventional systems are insufficient to allow the secure execution of security-critical applications.

[0049] Similarly, traditional systems or technologies may be based on memory integrity features (also known as hypervisor-protected code integrity or hypervisor-enforced code integrity), which implement hypervisor-based protection of OS kernel memory pages, preventing execution of those memory pages until code integrity is successfully checked, and preventing writes to executable memory pages. However, this approach is based on the assumption that only integrity-verified and / or security-qualified kernel code can be executed. Therefore, this approach may also be insufficient to ensure the secure execution of security-critical applications on the guest OS kernel.

[0050] Compared to the conventional methods or techniques described above for isolating computing resources, the method of this disclosure can ensure, for example, memory isolation, between a guest OS and / or guest OS kernel and a security-qualified application (at least one security-critical application, respectively) running in user space above the kernel by implementing a monitoring component executed on or by a hypervisor—the hypervisor having a higher privilege level than a virtual machine running a non-security-qualified guest OS and guest OS kernel. The hypervisor may optionally be security-qualified.

[0051] According to an embodiment, the actions to be performed on the predefined action list include the switching of control flow between the security-critical application and the guest operating system. In other words, the actions to be performed may include or involve context switching between the security-critical application and the guest operating system. This may include context switching or switching of control flow from the security-critical application to the guest OS and / or context switching from the guest OS to the security-critical application.

[0052] As described above, context switching and / or the corresponding control flow transition may include storing the state of a process, program, thread, and / or application so that the state can be restored and execution resumed at a later point in time. Therefore, storing and / or loading the state to resume execution, for example when a disruptive process corrupts the state, could, in principle, carry the risk of impacting safety-critical applications. Therefore, by defining such actions on a predefined list of actions and instructing the hypervisor to redirect control flow to the appropriate handler, context switching can be performed safely or without affecting safety-critical applications.

[0053] According to embodiments, the processor can be configured to identify and / or detect the transition of control flow between the safety-critical application and the guest operating system as an action to be performed, and prepare for the transition of control flow between the safety-critical application and the guest operating system as the action to be performed. This preparation may include changing access permissions to at least one resource (also referred to herein as a computing resource) used by the safety-critical application. It should be noted that unless explicitly specified, resources and / or computing resources may refer to virtual resources and / or physical resources. Furthermore, any such resource may include memory (memory and memory pages are used interchangeably) and / or processor processing resources. Therefore, computing resources may include, for example, virtual resources (such as virtual memory (virtual private memory and / or shared memory) and / or virtual processing resources), physical computing resources, and software-based resources.

[0054] For example, changing access permissions may involve applying appropriate settings in one or more memory pages and / or memory registers. By changing access permissions to at least one resource, it can be ensured that context switches can be reliably detected by the monitoring components and / or hypervisor, and that control flow can be reliably redirected to the hypervisor, its monitoring components, and / or appropriate handlers. Therefore, it can be ensured that context switches do not impair or otherwise affect the execution of security-critical applications.

[0055] According to an embodiment, the action to be performed is related to the transition of control flow from the safety-critical application to the guest operating system, wherein preparation for the transition of control flow from the safety-critical application to the guest operating system as the action to be performed includes disabling or disabling write access to memory pages used by the safety-critical application. The memory pages of the safety-critical application may refer to virtual memory or memory space, private memory, and / or shared memory allocated to and used for executing the safety-critical application.

[0056] Disabling write access can, for example, involve applying appropriate settings to one or more memory pages and / or memory registers, such as setting the memory page to non-writable and / or read-only. By disabling write access to memory pages, it can be ensured that any attempt by any process, such as those executed by the guest OS and / or guest kernel, to trigger an exception can cause, trigger, and / or instruct the hypervisor to take over control of the flow of control and redirect it to the monitoring component and / or the appropriate handler. Therefore, it can be ensured that context switching cannot impair or otherwise affect the execution of safety-critical applications.

[0057] Specifically, by disabling write access to prepare for context switching, spatial and / or temporal memory isolation can be ensured, thereby ensuring that the guest OS and / or guest OS kernel cannot change or modify memory pages used by safety-critical applications during context switching, and / or any such attempts can be reliably detected by monitoring components.

[0058] According to an embodiment, the actions to be performed are related to the transition of control flow from the guest OS and / or the guest OS kernel to a safety-critical application, wherein preparation for the transition of control flow from the guest OS to the safety-critical application includes allowing or enabling write access to memory pages used by the safety-critical application. By allowing or enabling write access to memory pages allocated to or used by the safety-critical application, it can be ensured that the safety-critical application can resume execution, for example, based on loading its previous state from the memory pages.

[0059] According to an embodiment, the method further includes: making at least one memory region writable when access to memory pages is prohibited, the memory region being designated for data transfer between a security-critical application and a guest operating system. This at least one memory region may, for example, include shared memory dedicated to data exchange between the security-critical application and the guest OS and / or kernel, which may be necessary in certain scenarios or use cases. For example, access to data from other hardware and / or software components may be provided to the security-critical application. Such shared memory may optionally be verified by the security-critical application or be accessible only for non-security-related functions provided by the security-critical application, such that making at least one memory region writable does not impair or otherwise affect the execution of the security-critical application.

[0060] According to an embodiment, in addition to disabling write access to memory pages, access to one or more page tables and / or page table trees (PTTs) maintained in the virtual machine is also modified. Modifying and / or changing access to one or more page tables and / or page table trees can, for example, involve applying appropriate settings in one or more page tables, one or more levels of the page table tree, and / or one or more PTTs. This ensures proper isolation of hardware resources and protection from interference.

[0061] Typically, a page table refers to a data structure used by the virtual memory system in a computer operating system to store, for example, the mapping between virtual memory addresses and the physical memory of a hardware platform in the form of one or more page table entries in a page table and / or page table tree. Optionally, the page table may store permission settings and / or other settings regarding memory access, and / or be associated with such permission settings and / or other settings. Page tables may be further arranged or structured in a hierarchical manner as a multi-level or multi-stage page table tree. In a multi-level page table, page table entries of level 1 page tables may be pointers to level 2 page tables (trees), and entries of level 2 page tables (trees) may be pointers to level 3 page tables (trees), and so on. The entries of the last-level page tables (trees) store the actual frame information of the memory, and level 1 page tables (trees) typically contain single-page tables, and the addresses of these tables are typically stored in the page table base address register (PTBR). In the case of modern ARM-based processors, pointers to the PTT may be stored in translation table base address registers 0 and / or 1 (referred to as TTBR0 and TTBR1). However, as stated above, this disclosure is not limited to a specific processor architecture. When virtualization is used, for example, through a hypervisor, different stages of address translation may be involved. For example, the hypervisor may be responsible for the second stage of address translation using Stage 2 PTT, while within the virtual machine, the guest OS may be responsible for the first stage of address translation using Stage 1 PTT.

[0062] According to an embodiment, in addition to prohibiting write access to memory pages, access to the Stage 1 Page Table Tree (PTT) maintained in the virtual machine is also prohibited. Prohibiting access to the Stage 1 PTT can, for example, involve applying appropriate settings in the Stage 1 PTT and / or base addresses or memory registers. For example, the Stage 1 PTT can be set to non-readable, non-writable, and / or non-executable. By prohibiting access to the Stage 1 PTT, any attempt by any process, such as those executed by the guest OS and / or guest kernel, to access the Stage 1 PTT can trigger an exception that can cause, trigger, and / or instruct the hypervisor to take over control of the control flow and redirect it to the monitoring component and / or the appropriate handler.

[0063] Furthermore, any modifications to the Phase 1 PTT can be effectively blocked, thereby ensuring the integrity of the Phase 1 PTT and its availability to safety-critical applications. Specifically, by disallowing access to the Phase 1 PTT and / or one or more levels of the Phase 1 PTT, it can be effectively ensured that the memory space pointed to by one or more page table entries of the Phase 1 PTT, one or more levels thereof, and / or one or more PTTs of higher phases (such as the Phase 2 PTT) (and / or one or more levels of the Phase 2 PTT) cannot be accessed by components running at low privilege levels, but can only be accessed by hypervisors running at high privilege levels. Thus, the physical memory allocated to safety-critical applications via the page table tree and one or more of its phases can be reliably isolated, thereby ensuring the secure execution of safety-critical applications.

[0064] According to the embodiment, in addition to allowing write access to memory pages, access to the Stage 1 Page Table Tree (PTT) maintained in the virtual machine is also permitted. By allowing access to the Stage 1 PTT, access to physical memory can be provided. This ensures that actions that could compromise safety-critical applications and / or the safety-critical applications themselves cannot be performed.

[0065] According to an embodiment, the instruction processor core redirects control flow and / or disables or enables access to memory pages by modifying the Stage 2 Page Table Tree (PTT) maintained by the hypervisor for virtual machines.

[0066] In an exemplary embodiment, stage 2 page tables (PTs) and / or page table trees may be maintained in and / or by a hypervisor for at least one virtual machine, and stage 1 page tables and / or page table trees may be maintained in and / or by the virtual machine. Optionally, one or more of stage 1 and stage 2 PTs and / or PTTs may have one or more PTT levels. Therefore, allowing or disallowing access to stages of PTs / PTTs may include allowing or disallowing access to one or more levels of the corresponding stages of PTs / PTTs. Further, the instruction processor core directing control flow and / or disallowing or allowing access to memory pages may include modifying one or more settings of stage 2 PTs and / or PTTs such that modifications to stage 1 PTs and / or PTTs are disabled or permitted in at least one virtual machine.

[0067] In the example, modifying the Phase 2 PTT may include modifying one or more page table entries of the Phase 2 PTT or one or more levels of the Phase 2 PTT, for example, causing the physical and / or virtual memory addresses mapped to the corresponding one or more page table entries to be modified / changed. Such modifications to the Phase 2 PTT, one or more of its levels, and / or one or more of its page table entries can allow switching of physical and / or virtual memory used by the guest OS and / or safety-critical applications, and thus provide an efficient means of hardware or memory isolation, for example, when a context switch occurs between the guest OS or other software processes running on it and a safety-critical application.

[0068] Alternatively or additionally, modifying the Phase 2 PTT may include modifying access permissions for one or more page table entries and / or one or more levels of the Phase 2 PTT. For example, modifying access permissions may include setting the Phase 2 PTT to at least one of non-writable, non-readable, non-executable, writable, readable, and executable, as discussed further below.

[0069] In an exemplary embodiment, after modifying the Phase 2 PTT on one of the processor's multiple cores, the Translation Lookaside Buffer (TLB) of the other cores is flushed. This prevents other cores from using PTT entries with outdated address mappings or licensed caches, and thus prevents accidental access to or modification (e.g., writing to) of memory used by safety-critical applications.

[0070] Providing a predefined list of actions can include, for example, activating one or more traps on a processor and / or processor core by the hypervisor and / or its monitoring components to redirect control flow to the appropriate handler. In other words, capturing at least one processor and / or processor core (also known as hardware root capture or hardware-assisted capture) can be used to capture control flow and / or redirect control flow to the hypervisor, its monitoring components, and / or the appropriate handler for the action to be performed. Typically, a trap can be considered a condition or criterion that triggers an exception when met, which can be detected by the hypervisor and / or its monitoring components. In other words, a trap and / or the corresponding exception can cause and / or instruct the hypervisor to take over control of the control flow and redirect control flow to the monitoring components and / or the appropriate handler. Therefore, capture can provide a reliable tool for reliably detecting any action on the predefined list of actions, such as a context switch between a safety-critical application and a guest OS.

[0071] Optionally, capturing and / or redirecting control flow to the hypervisor may include, trigger, and / or be accompanied by the exit of at least one virtual machine, which may be detected by the monitoring component, for example, based on the corresponding exit signal or status code of the virtual machine. Exiting at least one virtual machine, the corresponding exception, and / or trap may allow the invocation of associated functions of the monitoring component and / or the corresponding handler.

[0072] In an exemplary implementation, trapping and / or redirecting of control flow can be triggered by applying appropriate settings in a page table tree (e.g., a Stage 2 page table tree (PTT) maintained by a hypervisor for running security-critical applications). Alternatively or additionally, traps can be generated at least partially programmatically, for example via a so-called Hypervisor Call (HVC), and / or whenever a guest OS attempts to overwrite the contents of specific core registers, processor cores, and / or memory pages (virtual and / or physical memory pages) that should be protected. An example of such memory pages is memory pages protected by other Stage 2 Memory Management Units (MMU-protected) memory pages.

[0073] In exemplary implementations, different phases of the PTT can be stored in different locations and / or maintained by different entities or components, for example, to further improve or increase hardware isolation. For instance, Phase 1 PTT can be maintained and / or stored at the application or guest OS level (e.g., at the security-critical application and / or guest OS level), while Phase 2 PTT can be stored and / or maintained at the hypervisor. Disposing of Phase 2 PTT or higher at the hypervisor, which has a higher privilege level than the virtual machine, can allow for effective control over access to physical and / or virtual memory, and thus allows for more comprehensive control over the control flow and improved hardware isolation.

[0074] According to an embodiment, the action to be performed includes setting up a new security-critical application by the guest operating system. Setting up a new security-critical application may include, for example, configuring the security-critical application with respect to one or more virtual and / or physical resources provided to the security-critical application for its execution. Alternatively or additionally, setting up a new security-critical application may include creating and / or providing a secure execution environment for the security-critical application based on the configuration of one or more virtual and / or physical resources provided to the security-critical application for its execution. Including setting up a new security-critical application as an action on a predefined list of actions (which can trigger a redirection of control flow to the hypervisor) can ensure that the hypervisor and / or monitoring components are aware of any new security-critical applications running in one or more virtual machines on the hardware platform. Therefore, proper monitoring and secure execution of the new security-critical application can be ensured.

[0075] According to an embodiment, preparation for the action to be performed includes allowing write access to memory pages to be used by the new security-critical application. In other words, the hypervisor, monitoring components, and / or the corresponding handlers for the action to be performed may allow the guest OS and / or guest OS kernel to populate memory pages for the new security application to be configured. For example, this may involve appropriate settings for different PTT levels, which may affect Phase 1 PTT and / or Phase 2 PTT. Optionally, the hypervisor, monitoring components, and / or the corresponding handlers may keep track of new memory pages added to the Phase 1 PTT for the new security application.

[0076] According to embodiments, in addition to allowing write access to memory pages used for new safety-critical applications, code execution within those memory pages is also prohibited. This could involve, for example, appropriate settings for different PTT levels, which could affect Phase 1 PTT and / or Phase 2 PTT. Disallowing code execution within memory pages used for new safety-critical applications ensures reliable detection and prevention of any attempts to execute code by any process, such as from the guest OS and / or the guest OS kernel, thereby ensuring that no interference with resources provided to the safety-critical application is included or modified during the startup of the new application. For example, execution permission could be removed in Phase 2 PTT, which could also be used to enforce traps on the hypervisor when the new safety-critical application begins execution, for example, to detect when the startup process of the safety-critical application is complete.

[0077] Alternatively or additionally, after the setup of a new safety-critical application is complete, code execution can be permitted in that memory page. This could, for example, involve applying appropriate settings in one or more stages of a PTT (Performance Time Limit). Specifically, a memory page referenced in the final stage of a PTT (such as stage 2 PTT) can be set to executable. Therefore, after the new safety-critical application is fully set up and, for example, loaded, code execution can be permitted in the memory page allocated to the new safety-critical application, thus ensuring that the new safety-critical application can be executed.

[0078] According to an embodiment, in response to a control flow being redirected to a handler (for and / or due to an attempt by the guest OS to execute code in a non-executable memory page of a safety-critical application), it is determined that the control flow is being redirected to the guest OS, respectively, for the safety-critical application. As discussed above, setting a memory page to non-executable ensures that any attempt by any process of the guest OS and / or the guest OS kernel to execute code in that memory page is captured and / or results in an exception. Such capture and / or exception can further indicate that a context switch is occurring, which can instruct or cause monitoring components and / or corresponding handlers to analyze and / or inspect the control flow to determine whether an action can be permitted and / or whether preparatory steps should be performed to allow the action to be performed.

[0079] According to an embodiment, the method further includes executing at least one other application on top of a guest operating system within at least one virtual machine. This at least one other application may be a non-security-qualified application and / or have a lower security level than the security-critical application. Therefore, the method can be executed in a hybrid-critical system, and / or a security-critical application can be executed in a hybrid-critical system. Specifically, in such systems, the methods described herein can reliably ensure protection against interference, although this disclosure and method are not limited to this aspect.

[0080] Furthermore, it should be noted that multiple virtual machines can be instantiated or configured on the hardware platform and monitored by a hypervisor, with each virtual machine running one or more security-critical applications and / or one or more non-security-critical applications. Optionally, multiple hypervisors and / or monitoring components can be utilized.

[0081] According to an embodiment, the method further includes: processing measurement data acquired by at least one sensor into an actuation signal or control signal by a safety-critical application, and actuating at least one land vehicle, air vehicle, or sea vehicle, at least one robot, and / or any component thereof with the actuation signal. In other words, based on measurement or sensor data from one or more sensors, the safety-critical application can determine an actuation signal to actuate at least one component of a land vehicle, air vehicle, or sea vehicle and / or at least one robot, which can be any type of robotic device. For example, the output of the safety-critical application may include an actuation signal that can actuate one or more display components in the vehicle.

[0082] A further aspect of this disclosure relates to a computing system comprising a hardware platform having one or more processors and / or processor cores and (physical and / or virtual) memory for data storage. The computing system is configured to perform the steps of the methods described above and below. It should be emphasized that any step, feature, function, and / or element described herein with reference to the method can be a feature, function, and / or element of the computing system, and vice versa.

[0083] Another aspect of this disclosure relates to one or more computer programs including machine-readable instructions that, when executed by a computing system, cause the computing system to perform the steps of the methods described above and below, and / or cause the computing system to perform the role of a monitoring component in the context of the methods described above and below.

[0084] A further aspect of this disclosure relates to a non-transitory machine-readable data carrier and / or download product having and / or storing one or more computer programs including machine-readable instructions that, when executed by a computing system, cause the computing system to perform the steps of the methods described above and below, and / or cause the computing system to perform the role of a monitoring component in the context of the methods described above and below. Attached Figure Description

[0085] These and other aspects of the invention will become apparent and further elucidated by referring to the embodiments described by way of example in the following description and by referring to the accompanying drawings, in which... Figure 1 A flowchart illustrating an exemplary computer implementation of a method for executing a security-critical application on a hardware platform is shown; Figure 2 A block diagram illustrating an exemplary hardware platform and method for performing safety-critical applications is shown; and Figures 3 to 5 Each shows a flowchart illustrating an exemplary computer implementation of a method for executing a security-critical application on a hardware platform.

[0086] In the accompanying drawings, elements corresponding to those already described may have the same reference numerals. Examples, embodiments, or optional features, whether or not indicated as non-limiting, should not be construed as limiting the invention as claimed. Detailed Implementation

[0087] Figure 1 The diagram shows the hardware platform (e.g., reference) Figure 2 A flowchart illustrating an exemplary computer implementation of a method for executing a safety-critical application on a hardware platform 100.

[0088] Figure 2 A block diagram illustrating an exemplary hardware platform 100, computing system 500, and method for performing a safety-critical application 150 is shown. References are made, mutually or jointly, below. Figure 1 and Figure 2 .

[0089] like Figure 2 As shown, the hardware platform 100 includes a processing circuitry system 110: a central processing unit (CPU) 110 and / or a processor 110, which includes two processor cores 112a and 112b. The hardware platform 100 may include a single processor core 112a or more than two processor cores 112a and 112b.

[0090] The hardware platform 100 further includes a physical data storage device 114 or a memory 114. The memory 114 can be any type of hardware-based memory, such as random access memory or other types, which can be used as a computing resource by the processing circuitry system 110.

[0091] Hardware platform 100 may be embodied in and / or be part of computing system 500, which may include optional other components 520, 540, such as one or more communication interfaces 520 and / or one or more other data storage devices 540. One or more other components or entities may be communicatively and / or operatively coupled to computing system 500, and correspondingly, to hardware platform 100, via one or more communication interfaces 520. For example, one or more sensors 522 may be coupled to one or more communication interfaces 520 to provide sensor signals. Alternatively or additionally, one or more actuators 524 may be coupled to one or more communication interfaces 520, for example, to receive one or more control or actuation signals from computing system 500 and / or hardware platform 100.

[0092] Hardware platform 100 further includes a hypervisor 120 having a monitoring component 130 and one or more processors 132. Additionally, hardware platform 100 includes at least one virtual machine 140 running a guest operating system 142 and / or a guest operating system kernel 142. On top of the guest OS 142, one or more security applications 150 are executed, and optionally one or more non-security-critical applications 160 are executed.

[0093] The OS kernel 142 can be, for example, based on a Linux kernel. Furthermore, more than one virtual machine 140 can run. Figure 1 The flowchart further illustrates the functionality of the hypervisor 120 in conjunction with the virtual machine 140 and the safety-critical application 150.

[0094] In step S1, Figure 1 The method shown includes executing a hypervisor 120 on a hardware platform 100, the hypervisor 120 including a monitoring component 130 for one or more security-critical applications 150.

[0095] In step S2, the method includes instantiating at least one virtual machine 140 by hypervisor 120 at a privilege level of hardware platform 100 that is lower than the privilege level of hypervisor 120.

[0096] In step S3, the method includes executing at least one security-critical application 150 on a guest operating system 142 in at least one virtual machine 140. Optionally, one or more non-security-critical applications 160 may be executed.

[0097] In step S4, the method includes providing a list of one or more predefined actions that, when executed by processor cores 112a, 112b, are relevant to the integrity and / or operation of the safety-critical application 150. Providing the list of actions may, for example, mean defining the one or more actions based on one or more criteria for defining one or more actions that may potentially affect the integrity and / or operation of the safety-critical application 150.

[0098] The method includes a further step S5: the hypervisor 120 instructs the processor cores 112a, 112b to redirect the control flow of the processor cores 112a, 112b toward the corresponding processor 132 in the monitoring component 130 for the action to be performed when the action to be performed on the list is about to be performed and / or when such an action is scheduled to be performed on the processor cores 112a, 112b.

[0099] It should be emphasized that steps S1 to S5 can be executed, at least partially, in any order or simultaneously. The method includes a further step S6a, which includes: when the control flow is executed to the handler 132 for the action to be executed, the handler 132 checks and / or analyzes whether the action to be executed is allowed or not according to a predetermined rule set, and causes the action to be executed when the action to be executed is to be allowed.

[0100] The actions to be performed may be, for example, related to setting up a new safety-critical application, and / or the actions to be performed may include the transfer of control flow between the safety-critical application 150 and the guest operating system 142 or other processes.

[0101] Alternatively, in addition to step S6a, the method further includes step S6b: the processor 132 performs at least one preparation for the action to be performed, and then causes the action to be performed to be executed.

[0102] As stated above and below, Figure 1 The general method shown can be supplemented with one or more optional features, steps, or aspects. See below for further reference. Figure 1 as well as Figure 2 This paper summarizes such exemplary steps and aspects, as well as the advantages and benefits achieved by this method.

[0103] Spatial and / or temporal isolation, such as memory isolation, can be achieved between a non-secure guest OS kernel 142 and a secure application 150 running in user space above the guest OS kernel 142 by implementing a monitoring component 130 that executes on a preferred secure hypervisor 120.

[0104] Figure 2An exemplary configuration is shown with a hypervisor 120 running on two processor cores 112a, 112b, for example, with a Linux kernel-based hypervisor 120, without limiting the mode to a microkernel root hypervisor or other scenarios. For example, the hypervisor 120 can be implemented as a user-space application.

[0105] Monitoring component 130 can be considered, or referred to as, a virtual machine monitor (VMM) application that allows virtual machines (VMs) 140, including a guest OS kernel 142 such as the Linux kernel, to run on top of hypervisor 120. In the illustrated setup, only security-critical applications 150 are running on top of the guest OS kernel 142. The supervision performed by hypervisor 120 and / or monitoring component 130 allows a secure execution environment to be established on top of the insecure guest OS kernel 142. Monitoring component 130 can be integrated into hypervisor 120 or can be implemented as a standalone application of hypervisor 120.

[0106] For example, this setting can define the detection of unauthorized memory access as an "action to be performed" defined on or according to a predefined action list, or target the detection of unauthorized memory access during the execution of that action. Such unauthorized memory access can originate from the guest OS kernel 142 to the private memory of any security-critical application 150 that can run on top of the guest OS and / or kernel 142. This may also include unintended memory access from any other user process to the private memory of the security-critical application 150.

[0107] In an exemplary implementation, such access can be prevented by hardware assistance or hardware root capture into the hypervisor 120, which could cause the VM executing from the virtual machine 140 running the security-critical application 150 to exit. Alternatively, such access can be prevented by invoking the functions of the relevant monitoring component 130 and / or the corresponding handler 132 within the hypervisor 120.

[0108] A trap can be triggered by applying appropriate settings to the Stage 2 Page Table Tree (PTT) maintained by the hypervisor 120 for the virtual machine 140 under consideration (which runs the security-critical application 150). Alternatively, the trap can be generated by a so-called hypervisor call (HVC), or whenever the guest OS 142 attempts to overwrite the contents of a memory page protected by a specific kernel register or other Stage 2 memory management unit.

[0109] By utilizing such a capture mechanism, when the (new) safety-critical application 150 has been set up and begun its regular execution, and when a context switch occurs within the virtual machine 140, for example, by a system call or by another process running in user space, the hypervisor 120 is able to detect and / or take notice of one or more settings of the (new) safety-critical application 150 (as actions to be performed that may affect the integrity and / or operation of the safety-critical application 150).

[0110] In an exemplary implementation, when the hypervisor 120 detects a context switch in the virtual machine 140, it redirects control flow to the monitoring component 130 and the corresponding handler 132, for example, by capturing the context switch. To ensure the secure execution of the safety-critical application 150 and to ensure its resumption of execution after the context switch, the monitoring component 130 and / or handler 132 apply a Phase 2 PTT, which sets permissions so that the guest OS and / or kernel 142 cannot access the Phase 1 PTT or the pages allocated to any safety-critical application 150. Optionally, permissions can be set on a per-CPU-core basis, i.e., only the CPU core currently executing the safety-critical application 150 in the virtual machine is granted permission to access the private memory of the safety-critical application 150.

[0111] When switching to a security application in the guest OS 142, the monitoring component 130 and / or the handler 132 apply a phase 2 PTT, which is configured with permissions that allow unrestricted access to the phase 1 PTT and the pages assigned to that security-critical application 150 (also referred to herein as security application 150).

[0112] The above-described pattern can be used when static memory is mapped to security-critical user processes, or it can be used for dynamically mapped memory. In the former case, for example, as part of the configuration of VM 140, the physical memory 114 for that purpose must be continuously defined. When the guest OS 142 dynamically decides which memory to use, the interaction pattern between the hypervisor 120 and the guest OS 142 can be implemented based on shared memory and a notification mechanism of selection, and / or by having the guest OS 142 perform HVC and pass data as a payload to such meta-system calls.

[0113] Figure 3 A flowchart illustrating an exemplary computer implementation of a method for executing a security-critical application 150 on hardware platform 100 is shown. Specifically, Figure 3 The startup process or setup for (new) safety-critical application 150 is shown, as per reference, among other things. Figure 1 and Figure 2 As stated above.

[0114] Configure (new) security-critical applications 150 Figure 3 The process begins with step S10, which may include redirecting control flow to the hypervisor 120 and / or monitoring components, as described with reference to the foregoing figures.

[0115] When the guest OS kernel 142 sets up a (new) safety-critical application 150, the monitoring component 130 and / or the handler 132 may allow the guest OS 142 to populate the memory pages of the safety-critical application 150 to be set up by applying appropriate settings in stage 2 PTT in step S12 during step S12. Therefore, the memory pages of the safety-critical application 150 can be configured without restriction during step S12 when starting up or setting up the safety-critical application 150.

[0116] The monitoring component 130 can also keep track of new memory pages added in phase 1PTT for safety-critical applications 150 in step S12.

[0117] In a further step S14, the monitoring component 130 and / or the processor 132 removes access to the user space memory and the memory pages that store the page table tree of the security-critical application 150 in phase 2 PTT.

[0118] In subsequent step S16, write access rights can be granted or added to the user space memory of the security-critical application 150 in phase 2 PTT, and execution rights can be removed from the memory page storing one or more exception handlers. Therefore, a trap can be forcibly applied to the hypervisor 120 when an exception occurs, and the exception handler can begin execution.

[0119] Once the setup of new security applications 150 (respectively all security-critical applications 150 on VM 140) is complete and they begin their regular execution phase, hypervisor 120 can set permissions for memory pages of security-critical applications 150 pointed to by the phase 1 PTT leaf, specifically changing the execution of the memory page from non-execution to execution in phase 2 PTT, so as to allow the execution of the security-critical applications 150 under consideration.

[0120] This allows implicit detection of the startup completion of the safety-critical application 150 by starting execution with a non-executable license initially configured in Phase 2 PTT. Alternatively or additionally, the startup completion of the safety-critical application 150 can be explicitly indicated via dedicated VM exit and / or HVC.

[0121] Steps S14 and S16 can be performed or repeated for each security-critical application 150 started by guest OS 142 and / or kernel 142 until all security-critical applications are set up and running, such as Figure 3 Step S18 is shown in the diagram.

[0122] Since the hypervisor 120 and guest OS 142 can run on multiple CPU cores 112a and 112b, the following specific aspects can be considered. When a Phase 2 PTT modification is performed by the monitoring component 130 on one CPU core 112a, it can be ensured that the unmodified Phase 2 PTT is still enforced on other CPU cores 112b. Whenever a Phase 2 PTT modification has been performed by the monitoring component 130 on CPU core 112a, the TLB of the affected modified PTT entries can be flushed on all used CPU cores 112a and 112b to prevent other CPU cores 112b from using PTT entries with outdated address mappings or licensed caches.

[0123] Figure 4 and Figure 5 Each example shows a flowchart illustrating an exemplary computer implementation of a security-critical application on a hardware platform. Specifically, Figure 4 and Figure 5 The sequence of events, including context switching, is shown for handling the private memory and PTT of the safety-critical application 150.

[0124] The following describes various aspects and exemplary implementations, as well as the advantages of implementing this method. Therefore, the following description also applies to... Figures 1 to 3 And the corresponding description, based on the following Figure 4 and Figure 5 To supplement it.

[0125] In the exemplary implementation, Linux is used as the guest OS 142 and ARM-based processor cores 112a and 112b, such as the ARMv8 architecture.

[0126] For reference Figures 1 to 3 As described, each instance of the user-level virtual machine monitor (VMM) and / or monitoring component 130 of the hypervisor can only manage one virtual machine 140. However, this is not a necessary condition. In a normal setup, the monitoring component 130 can maintain a set of memory regions mapped to VM 140. This set can typically be defined and managed by a page table tree. For simplicity, it is assumed that in microkernel 122 (see...) Figure 2The system maintains a page table tree (PTT) for managing the set of 140 memory pages per VM, which is part of a so-called VM object or VMO. Specifically, multiple VM objects can be utilized, each associated with a specific phase 2 PTT.

[0127] According to the method described herein, more than 140 PTTs per VM can be introduced, with each PTT managed as part of a separate VM object. This allows each thread of the monitoring component 130 running on cores 112a and 112b to select its own PTT for the Stage 2 MMU (Memory Management Unit) on the corresponding core 112a or 112b.

[0128] When the VM exits, the thread of the monitoring component 130 on the relevant cores 112a and 112b can repeat which VM object and / or which phase 2 PTT should be active.

[0129] The anticipated guarantee of space freedom from interference can be based on the concept that the memory pages of the safety-critical (user) process (referred to as safety-critical application 150) to be protected by the Phase 2 MMU are marked as read-only, while the safety-critical process or safety-critical application 150 itself is not an execution process on the corresponding cores 112a, 112b. This prevents modification of the memory pages from outside the context of the safety-critical process or safety-critical application 150. Optionally, in addition to protecting the actual memory pages of safety-critical application 150 (setting their permissions), Phase 1 PTT modifications to the safety-critical application's 150 PTT can also be prevented.

[0130] Furthermore, this allows for a kernel-local stage 2 MMU delivery exception after any write access to a memory page, provided write protection for that memory page is enabled. Subsequently, write protection can only be deactivated if a safety-critical user process or safety-critical application 150, which should be protected, requires write access to its memory.

[0131] In a preferred embodiment, at least two VM objects can be used, and the following configuration may exist.

[0132] The first VM object can be used whenever software in a security context or of high criticality is active. The corresponding VM object may be referred to herein as VMO-HI, and its configuration can be stored within the corresponding VM object. VMO-HI can define that all pages mapped to the VM 140 under consideration are marked as read, write, and executable; optionally, memory pages containing exception handlers for the guest OS kernel can be marked as non-executable (see [link to documentation]). Figure 3(Steps S14 and S16 in the process). This ensures that any attempt to make a system call within the guest OS 142 during VMO-HI activity can trigger a VM exit in the hypervisor 120.

[0133] A second VM object can be used whenever the guest OS 142 is executing in a non-security-critical context or in low-critical software. This VM object can be defined as VM object-LOW (also referred to as VMO-LOW in this document, specifically in...). Figure 4 and Figure 5 (In the middle). VMO-LOW can be defined such that memory pages considered private memory for any safety-critical process or safety-critical application 150 are marked as non-writable, and all other memory pages reserved for VM 140 are marked as read, write, and executable.

[0134] Alternatively, in both VM objects VMO-LOW and VMO-HI, once started or configured, the memory storing the 150-page table of safety-critical processes or applications can be marked as read-only.

[0135] In addition to the above, a few pages of the 150 private memory for each security process or each security-critical application can optionally be excluded, and these pages in both VM objects can be marked as writable. This memory can be used whenever interaction with the guest OS 142 of the security user process or security-critical application 150 is anticipated. From the perspective of the security-critical process, this memory may be considered untrusted.

[0136] The activation of VMO-HI and VMO-LOW is discussed in more detail below. For example, the startup and startup completion indication of safety-critical application 150 can be implemented as follows.

[0137] Once the safety-critical application 150, hosted within VM 140, has completed its startup phase, VM exit can be used to inform the monitoring component 130 of the process's private memory and the location of the Stage 1 PTT. Here, data exchange can be accomplished via HVC from Exception Level 1 (EL1) (e.g., the Linux kernel), or by having the process under consideration write to a memory page not mapped to the EL2-related Stage 2 MMU. The address of this memory page can be agreed upon by configuring it as a shared memory device and having the safety-critical process or application 150 write to it via sysfs. In both cases, VM exit occurs, and the hypervisor 120 can take over control to set up memory protection.

[0138] like Figure 4As shown in the sequence or flowchart, setting memory page and page table protection in operation can be implemented as follows. Specifically, Figure 4 The event between the safety-critical application 150 and the monitoring component 130 is shown.

[0139] Safety-critical application 150 may attempt to write to its memory at step or event S40, which triggers a write-time page fault at step S42, causing control flow to redirect to monitoring component 130.

[0140] The private memory of a safety-critical process or application 150, i.e., the set of relevant memory pages, can be obtained from a process-specific PTT, such as that generated by the guest OS 142. This may involve a complete traversal of all relevant page tables at step S44, for example, a page table scan.

[0141] Once VM exit occurs, and the safety-critical process or application 150 under consideration is already active, the starting address of the PTT can be provided in the TTBR0 register, or passed to the monitoring component 130 via HVC. This allows the monitoring component 130 to set VMO-HI and VMO-LOW at step S45 and record the address of the entry node and the memory pages storing the PTT of the safety-critical process or application 150. These memory pages may optionally be protected.

[0142] Once the monitoring component 130 has created VMO-HI and VMO-LOW, the microkernel 122 or hypervisor 120 can perform a TLB refresh on all relevant kernels 112a, 112b at step S46, and if necessary.

[0143] In addition to creating VMO-HI and VMO-LOW, for example, for both VMO-HI and VMO-LOW, the monitoring component 130 can also mark memory pages that host page tables specific to safety-critical processes or safety-critical applications 150 within the guest OS kernel 142 as write-protected. This ensures that the guest OS kernel 142 cannot silently or imperceptibly modify the memory mapped to the safety-critical processes or safety-critical applications 150 at any later stage.

[0144] Additionally, the monitoring component 130 can inspect memory regions used for different safety-critical processes or applications 150 and ensure that these memory regions overlap only in the case of shared memory and that the set of shared memory pages is consistent across the processes involved.

[0145] After performing a TLB refresh, VMO-LOW can be activated or loaded at step S47 and returned to the safety-critical application 150 at step S48.

[0146] Figure 5 The swapping of VM objects and the corresponding loading of Phase 2 PTT are illustrated. Specifically, Figure 5 The event between the safety-critical application 150 and the monitoring component 130 is shown.

[0147] When a VM exit to a protected memory page is triggered at step S50 in the presence of a write attempt to private memory, monitoring component 130 can check at step S52 whether the safety-critical process or safety-critical application 150 is a violator. In such a case, the TTBR0 register can point to the latter's PTT. In this case, monitoring component 130 can activate VMO-HI and the corresponding Level 2 PTT for safety-critical application 150, and return (step S54) to safety-critical process or application 150, which can then execute the procedure at step S55.

[0148] If the guest OS kernel 142 attempts to generate a page fault, for example through a system call or interrupt, by attempting to execute the exception handler at step S56, the monitoring component 130 can deactivate VMO-HI, activate, or switch to VMO-LOW at step S58, and return to the guest OS kernel 142 at step S60. This allows the guest OS kernel 142 to continue executing the exception handler.

[0149] Other write accesses that result in VM exit (e.g., write accesses generated by guest OS kernel 142) may be considered erroneous behavior and may thus be flagged, or generally disposed of as needed and / or defined (e.g., including terminating VM 140).

[0150] By studying the accompanying drawings, this disclosure, and the appended claims, those skilled in the art can understand and implement other variations of the disclosed embodiments in practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude multiple. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used for an advantageous purpose. Any reference numerals in the claims should not be construed as limiting the scope of the claims.

Claims

1. A method for executing a security-critical application (150) on a hardware platform (100) including at least one processor core (112a, 112b), the method comprising the steps of: • A hypervisor (120) is executed on a hardware platform (100), the hypervisor (120) including a monitoring component (130) for the security-critical application (150); • The hypervisor (120) instantiates at least one virtual machine (140) on the hardware platform at a privilege level lower than that of the hypervisor (120); • Provide a list of one or more predefined actions that, when executed by the processor cores (112a, 112b), are relevant to the integrity and / or operation of the security-critical application (150); • The processor cores (112a, 112b) are instructed by the hypervisor (120) to redirect control flow toward the corresponding processor (132) in the monitoring component (130) for the action to be performed when the action to be performed is about to be executed on the list. • The security-critical application (150) is executed on top of the guest operating system (142) in at least one virtual machine (140); as well as • When the control flow is redirected to the handler (132) for the action to be performed: ○ The processor (132) checks whether the action to be performed is allowed or not according to a predetermined set of rules, and causes the action to be performed when the action to be performed is to be allowed; and / or ○ The processor (132) performs at least one preparation for the action to be performed, and then causes the action to be performed to be performed.

2. The method of claim 1, wherein the action to be performed includes the switching of the control flow between the security-critical application (150) and the guest operating system (142).

3. The method of claim 1 or 2, wherein preparation for the transition of the control flow for the action to be performed between the security-critical application (150) and the guest operating system (142) includes changing the access permission for at least one resource used by the security-critical application.

4. The method according to any one of claims 1 to 3, wherein: • Preparation for the transition of the control flow from the safety-critical application (150) to the guest operating system (142) for the action to be performed includes prohibiting or disabling write access to memory pages used by the safety-critical application (150). as well as • Preparations for the transition of control flow from the guest operating system (142) to the security-critical application (150) include allowing or enabling write access to memory pages used by the security-critical application (150).

5. The method of claim 4, further comprising: When access to memory pages is prohibited, at least one memory region is made writable, the memory region being designated for data transfer between the security-critical application (150) and the guest operating system (142).

6. The method of any one of claims 4 to 5, wherein in addition to prohibiting write access to memory pages, access to the Stage 1 Page Table Tree (PTT) maintained in the virtual machine (140) is also prohibited; and / or In addition to allowing write access to memory pages, it also allows access to the Stage 1 Page Table Tree (PTT) maintained in the virtual machine (140).

7. The method of any one of claims 1 to 6, wherein the instruction of the processor core to redirect the control flow and / or to disable or enable access to memory pages includes modifying the Stage 2 Page Table Tree (PTT) maintained by the hypervisor (120) for the virtual machine (140).

8. The method of claim 7, further comprising: After modifying the Phase 2 PTT on one of the processor cores, refresh the Translation Lookaside Buffer (TLB) of the other cores (112a, 112b).

9. The method according to any one of claims 1 to 8, wherein • The actions to be performed include setting up new security-critical applications (150) by the guest operating system (142); and • The preparation includes allowing write access to memory pages to be used by the new security-critical application (150).

10. The method of claim 9, wherein: • In addition to allowing write access to memory pages used for the new safety-critical application (150), code execution is not permitted in these memory pages; and • After the setup of the new security-critical application (150) is completed, code execution in the memory page is permitted.

11. The method according to any one of claims 1 to 10, wherein: In response to an attempt by the control flow to be redirected to the processor for the guest operating system (142) to execute code in the non-executable memory pages of the safety-critical application (150), it is determined that the control flow is being redirected to the guest operating system (142) from the safety-critical application (150).

12. The method of any one of claims 1 to 11, further comprising: At least one other application (160) is executed on top of the guest operating system (142) in the at least one virtual machine (140).

13. The method of any one of claims 1 to 12, further comprising: • The safety-critical application (150) processes the measurement data acquired by at least one sensor (522) into an actuation signal; as well as • Use the actuation signal to actuate at least one land vehicle, air vehicle, or sea vehicle and / or at least one robot, and / or any of its components.

14. A computing system (500), comprising: A hardware platform (100) having one or more processor cores (112a, 112b); as well as Memory (114) for data storage; The computing system is configured to perform the steps of the method according to any one of the preceding claims.

15. One or more computer programs, the one or more computer programs comprising machine-readable instructions that, when executed by a computing system (500), cause the computing system to perform the method as claimed in any one of claims 1 to 13, and / or to perform the role of the monitoring component (130) in the context of performing the method as claimed in any one of claims 1 to 13.

16. A non-transitory machine-readable data carrier and / or downloadable product having one or more computer programs as described in the preceding claims.

Images