US10180915B2 - Method and apparatus for accessing physical resources - Google Patents

Method and apparatus for accessing physical resources Download PDF

Info

Publication number
US10180915B2
US10180915B2 US15/160,863 US201615160863A US10180915B2 US 10180915 B2 US10180915 B2 US 10180915B2 US 201615160863 A US201615160863 A US 201615160863A US 10180915 B2 US10180915 B2 US 10180915B2
Authority
US
United States
Prior art keywords
light
physical
accessed
resource
physical address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US15/160,863
Other languages
English (en)
Other versions
US20160267026A1 (en
Inventor
Chen Zheng
Long Fu
Jianfeng Zhan
Lixin Zhang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Assigned to HUAWEI TECHNOLOGIES CO., LTD. reassignment HUAWEI TECHNOLOGIES CO., LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ZHANG, LIXIN, FU, LONG, ZHAN, Jianfeng, ZHENG, CHEN
Publication of US20160267026A1 publication Critical patent/US20160267026A1/en
Application granted granted Critical
Publication of US10180915B2 publication Critical patent/US10180915B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/4555—Para-virtualisation, i.e. guest operating system has to be modified
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • the present disclosure relates to the field of operating system technologies, and in particular, to a method and an apparatus for accessing physical resources.
  • a microkernel and multiple kernels have become a future development trend of the operating system. Collaboration of multiple kernels can well isolate applications, increase a system throughput rate, and significantly improve system performance. Therefore, in face of big data processing nowadays, a virtualization technology and a multi-kernel technology are increasingly studied and applied due to high scalability.
  • a parallel virtualization system combined with the multi-kernel technology and the virtualization technology, ensures resource reuse and isolation, and each kernel in a multi-kernel operating system can autonomously manage memory resources.
  • a heavy system kernel (Heavy Operating System) runs on one physical node (for example, a server or a computer), where the Heavy OS manages multiple light system kernels (Light Operating System) that have independent physical resources.
  • the Heavy OS manages multiple light system kernels (Light Operating System) that have independent physical resources.
  • a global physical memory is visible to each Light OS. Therefore, when a Light OS kernel itself is untrusted, or a logic error occurs in a page table mapping, the Light OS kernel may access a physical memory that does not belong to the Light OS kernel, resulting in memory resource leakage of other system kernels and causing insecurity of memory resources.
  • Embodiments of the present disclosure provide a method and an apparatus for accessing physical resources, to restrict access to physical resources of other Light OSs by a light system kernel Light OS in a multi-kernel operating system and ensure security of accessing physical resources among the Light OSs.
  • an embodiment of the present disclosure provides a method for accessing physical resources, applied to a parallel virtualization system, where the system includes a heavy system kernel Heavy OS, at least one light system kernel Light OS, and secure firmware, and the method includes:
  • the determining, by the secure firmware, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds includes:
  • second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and determining whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, where the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS.
  • a second possible implementation manner of the first aspect is further provided, where: the querying, by the secure firmware, whether stored second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and determining whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, includes:
  • a third possible implementation manner of the first aspect is further provided, where: the querying, by the secure firmware, whether stored second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and determining whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, includes:
  • the Heavy OS receiving an access violation instruction sent by the Heavy OS, and determining, according to the received access violation instruction, that the access of the first Light OS is out of bounds, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information do not include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the determining, by the secure firmware, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds includes:
  • a fifth possible implementation manner of the first aspect is further provided, where the receiving, by the secure firmware, a physical address corresponding to a physical resource to be accessed by a first Light OS, includes:
  • a sixth possible implementation manner of the first aspect is further provided, where a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • an embodiment of the present disclosure provides a method for accessing physical resources, applied to a parallel virtualization system, where the system includes a heavy system kernel Heavy OS, at least one light system kernel Light OS, and secure firmware, and the method includes:
  • the secure firmware sends, by a first Light OS, an access request, so that the secure firmware receives a physical address corresponding to a physical resource to be accessed by the first Light OS, and determines whether access of the first Light OS is out of bounds, where the access request includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and the first Light OS is any one of the at least one Light OS;
  • the method further includes:
  • the method further includes: allocating a kernel object resource to each task in user space;
  • a third possible implementation manner of the second aspect where after the process of the first task in the tasks violates the kernel object resource that can be accessed by the first task in the capability table, and/or the propagation path of the critical data is modified, the method further includes:
  • an embodiment of the present disclosure provides a method for accessing physical resources, applied to a parallel virtualization system, where the system includes a heavy system kernel Heavy OS, at least one light system kernel Light OS, and secure firmware, and the method includes:
  • the Heavy OS receives, by the Heavy OS, an access exception signal fed back by the secure firmware, where the access exception signal is used to indicate that second resource allocation mapping information currently stored in the secure firmware does not include a physical address corresponding to a physical resource to be accessed by a first Light OS, the first Light OS is any one of the at least one Light OS, and the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS;
  • the method before the receiving, by the Heavy OS, an access exception signal fed back by the secure firmware, the method further includes:
  • a second possible implementation manner of the third aspect is further provided, where before the allocating, by the Heavy OS, the physical resources to each Light OS, the method further includes:
  • the initialization setting includes: setting a capacity for storing the second resource allocation mapping information in the secure firmware;
  • the storing all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware includes: storing all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware according to the capacity.
  • a third possible implementation manner of the third aspect is further provided, where the initialization setting further includes: binding the secure firmware with the Heavy OS, so that the secure firmware stores or updates the second resource allocation mapping information only under control of the Heavy OS, and that the secure firmware feeds back the access exception signal only to the Heavy OS.
  • the method further includes:
  • a fifth possible implementation manner of the third aspect is further provided, where the method further includes:
  • a sixth possible implementation manner of the third aspect is further provided, where before the sending a security detection request to the first Light OS, the method further includes:
  • a seventh possible implementation manner of the third aspect is further provided, where: a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • an embodiment of the present disclosure provides secure firmware for accessing physical resources, applied to a parallel virtualization system, where the system further includes a heavy system kernel Heavy OS and at least one light system kernel Light OS, and the secure firmware includes:
  • a receiving module configured to receive a physical address corresponding to a physical resource to be accessed by a first Light OS, where the first Light OS is any one of the at least one Light OS;
  • a determining module configured to determine whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, where being out of bounds is that physical addresses corresponding to physical resources allocated by the Heavy OS to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • a sending module configured to: send an access continuity signal to the first Light OS, when the access of the first Light OS is within bounds, where the access continuity signal is used to indicate that the first Light OS can access the physical resource corresponding to the physical address; or send an access error signal to the first Light OS, when the access of the first Light OS is out of bounds, where the access error signal is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the determining module includes a querying unit and a determining unit, where:
  • the querying unit is configured to query whether stored second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit is configured to determine, according to a query result of the querying unit, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds;
  • the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS.
  • a second possible implementation manner of the fourth aspect is further provided, where the querying unit is specifically configured to query whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS; and
  • the determining unit is specifically configured to determine, that the access of the first Light OS is within bounds, when the querying unit finds that the physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • a third possible implementation manner of the fourth aspect is further provided, where the secure firmware further includes a signal generation module, where:
  • the querying unit is specifically configured to query whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the signal generation module is configured to generate an access exception signal, when the physical addresses corresponding to the first Light OS in the second resource allocation mapping information currently stored in the secure firmware do not include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the access exception signal is used to indicate that the second resource allocation mapping information currently stored in the secure firmware does not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the sending module is further configured to send the access exception signal obtained by the signal generation module to the Heavy OS, so that the Heavy OS queries the first resource allocation mapping information;
  • the querying unit is specifically configured to query, second resource allocation mapping information updated by the Heavy OS, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit is further configured to determine, according to a query result of the querying unit, that the access of the first Light OS is within bounds, where the updated second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS; or
  • the receiving module is further specifically configured to receive, an access violation instruction sent by the Heavy OS, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information do not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit is further configured to determine, according to the access violation instruction received by the receiving module, that the access of the first Light OS is out of bounds, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the secure firmware further includes a loading module, where:
  • the loading module is configured to load first resource allocation mapping information
  • the querying unit is configured to query whether physical addresses corresponding to the first Light OS in the first resource allocation mapping information loaded by the loading module include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit is configured to: determine that the access of the first Light OS is within bounds, when the physical addresses corresponding to the first Light OS in the first resource allocation mapping information queried by the querying unit include the physical address corresponding to the physical resource to be accessed by the first Light OS; or determine that the access of the first Light OS is out of bounds, when the physical addresses corresponding to the first Light OS in the first resource allocation mapping information queried by the querying unit do not include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • a fifth possible implementation manner of the fourth aspect is further provided, where the receiving module is specifically configured to:
  • a sixth possible implementation manner of the fourth aspect is further provided, where a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • an embodiment of the present disclosure provides a light system kernel entity for accessing physical resources, applied to a parallel virtualization system, where the system further includes a heavy system kernel Heavy OS and secure firmware, and the light system kernel entity includes:
  • a sending module configured to send an access request, so that the secure firmware receives a physical address corresponding to a physical resource to be accessed by a first Light OS, and determines whether access of the first Light OS is out of bounds, where the access request includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and the first Light OS is any one of at least one Light OS;
  • a receiving module configured to receive an access continuity signal or an access error signal sent by the secure firmware
  • a handling module configured to: access the physical resource corresponding to the physical address, when the access continuity signal is received; or perform exception handling on a task that initiates the access, when the access error signal is received, where the exception handling is used to instruct the first Light OS to stop accessing the physical resource corresponding to the physical address and destroy the access request.
  • the light system kernel entity further includes a signal generation module, where:
  • the receiving module is further configured to receive a security detection request sent by the Heavy OS, where the security detection request is used to detect whether an exception occurs in the first Light OS;
  • the signal generation module is configured to generate a security response signal according to the security detection request received by the receiving module, where the security response signal is used to indicate that the first Light OS is in a normal state;
  • the sending module is further configured to send the security response signal generated by the signal generation module to the Heavy OS within a preset time.
  • a second possible implementation manner of the fifth aspect is further provided, where the light system kernel entity further includes:
  • an allocation module configured to allocate a kernel object resource to each task in user space
  • a creation module configured to create a capability table according to the kernel object resource that is allocated by the allocation module to each task, where the capability table is used to identify access permission of each task in the Light OS for the kernel object resource;
  • a monitoring module configured to monitor whether a process of each task violates the kernel object resource that can be accessed by each task in the capability table and monitor a propagation path of critical data
  • the handling module is further configured to: perform destruction processing on the first task and/or the propagation path of the critical data, when the monitoring module detects that a process of a first task in the tasks violates a kernel object resource that can be accessed by the first task in the capability table, and/or the propagation path of the critical data is modified.
  • the light system kernel entity further includes a recording module, where:
  • the recording module is configured to: record information indicating that the process of the first task violates the kernel object resource that can be accessed by the task in the capability table, when the monitoring module detects that the process of the first task in the tasks violates the kernel object resource that can be accessed by the first task in the capability table; and/or record information indicating that the propagation path of the critical data is modified, when the monitoring module detects that the propagation path of the critical data is modified.
  • an embodiment of the present disclosure provides a heavy system kernel entity for accessing physical resources, applied to a parallel virtualization system, where the system further includes at least one light system kernel Light OS and secure firmware, and the heavy system kernel entity includes:
  • a receiving module configured to receive an access exception signal fed back by the secure firmware, where the access exception signal is used to indicate that second resource allocation mapping information currently stored in the secure firmware does not include a physical address corresponding to a physical resource to be accessed by a first Light OS, the first Light OS is any one of the at least one Light OS, and the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS;
  • a querying module configured to query, according to the access exception signal received by the receiving module, whether physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • an updating module configured to update a correspondence between the first Light OS and the physical address corresponding to the physical resource to be accessed by the first Light OS, to the second resource allocation mapping information stored in the secure firmware when the querying module finds that the physical addresses corresponding to the first Light OS include the physical address corresponding to the physical resource to be accessed by the first Light OS, so that the secure firmware determines, according to the updated second resource allocation mapping information, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds; or
  • a signal generation module configured to generate an access violation instruction when the physical addresses corresponding to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • a sending module configured to send the access violation instruction generated by the signal generation module to the secure firmware, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the heavy system kernel entity further includes:
  • an allocation module configured to allocate the physical resources to each Light OS before the receiving module receives the access exception signal fed back by the secure firmware
  • a creation module configured to create the first resource allocation mapping information according to the physical resources that are allocated by the allocation module to each Light OS, and store the first resource allocation mapping information
  • a storage module configured to store all or some of the first resource allocation mapping information generated by the creation module as the second resource allocation mapping information in the secure firmware.
  • a second possible implementation manner of the sixth aspect is further provided, where the heavy system kernel entity further includes:
  • a setting module configured to perform an initialization setting on the secure firmware before the allocation module allocates the physical resources to each Light OS, where the initialization setting includes: setting a capacity for storing the second resource allocation mapping information in the secure firmware;
  • the storage module is further configured to store all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware according to the capacity set by the setting module.
  • a third possible implementation manner of the sixth aspect is further provided, where the setting module is further configured to bind the secure firmware with the Heavy OS, so that the secure firmware stores or updates the second resource allocation mapping information only under control of the Heavy OS, and that the secure firmware feeds back the access exception signal only to the Heavy OS.
  • the heavy system kernel entity further includes:
  • a counting module configured to count, after the receiving module receives the access exception signal fed back by the secure firmware, the number of times the secure firmware feeds back the access exception signal of the first Light OS;
  • a handling module configured to destroy an exceptional access task in the first Light OS when the number of times obtained by the counting module exceeds a preset threshold.
  • the sending module is further configured to send a security detection request to the first Light OS, where the security detection request is used to detect whether an exception occurs in the first Light OS;
  • the receiving module is further configured to receive, within a preset time, a security response signal sent by the first Light OS, where the security response signal is used to indicate that the first Light OS is in a normal state; or
  • the handling module is further configured to perform restoration processing on a capability table in the first Light OS and a propagation path of critical data when no security response signal sent by the first Light OS is received within a preset time, where the capability table is used to identify access permission of each task in the Light OS for a kernel object resource.
  • a sixth possible implementation manner of the sixth aspect is further provided, where the heavy system kernel entity further includes a recording module, where
  • the recording module is configured to periodically record capability table information of the first Light OS and propagation path information of the critical data before the sending module sends the security detection request to the first Light OS.
  • a seventh possible implementation manner of the sixth aspect is further provided, where: a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • an embodiment of the present disclosure provides a system for accessing physical resources, including the secure firmware in the fourth aspect or any one of the possible implementation manners of the fourth aspect, the light system kernel entity in the fifth aspect or any one of the possible implementation manners of the fifth aspect, the heavy system kernel entity in the sixth aspect or any one of the possible implementation manners of the sixth aspect.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • each independent Light OS ensures, by monitoring a capability operation of a task process, access permission of the task process in the Light OS for a kernel object resource, therefore further ensuring robustness of the Light OS against an untrusted task.
  • a Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS.
  • FIG. 1 is a schematic flowchart diagram of a method for accessing physical resources according to an embodiment of the present disclosure
  • FIG. 2 is a schematic flowchart diagram of another method for accessing physical resources according to an embodiment of the present disclosure
  • FIG. 3 is a schematic flowchart diagram of another method for accessing physical resources according to an embodiment of the present disclosure
  • FIG. 4 is a schematic flowchart diagram of a method for accessing physical resources according to an embodiment of the present disclosure
  • FIG. 5 is a schematic flowchart diagram of a method for accessing physical resources by a Light OS according to an embodiment of the present disclosure
  • FIG. 6 is a schematic flowchart diagram of a method for performing security detection on a Light OS by a Heavy OS according to an embodiment of the present disclosure
  • FIG. 7 is a schematic diagram of secure firmware for accessing physical resources according to an embodiment of the present disclosure.
  • FIG. 8 is a schematic diagram of another secure firmware for accessing physical resources according to an embodiment of the present disclosure.
  • FIG. 9 is a schematic diagram of a light system kernel for accessing physical resources according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic diagram of another light system kernel for accessing physical resources according to an embodiment of the present disclosure.
  • FIG. 11 is a schematic diagram of a heavy system kernel for accessing physical resources according to an embodiment of the present disclosure.
  • FIG. 12 is a schematic diagram of another heavy system kernel for accessing physical resources according to an embodiment of the present disclosure.
  • FIG. 13 is a schematic diagram of an entity apparatus of secure firmware for accessing physical resources according to an embodiment of the present disclosure
  • FIG. 14 is a schematic diagram of an entity apparatus of a light system kernel for accessing physical resources according to an embodiment of the present disclosure.
  • FIG. 15 is a schematic diagram of an entity apparatus of a heavy system kernel for accessing physical resources according to an embodiment of the present disclosure.
  • An embodiment of the present disclosure provides a system for accessing physical resources, where the system includes: a heavy system kernel (Heavy Operating System), at least one light system kernel (Light Operating System), secure firmware (Secure Ware), and a memory.
  • a heavy system kernel Heavy Operating System
  • at least one light system kernel Light Operating System
  • secure firmware Secure Ware
  • the physical resources may be physical memory resources or may be hardware device resources such as a hard disk, a network adapter or other peripheral component interconnect (PCI) devices, which are not limited certainly.
  • PCI peripheral component interconnect
  • the Heavy OS is a management system kernel in a multi-kernel operating system, and is configured to: distribute, manage, and schedule tasks; perform operations on the secure firmware such as an initialization setting, exception handling, and resetting to ensure security and validity of accessing the physical resources by the Light OS; and perform security detection on the Light OS to ensure functional completeness of the Light OS.
  • the Light OS is an application system kernel in the multi-kernel operating system, and is configured to access the physical resources according to independent memory resources and address space allocated by the Heavy OS to the Light OS; in addition, the Light OS encapsulates kernel resources of the Light OS to ensure robustness of the Light OS against an untrusted task, and accepts the security detection performed by the Heavy OS to ensure functional completeness of the Light OS.
  • the secure firmware is configured to verify validity of accessing physical memory resources by the Light OS, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of physical resources.
  • the memory is configured to store a physical resource to be accessed by the Light OS.
  • an embodiment of the present disclosure provides a method for accessing physical resources.
  • an execution entity of this method is the secure firmware, and as shown in FIG. 1 , the method includes:
  • the secure firmware receives a physical address corresponding to a physical resource to be accessed by a first light system kernel Light OS, where the first Light OS is any one of the at least one Light OS.
  • the secure firmware is hardware for implementing validity verification of memory access, and the secure firmware may be implemented on a memory controller, or may be implemented on a memory management unit (MMU), which is not limited certainly.
  • MMU memory management unit
  • the first light system kernel Light OS is responsible for providing an environment for system service and application execution, where the multi-kernel operating system includes at least one light system kernel.
  • the secure firmware receives the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by a cache controller;
  • the secure firmware receives the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by a memory management unit MMU.
  • the first Light OS sends, to the MMU, a request for accessing a physical resource corresponding to a physical address.
  • the MMU converts a virtual address in the request into a physical address.
  • the MMU sends the physical address to the Cache controller, and the Cache controller detects whether the physical address exists in the Cache.
  • a physical resource hit corresponding to the physical address is returned to the first Light OS, when the physical address exists in the Cache; a cache miss (Cache miss) is generated and then a memory is accessed, when the physical address does not exist in the Cache.
  • the secure firmware receives the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by the cache controller.
  • the first Light OS sends, to the MMU, a request for accessing a physical resource corresponding to a physical address.
  • the MMU converts a virtual address in the request into a physical address.
  • the MMU sends the physical address to the secure firmware, and therefore, the secure firmware receives the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by the memory management unit MMU.
  • the secure firmware determines whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, where being out of bounds is that physical addresses corresponding to physical resources allocated by the Heavy OS to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • That the secure firmware determines whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds includes two cases: The secure firmware determines that the physical address corresponding to the physical resource to be accessed by the first Light OS is within bounds, and the secure firmware determines that the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds.
  • the case in which the secure firmware determines whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds may be determined by using two different methods.
  • the first method is that the secure firmware determines, by querying second resource allocation mapping information stored by the secure firmware, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds.
  • the second method is that the secure firmware determines, by querying a first resource allocation mapping information, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds.
  • the secure firmware determines whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds includes: The secure firmware queries whether the stored second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and determines whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, where the second resource allocation mapping information includes all or some of the first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS.
  • the first method may further include two cases.
  • the following describes the two different cases (two different cases A and B) in detail.
  • the secure firmware determines, by using the currently stored second resource allocation mapping information, that the physical address corresponding to the physical resource to be accessed by the first Light OS is within bounds.
  • the steps of case A includes A1 and A2.
  • the secure firmware queries whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the secure firmware determine that the access of the first Light OS is within bounds, when the physical addresses corresponding to the first Light OS in the second resource allocation mapping information currently stored in the secure firmware include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the secure firmware determines, by using the second resource allocation mapping information updated and stored by the secure firmware, that the physical address corresponding to the physical resource to be accessed by the first Light OS is within bounds.
  • the steps of case B includes B1, B2, B3, B4 and B5.
  • the secure firmware queries whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the secure firmware queries second resource allocation mapping information updated by the Heavy OS, and determines that the access of the first Light OS is within bounds, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the updated second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • B5. Receive an access violation instruction sent by the Heavy OS, and determine, according to the received access violation instruction, that the access of the first Light OS is out of bounds, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information do not include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the secure firmware determines, by querying the first resource allocation mapping information, that the physical address corresponding to the physical resource to be accessed by the first Light OS is within bounds.
  • the steps of this case includes:
  • Step S 103 a is performed, when the access of the first Light OS is within bounds; step S 103 b is performed, when the access of the first Light OS is out of bounds.
  • the secure firmware sends an access continuity signal to the first Light OS, when the access of the first Light OS is within bounds, where the access continuity signal is used to indicate that the first Light OS can access the physical resource corresponding to the physical address.
  • That the first Light OS accesses, under control of the secure firmware, the physical resource corresponding to the physical address includes:
  • the first Light OS accesses the physical resource corresponding to the physical address in the cache controller
  • the first Light OS accesses the physical resource corresponding to the physical address in the memory.
  • the Cache controller does not have the physical address corresponding to the physical resource to be accessed by the first Light OS
  • the secure firmware is implemented on the memory controller
  • the physical addresses corresponding to the first Light OS in the second resource allocation mapping information stored in the secure firmware include the physical address
  • the first Light OS is controlled to access the physical resource corresponding to the physical address in the memory
  • the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly in the Cache without using the secure firmware.
  • the first Light OS is controlled to access the physical resource corresponding to the physical address in the cache.
  • the physical resource corresponding to the physical address is returned to the first Light OS, when the cache stores the physical address; the first Light OS continues to access the physical resource corresponding to the physical address in the memory, when the cache does not store the physical address.
  • the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly in the Cache.
  • the Cache controller does not have the physical address corresponding to the physical resource to be accessed by the first Light OS, and physical addresses corresponding to a CPU identifier included in the first Light OS in the first resource allocation mapping information include the physical address when the secure firmware is implemented on the memory controller, the first Light OS is controlled to access the physical resource corresponding to the physical address in the memory. Further, the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly without using the secure firmware.
  • the first Light OS is controlled to access the physical resource corresponding to the physical address in the cache.
  • the physical resource corresponding to the physical address is returned to the first Light OS, when the cache stores the physical address;
  • the first Light OS is controlled to continue to access the physical resource corresponding to the physical address in the memory, when the cache does not store the physical address.
  • the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly in the Cache.
  • the secure firmware sends an access error signal to the first Light OS, when the access of the first Light OS is out of bounds, where the access error signal is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • an embodiment of the present disclosure provides a method for accessing physical resources, where the method is performed by a Light OS. As shown in FIG. 2 , specific steps include:
  • a first Light OS sends an access request, so that the secure firmware receives a physical address corresponding to a physical resource to be accessed by the first Light OS, and determines whether access of the first Light OS is out of bounds, where the access request includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and the first Light OS is any one of the at least one Light OS.
  • the secure firmware receives the physical address and determines whether the access of the first Light OS is out of bounds, which is not further described herein. For details, reference may be made to the foregoing steps S 101 and S 102 .
  • the first Light OS receives an access continuity signal or an access error signal sent by the secure firmware.
  • the access continuity signal is used to indicate that the first Light OS can access the physical resource corresponding to the physical address
  • the access error signal is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the first Light OS accesses the physical resource corresponding to the physical address, when the access continuity signal is received.
  • That the first Light OS accesses the physical resource corresponding to the physical address includes:
  • the first Light OS accesses the physical resource corresponding to the physical address in a cache controller
  • the first Light OS accesses the physical resource corresponding to the physical address in a memory.
  • the Cache controller does not have the physical address corresponding to the physical resource to be accessed by the first Light OS
  • physical addresses corresponding to the first Light OS in second resource allocation mapping information stored in the secure firmware include the physical address
  • the first Light OS is controlled to access the physical resource corresponding to the physical address in the memory
  • the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly without using the secure firmware.
  • the secure firmware is implemented on an MMU, and physical addresses corresponding to the first Light OS in second resource allocation mapping information stored in the secure firmware include the physical address
  • the first Light OS is controlled to access the physical resource corresponding to the physical address in a cache; the physical resource corresponding to the physical address is returned to the first Light OS, when the cache stores the physical address; or the first Light OS continues to access the physical resource corresponding to the physical address in the memory, when the cache does not store the physical address; and further, the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly in the Cache.
  • the Cache controller does not have the physical address corresponding to the physical resource to be accessed by the first Light OS, and when the secure firmware is implemented on a memory controller, physical addresses corresponding to a CPU identifier included in the first Light OS in a first resource allocation mapping information include the physical address, the first Light OS is controlled to access the physical resource corresponding to the physical address in the memory; and further, the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly without using the secure firmware.
  • the secure firmware is implemented on an MMU, and physical addresses corresponding to a CPU identifier included in the first Light OS in a first resource allocation mapping information include the physical address
  • the first Light OS is controlled to access the physical resource corresponding to the physical address in a cache; the physical resource corresponding to the physical address is returned to the first Light OS, when the cache stores the physical address; or the first Light OS is controlled to continue to access the physical resource corresponding to the physical address in the memory, when the cache does not store the physical address; and further, the physical address is cached to a Cache of a CPU that sends the access request, to ensure that when the physical address is accessed next time, the physical resource corresponding to the physical address can be hit directly in the Cache.
  • the first Light OS performs exception handling on a task that initiates the access, when the access error signal is received, where the exception handling is used to instruct the first Light OS to stop accessing the physical resource corresponding to the physical address and destroy the access request.
  • the exception handling may be that the first Light OS stops the access request, or may be that the first Light OS directly destroys the access request, which is not limited certainly.
  • the exception handling ensures validity and security of accessing physical resources by the first Light OS.
  • the Heavy OS needs to perform security detection on the first Light OS to ensure functional completeness of the Light OS. Therefore, the first Light OS may perform the following steps to ensure functional completeness of the Light OS, including:
  • functions of the first Light OS are complete, when the first Light OS generates the security response signal according to the security detection request, and sends the security response signal to the Heavy OS within the preset time; functions of the first Light OS are incomplete, when the first Light OS generates the security response signal according to the security detection request, but does not send the security response signal to the Heavy OS within the preset time; functions of the first Light OS are also incomplete, when the first Light OS does not generate the security response signal according to the security detection request.
  • the first Light OS may further allocate independent memory resources and address space according to a used operating system, perform permission management in fine granularity on kernel resources by using a capability mechanism, and ensure correctness of the capability mechanism by monitoring an access path of a process.
  • the method includes:
  • information indicating that the process of the first task violates the kernel object resource that can be accessed by the task in the capability table is recorded, when it is detected that the process of the first task in the tasks violates the kernel object resource that can be accessed by the first task in the capability table;
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • each independent Light OS ensures, by monitoring a capability operation of a task process, access permission of the task process in the Light OS for a kernel object resource, therefore further ensuring robustness of the Light OS against an untrusted task.
  • security detection is performed on the Light OS by a Heavy OS to ensure functional completeness of the Light OS.
  • an embodiment of the present disclosure provides a method for accessing physical resources, where the method is performed by a Heavy OS. As shown in FIG. 3 , specific steps include:
  • the Heavy OS receives an access exception signal fed back by the secure firmware, where the access exception signal is used to indicate that second resource allocation mapping information currently stored in the secure firmware does not include a physical address corresponding to a physical resource to be accessed by a first Light OS, the first Light OS is any one of the at least one Light OS, and the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS.
  • a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • the secure firmware when the secure firmware receives the physical address corresponding to the physical resource to be accessed by the first Light OS, the secure firmware finds that the currently stored second resource allocation mapping information does not include the physical address corresponding to the physical resource to be accessed by the first Light OS, and the secure firmware generates the access exception signal, and sends the access exception signal to the Heavy OS; correspondingly, the Heavy OS receives the access exception signal fed back by the secure firmware.
  • the Heavy OS queries, according to the received access exception signal, whether physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • a data storage structure of the first resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • Step S 303 continues to be performed, when the physical addresses corresponding to the first Light OS include the physical address; step S 304 continues to be performed, when the physical addresses corresponding to the first Light OS do not include the physical address.
  • the Heavy OS updates a correspondence between the first Light OS and the physical address corresponding to the physical resource to be accessed by the first Light OS, to the second resource allocation mapping information stored in the secure firmware, when the physical addresses corresponding to the first Light OS include the physical address corresponding to the physical resource to be accessed by the first Light OS, so that the secure firmware determines, according to the updated second resource allocation mapping information, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds.
  • a data storage structure of the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • the Heavy OS generates an access violation instruction, and send the access violation instruction to the secure firmware, when the physical addresses corresponding to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the secure firmware stores all or some of resource allocation mapping information of the first Light OS.
  • attribute flag of the resource allocation mapping information of the first Light OS stored in the secure firmware of the first Light OS may be set, to indicate that the secure firmware does not store the physical address of the first Light OS, when the physical addresses corresponding to the first Light OS in the first resource allocation mapping information do not include the physical address.
  • step S 301 the method includes:
  • the method further includes:
  • the initialization setting includes: setting a capacity for storing the second resource allocation mapping information in the secure firmware;
  • the storing all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware includes: storing all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware according to the capacity.
  • the initialization setting further includes: binding the secure firmware with the Heavy OS, so that the secure firmware stores or updates the second resource allocation mapping information only under control of the Heavy OS, and that the secure firmware feeds back the access exception signal only to the Heavy OS.
  • the binding the secure firmware with the Heavy OS may be setting an identifier of the Heavy OS in the secure firmware, so that when any CPU in the multi-kernel operating system sends a signal to the secure firmware, the secure firmware determines, according to an identifier of the CPU that sends the signal, whether the identifier of the CPU is an identifier of the Heavy OS or is an identifier of the Light OS, to ensure a unique authority of setting function of the Heavy OS for the secure firmware and a unique authority for storage and update of the second resource allocation mapping information in the secure firmware; in addition, the secure firmware feeds back the access exception signal only to the Heavy OS.
  • step S 304 after the Heavy OS receives the access exception signal fed back by the secure firmware, the method further includes:
  • Performing exception handling on the first Light OS may be performing isolation processing on the first Light OS, or may be performing destruction processing on the first Light OS, which is not limited certainly.
  • the Heavy OS needs to perform security detection on the first Light OS to ensure functional completeness of the first Light OS. Therefore, the Heavy OS may perform the following steps to perform security detection on the first Light OS, including:
  • the Heavy OS before the Heavy OS sends the security detection request to the first Light OS, the Heavy OS periodically records capability table information of the first Light OS and propagation path information of the critical data, so that when no security response signal sent by the first Light OS is received within the preset time, restoration processing is performed on the capability table in the first Light OS and the propagation path of the critical data.
  • secure firmware for accessing physical resources is added, so that when a Light OS in a multi-kernel operating system initiates physical resource access, the secure firmware verifies validity of memory access by the Light OS, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs. Further, a Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS.
  • the following provides a specific implementation solution to a method for accessing physical resources. As shown in FIG. 4 , specifically the following steps are included:
  • Step 401 When started, a Heavy OS performs an initialization setting on secure firmware.
  • the initialization setting is performed on the secure firmware, where the initialization setting includes: setting a capacity for storing second resource allocation mapping information in the secure firmware; and binding the secure firmware with the Heavy OS, so that the secure firmware stores or updates the second resource allocation mapping information only under control of the Heavy OS, and that the secure firmware feeds back an access exception signal only to the Heavy OS.
  • the second resource allocation mapping information may be a correspondence between a CPU included in a Light OS and physical addresses of all or some of physical resources allocated by the Heavy OS to the CPU included in the Light OS.
  • the initialization setting includes: setting an address range that can be stored by the secure firmware, of an access memory, to 4 Q and binding the Heavy OS with the secure firmware, that is, setting an attribute flag identifying the CPU 0 in the secure firmware.
  • Step 402 The Heavy OS allocates physical memory resources to each Light OS.
  • Step 403 The Heavy OS generates first resource allocation mapping information according to the physical memory resources allocated to each Light OS, and stores the first resource allocation mapping information.
  • the first resource allocation mapping information may be a Light OS resource table.
  • the Light OS resource table includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • Step 404 The Heavy OS stores all or some of the first resource allocation mapping information as second resource allocation mapping information in the secure firmware.
  • the second resource allocation mapping information may be a part or all of the Light OS resource table.
  • the Light OS resource table includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • the Heavy OS divides the 4 G address range that can be stored by the secure firmware, of the access memory, into different areas, where each area records some or all of physical addresses that can be accessed by a Light OS in the Light OS resource table.
  • Step 405 A first light system kernel Light OS initiates a request for accessing a memory resource, and sends the request to an MMU.
  • Step 406 The MMU converts a virtual address in the request for accessing the memory resource into a physical address.
  • Step 407 The MMU sends the physical address to a Cache; correspondingly, the Cache receives the physical address sent by the MMU.
  • Step 408 The Cache returns, to the first Light OS, the memory resource corresponding to the physical address, when the Cache stores the physical address.
  • Step 409 The Cache sends the physical address to the secure firmware, when the Cache does not store the physical address; correspondingly, the secure firmware receives the physical address sent by the Cache.
  • Step 410 The secure firmware determines, according to a part or all of a Light OS resource table stored by the secure firmware, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds.
  • Step 411 The secure firmware controls the first Light OS to access the physical memory resource corresponding to the physical address in the memory, when the physical address corresponding to the physical resource to be accessed by the first Light OS is within bounds.
  • Step 412 The secure firmware generates an access exception signal, when the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds.
  • Step 413 The secure firmware sends the access exception signal to the Heavy OS; correspondingly, the Heavy OS receives the access exception signal sent by the secure firmware.
  • Step 414 The Heavy OS detects, according to the received access exception signal sent by the secure firmware, whether physical addresses corresponding to the first Light OS in the Light OS resource table include the physical address.
  • Step 415 The Heavy OS updates a correspondence between the first Light OS and the physical address to the second resource allocation mapping information stored in the secure firmware, when it is detected that the physical addresses corresponding to the first Light OS in the Light OS resource table include the physical address, so that the first Light OS accesses the physical memory resource corresponding to the physical address in the memory.
  • Step 416 The Heavy OS generates an access violation instruction, and sends the access violation instruction to the secure firmware, when it is detected that the physical addresses corresponding to the first Light OS in the Light OS resource table do not include the physical address; correspondingly, the secure firmware receives the access violation instruction sent by the Heavy OS.
  • Step 417 The secure firmware generates an access error signal according to the received access violation instruction, and sends the access error signal to the first Light OS; correspondingly, the first Light OS receives the access error signal sent by the secure firmware.
  • Step 418 The first Light OS performs, according to the received access error signal, exception processing on a task that initiates the access.
  • secure firmware for accessing physical resources is added, so that when a Light OS in a multi-kernel operating system initiates physical resource access, the secure firmware verifies validity of memory access by the Light OS, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • the embodiment of the present disclosure provides a method for accessing physical resources, where the method is performed by a first Light OS, which ensures access permission for a kernel object resource by monitoring a capability operation of a task process in the first Light OS, and monitoring a propagation path of critical data.
  • specific steps include:
  • Step 501 The first light system kernel Light OS allocates a kernel object resource to each task in user space.
  • the kernel object resource exists in a form of an object (Object) after the Light OS encapsulates kernel resources (for example, a memory and a device).
  • kernel resources for example, a memory and a device.
  • a first Light OS allocates a kernel object resource to each task in user space is completed by a capability authorization module in the first Light OS, where the capability authorization module is a part of a capability mechanism.
  • the capability authorization module decides access permission of task processes in the user space for each kernel object resource, and may dynamically adjust and allocate kernel object resources according to a requirement of a task process.
  • Step 502 The first Light OS creates a capability table according to the kernel object resource allocated to each task, where the capability table is used to identify access permission of each task in the first Light OS for the kernel object resource.
  • Step 503 The first Light OS monitors whether a process of each task violates the kernel object resource that can be accessed by each task in the capability table and monitors a propagation path of critical data.
  • the child process of this task needs to inherit some or all of kernel object resources of a parent process, that is, access permission of all child processes of this task for the kernel object resources can never be higher than access permission of the parent process for the kernel object resources.
  • the child process may obtain access permission that does not belong to the parent process for a kernel object resource, and thereby obtain higher permission to perform an illegal operation on the system, when the task is intruded and tampered by a malicious user program. Therefore, the capability authorization module in the first Light OS monitors, by monitoring a capability flow of the task process, whether a child processes of each task violate a kernel object resource that can be accessed by the parent process in the capability table, and traces whether a propagation path of multiple pieces of critical data in the kernel is modified.
  • Step 504 The first Light OS performs destruction processing on the first task and/or the propagation path of the critical data, when a process of a first task in the tasks violates a kernel object resource that can be accessed by the first task in the capability table, and/or the propagation path of the critical data is modified.
  • the first Light OS performs isolation or destruction processing on the task, which is not limited certainly, when the capability authorization module in the first Light OS detects that the child process of the task process violates the kernel object resource that can be accessed by the parent process, and/or that the propagation path of the critical data is modified.
  • the method further includes:
  • the first Light OS in the foregoing Embodiment 2 ensures, by monitoring a capability operation of a task process in the first Light OS, access permission management of the task process in the first Light OS for a kernel object resource.
  • the method may be implemented in an independent Light OS, or may be implemented in any step in the foregoing Embodiment 1.
  • the Light OS by monitoring a capability operation of a task process of a Light OS, in a case in which a task process of the Light OS violates a kernel object resource that can be accessed by the task in a capability table and/or a propagation path of critical data is modified, the Light OS performs exception handling on the task and/or the propagation path of the critical data, thereby ensuring access permission management of the task process in the Light OS for the kernel object resource, and further ensuring robustness of the Light OS against an untrusted task.
  • the embodiment of the present disclosure provides a method for accessing physical resources, where the method is performed by a Heavy OS, and security detection performed on a Light OS ensures functional completeness of the Light OS. As shown in FIG. 6 , specific steps include:
  • Step 601 The heavy system kernel Heavy OS sends a security detection request to the first Light OS; correspondingly, the first Light OS receives the security detection request sent by the Heavy OS.
  • the security detection request is used to detect whether an exception occurs in the first Light OS; the Heavy OS may perform security detection on the first Light OS periodically or in real time, which is not limited certainly.
  • the method further includes: the Heavy OS periodically records capability table information of the first Light OS and propagation path information of critical data, so that when no security response signal sent by the first Light OS is received, restoration processing is performed on a capability table in the first Light OS and a propagation path of the critical data.
  • steps 602 and 603 are performed; when functions of the first Light OS are incomplete and an exception occurs, steps 604 is performed.
  • Step 602 The first Light OS generates a security response signal according to the received security detection request.
  • the security response signal is used to indicate that the first Light OS is in a normal state.
  • Step 603 The first Light OS sends the security response signal to the Heavy OS within a preset time; correspondingly, the Heavy OS receives the security response signal sent by the first Light OS.
  • a responding module in the first Light OS responds to the security detection request of the Heavy OS.
  • a security response signal is generated, when the first Light OS does not record information indicating that a task process in the first Light OS violates a kernel object resource that can be accessed by the task in the capability table and/or information indicating that the propagation path of the critical data is modified.
  • a capability authorization module in the first Light OS is complete, when the Heavy OS detects that the first Light OS does not record information indicating that a task process in the first Light OS violates a kernel object resource that can be accessed by the task in the capability table and/or information indicating that the propagation path of the critical data is modified, and the security response signal sent by the first Light OS is received within a preset time.
  • a security response signal is not generated, when the first Light OS records information indicating that a task process in the first Light OS violates a kernel object resource that can be accessed by the task in the capability table and/or information indicating that the propagation path of the critical data is modified.
  • the responding module may be implemented in the capability authorization module, or may be independently implemented in the first Light OS, which is not limited certainly.
  • Step 604 The Heavy OS performs restoration processing on a capability table in the first Light OS and a propagation path of critical data, when no security response signal sent by the first Light OS is received within a preset time, where the capability table is used to identify access permission of each task in the Light OS for a kernel object resource.
  • the Heavy OS when the Heavy OS detects that the first Light OS does not record the information indicating that the task process in the first Light OS violates the kernel object resource that can be accessed by the task in the capability table and/or the information indicating that the propagation path of the critical data is modified, and the security response signal sent to the Heavy OS is not received within the preset time, the Heavy OS performs restoration processing on the capability table in the first Light OS and the propagation path of the critical data.
  • the Heavy OS when the Heavy OS detects that the first Light OS records the information indicating that the task process in the first Light OS violates the kernel object resource that can be accessed by the task in the capability table and/or the information indicating that the propagation path of the critical data is modified, the Heavy OS performs restoration processing on the capability table in the first Light OS and the propagation path of the critical data.
  • the restoration processing is resending the capability table information of the first Light OS and the propagation path information of the critical data that are periodically recorded by the Heavy OS to the first Light OS.
  • the Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS; the method may be implemented independently, or may be implemented in any step in the foregoing Embodiment 1 and/or Embodiment 2.
  • a Heavy OS performs security detection on a Light OS, to perform restoration processing on a capability table in the first Light OS and a propagation path of critical data when detecting information indicating that a task process in the Light OS violates a kernel object resource that can be accessed by the task in the capability table and/or information indicating that the propagation path of the critical data is modified, and ensure functional completeness of the Light OS.
  • the present disclosure provides secure firmware 70 for accessing physical resources, applied to a parallel virtualization system, where the system further includes a heavy system kernel Heavy OS and at least one light system kernel Light OS.
  • the secure firmware 70 includes:
  • a receiving module 701 configured to receive a physical address corresponding to a physical resource to be accessed by a first Light OS, where the first Light OS is any one of the at least one Light OS;
  • a determining module 702 configured to determine whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, where being out of bounds is that physical addresses corresponding to physical resources allocated by the Heavy OS to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • a sending module 703 configured to: send an access continuity signal to the first Light OS, when the access of the first Light OS is within bounds, where the access continuity signal is used to indicate that the first Light OS can access the physical resource corresponding to the physical address; or send an access error signal to the first Light OS, when the access of the first Light OS is out of bounds, where the access error signal is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the determining module 702 includes a querying unit 702 a and a determining unit 702 b , where:
  • the querying unit 702 a is configured to query whether stored second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit 702 b is configured to determine, according to a query result of the querying unit 702 a , whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds;
  • the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS.
  • the querying unit 702 a is specifically configured to query whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit 702 b is specifically configured to determine, that the access of the first Light OS is within bounds, when the querying unit 702 a finds that the physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the secure firmware 70 further includes a signal generation module 704 , where:
  • the querying unit 702 a is further configured to query whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the signal generation module 704 is configured to generate an access exception signal when the querying unit 702 a finds that the physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information do not include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the access exception signal is used to indicate that the second resource allocation mapping information currently stored in the secure firmware does not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the sending module 703 is further configured to send the access exception signal obtained by the signal generation module 704 to the Heavy OS, so that the Heavy OS queries the first resource allocation mapping information;
  • the querying unit 702 a is further configured to query, second resource allocation mapping information updated by the Heavy OS, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit 702 b is further configured to determine, according to a query result of the querying unit 702 a , that the access of the first Light OS is within bounds, where the updated second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS; or
  • the receiving module 701 is further specifically configured to receive, an access violation instruction sent by the Heavy OS, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information do not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit 702 b is further configured to determine, according to the access violation instruction received by the receiving module 701 , that the access of the first Light OS is out of bounds, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the secure firmware further includes a loading module 705 , where:
  • the loading module 705 is configured to load first resource allocation mapping information
  • the querying unit 702 a is configured to query whether physical addresses corresponding to the first Light OS in the first resource allocation mapping information loaded by the loading module 705 include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the determining unit 702 b is configured to: determine that the access of the first Light OS is within bounds, when the physical addresses corresponding to the first Light OS in the first resource allocation mapping information queried by the querying unit 702 a include the physical address corresponding to the physical resource to be accessed by the first Light OS; or determine that the access of the first Light OS is out of bounds, when the physical addresses corresponding to the first Light OS in the first resource allocation mapping information queried by the querying unit 702 a do not include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the receiving module 701 is specifically configured to: receive the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by a cache controller; or receive the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by a memory management unit MMU.
  • a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • the present disclosure provides a light system kernel entity 90 for accessing physical resources, applied to a parallel virtualization system, where the system further includes a heavy system kernel Heavy OS and secure firmware, and the light system kernel entity 90 may include at least one CPU kernel.
  • the light system kernel entity 90 includes:
  • a sending module 901 configured to send an access request, so that the secure firmware receives a physical address corresponding to a physical resource to be accessed by a first Light OS, and determines whether access of the first Light OS is out of bounds, where the access request includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and the first Light OS is any one of at least one Light OS;
  • a receiving module 902 configured to receive an access continuity signal or an access error signal sent by the secure firmware
  • a handling module 903 configured to: access the physical resource corresponding to the physical address, when the receiving module 902 receives the access continuity signal; or perform exception handling on a task that initiates the access, when the receiving module 902 receives the access error signal, where the exception handling is used to instruct the first Light OS to stop accessing the physical resource corresponding to the physical address and destroy the access request.
  • the light system kernel entity 90 further includes:
  • an allocation module 904 configured to allocate a kernel object resource to each task in user space
  • a creation module 905 configured to create a capability table according to the kernel object resource that is allocated by the allocation module 904 to each task, where the capability table is used to identify access permission of each task in the Light OS for the kernel object resource;
  • a monitoring module 906 configured to monitor whether a process of each task violates the kernel object resource that can be accessed by each task in the capability table obtained by the creation module 905 and monitor a propagation path of critical data;
  • the handling module 903 is further configured to: perform destruction processing on the first task and/or the propagation path of the critical data, when the monitoring module 906 detects that a process of a first task in the tasks violates a kernel object resource that can be accessed by the first task in the capability table, and/or the propagation path of the critical data is modified.
  • the light system kernel entity 90 further includes a recording module 907 , where:
  • the recording module 907 is configured to: record information indicating that the process of the first task violates the kernel object resource that can be accessed by the task in the capability table, when the monitoring module 906 detects that the process of the first task in the tasks violates the kernel object resource that can be accessed by the first task in the capability table; and/or record information indicating that the propagation path of the critical data is modified, when the monitoring module 906 detects that the propagation path of the critical data is modified.
  • the light system kernel entity 90 further includes a signal generation module 908 , where:
  • the receiving module 902 is further configured to receive a security detection request sent by the Heavy OS, where the security detection request is used to detect whether an exception occurs in the first Light OS;
  • the signal generation module 908 is configured to generate a security response signal according to the security detection request received by the receiving module 902 , where the security response signal is used to indicate that the first Light OS is in a normal state;
  • the sending module 901 is further configured to send the security response signal generated by the signal generation module to the Heavy OS within a preset time.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • each independent Light OS ensures, by monitoring a capability operation of a task process, access permission of the task process in the Light OS for a kernel object resource, therefore further ensuring robustness of the Light OS against an untrusted task.
  • a Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS.
  • the present disclosure provides a heavy system kernel entity 110 for accessing physical resources, applied to a parallel virtualization system, where the system further includes at least one light system kernel Light OS and secure firmware, and the heavy system kernel entity 110 may include at least one CPU kernel.
  • the heavy system kernel entity 110 includes:
  • a receiving module 1101 configured to receive an access exception signal fed back by the secure firmware, where the access exception signal is used to indicate that second resource allocation mapping information currently stored in the secure firmware does not include a physical address corresponding to a physical resource to be accessed by a first Light OS, the first Light OS is any one of the at least one Light OS, and the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS;
  • a querying module 1102 configured to query, according to the access exception signal received by the receiving module 1101 , whether physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • an updating module 1103 configured to update a correspondence between the first Light OS and the physical address corresponding to the physical resource to be accessed by the first Light OS, to the second resource allocation mapping information stored in the secure firmware, when the querying module 1102 finds that the physical addresses corresponding to the first Light OS include the physical address corresponding to the physical resource to be accessed by the first Light OS, so that the secure firmware determines, according to the updated second resource allocation mapping information, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds; or
  • a signal generation module 1104 configured to generate an access violation instruction, when the physical addresses corresponding to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • a sending module 1105 configured to send the access violation instruction generated by the signal generation module 1104 to the secure firmware, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the heavy system kernel entity 110 further includes:
  • an allocation module 1106 configured to allocate the physical resources to each Light OS
  • a creation module 1107 configured to generate the first resource allocation mapping information according to the physical resources that are allocated by the allocation module 1106 to each Light OS, and store the first resource allocation mapping information;
  • a storage module 1108 configured to store all or some of the first resource allocation mapping information generated by the creation module 1107 as the second resource allocation mapping information in the secure firmware.
  • the heavy system kernel entity 110 further includes a setting module 1109 , where:
  • the setting module 1109 is configured to perform an initialization setting on the secure firmware before the allocation module 1106 allocates the physical resources to each Light OS, where the initialization setting includes: setting a capacity for storing the second resource allocation mapping information in the secure firmware; and
  • the storage module 1108 is further configured to store all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware according to the capacity set by the setting module 1109 .
  • the setting module 1109 is further configured to bind the secure firmware with the Heavy OS, so that the secure firmware stores or updates the second resource allocation mapping information only under control of the Heavy OS, and that the secure firmware feeds back the access exception signal only to the Heavy OS.
  • the heavy system kernel entity further includes a counting module 1110 and a handling module 1111 , where:
  • the counting module 1110 is configured to count, after the receiving module 1101 receives the access exception signal fed back by the secure firmware, the number of times the secure firmware feeds back the access exception signal of the first Light OS;
  • the handling module 1111 is configured to destroy an exceptional access task in the first Light OS, when the number of times obtained by the counting module 1110 exceeds a preset threshold.
  • the sending module 1105 is further configured to sends a security detection request to the first Light OS, where the security detection request is used to detect whether an exception occurs in the first Light OS;
  • the receiving module 1101 is further configured to receive, within a preset time, a security response signal sent by the first Light OS, where the security response signal is used to indicate that the first Light OS is in a normal state; or
  • the handling module 1111 is further configured to perform restoration processing on a capability table in the first Light OS and a propagation path of critical data, when no security response signal sent by the first Light OS is received within a preset time, where the capability table is used to identify access permission of each task in the Light OS for a kernel object resource.
  • the heavy system kernel entity 110 further includes a recording module 1112 , where:
  • the recording module 1112 is configured to periodically record capability table information of the first Light OS and propagation path information of the critical data before the sending module 1105 sends the security detection request to the first Light OS.
  • a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs. Further, the Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS.
  • the present disclosure provides a system for accessing physical resources, where the system includes the secure firmware shown in FIG. 7 or FIG. 8 , the light system kernel entity shown in FIG. 9 or FIG. 10 , and the heavy system kernel entity shown in FIG. 11 or FIG. 12 .
  • secure firmware for accessing physical resources is added, so that when a Light OS in the multi-kernel operating system initiates physical resource access, the secure firmware verifies validity of memory access by the Light OS, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • each independent Light OS ensures, by monitoring a capability operation of a task process, access permission of the task process in the Light OS for a kernel object resource, therefore further ensuring robustness of the Light OS against an untrusted task.
  • a Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS.
  • the present disclosure provides secure firmware 130 for accessing physical resources.
  • the secure firmware 130 includes a receiver 1301 , a processor 1302 , and a transmitter 1303 .
  • the receiver 1301 is configured to receive a physical address corresponding to a physical resource to be accessed by a first Light OS, where the first Light OS is any one of at least one Light OS.
  • the processor 1302 is configured to determine whether the physical address received by the receiver 1301 and corresponding to the physical resource to be accessed by the first Light OS is out of bounds, where being out of bounds is that physical addresses corresponding to physical resources allocated by the Heavy OS to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the transmitter 1303 is configured to: send an access continuity signal to the first Light OS, when the access of the first Light OS is within bounds, where the access continuity signal is used to indicate that the first Light OS can access the physical resource corresponding to the physical address; or send an access error signal to the first Light OS, when the access of the first Light OS is out of bounds, where the access error signal is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the processor 1302 is specifically configured to query whether stored second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and determine whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds, where the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS.
  • the processor 1302 is specifically configured to query whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS; and determine that the access of the first Light OS is within bounds, when the physical addresses corresponding to the first Light OS in the second resource allocation mapping information currently stored in the secure firmware include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the processor 1302 is specifically configured to query whether physical addresses corresponding to the first Light OS in the currently stored second resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS; generate an access exception signal, when the physical addresses corresponding to the first Light OS in the second resource allocation mapping information currently stored in the secure firmware do not include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the access exception signal is used to indicate that the second resource allocation mapping information currently stored in the secure firmware does not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the transmitter 1303 is specifically configured to send the access exception signal generated by the processor 1302 to the Heavy OS, so that the Heavy OS queries the first resource allocation mapping information;
  • the processor 1302 is specifically configured to: query, second resource allocation mapping information updated by the Heavy OS, and determine that the access of the first Light OS is within bounds, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS, where the updated second resource allocation mapping information includes the physical address corresponding to the physical resource to be accessed by the first Light OS; or
  • the receiver 1301 is specifically configured to: receive an access violation instruction sent by the Heavy OS, when physical addresses corresponding to the first Light OS in the first resource allocation mapping information do not include the physical address corresponding to the physical resource to be accessed by the first Light OS; and
  • the processor 1302 is specifically configured to determine, according to the access violation instruction received by the receiver 1301 , that the access of the first Light OS is out of bounds, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the processor 1302 is specifically configured to: load first resource allocation mapping information; query whether physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS; and determine that the access of the first Light OS is within bounds, when the physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS; or determine that the access of the first Light OS is out of bounds, when the physical addresses corresponding to the first Light OS in the first resource allocation mapping information do not include the physical address corresponding to the physical resource to be accessed by the first Light OS.
  • the receiver 1301 is specifically configured to: receive the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by a cache controller; or receive the physical address corresponding to the physical resource to be accessed by the Light OS, where the physical address corresponding to the physical resource is sent by a memory management unit MMU.
  • a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • the present disclosure provides a light system kernel entity 140 for accessing physical resources.
  • the light system kernel entity 140 includes a processor 1401 , a receiver 1402 , and a transmitter 1403 .
  • the transmitter 1403 is configured to send an access request, so that a secure firmware receives a physical address corresponding to a physical resource to be accessed by the first Light OS, and determines whether access of the first Light OS is out of bounds, where the access request includes the physical address corresponding to the physical resource to be accessed by the first Light OS, and the first Light OS is any one of the at least one Light OS.
  • the receiver 1402 is configured to receive an access continuity signal or an access error signal sent by the secure firmware, where the access continuity signal is used to indicate that the first Light OS can access the physical resource corresponding to the physical address, and the access error signal is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the processor 1401 is configured to: access the physical resource corresponding to the physical address, when the receiver 1402 receives the access continuity signal.
  • the processor 1401 is further configured to: perform exception handling on a task that initiates the access, when the receiver 1402 receives the access error signal, where the exception handling is used to instruct the first Light OS to stop accessing the physical resource corresponding to the physical address and destroy the access request.
  • the processor 1401 is further configured to: allocate a kernel object resource to each task in user space; create a capability table according to the kernel object resource allocated to each task, where the capability table is used to identify access permission of each task in the Light OS for the kernel object resource; monitor whether a process of each task violates the kernel object resource that can be accessed by each task in the capability table and monitor a propagation path of critical data; and perform destruction processing on the first task and/or the propagation path of the critical data, when a process of a first task in the tasks violates a kernel object resource that can be accessed by the first task in the capability table, and/or the propagation path of the critical data is modified.
  • the processor 1401 is further configured to: record information indicating that the process of the first task violates the kernel object resource that can be accessed by the task in the capability table, when detecting that the process of the first task in the tasks violates the kernel object resource that can be accessed by the first task in the capability table; and/or record information indicating that the propagation path of the critical data is modified, when the propagation path of the critical data is modified.
  • the receiver 1402 is further configured to receive a security detection request sent by the Heavy OS, where the security detection request is used to detect whether an exception occurs in the first Light OS;
  • the processor 1401 is further configured to generate a security response signal according to the security detection request received by the receiver 1402 , where the security response signal is used to indicate that the first Light OS is in a normal state;
  • the transmitter 1403 is further configured to send the security response signal generated by the processor 1401 to the Heavy OS within a preset time.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs.
  • each independent Light OS ensures, by monitoring a capability operation of a task process, access permission of the task process in the Light OS for a kernel object resource, therefore further ensuring robustness of the Light OS against an untrusted task.
  • a Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS.
  • the heavy system kernel entity 150 includes a receiver 1501 , a processor 1502 and a transmitter 1503 , where:
  • the receiver 1501 is configured to receive an access exception signal fed back by a secure firmware, where the access exception signal is used to indicate that second resource allocation mapping information currently stored in the secure firmware does not include a physical address corresponding to a physical resource to be accessed by the first Light OS, the first Light OS is any one of the at least one Light OS, and the second resource allocation mapping information includes all or some of first resource allocation mapping information, where the first resource allocation mapping information is stored in the Heavy OS, and is a correspondence between physical addresses corresponding to physical resources allocated by the Heavy OS to each Light OS and each Light OS;
  • the processor 1502 is configured to query, according to the access exception signal received by the receiver 1501 , whether physical addresses corresponding to the first Light OS in the first resource allocation mapping information include the physical address corresponding to the physical resource to be accessed by the first Light OS; and update a correspondence between the first Light OS and the physical address corresponding to the physical resource to be accessed by the first Light OS, to the second resource allocation mapping information stored in the secure firmware, when the physical addresses corresponding to the first Light OS include the physical address corresponding to the physical resource to be accessed by the first Light OS, so that the secure firmware determines, according to the updated second resource allocation mapping information, whether the physical address corresponding to the physical resource to be accessed by the first Light OS is out of bounds; or
  • the processor 1502 is further configured to generate an access violation instruction when the physical addresses corresponding to the first Light OS do not include the physical address corresponding to the physical resource to be accessed by the first Light OS;
  • the transmitter 1503 is configured to send the access violation instruction generated by the processor 1502 to the secure firmware, where the access violation instruction is used to indicate that the first Light OS cannot access the physical resource corresponding to the physical address.
  • the processor 1502 is further configured to: allocate the physical resources to each Light OS before the receiver 1501 receives the access exception signal fed back by the secure firmware; generate the first resource allocation mapping information according to the physical resources that are allocated to each Light OS, and store the first resource allocation mapping information; and store all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware.
  • the processor 1502 is further configured to perform an initialization setting on the secure firmware before the physical resources are allocated to each Light OS, where the initialization setting includes: setting a capacity for storing the second resource allocation mapping information in the secure firmware; and store all or some of the first resource allocation mapping information as the second resource allocation mapping information in the secure firmware according to the capacity.
  • the processor 1502 is further configured to bind the secure firmware with the Heavy OS, so that the secure firmware stores or updates the second resource allocation mapping information only under control of the Heavy OS, and that the secure firmware feeds back the access exception signal only to the Heavy OS.
  • the processor 1502 is further configured to count, after the receiver 1501 receives the access exception signal fed back by the secure firmware, the number of times the secure firmware feeds back the access exception signal of the first Light OS; and destroy an exceptional access task in the first Light OS when the number of times exceeds a preset threshold.
  • the transmitter 1503 is further configured to send a security detection request to the first Light OS, where the security detection request is used to detect whether an exception occurs in the first Light OS;
  • the receiver 1501 is further configured to receive, within a preset time, a security response signal sent by the first Light OS, where the security response signal is used to indicate that the first Light OS is in a normal state; or
  • the processor 1502 is further configured to perform restoration processing on a capability table in the first Light OS and a propagation path of critical data when no security response signal sent by the first Light OS is received within a preset time, where the capability table is used to identify access permission of each task in the Light OS for a kernel object resource.
  • the processor 1502 is further configured to periodically record capability table information of the first Light OS and propagation path information of the critical data before the transmitter 1503 sends the security detection request to the first Light OS.
  • a data storage structure of the first resource allocation mapping information and the second resource allocation mapping information includes index items and data items, where a CPU identifier included in the Light OS is used as an index item, and a physical address of a physical resource allocated to the Light OS is used as a data item.
  • secure firmware for accessing physical resources is added, so that when a Light OS initiates physical resource access, the secure firmware verifies validity of memory access by the light system kernel Light OS in a multi-kernel operating system, to restrict access to physical resources of other Light OSs by the Light OS and ensure security of accessing physical resources among the Light OSs. Further, the Heavy OS performs security detection on the Light OS to ensure functional completeness of the Light OS.
  • the disclosed system, apparatus, and method may be implemented in other manners.
  • the described apparatus embodiment is merely exemplary.
  • the unit division is merely logical function division and may be other division in actual implementation.
  • a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed.
  • the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces.
  • the indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.
  • the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • functional units in the embodiments of the present disclosure may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.
  • the integrated unit may be implemented in a form of hardware, or may be implemented in a form of hardware in addition to a software functional unit.
  • the integrated unit may be stored in a computer-readable storage medium.
  • the software functional unit is stored in a storage medium and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to perform some of the steps of the methods described in the embodiments of the present disclosure.
  • the foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)
US15/160,863 2013-11-21 2016-05-20 Method and apparatus for accessing physical resources Active 2035-09-15 US10180915B2 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201310594764.3A CN104657193B (zh) 2013-11-21 2013-11-21 一种访问物理资源的方法和装置
CN201310594764 2013-11-21
CN201310594764.3 2013-11-21
PCT/CN2014/091037 WO2015074512A1 (fr) 2013-11-21 2014-11-13 Procédé et appareil d'accès à des ressources physiques

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/091037 Continuation WO2015074512A1 (fr) 2013-11-21 2014-11-13 Procédé et appareil d'accès à des ressources physiques

Publications (2)

Publication Number Publication Date
US20160267026A1 US20160267026A1 (en) 2016-09-15
US10180915B2 true US10180915B2 (en) 2019-01-15

Family

ID=53178924

Family Applications (1)

Application Number Title Priority Date Filing Date
US15/160,863 Active 2035-09-15 US10180915B2 (en) 2013-11-21 2016-05-20 Method and apparatus for accessing physical resources

Country Status (4)

Country Link
US (1) US10180915B2 (fr)
EP (1) EP3070604B1 (fr)
CN (1) CN104657193B (fr)
WO (1) WO2015074512A1 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105740937A (zh) * 2015-11-11 2016-07-06 哈尔滨安天科技股份有限公司 一种高强度加密u盘、加密装置及系统
DE102015223335A1 (de) * 2015-11-25 2017-06-01 Robert Bosch Gmbh Verfahren zum Betreiben eines Mikrocontrollers
CN107797937A (zh) * 2016-09-05 2018-03-13 康齐科技股份有限公司 内存管理系统及其方法
CN106502926B (zh) * 2016-09-26 2019-11-19 华为技术有限公司 一种内存监控方法、内存访问控制器及SoC系统
CN108228333A (zh) * 2016-12-14 2018-06-29 中国航空工业集团公司西安航空计算技术研究所 一种多核系统的核间资源隔离方法
US10671547B2 (en) * 2016-12-19 2020-06-02 Intel Corporation Lightweight trusted tasks
CN106685981B (zh) * 2017-01-13 2021-03-23 北京元心科技有限公司 多系统的数据加密传输方法及装置
CN106844036B (zh) * 2017-02-09 2020-03-31 东软集团股份有限公司 物理设备的访问方法及装置
CN109343957A (zh) * 2018-09-21 2019-02-15 深圳市汇川技术股份有限公司 控制卡资源配置方法、系统、运动控制卡及存储介质
CN109885408B (zh) * 2019-03-13 2022-05-03 四川长虹电器股份有限公司 基于Android系统的轻量级浏览器资源优化方法
CN110851819A (zh) * 2019-11-20 2020-02-28 杭州安恒信息技术股份有限公司 多应用的访问权限控制方法、装置及电子设备
CN115587071B (zh) * 2022-12-12 2023-03-10 南京芯驰半导体科技有限公司 一种基于多核异构SoC车载系统数据储存系统及方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6233667B1 (en) * 1999-03-05 2001-05-15 Sun Microsystems, Inc. Method and apparatus for a high-performance embedded memory management unit
US6598144B1 (en) 2001-12-12 2003-07-22 Advanced Micro Devices, Inc. Arrangement for limiting access to addresses by a consumer process instigating work in a channel adapter based on virtual address mapping
US7779254B1 (en) 2005-12-21 2010-08-17 Rockwell Collins, Inc. Mechanism to enhance and enforce multiple independent levels of security in a microprocessor memory and I/O bus controller
US20110010483A1 (en) 2007-06-28 2011-01-13 Nokia Corporation Memory protection unit in a virtual processing environment
CN102184373A (zh) 2011-05-30 2011-09-14 南京大学 基于保护模式与虚拟化机制实现操作系统安全核设计方法
CN102339229A (zh) 2010-07-15 2012-02-01 戴元顺 基于操作系统层的虚拟化方法
US20120331465A1 (en) 2011-03-02 2012-12-27 Tadao Tanikawa Virtual machine system, virtual machine control method, virtual machine control application, and semiconductor integrated circuit
CN102982001A (zh) 2012-11-06 2013-03-20 无锡江南计算技术研究所 众核处理器及其空间访问的方法、主核

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6233667B1 (en) * 1999-03-05 2001-05-15 Sun Microsystems, Inc. Method and apparatus for a high-performance embedded memory management unit
US6598144B1 (en) 2001-12-12 2003-07-22 Advanced Micro Devices, Inc. Arrangement for limiting access to addresses by a consumer process instigating work in a channel adapter based on virtual address mapping
US7779254B1 (en) 2005-12-21 2010-08-17 Rockwell Collins, Inc. Mechanism to enhance and enforce multiple independent levels of security in a microprocessor memory and I/O bus controller
US20110010483A1 (en) 2007-06-28 2011-01-13 Nokia Corporation Memory protection unit in a virtual processing environment
CN102339229A (zh) 2010-07-15 2012-02-01 戴元顺 基于操作系统层的虚拟化方法
US20120331465A1 (en) 2011-03-02 2012-12-27 Tadao Tanikawa Virtual machine system, virtual machine control method, virtual machine control application, and semiconductor integrated circuit
CN102184373A (zh) 2011-05-30 2011-09-14 南京大学 基于保护模式与虚拟化机制实现操作系统安全核设计方法
CN102982001A (zh) 2012-11-06 2013-03-20 无锡江南计算技术研究所 众核处理器及其空间访问的方法、主核

Also Published As

Publication number Publication date
EP3070604A1 (fr) 2016-09-21
EP3070604A4 (fr) 2017-03-29
CN104657193B (zh) 2018-07-20
WO2015074512A1 (fr) 2015-05-28
US20160267026A1 (en) 2016-09-15
EP3070604B1 (fr) 2022-08-24
CN104657193A (zh) 2015-05-27

Similar Documents

Publication Publication Date Title
US10180915B2 (en) Method and apparatus for accessing physical resources
JP5736090B2 (ja) 仮想ゲストのメモリ保護の方法、システムおよびコンピュータプログラム
US9971623B2 (en) Isolation method for management virtual machine and apparatus
US10831889B2 (en) Secure memory implementation for secure execution of virtual machines
JP6516860B2 (ja) 計算機システム、及び、アクセス制御方法
US11847225B2 (en) Blocking access to firmware by units of system on chip
KR20180099682A (ko) 가상 머신 감사를 위한 시스템 및 방법들
US10558584B2 (en) Employing intermediary structures for facilitating access to secure memory
US9183391B2 (en) Managing device driver cross ring accesses
US10552345B2 (en) Virtual machine memory lock-down
JP2013073405A (ja) 監視装置、制御方法及び制御プログラム
US10592267B2 (en) Tree structure for storing monitored memory page data
US9032484B2 (en) Access control in a hybrid environment
US9176781B2 (en) Virtual machine system, memory management method, memory management program, recording medium, and integrated circuit
US11301282B2 (en) Information protection method and apparatus
US11704426B1 (en) Information processing system and information processing method
WO2024067479A1 (fr) Procédé de détection de fuite de conteneur, dispositif électronique et système
US11836514B2 (en) System and method of utilizing memory medium fault resiliency with secure memory medium portions
TWI467374B (zh) 運算系統及用於分割記憶體之受保護部分之方法

Legal Events

Date Code Title Description
AS Assignment

Owner name: HUAWEI TECHNOLOGIES CO., LTD., CHINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ZHENG, CHEN;FU, LONG;ZHAN, JIANFENG;AND OTHERS;SIGNING DATES FROM 20160823 TO 20160826;REEL/FRAME:039606/0725

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4