WO2022012201A1 - 切换系统架构的方法与装置 - Google Patents

切换系统架构的方法与装置 Download PDF

Info

Publication number
WO2022012201A1
WO2022012201A1 PCT/CN2021/097850 CN2021097850W WO2022012201A1 WO 2022012201 A1 WO2022012201 A1 WO 2022012201A1 CN 2021097850 W CN2021097850 W CN 2021097850W WO 2022012201 A1 WO2022012201 A1 WO 2022012201A1
Authority
WO
WIPO (PCT)
Prior art keywords
system architecture
service process
service
privilege level
communication interface
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.)
Ceased
Application number
PCT/CN2021/097850
Other languages
English (en)
French (fr)
Inventor
吴宇明
卢方舟
缪勰
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
Priority to EP21843079.1A priority Critical patent/EP4184338A4/en
Publication of WO2022012201A1 publication Critical patent/WO2022012201A1/zh
Priority to US18/154,560 priority patent/US12050896B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/457—Communication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/76—Adapting program code to run in a different environment; Porting
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6281—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database at program execution time, where the protection is within the operating system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5018—Thread allocation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/2113—Multi-level security, e.g. mandatory access control
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 application relates to the field of computer technology, and in particular, to a method and apparatus for switching system architectures.
  • a solution proposed in the prior art is to design multiple system architectures in a computer system, and enable the required system architectures according to application scenarios.
  • implementing one more set of system architectures requires twice as much code, which leads to high code overhead, which is unacceptable in resource-constrained scenarios such as the Internet of Things (IoT).
  • IoT Internet of Things
  • the present application provides a method and device for switching system architectures, which realizes dynamic switching of system architectures through a deformable system architecture, so that switching between different architectures can be realized with only one system architecture, so only one system architecture is needed to realize the switching of different architectures.
  • the code of the architecture can reduce the code overhead.
  • a first aspect provides a method for switching a system architecture, the method comprising: transforming a first system architecture into a second system architecture, the second system architecture representing the system architecture before switching, and the first system architecture representing The system architecture after switching; using the second system architecture to provide services to users.
  • the first system architecture and the second system architecture are mutually deformable, wherein the relationship between the first system architecture and the second system architecture is any one or more of the following situations:
  • the privilege level of the service process in the first system architecture is different from the privilege level of the service process in the second system architecture, and the number of service processes in the first system architecture is different from the number of service processes in the second system architecture. different.
  • the system architecture needs to be switched according to the requirements of the application scenario for the system architecture, and if the system needs to be switched, the deformation of the system architecture is enabled, that is, the dynamic switching of the system architecture is realized. In this way, the requirements of application scenarios for different system architectures can be dynamically met when the system is running.
  • the first system architecture includes a first service process; wherein the transforming the first system architecture into the second system architecture includes: changing the first service The privilege level of the process.
  • Privileges represent the ability to perform security-related functions in a computer.
  • a process with the privilege to perform security-related functions is considered to be running in a privileged state.
  • a process that does not have the privilege to perform security-related functions is considered to be running in an unprivileged state.
  • Privileged state and unprivileged state are different privilege levels, and different levels of privileged state are also different privilege levels.
  • Changing the privilege level of the first service process includes privilege escalation processing and privilege reduction processing.
  • Privilege escalation processing means raising the privilege level of a service process.
  • Downgrade processing means to reduce the privilege level of the service process.
  • the first system architecture is switched to the second system architecture.
  • the privilege level of the first service process in the first system architecture is different from the privilege level of the first service process in the second system architecture.
  • the first service process adopts the mechanism that the data segment supports address-independent relocation and the code segment supports the mechanism of address-independent relocation. created.
  • the mechanism that the code segment supports address-independent relocation means that the service process can be guaranteed to run regardless of whether the address of the code segment of the service process changes. In other words, the service process runs independently of the address of the code segment.
  • the data segment supports address-independent relocation mechanism representation, which means that the service process can be guaranteed to run regardless of whether the address of the data segment of the service process changes. In other words, the operation of the service process is independent of the address of the data segment.
  • the privilege level of the first service process includes a first privilege level state and a second privilege level state, wherein the first privilege level state uses a low address, and the second privilege level state uses a high address;
  • the mechanism for the data segment to support address-independent relocation includes: always mapping the data segment of the first service process to the low address.
  • one of the first privilege level state and the second feature level state represents an unprivileged state, and the other represents a privileged state.
  • the first privilege level state and the second feature level state are both privilege states, and the privilege level of one is higher than the privilege level of the other.
  • High address and low address are common concepts in the computer field.
  • the high address and the low address are relative, that is, relative to the size of the address code.
  • the operation of always mapping the data segment of the first service process to the low address includes: static configuration and dynamic maintenance.
  • the static configuration refers to mapping the data segment of the first service process to a low address through static configuration before the first service process runs.
  • the dynamic maintenance means that when the privilege level of the first service process changes during the running process (ie, the address of the data segment is changed), the dynamic maintenance data segment is still mapped at a low address.
  • the mechanism for the data segment to support address-independent relocation includes performing address translation processing on the data segment of the first service process, so that the data segment of the first service process after the privilege level is changed is the same as the data segment in the privilege level.
  • the data segment before the level change is mapped to the same address;
  • the mechanism for the code segment to support address-independent relocation includes performing address translation processing on the code segment of the first service process, so that the first service process is at the privilege level
  • the code segment after the change is mapped to the same address as the code segment before the privilege level change.
  • the address translation processing may be performed on the code segment and the data segment of the first service process by means of hardware or software.
  • the method of changing the privilege level of a process is to destroy the old process first, and then re-validate the new process. That is, the prior art cannot change the privilege level of the service process during the running process of the service process.
  • a service process is created by adopting the mechanism that the data segment supports the address-independent relocation and the code segment that supports the address-independent relocation, which can support the dynamic change of the privilege level of the service process during the running process of the service process, Therefore, the dynamic switching of the system architecture can be realized by dynamically changing the privilege level of the service process.
  • the system architecture itself may be configured to allow different privilege levels to use the same address space.
  • the dynamic deformation of the service process is realized through the dynamic change of the privilege level of the service process, thereby realizing the dynamic deformation of the system architecture, and therefore, the dynamic switching of the system architecture can be realized.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not wherein, the transforming the first system architecture into the second system architecture includes: based on the multiple components, splitting the first service process into multiple sub-service processes, wherein each sub-service process includes all One or more components in the multiple components, and the components included in different sub-service processes are different.
  • the data between the multiple components that the first service process is pre-divided into are not coupled, which means that when accessing between these multiple components, member access is performed through the function interface, rather than direct access to resources or shared variables. for direct access.
  • the first service process is divided into multiple sub-service processes, it can be considered that the multiple components are divided into multiple subsets as a whole, and each subset can be isolated as a new The service process (that is, the child service process obtained by splitting the first service process).
  • the switching of the first system architecture to the second system architecture is realized.
  • the number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • the first system architecture includes a second service process and a third service process
  • the transforming the first system architecture into the second system architecture includes: transforming the second service process Merge with the third service process into the first service process.
  • the first service process is pre-divided into multiple components, and the data between the multiple components is not coupled; and the second service process and the third service process are respectively composed of some of the multiple components.
  • the components included in the service process and the third service process are different.
  • Combining the second service process and the third service process into the first service process can be regarded as the first service process combining the components in the second service process with the components in the third service process.
  • the first system architecture is switched to the second system architecture.
  • the number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • the dynamic deformation of the service process is realized through the dynamic change of the number of the service process, thereby realizing the dynamic deformation of the system architecture, and therefore, the dynamic switching of the system architecture can be realized.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupling; wherein the transforming the first system architecture into the second system architecture includes: based on the multiple components, splitting the first service process into multiple sub-service processes, and changing the multiple sub-service processes the privilege level of one or more sub-service processes in the second, so that the privilege level of the one or more sub-service processes is different from the privilege level of the first service process, wherein each sub-service process includes one of the multiple components or multiple components, and the components included in different child service processes are different.
  • the privilege level of the one or more sub service processes is different from the privilege level of the first service process, and also belongs to the situation where the privilege level of the first service process changes.
  • the first service process is created by adopting the mechanism that the data segment supports address-independent relocation and the mechanism that the code segment supports address-independent relocation.
  • the mechanism of the data segment supporting address-independent relocation and the code segment supporting the address-independent relocation mechanism refer to the foregoing description, which will not be repeated here.
  • the first system architecture is realized. Switch to the second system architecture.
  • the number of service processes in the first system architecture is different from the number of service processes in the second system architecture, and the privilege levels of the service processes in the first system architecture and the privilege levels of the service processes in the second system architecture are also different.
  • the dynamic deformation of the service process is realized through the dynamic change of the number of service processes and the privilege level, thereby realizing the dynamic deformation of the system architecture, and therefore, the dynamic switching of the system architecture can be realized.
  • the service process can be dynamically deformed at runtime, for example, split deformation, merge deformation, weight elevation deformation, or weight reduction deformation, which can realize dynamic deformation of the system architecture. Therefore, the present application can adaptively adjust the system architecture according to the changes of the application scenarios, so that the requirements for different system architectures of the application scenarios can be dynamically met at runtime.
  • one system architecture can support variants of different architectures, so only one code for implementing the one system architecture is required, thereby reducing code overhead. It should be understood that a piece of code can adjust the system architecture in a finer-grained manner for the application scenario without interrupting the service and the business being offline, so that the switching of the system architecture is more flexible and the noise floor is smaller.
  • the parameter transfer specifications (may be referred to as parameter transfer specifications) of all communication interfaces related to the deformed service process are unified.
  • the communication interface includes any one or more of the following: a function call communication interface, an inter-privilege level communication interface, and an inter-process communication interface.
  • the function call communication interface represents the communication interface corresponding to the function call.
  • the inter-privilege level communication interface represents a communication interface for communication between privilege levels.
  • An inter-process communication interface represents a communication interface for communication between processes.
  • the parameter transfer specifications of all communication interfaces involved in the deformed service process are unified, and the parameter transfer specifications of all communication interfaces of the service process for request calling are unified, and the parameter transfer specifications for all communication interfaces to return results are also unified.
  • the unification of parameter transfer specifications involving all communication interfaces of the deformed service process can also be expressed as the unification of the parameter transfer specifications of the request invocation of each communication interface of the service process and the result returned.
  • the original service when switching the system architecture, the original service will be stopped first, and the new service will be restarted repeatedly. From the business side, the original service request will be interrupted, a new service request needs to be re-initiated, and the service will also have a brief interruption to synchronize the previous state, that is, the existing technology cannot achieve the service when switching the system architecture. of insensitivity.
  • the communication interface includes any one or more of the following: a function call communication interface, an inter-privilege level communication interface, and an inter-process communication interface.
  • the parameter transfer specifications of all the communication interfaces of the first service process are unified; wherein, the communication interface includes any of the following: Or more: function call communication interface, inter-privilege level communication interface and inter-process communication interface.
  • the parameter transfer specifications of all communication interfaces in the first system architecture and all communication interfaces in the second system architecture are unified; wherein, the communication interfaces include the following: Any one or more of: function call communication interface, inter-privilege level communication interface and inter-process communication interface.
  • an apparatus for switching a system architecture includes a switching unit and a processing unit.
  • the switching unit is configured to transform the first system architecture into a second system architecture, where the first system architecture represents the system architecture before switching, and the second system architecture represents the system architecture after switching.
  • the processing unit is configured to provide services for users by using the second system architecture.
  • the relationship between the first system architecture and the second system architecture is any one or more of the following situations: the privilege level of the service process in the first system architecture and the second system architecture
  • the privilege levels of service processes in the first system architecture are different, and the number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • the first system architecture includes a first service process; wherein, the switching unit is configured to change the privilege level of the first service process.
  • the first service process adopts the mechanism that the data segment supports address-independent relocation and the code segment supports the mechanism of address-independent relocation. created.
  • the privilege level of the first service process includes a first privilege level state and a second privilege level state, wherein the first privilege level state uses a low address, and the second privilege level state uses a high address;
  • the mechanism for the data segment to support address-independent relocation includes: always mapping the data segment of the first service process to the low address.
  • the mechanism for the data segment to support address-independent relocation includes performing address translation processing on the data segment of the first service process, so that the data segment of the first service process after the privilege level is changed is the same as the data segment in the privilege level.
  • the data segment before the level change is mapped to the same address;
  • the mechanism for the code segment to support address-independent relocation includes performing address translation processing on the code segment of the first service process, so that the first service process is at the privilege level
  • the code segment after the change is mapped to the same address as the code segment before the privilege level change.
  • the system architecture itself may be configured to allow different privilege levels to use the same address space.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupling; wherein the switching unit is configured to, based on the multiple components, split the first service process into multiple sub-service processes, wherein each sub-service process includes one or more of the multiple components components, and the components included in different child service processes are different.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupling; wherein the switching unit is configured to, based on the multiple components, split the first service process into multiple sub-service processes, and change the privileges of one or more sub-service processes in the multiple sub-service processes level, so that the privilege level of the one or more sub-service processes is different from the privilege level of the first service process, wherein each sub-service process includes one or more of the multiple components, and different sub-service processes The components included are different.
  • the first system architecture includes a first service process; wherein, the switching unit is configured to change the privilege level of the first service process; wherein, the The parameter transfer specifications of all communication interfaces of the first service process are unified; wherein, the communication interfaces include any one or more of the following: a function call communication interface, an inter-privilege level communication interface, and an inter-process communication interface.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupling; the switching unit is configured to, based on the multiple components, split the first service process into multiple sub-service processes, wherein each sub-service process includes one or more of the multiple components , the components included in different sub-service processes are different.
  • the parameter transfer specifications of all communication interfaces of the first service process and all communication interfaces of each sub-service process in the plurality of sub-service processes are unified; wherein, the communication interfaces include any one or more of the following: Function call communication interface, inter-privilege communication interface and inter-process communication interface.
  • the parameter transfer specifications of all communication interfaces in the first system architecture and all communication interfaces in the second system architecture are unified; wherein, the communication interfaces include the following: Any one or more of: function call communication interface, inter-privilege level communication interface and inter-process communication interface.
  • a computer system in a third aspect, includes: a system architecture, the system architecture can be deformed into multiple architectures; a processor for controlling the deformation of the system architecture, and using the system architecture A variant architecture provides services.
  • the processor is configured to: transform the first system architecture into a second system architecture, where the first system architecture represents the system architecture before switching, and the second system architecture The architecture represents the system architecture after the handover; the second system architecture is used to provide services to users.
  • the relationship between the first system architecture and the second system architecture is any one or more of the following situations: the privilege level of the service process in the first system architecture and the second system architecture
  • the privilege levels of service processes in the first system architecture are different, and the number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • the processor is configured to execute the method provided in the first aspect. For a specific description, refer to the description of the first aspect, which will not be repeated here.
  • a data processing device comprising: a memory for storing a program; a processor for executing the program stored in the memory, and when the program stored in the memory is executed, the processor is used for executing the above-mentioned first method in aspect.
  • a computer-readable medium storing program code for execution by a device, the program code comprising for performing the method in the above-mentioned first aspect.
  • a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of the first aspect above.
  • a chip in a seventh aspect, includes a processor and a data interface, the processor reads an instruction stored in a memory through the data interface, and executes the method in the first aspect.
  • the chip may further include a memory, in which instructions are stored, the processor is configured to execute the instructions stored in the memory, and when the instructions are executed, the The processor is configured to perform the method in the first aspect above.
  • the request call and result return of different communication interfaces can be replaced with each other, and this replacement will not cause service interruption, so it can be Realize that the service is not aware when the system architecture is dynamically switched.
  • FIG. 1 is a schematic diagram of a high security system architecture.
  • FIG. 2 is a schematic diagram of a high-performance system architecture.
  • FIG. 3 is a schematic flowchart of a method for switching a system architecture provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of implementing system architecture switching through splitting or merging of service processes in an embodiment of the present application.
  • FIG. 5 is a schematic diagram of implementing system architecture switching by changing the privilege level of a service process in an embodiment of the present application.
  • FIG. 6 is a schematic diagram of a mechanism for supporting address-independent relocation provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of implementing system architecture switching through a split variant or a merge variant of a service process and a change in the privilege level of the service process in an embodiment of the present application.
  • FIG. 8 is a schematic diagram of setting a unified communication interface for parameter transmission specifications in an embodiment of the present application.
  • FIG. 9 is a schematic diagram of an example of a switching system architecture provided by an embodiment of the present application.
  • FIG. 10 is another schematic flowchart of a method for switching a system architecture provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram of dynamic switching of architectures applied to a file system according to an embodiment of the present application.
  • FIG. 12 is a schematic block diagram of an apparatus for switching a system architecture provided by an embodiment of the present application.
  • FIG. 13 is another schematic block diagram of an apparatus for switching a system architecture provided by an embodiment of the present application.
  • FIG. 14 is a schematic diagram of a computer system provided by an embodiment of the present application.
  • FIG. 15 is another schematic diagram of a computer system provided by an embodiment of the present application.
  • the system architecture In order to meet the requirements of high security, the system architecture needs to ensure fine-grained error isolation. The purpose is that when an exception occurs, the abnormal service process behavior will not affect other service processes, or the system architecture needs to ensure that the service process runs in non- privileged state. In order to meet the requirements of high communication performance, the system architecture needs to ensure a certain coupling between service processes, or run the service processes in a privileged state, in order to improve communication efficiency and/or reduce communication overhead. Therefore, in the face of different application requirements, different system architectures need to be designed.
  • the system architecture is usually static, that is, after the system architecture is determined, the system architecture will not change when the system is running.
  • the system architecture is fixed to the high-security system architecture shown in FIG. 1
  • the system architecture is fixed to the high-performance system architecture shown in FIG. 2 .
  • FIG. 1 is a schematic diagram of a high security system architecture.
  • each solid line segment has a separate address space, isolated from each other.
  • the high security system architecture includes microkernel, memory, driver, file system (FS), system services, other services and applications (application, APP).
  • FS file system
  • APP application, APP
  • the system, system services and other services and apps run in an unprivileged state.
  • Memory, file systems, system services, and other services can all be service processes. Because the service process runs in an unprivileged state, system security can be guaranteed.
  • the memory, file system, system services and other services have independent address spaces and are isolated from each other.
  • each service process is isolated (or called decoupling), and when an exception occurs, the abnormal service process behavior will not affect other service processes, which can ensure system security.
  • IPC inter-process call
  • FIG. 2 is a schematic diagram of a high-performance system architecture.
  • each solid line part has an independent address space, isolated from each other.
  • the system architecture includes microkernel, memory, file system, system services, other services, and APP.
  • the microkernel, memory, file system, system services, and other services run in a privileged state
  • the APP runs in an unprivileged state.
  • Memory, file systems, system services, and other services can all be service processes.
  • the service process runs in a privileged state, so that the service process can directly access some hardware registers, which can reduce communication overhead.
  • the memory, file system, system services and other services are located in the same address space. That is, in the system architecture shown in FIG. 2, the service processes are coupled, which can improve the communication performance. However, because service processes are coupled, when a service process behaves incorrectly, other service processes coupled to it will be affected, resulting in system crashes and reduced security resilience.
  • a fixed system architecture can deal with a single application scenario, but with the complexity and change of the application scenario, there may be a problem that the fixed system architecture cannot meet the changes of the application scenario.
  • application scenario 1 when the system interacts with the user (referred to as application scenario 1), it is necessary to prevent abnormal input or attacks, so it is necessary to decouple or isolate the interacting service processes; when the interaction is completed, it is necessary to use the data of the service process for a large number of Computing (referred to as application scenario 2), at this time, it is necessary to improve the communication efficiency with the service process as much as possible.
  • application scenario 2 If the system architecture is fixed to the high security system architecture shown in FIG. 1 , the system architecture can meet the requirements of application scenario 1, but cannot meet the requirements of application scenario 2. If the system architecture is fixed to the high-performance system architecture shown in FIG. 2 , the system architecture can meet the requirements of application scenario 2, but cannot meet the requirements of application scenario 1.
  • the present application provides a solution for switching system architectures, which realizes dynamic switching of system architectures through a deformable system architecture, so that switching between different architectures can be realized with only one system architecture. Compared with the prior art, the code overhead can be reduced.
  • the core of a computer is the central processing unit (CPU), which undertakes all computing tasks, while the operating system is the manager of the computer, which is responsible for task scheduling, resource allocation and management, and oversees the entire computer hardware.
  • An application application, APP is a program with a certain function, and the program runs on the operating system.
  • a process is a dynamic execution process of a program with certain independent functions on a data set. It is an independent unit for the operating system to allocate and schedule resources, and it is the carrier of the application program.
  • Dynamic a process is an execution process of a program, it is temporary, has a lifetime, is dynamically generated, and dynamically dies;
  • a process is an independent unit for the system to allocate and schedule resources
  • Structural A process consists of three parts: program, data and process control blocks.
  • the process running is dynamic.
  • the process context is a static description of a certain moment in the dynamic process of the process running.
  • the static description at a certain moment includes all the states of the CPU related to the process at this moment, for example, usually includes the general registers of the process at this moment, the status of the status register (saved program status register, SPSR), etc.
  • SPSR represents the register/program status register that saves program status (including privilege level) in ARM.
  • the process context is all the CPU states related to the process at this moment.
  • one process corresponds to one service.
  • a process corresponding to a service can be called a service process. It should be understood that a service process is different from a process corresponding to an application program (APP).
  • APP application program
  • the embodiments of the present application relate to a process corresponding to a service, and therefore, the process is described as a "service process" in this document. That is to say, the service process mentioned in the embodiments of the present application represents the process corresponding to the service.
  • a component is a collection of code and data.
  • a service process may be divided into multiple components, some of the multiple components may form a new service process, and the remaining components may form another new service process.
  • the service process can be transformed (split) into multiple new service processes.
  • the split service processes can also be reversed (merged) as The original service process. That is, the splitting and merging of components within a service process is reversible.
  • a service process 1 is divided into component 1.1, component 1.2, component 1.3, and component 1.4.
  • a variant process is that component 1.1 and component 1.2 form service process 1.1, and component 1.3 and component 1.4 form service process 1.2, that is, service process 1 is split into service process 1.1 and service process 1.2.
  • the inverse transformation process is that the component 1.1, the component 1.2, the component 1.3, and the component 1.4 can be merged into the service process 1 again, that is, the service process 1.1 and the service process 1.2 are merged into the service process 1.
  • Embodiment 1 please refer to the description of Embodiment 1 below.
  • Privileges represent the ability to perform security-related functions in a computer.
  • a process with the privilege to perform security-related functions is considered to be running in a privileged state.
  • a process that does not have the privilege to perform security-related functions is considered to be running in an unprivileged state.
  • Privileged state and unprivileged state are different privilege levels.
  • privilege levels include user mode (exception level 0, EL0) and kernel mode (exception level 1, EL1), or trusted execution environment (trusted execution environment, TEE) and general execution environment (rich execution environment). environment, REE).
  • the privilege level includes the user mode authority (ring3) and the privileged mode authority (ring0), and the Intel system can also divide the privilege level into the root mode (Root mode) and the non-root mode (Non-root mode). )Wait.
  • the privilege level of an AMD system may include a guest mode and a host mode.
  • the commands for communication between privilege levels are different.
  • the command for communication between privilege levels in ARM system can be SVC (supervisor call), HVC (hypervisor call) or SMC (secure monitor call);
  • the command for communication between privilege levels in x86 system is INT 80 or system call (syscall) instructions, etc.
  • SVC is the communication mode between the user (EL0) and the kernel mode (EL1) under the ARM architecture, for example, the communication mode of the system call.
  • HVC is the communication mode of EL0, EL1 and EL2 under the ARM architecture.
  • SMC is the communication method of EL0, EL1 and EL3 under the ARM architecture.
  • EL represents the permission level restrictions under the ARM architecture, where EL0 represents the user mode, and EL1, EL2 and EL3 represent the restrictions on different permissions in the kernel mode.
  • Interprocess communication represents the way in which messages are propagated or exchanged between different processes in a computer system.
  • the kernel needs to provide an implementation of inter-process communication.
  • a communication interface for communication between processes may be referred to as an inter-process communication interface (may be referred to as an IPC interface for short).
  • Communication between privileged levels means the communication between the privileged state and the unprivileged state.
  • a communication interface for communication between privilege levels may be referred to as an inter-privilege level communication interface.
  • a function call means that a function is used to complete a related command when the computer compiles or runs.
  • the communication interface corresponding to the function call may be referred to as a function call communication interface.
  • FIG. 3 is a schematic flowchart of a method for switching a system architecture provided by an embodiment of the present application.
  • the execution body of the method is a processor.
  • the method includes steps S310 and S320.
  • the first system architecture and the second system architecture can be mutually deformed, wherein the relationship between the first system architecture and the second system architecture is any one or more of the following situations:
  • the privilege level is different from the privilege level of the service process in the second system architecture, and the number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • the current system architecture is the first system architecture
  • the first system architecture when it is necessary to switch from the first system architecture to the second system architecture, the first system architecture is transformed into the second system architecture, thereby realizing the transition from the first system architecture to the second system architecture.
  • System architecture switching In this case, the first system architecture represents the system architecture before switching, and the second system architecture represents the system architecture after switching.
  • the second system architecture when it is necessary to switch from the second system architecture to the first system architecture, the second system architecture is transformed into the first system architecture, so as to realize the transformation from the second system architecture to the first system architecture. Switch to the first system architecture.
  • the second system architecture represents the system architecture before the handover
  • the first system architecture represents the system architecture after the switchover.
  • the first system architecture is transformed into the second system architecture as an example for description.
  • Transforming the first system architecture into the second system architecture means that the second system architecture is obtained by transforming the first system architecture.
  • the first system architecture and the second system architecture may be regarded as different variants of the same system architecture.
  • one system architecture may support multiple variants, for example, two or more variants.
  • the embodiments of the present application take two variants of the first system architecture and the second system architecture as examples for description.
  • the names of the first system architecture and the second system architecture are only to distinguish the system architectures before and after the handover, and there is no special limitation.
  • the first system architecture represents a high security system architecture
  • the second system architecture represents a high performance system architecture, or vice versa.
  • the switching mode of the system architecture can be determined according to application requirements.
  • Providing services to users mentioned in this article can also be expressed as providing services to application programs (APPs).
  • APPs application programs
  • service process 1 it is the service process in the first system architecture (denoted as service process 1) to provide services
  • service process 2 it is the service process in the second system architecture (denoted as service process 2) Provide services.
  • the service provided by service process 1 corresponds to the same service logically as the service provided by service process 2.
  • the service process 1 provides services to the APP1
  • the service process 2 provides services to the APP1.
  • the service process 1 and the service process 2 mentioned here can be mutually deformed, which will be described below.
  • the dynamic switching of the system architecture is realized through the deformable system architecture, so that the switching of different architectures can be realized only by implementing one system architecture.
  • the code overhead can be reduced.
  • the embodiments of the present application can not only implement dynamic switching of the system architecture, but also reduce code overhead.
  • step S310 it may be determined whether the system architecture needs to be switched according to the application scenario, and if the system needs to be switched, the deformation of the system architecture is enabled.
  • the current system architecture is the first system architecture
  • the first system architecture ie, the current system architecture
  • the second system architecture represents a high-performance system architecture. If the current application scenario has high requirements on the communication efficiency of the system, it is necessary to switch the system architecture, that is, the first system architecture is transformed into the second system architecture. It should be understood that if the current application scenario has higher requirements on the security of the system, in this case, there is no need to switch the system architecture.
  • the second system architecture is a variant of the first system architecture, that is, the second system architecture is different from the first system architecture.
  • the differences between the second system architecture and the first system architecture may include any one or more of the following situations: the number of service processes is different, and the privilege levels of the service processes are different.
  • splitting or merging of service processes changes in the privilege level (escalation or demotion) of service processes.
  • changes in the privilege level (escalation or demotion) of service processes may be included.
  • Embodiment 1 Split deformation or merge deformation of service process
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between multiple components is not coupled; step S310 includes: based on the multiple components components, the first service process is divided into multiple sub-service processes, wherein each sub-service process includes one or more components among the multiple components, and different sub-service processes include different components.
  • the data between the multiple components that the first service process is pre-divided into are not coupled, which means that when these multiple components are called, member access is performed through the function interface, rather than direct access to resources or shared variables. for direct access.
  • the first service process is divided into multiple sub-service processes. It can be considered that the multiple components are divided into multiple subsets as a whole, and each subset can be isolated as a new service process ( That is, the child service process obtained by splitting the first service process).
  • multiple service processes obtained by splitting the first service process are recorded as multiple sub-service processes.
  • the service process 1 is pre-divided into three components: component 1, component 2 and component 3, wherein the data between component 1, component 2 and component 3 are not coupled.
  • Component 1 and component 2 can form a new service process: service process 1.1
  • component 3 can form a new service process: service process 1.2. Because the addresses of different processes are different, that is, the processes are isolated. Therefore, it can be considered that component 1 and component 2 are isolated as service process 1.1, and component 3 is isolated as service process 1.2.
  • the service process 1 can be split and transformed into a service process 1.1 and a service process 1.2.
  • service process 1.1 and service process 1.2 are also reversibly deformed into service process 1.
  • the service process 1.1 and the service process 1.2 can be merged and transformed into the service process 1 .
  • the service process 1 in FIG. 4 may correspond to the first service process, and the service process 1.1 and the service process 1.2 in FIG. 4 may correspond to multiple sub-service processes divided by the first service process.
  • the system architecture when the first service process is not split and deformed is regarded as the first system architecture
  • the system architecture after the first service process is split and deformed is regarded as the second system architecture. That is to say, the switching of the system architecture (switching from the first system architecture to the second system architecture) is realized through the splitting and deformation of the service process.
  • the switching of the first system architecture to the second system architecture is realized.
  • the number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • deformations between service processes are reversible, that is, deformations can be split or merged.
  • the first system architecture includes a second service process and a third service process
  • step S310 includes: merging the second service process and the third service process into a first service process, so as to combine the first service process
  • the system architecture is transformed into the second system architecture.
  • the first service process is pre-divided into multiple components, and the data between the multiple components is not coupled; and the second service process and the third service process are respectively composed of some of the multiple components.
  • the components included in the service process and the third service process are different.
  • Combining the second service process and the third service process into the first service process can be regarded as the first service process combining the components in the second service process with the components in the third service process.
  • the service process 1.1 in FIG. 4 may correspond to the second service process
  • the service process 1.2 in FIG. 4 may correspond to the third service process
  • the service process 1 in FIG. 4 may correspond to the first service process. That is, the second service process and the third service process are merged and transformed into the first service process.
  • the system architecture when the second service process and the third service process are not merged and deformed is regarded as the first system architecture
  • the system architecture after the second service process and the third service process are merged and deformed is regarded as the first system architecture.
  • the first system architecture is switched to the second system architecture.
  • the number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • the dynamic deformation of the service process is realized through the dynamic change of the number of the service process, thereby realizing the dynamic deformation of the system architecture, and therefore, the dynamic switching of the system architecture can be realized.
  • a service process is pre-divided into multiple components whose data are not coupled to each other, and based on these multiple components, the service process can be split and merged and deformed, which is a system architecture that can be deformed to high
  • the safety system architecture which can be transformed into a high-performance system architecture, provides the possibility.
  • Embodiment 2 Change of the privilege level of the service process (transformation of privilege elevation or privilege reduction)
  • the first system architecture includes a first service process; step S310 includes: changing the privilege level of the first service process.
  • Changing the privilege level of the first service process includes privilege escalation processing and privilege reduction processing.
  • Privilege escalation processing means raising the privilege level of a service process.
  • Downgrade processing means to reduce the privilege level of the service process.
  • the privilege level of the first service process can be changed to a privileged state.
  • This variant of the first service process may be referred to as a privilege escalation variant.
  • the initial privilege level of the first service process is a privileged state
  • the privilege level of the first service process can be changed to an unprivileged state.
  • This variant of the first service process may be referred to as a downweight variant.
  • service process 2 in the privileged state is denoted as the service process 2
  • service process 2 in the unprivileged state is denoted as the service process 2 ′.
  • service process 2 can be transformed into privilege escalation, that is, the privilege level of service process 2 is changed from unprivileged state to privileged state; service process 2 can also undergo privilege reduction transformation, that is, the privilege level of service process 2 is changed from privileged state to privileged state. state to unprivileged state.
  • the system architecture when the privilege level of the first service process does not change is regarded as the first system architecture
  • the system architecture after the privilege level of the first service process is changed is regarded as the second system architecture. That is to say, the switching of the system architecture (switching from the first system architecture to the second system architecture) is realized through the transformation of the privilege escalation or the transformation of the lowering of the privilege of the service process.
  • Embodiment 2 by changing the privilege level of the first service process, the first system architecture is switched to the second system architecture.
  • the privilege level of the first service process in the first system architecture is different from the privilege level of the first service process in the second system architecture.
  • the addresses of different privilege levels are different.
  • the privilege level of the service process is changed (delegated or escalated), causing the address (including code address and data address) of the service process to change. , so it will involve the reloading and redirection of the service process.
  • the kernel mode (EL1) runs at a high address
  • the user mode (EL0) runs at a low address.
  • the privilege level of the service process is lowered from the kernel mode to the user mode, its address changes, that is, from high address becomes low address.
  • High address and low address are common concepts in the computer field.
  • the high address and the low address are relative, that is, relative to the size of the address code. This article does not elaborate on this.
  • the first service process It is created using the mechanism that the data segment supports address-independent relocation and the mechanism that the code segment supports address-independent relocation.
  • the mechanism that the code segment supports address-independent relocation means that the service process can be guaranteed to run regardless of whether the address of the code segment of the service process changes. In other words, the service process runs independently of the address of the code segment.
  • the data segment supports address-independent relocation mechanism representation, which means that the service process can be guaranteed to run regardless of whether the address of the data segment of the service process changes. In other words, the operation of the service process is independent of the address of the data segment.
  • an appropriate address-independent relocation mechanism can be selected to create a service process according to the system architecture.
  • the privilege level of the first service process includes a first privilege level state and a second privilege level state, wherein the first privilege level state uses a low address, and the second privilege level state uses a high address; wherein, the data segment supports the address
  • the irrelevant relocation mechanism includes that the data segment of the first service process is always mapped at a low address.
  • one of the first privilege level state and the second feature level state represents an unprivileged state, and the other represents a privileged state.
  • the first privilege level state and the second feature level state are both privilege states, and the privilege level of one is higher than the privilege level of the other.
  • the operations of always mapping the data segment of the first service process to a low address include: static configuration and dynamic maintenance.
  • the static configuration refers to mapping the data segment of the first service process to a low address through static configuration before the first service process runs.
  • the dynamic maintenance means that when the privilege level of the first service process changes during the running process (ie, the address of the data segment is changed), the dynamic maintenance data segment is still mapped at a low address.
  • the mechanism for the data segment to support address-independent relocation includes performing address translation processing on the data segment of the first service process, so that the data segment of the first service process after the privilege level change is the same as the data segment before the privilege level change. Mapping to the same address; the mechanism for the code segment to support address-independent relocation includes performing address translation processing on the code segment of the first service process, so that the code segment of the first service process after the privilege level change is the same as the code segment before the privilege level change.
  • the code segment maps to the same address.
  • the address translation processing may be performed on the code segment and the data segment of the first service process by means of hardware or software.
  • an address processing module (the address processing block shown in (c) in Figure 6) is introduced into the hardware ), so that the high-address code segment can be mapped to the same physical page as the low-address code segment after being processed by the address processing module, so that the high-address data segment can be processed with the low-address data segment after being processed by the address processing module. Mapped to the same physical page. In this way, when the first service process is running, the change of the address of the first service process will not affect the hardware.
  • the method shown in FIG. 6 (c) is to perform address translation processing on the code segment and the data segment of the first service process by means of hardware.
  • the "intermediate translation/address processing" shown in Fig. 6(d) is an intermediate translation
  • the addresses of the code segment and the address segment are translated at the software level and processed into the correct high address and low address, and then the translated address is used to access the hardware MMU.
  • means for translating code and data at the software level include, but are not limited to, using the shadow page table of virtualization technology, the secondary page table, or directly using software to implement translation tables and other means.
  • the method is to perform address translation processing on the code segment and the data segment of the first service process by means of software; If the address of the code and data is processed by the hardware module to achieve the purpose of translating the address, the method is to perform address translation processing on the code segment and the data segment of the first service process by means of hardware.
  • the method of changing the privilege level of a process is to destroy the old process first, and then re-validate the new process. That is, the prior art cannot change the privilege level of the service process during the running process of the service process.
  • a service process is created by adopting the mechanism that the data segment supports the address-independent relocation and the code segment that supports the address-independent relocation, which can support the dynamic change of the privilege level of the service process during the running process of the service process, Therefore, the dynamic switching of the system architecture can be realized by dynamically changing the privilege level of the service process.
  • the system architecture itself may be configured to allow different privilege levels to use the same address space.
  • Mechanisms that support address-independent relocation include: through system configuration, the system architecture itself allows different privilege levels to use the same address space.
  • the memory management unit is configured so that both the user mode (EL0) and the kernel mode (EL1) use the same page table and base register. Under this scheme, no special handling of the compiled binary is required, and changing the privilege level of the process will not have abnormal effects.
  • any one of the four methods shown in (a), (b), (c), and (d) in FIG. 6 can be used to create the first service process, which can support the The privilege level of the first service process is dynamically changed during the running process.
  • the dynamic deformation of the service process is realized through the dynamic change of the privilege level of the service process, thereby realizing the dynamic deformation of the system architecture, and therefore, the dynamic switching of the system architecture can be realized.
  • privilege escalation processing or privilege reduction processing is performed on the process when the process is running.
  • Embodiment 3 the combination of Embodiment 1 and Embodiment 2
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between multiple components is not coupled; step S310 includes: based on multiple components , split the first service process into multiple sub-service processes, and change the privilege level of one or more sub-service processes in the multiple sub-service processes, so that the privilege level of the one or more sub-service processes is the same as the privilege level of the first service process
  • each sub-service process includes one or more components among multiple components, and the components included in different sub-service processes are different.
  • the service process 3 is divided into three components in advance: component 1, component 2 and component 3, wherein the data between component 1, component 2 and component 3 is not coupled.
  • the privilege level of the service process 3 is the privileged state.
  • the service process 3 can be transformed into a service process 3.1 and a service process 3.2, wherein the privilege level of the service process 3.1 is a privileged state, and the privilege level of the service process 3.2 is an unprivileged state.
  • Service process 3.1 is formed by component 1 and component 2
  • service process 3.2 is formed by component 3. Because the addresses of different processes are different, that is, the processes are isolated. Therefore, it can be considered that component 1 and component 2 are isolated as service process 3.1, and component 3 is isolated as service process 3.2.
  • the modification of the service process includes not only a change in the number of service processes, but also a change in the privilege level.
  • the deformation of service process 3 to service process 3.1 and service process 3.2 is reversible, that is, service process 3.1 and service process 3.2 are also reversibly deformed into service process 3 .
  • the inverse deformation process includes merge deformation and privilege escalation deformation of the service process.
  • the deformation of service process 3.1 and service process 3.2 can also be regarded as positive deformation, and correspondingly, the deformation of service process 3 to service process 3.1 and service process 3.2 can be regarded as inverse deformation.
  • the privilege level of one or more sub-service processes obtained by splitting the first service process is different from the privilege level of the first service process, and also belongs to the situation where the privilege level of the first service process changes.
  • the first service process is created by adopting the mechanism that the data segment supports address-independent relocation and the mechanism that the code segment supports address-independent relocation.
  • the mechanism of the data segment supporting address-independent relocation and the code segment supporting the address-independent relocation mechanism refer to the foregoing related descriptions, which will not be repeated here.
  • the first system architecture is realized. Switch to the second system architecture.
  • the number of service processes in the first system architecture is different from the number of service processes in the second system architecture, and the privilege levels of the service processes in the first system architecture and the privilege levels of the service processes in the second system architecture are also different.
  • the dynamic deformation of the service process is realized through the dynamic change of the number of service processes and the privilege level, thereby realizing the dynamic deformation of the system architecture, and therefore, the dynamic switching of the system architecture can be realized.
  • FIG. 4 , FIG. 5 and FIG. 7 are only examples and not limitations.
  • Embodiment 1 which of the above-mentioned Embodiment 1, Embodiment 2 and Embodiment 3 is adopted to switch the system architecture can be determined according to the application scenario.
  • the application scenario has high requirements on the security of the system architecture, and the current system architecture is a high-performance system architecture.
  • any one of the following operations can be used to switch the system architecture.
  • the first embodiment is used to split and deform the service process to ensure more fine-grained error isolation. For example, when an exception occurs, the behavior of the erroneous service process will not affect other service processes.
  • the second embodiment is used to degrade the rights of the service process, so that the service process runs in an unprivileged state.
  • the third embodiment is used to perform split deformation and weight reduction deformation (or one of the two) of the service process.
  • the application scenario has high requirements on the communication efficiency of the system architecture, and the current system architecture is a high-security system architecture.
  • any one of the following operations can be used to switch the system architecture.
  • the second embodiment is used to perform privilege escalation deformation of the service process, so that the service process runs in a privileged state. For example, enabling the service process to directly access certain hardware registers to reduce communication overhead,
  • the third embodiment is adopted to carry out the merge deformation and the privilege escalation deformation of the service process (or one of the two).
  • the service process can be dynamically deformed during runtime, for example, split deformation, merge deformation, weight-elevation deformation, or weight-down deformation, which can realize dynamic deformation of the system architecture. Therefore, the present application can adaptively adjust the system architecture according to the changes of the application scenarios, so that the requirements for different system architectures of the application scenarios can be dynamically met at runtime.
  • one system architecture can support variants of different architectures, so only one piece of code is required to implement the one system architecture, thereby reducing code overhead. It should be understood that a piece of code can adjust the system architecture in a finer-grained manner for the application scenario without interrupting the service and the business being offline, so that the switching of the system architecture is more flexible and the noise floor is smaller.
  • the original service when switching the system architecture, the original service will be stopped first, and the new service will be restarted repeatedly. From the business side, the original service request will be interrupted, a new service request needs to be re-initiated, and the service will also have a brief interruption to synchronize the previous state, that is, the existing technology cannot achieve the service when switching the system architecture. of insensitivity.
  • the embodiment of the present application proposes to solve the problem by setting the parameter transfer specification (calling convention) of the communication interface to be unified.
  • the description will be made below.
  • the parameter transfer specification is simply referred to as the parameter transfer specification.
  • the "unification of parameter transmission specifications” mentioned in this article can also be expressed as “parameter transmission specifications are consistent”.
  • the parameter transmission specifications of all communication interfaces involved in the deformed service process are unified.
  • the communication interface includes any one or more of the following: a function call communication interface, an inter-privilege level communication interface, and an inter-process communication interface.
  • the function call communication interface represents the communication interface corresponding to the function call.
  • the inter-privilege level communication interface represents a communication interface for communication between privilege levels.
  • An inter-process communication interface represents a communication interface for communication between processes.
  • the parameter transfer specifications of all communication interfaces involved in the deformed service process are unified, the parameter transfer specifications of all communication interfaces of the service process for request calling are unified, and the parameter transfer specifications for all communication interfaces to return results are also unified.
  • the unification of parameter transfer specifications involving all communication interfaces of the deformed service process can also be expressed as the unification of parameter transfer specifications for request calls and results returned by each communication interface of the service process.
  • the component 1 and the component 2 in the service process 1 communicate through function calls. For example, component 1 dispatches a request to component 2 through a function call, and component 2 returns a result to component 1 through a function call.
  • the function call is initiated, the parameters are passed according to the ARM procedure call standard (APCS) specification, and the callee starts to calculate according to the call information.
  • APCS ARM procedure call standard
  • service process 1 is split into service process 1.1 and service process 1.2, wherein service process 1.1 is formed by component 1, and service process 1.2 is formed by component 2 , and the service process 1.2 (for example, it can be regarded as part of component 2 in service process 1) is demoted to user mode (EL0).
  • service process 1.2 needs to return the result after completing the calculation, it cannot directly return the returned result to the component 1 through the function call (“result return blocked” as shown in (b) in Figure 8).
  • the return result of the service process 1.2 can be returned in the form of an inter-privilege level call To the service process 1.1, as shown in (c.1) in Figure 8.
  • service process 1 is split into service process 1.1 and service process 1.2, wherein service process 1.1 is formed by component 1, and service process 1.2 is formed by component 2 is formed, and both service process 1.1 (for example, can be regarded as part of component 1 in service process 1) and service process 1.2 (for example, can be regarded as part of component 2 in service process 1) are both demoted to user mode ( EL0).
  • service process 1.2 cannot directly return the result to the component 1 through a function call after completing the calculation.
  • the return result of the service process 1.2 can be passed through the inter-process call (IPC ) is returned to the service process 1.1, as shown in (c.2) in Figure 8.
  • half of the requests have been processed when the system architecture is switched, and can continue to be processed after the system architecture is switched.
  • Embodiment 1 The embodiment of the unified parameter transmission specification of the communication interface of the service process can be applied to the above-mentioned Embodiment 1, Embodiment 2 and Embodiment 3.
  • the parameter transfer specifications of all communication interfaces of the first service process and of all communication interfaces of each sub-service process in the multiple sub-service processes are unified; wherein, the communication interfaces include any of the following or Various: function call communication interface, inter-privilege communication interface and inter-process communication interface.
  • the first service process is pre-divided into multiple independent components, and the parameter transmission specifications of the communication interfaces between the components are unified (that is, the communication interfaces of the unified parameter transmission specifications are used for communication between the components) .
  • Multiple independent components represent that the data between each component is not coupled, and the resources are not directly accessed between each other, but member access is performed through the communication interface.
  • the parameter transfer specifications of all communication interfaces of the first service process are unified; wherein, the communication interfaces include any one or more of the following: a function call communication interface, a communication interface between privilege levels and Interprocess communication interface.
  • the parameter transfer specifications of all communication interfaces of the first service process and of all communication interfaces of each service process in multiple service processes are unified; wherein, the communication interfaces include any of the following or Various: function call communication interface, inter-privilege communication interface and inter-process communication interface.
  • FIG. 9 Two mutually deformable system architectures are shown in FIG. 9 : a first system architecture and a second system architecture.
  • A1, A4, and B4 in Figure 9 represent calls between privilege levels;
  • A2, A3, B3, and B5 represent calls between processes.
  • the APP requests service from service process 2 as an example.
  • the service process 2 is pre-divided into a component 1 and a component 2, wherein the data between the component 1 and the component 2 is not coupled (ie, decoupled).
  • the communication interfaces A1, A4, B4, A2, A3, B3, B5 and the function call communication interface between component 1 and component 2 included in the service process 2 before the split and deformed are unified. .
  • APP requests service from service process 2 by calling A1 between privilege levels; service process 2 requests service process 1 through inter-process call A2; after completing the service requested by APP, service process 1 calls A3 returns the service response result to the service process 2, and the service process 2 calls A4 between the privilege levels to return the service response result to the APP.
  • the transformation from the first system architecture to the second system architecture is that the service process 2 is split and transformed into a service process 2.1 and a service process 2.2, wherein the service process 2.1 is composed of the component 1,
  • the service process 2.2 is composed of the component 2.
  • the service process 2.1 continues to run in the kernel mode (EL1), and the service process 2.2 is downgraded and runs in the user mode (EL0).
  • component 2 is responsible for processing APP requests.
  • component 2 requests component 1 through a function call (not shown in FIG. 9 ), and component 1 requests service process through inter-process call A2 1.
  • A1 the communication interface between component 1 and component 2, which is not shown in Figure 9
  • A2 the communication interface between component 1 and component 2, which is not shown in Figure 9
  • A1 the communication interface between component 1 and component 2, which is not shown in Figure 9
  • A2, A3, B3, B5 the inter-privilege level call communication interface
  • A1, A4, B4 inter-privilege level call communication interface
  • service process 1 can directly return the service response result to service process 2.1 through inter-process call B3, and service process 2.1 calls B4 between privilege levels to return the service response result.
  • service process 2.2 can directly return the service response result to the APP by calling B5 between processes.
  • the APP although the implementation of the communication interface used by the inter-privilege level call A1 and the inter-process call B5 is different (it should be understood that this is caused by the dynamic adjustment of the system architecture), for the APP, this is insensitive of. That is to say, the architecture adjustment of the transformation from the first system architecture shown in the left diagram in FIG. 9 to the second system architecture shown in the right diagram in FIG. 9 is service-agnostic.
  • component 1 and component 2 in service process 2 access each other through function calls.
  • service process 2 is split and transformed into service process 2.1 and service process 2.2, service process 2.1 and service process
  • the communication mode between 2.2 is an inter-privileged-level call, which can be understood as the communication mode between component 1 and component 2 in service process 2 is switched from a function call to an inter-privileged-level call.
  • the APP can also directly access the service process 2.2 through an inter-process call.
  • component 1 and component 2 in the service process 2 run in the same address space in the kernel state (EL1), and use function calls to communicate with each other. Access, at this time the communication overhead is minimal, only the time overhead of one function call.
  • the communication method between component 1 and component 2 is changed from function call to communication between privileged levels. At this time, the communication overhead will increase slightly.
  • component 1 and component 2 They are separated into service process 2.1 and service process 2.2 respectively, and service process 2.2 is downgraded to user mode, which can effectively improve the overall security resilience of the system.
  • the first system architecture shown in FIG. 9 may be regarded as a high-performance system architecture
  • the second system architecture shown in FIG. 9 may be regarded as a high-security system architecture.
  • the parameter transfer specifications of all communication interfaces in the first system architecture and all communication interfaces in the second system architecture are unified; wherein, the communication interfaces include any one or more of the following: function call Communication interface, inter-privilege communication interface and inter-process communication interface.
  • the request invocation and result return of different communication interfaces can be replaced with each other.
  • the replacement will not cause service interruption, so that the service can be unaware when the system architecture is dynamically switched.
  • system architecture provided by the embodiments of the present application can be applied to resource-constrained application scenarios such as IoT.
  • the process of realizing dynamic switching of the system architecture may include an offline static part and a runtime dynamic part, wherein the offline static part is the basis for dynamic switching at runtime.
  • the offline static part includes: unified communication interface design and implementation of parameter transmission specification, component resource division, address-independent scheme selection and corresponding implementation.
  • the dynamic part of the runtime mainly includes: the adjustment of resource mapping when the service process undergoes split deformation or merge deformation, the adjustment of the privilege level of the service process when the service process undergoes demotion or escalation deformation, and the adjustment of the communication interface before and after adjustment. switch.
  • ARM's existing function call specification APCS or AAPCS (procedure call standard for the ARM architecture) specifies the order in which the function is passed and participated in the return, and specifies the registers that the caller (Caller) and the callee (Callee) are responsible for saving respectively.
  • AAPCS is a new function call standard for the ARM architecture for arm64.
  • the embodiments of the present application design an inter-privilege-level call and an inter-process call with the same parameter transfer specification.
  • the design unifies the parameter passing specifications of all communication interfaces related to the deformed service process, wherein the communication interfaces include any one or more of the following: function call communication interface, inter-privilege level communication interface and inter-process communication interface .
  • the design unifies the parameter transfer specifications of all function call communication interfaces, privilege level communication interfaces and inter-process communication interfaces in the system.
  • process resources need to be divided into components in advance.
  • the data between the various components is not coupled, and the member access is uniformly performed through the exposed function interface (that is, the direct access to the shared variable is canceled) when called.
  • the code and data of each component are individually mapped centrally at compile time.
  • the resources of service process 1 in FIG. 4 are statically divided into three components: component 1, component 2 and component 3.
  • the code data of each component is mapped centrally.
  • the relocation load when the privilege level of the service process changes, the relocation load will be performed, and its address will change.
  • the kernel mode (EL1) runs at a high address
  • the user mode (EL0) runs at a low address.
  • the privilege level of the service process is lowered from the kernel state to the user state, its address changes from a high address to a low address.
  • any one of the four methods shown in (a), (b), (c), and (d) in FIG. 6 can be used to compile and generate a corresponding executable file.
  • any one of the four methods shown in (a), (b), (c), and (d) in FIG. 6 can be used to compile and generate a corresponding executable file.
  • the service process Before the split deformation, the service process may already be in the state of serving the APP. It is assumed that the component being served in the service process is the component 3 in FIG. 4 ; after step S1040 is completed, the component 3 is located in the service process 1.2. Since the service process 1.1 no longer needs the service APP, the process context is re-initialized to wait for the service state. The service process 1.2 continues to perform service processing according to the process context before the split and deformation. After the processing is completed, the service process 1.2 is responsible for returning the result to the user-mode APP.
  • the kernel decides to perform privilege escalation processing or privilege reduction processing on the service process, it is necessary to modify the status register of the corresponding service process to adjust the corresponding privilege level. Because after step S1030, the process can directly run on EL0 or EL1, so when the privilege level of the process is adjusted, it can continue to run without being affected.
  • each privilege level generally uses its own page table register and context register
  • the scheduler needs to replace the context register and page table of the corresponding privilege level when scheduling processes of different privilege levels. register. For example, when the service process is adjusted from EL1 to EL0, the next time the scheduler schedules the process, it will choose to switch the page table base address register of EL1, and when switching the context, select the stack register corresponding to the privilege level, etc.
  • step S1050 This step is similar to step S1050.
  • the process Before adjusting the privilege level, the process may already be in the service APP state. It is assumed that the process whose privilege level is to be adjusted is the service process 1.1 in (c.1) and (c.2) in FIG. 8 .
  • the service runs in EL1, and the user-mode APP or other services access the service process 1.1 through calls between the privilege levels.
  • the service process 1.1 is adjusted to EL0, as shown in Figure 8 (c.2).
  • the kernel Since the original service is an inter-privileged call (for example, a system call), the kernel needs to modify the context state of the service process 1.1 after adjusting to EL0.
  • the service process 1.1 completes the service, it will use the inter-process call (IPC) to transfer the return result to the kernel, and then the return result will continue to be returned to the caller APP through the inter-process call (IPC).
  • IPC inter-process call
  • FIG. 10 is only an example.
  • steps S1030, S1060, S1070 and S1080 in FIG. 10 are optional.
  • the dynamic switching of the system architecture is only achieved through the split deformation or merge deformation of the service process.
  • steps S1020, S1040 and S1050 in FIG. 10 are optional.
  • the dynamic switching of the system architecture is realized only by changing the privilege level of the service process (transformation of privilege elevation or privilege reduction).
  • a deformable system architecture can be flexibly designed according to application requirements. As long as it is a solution for realizing dynamic switching of the system architecture through a deformable system architecture, it all falls within the protection scope of the present application.
  • the embodiments of the present application can be applied to the architectural adjustment of various computer systems.
  • the microkernel architecture In the RTOSv3 version of the wireless RRU scenario, the microkernel architecture is used.
  • the microkernel provides IPC, interrupts and the most basic scheduling functions, in which kernel management, process management, file system, and drivers all run independently in the form of separate processes. By isolating each service process as a separate process, errors between service processes are isolated without affecting the rest of the system.
  • the microkernel itself has been formally verified, and its stability and security are much higher than other service processes. In this way, the system can run stably.
  • a common process is that the user-mode application (APP) needs to write the log (Log) or request the function of the driver service process (drivers), and its path is shown in Figure 11.
  • the APP sends the file descriptor (file descriptor, fd) to the DEV file system service process (devfs), and requests to write a log to the fd.
  • the devfs will parse the fd according to its own knowledge and find the drivers, call the functions of the drivers, and the drivers themselves. Then call the interface of the FAT file system service process (fatfs) to request to write a file to the flash memory (Flash).
  • fatfs is the flash (Flash) file system
  • devfs is the driver file system (FS)
  • microkernel is the verified safe and trusted kernel
  • the drivers are the drivers running in user mode
  • the APP is RRU business software.
  • the system can use the system architecture coupled with the file system (FS Merged architecture), as shown in the left figure in Figure 11.
  • FS Merged architecture By merging devfs and fatfs, the two can synergistically use cache pages in the file system to improve cache utilization; by escalating devfs to kernel mode, devfs can directly access app data.
  • the application request direction Call A1 between privilege levels ⁇ call A2 between privilege levels ⁇ call A3 between privilege levels.
  • this process can be completed with only 3 inter-privilege-level communications.
  • the system architecture can be adjusted to a file system decoupled system architecture (FS Split architecture) at runtime, as shown on the right in Figure 11.
  • FS Split architecture file system decoupled system architecture
  • devfs is demoted to user mode
  • the calling process is inter-process call B1 ⁇ inter-process call B2 ⁇ privilege-level call B3.
  • two IPCs and one inter-privilege-level communication are required.
  • the overhead of two IPCs is higher than the overhead of inter-privilege-level communication, and fatfs and devfs cannot cooperate through function calls.
  • the FS Split architecture can avoid affecting the entire file system when an error occurs in devfs. For example, in this scenario, even if the devfs is wrong, the wrong data will not affect the correctness of the file in Flash at all.
  • the kernel uses the Linux macro kernel.
  • the comparison results of the Linux macro kernel architecture, the Fs Merge architecture and the FS Split architecture shown in Figure 11 in terms of system security are shown in Table 1.
  • Devfs error Affects the entire system Affects only devfs Affects the entire fs
  • Fatfs error Affects the entire system Affects only fatfs Affects the entire fs
  • Table 1 shows that the embodiment shown in FIG. 11 uses the Fs Merge architecture and the FS Split architecture of the microkernel RTOSv3, which can first ensure the stability of the kernel.
  • RTOSv2 Linux kernel since the entire kernel is a macro kernel, and both the driver and the file system run in the kernel, errors in the driver or any file system will affect the entire system, resulting in system crashes and file system errors. Logs, damage to user data and other serious consequences.
  • the splitting or merging of services can be controlled in fine-grained manner. For example, under the FS Split architecture strategy, each file system service is isolated, and the driver is also isolated and lowered, so errors in the file system or driver will only affect the corresponding driver or file system. For another example, under the FS Merge architecture strategy, file system errors will affect the entire file system, but the kernel and drivers are still reliable.
  • the FS Merge architecture strategy may lead to the expansion of the impact of errors, considering that business application scenarios require a large number of file reads and writes during business startup, upgrade, and exit, in these scenarios, there is no longer a relationship between users and users. interaction, so the error probability can be greatly reduced.
  • the system needs to be upgraded or restarted as soon as possible to reduce the downtime of communication services, it is more suitable to use the FS Merge architecture to improve the processing capacity at this time.
  • Table 2 shows the comparison results between the Linux macro kernel architecture and the Fs Merge architecture and FS Split architecture shown in Figure 11 in terms of file system read and write performance.
  • Synchronous random write 2M File 82KB/s 66KB/s 80KB/s
  • Table 2 shows the read and write performance of the file system under the current architecture. As can be seen from Table 2, when the system architecture is adjusted to the FS Merge architecture, the overall performance can be improved by about 20%. It can also be seen from Table 2 that under the FS Merge architecture, the read and write of small files is not much different from the existing technology, and the writing of large files is on par with the existing solutions, which shows that the FS Merge architecture is more in line with the business Large file writing of the scene (log writing in large quantities) and random reading and writing (log management of each module).
  • the solution provided by the embodiments of the present application can adjust the system architecture at any time during operation, so that the product business scenarios can be adapted in more detail, for example, the security resilience of the product can be greatly improved without reducing the business performance.
  • the embodiments of the present application implement dynamic switching of system architectures through a deformable system architecture, so that switching between different architectures can be implemented only by implementing one system architecture. Therefore, only the code used to implement this one system architecture is required. , compared with the prior art, the code overhead can be reduced.
  • the request call and result return of different communication interfaces can be replaced with each other, and this replacement will not cause service interruption, so it can be Realize that the service is not aware when the system architecture is dynamically switched.
  • an embodiment of the present application provides an apparatus 1200 for switching a system architecture.
  • the apparatus 1200 includes a switching unit 1210 and a processing unit 1220 .
  • the switching unit 1210 is configured to transform the first system architecture into a second system architecture, where the first system architecture represents the system architecture before switching, and the second system architecture represents the system architecture after switching.
  • the relationship between the first system architecture and the second system architecture is any one or more of the following situations: the privilege level of the service process in the first system architecture is different from the privilege level of the service process in the second system architecture, The number of service processes in the first system architecture is different from the number of service processes in the second system architecture.
  • the processing unit 1220 is configured to provide services for users by using the second system architecture.
  • the first system architecture includes a first service process; wherein, the switching unit 1210 is configured to change the privilege level of the first service process.
  • the first service process is created by using the mechanism that the data segment supports address-independent relocation and the mechanism that the code segment supports address-independent relocation.
  • the privilege level of the first service process includes a first privilege level state and a second privilege level state, wherein the first privilege level state uses a low address, and the second privilege level state uses a high address; wherein, the data segment supports the address
  • the irrelevant relocation mechanism includes that the data segment of the first service process is always mapped at a low address.
  • the mechanism for the data segment to support address-independent relocation includes performing address translation processing on the data segment of the first service process, so that the data segment of the first service process after the privilege level change is the same as the data segment before the privilege level change. Mapping to the same address; the mechanism for the code segment to support address-independent relocation includes performing address translation processing on the code segment of the first service process, so that the code segment of the first service process after the privilege level change is the same as the code segment before the privilege level change.
  • the code segment maps to the same address.
  • the system architecture itself may be configured to allow different privilege levels to use the same address space.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupled; wherein, the switching unit 1210 is configured to: Based on the multiple components, the first service process is divided into multiple sub-service processes, wherein each sub-service process includes one or more components among the multiple components, and different sub-service processes include different components.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupled; wherein, the switching unit 1210 is configured to: Based on multiple components, the first service process is divided into multiple sub-service processes, and the privilege level of one or more sub-service processes in the multiple sub-service processes is changed, so that the privilege level of one or more sub-service processes is the same as that of the first service process.
  • the privilege levels of the sub-service processes are different, wherein each sub-service process includes one or more components among multiple components, and the components included in different sub-service processes are different.
  • the first system architecture includes a first service process; wherein, the switching unit 1210 is configured to change the privilege level of the first service process; wherein, parameters of all communication interfaces of the first service process are passed The specifications are unified; wherein, the communication interface includes any one or more of the following: a function call communication interface, a communication interface between privilege levels, and an interprocess communication interface.
  • the first system architecture includes a first service process, the first service process is pre-divided into multiple components, and data between multiple components is not coupled; the switching unit 1210 is configured to, based on multiple The first service process is divided into multiple sub-service processes, wherein each sub-service process includes one or more components among the multiple components, and different sub-service processes include different components.
  • the parameter transfer specifications of all communication interfaces of the first service process and all communication interfaces of each sub-service process in the multiple sub-service processes are unified; wherein, the communication interfaces include any one or more of the following: function call communication interface, privileged Inter-level communication interface and inter-process communication interface.
  • the parameter transfer specifications of all communication interfaces in the first system architecture and all communication interfaces in the second system architecture are unified; wherein, the communication interfaces include any one or more of the following: function call communication Interface, inter-privilege communication interface and inter-process communication interface.
  • the apparatus 1200 for switching the system architecture provided in this embodiment of the present application may be a kernel in a computer system.
  • an embodiment of the present application further provides an apparatus 1300 for data processing.
  • the apparatus 1300 includes a processor 1310, the processor 1310 is coupled with a memory 1320, the memory 1320 is used for storing computer programs or instructions, and the processor 1310 is used for executing the computer programs or instructions stored in the memory 1320, so that the methods in the above method embodiments are implemented be executed.
  • the apparatus 1300 may further include a memory 1320 .
  • the apparatus 1300 may further include a data interface 1330, and the data interface 1330 is used for data transmission with the outside world.
  • an embodiment of the present application further provides a computer system 1400 , where the computer system 1400 includes a system architecture 1410 and a processor 1420 .
  • System architecture 1410 may support a variety of architectural variations. In this embodiment, two variants of the system architecture 1410 , the first system architecture 1411 and the second system architecture 1412 , are used as examples for description. The system architecture 1411 and the second system architecture 1412 can be mutually deformed.
  • the processor 1420 is used to control the variation of the system architecture 1410 and provide services using a variation of the system architecture 1410 .
  • the processor 1420 is configured to transform the first system architecture 1411 into the second system architecture 1412, where the first system architecture 1411 represents the system architecture before switching, and the second system architecture 1412 represents the system architecture after switching;
  • the second system architecture 1412 provides services for users.
  • the relationship between the first system architecture 1411 and the second system architecture 1412 is any one or more of the following situations: the privilege level of the service process in the second system architecture 1412 and the privilege level of the service process in the second system architecture 1412 With different privilege levels, the number of service processes in the second system architecture 1412 is different from the number of service processes in the second system architecture 1412 .
  • the processor 1420 may use the method 300 in the above method embodiments to transform the first system architecture 1411 into the second system architecture 1412 .
  • the first system architecture 1411 includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupled; wherein, the processor 1420 is configured to: Based on the multiple components, the first service process is split into multiple sub-service processes, thereby switching the first system architecture 1411 to the second system architecture 1412, wherein each sub-service process includes one or more of the multiple components Components, components included in different child service processes are different.
  • the first system architecture 1411 includes a first service process; wherein, the processor 1420 is configured to change the privilege level of the first service process, thereby switching the first system architecture 1411 to the second system Architecture 1412.
  • the first system architecture 1411 includes a first service process, the first service process is pre-divided into multiple components, and data between the multiple components is not coupled; wherein, the processor 1420 is used for , based on the multiple components, split the first service process into multiple sub-service processes, and change the privilege level of one or more sub-service processes in the multiple sub-service processes, so that the privilege level of the one or more sub-service processes is the same as the first The privilege levels of a service process are different, so that the first system architecture 1411 is switched to the second system architecture 1412, wherein each sub-service process includes one or more components among multiple components, and the components included in different sub-service processes are different .
  • the parameter transfer specifications of all communication interfaces of the first service process and all communication interfaces of each service process in the multiple service processes are unified; wherein, the communication interfaces include any one or more of the following: function call communication interface , Privilege-level communication interface and inter-process communication interface.
  • the parameter transfer specifications of all communication interfaces in the first system architecture 1411 and all communication interfaces in the second system architecture 1412 are unified; wherein, the communication interfaces include any one or more of the following: a function call communication interface, a privilege level Inter-process communication interface and inter-process communication interface.
  • the processor 1420 may use the method shown in FIG. 10 to transform the first system architecture 1411 into the second system architecture 1412 .
  • the processor 1420 may use the method shown in FIG. 10 to transform the first system architecture 1411 into the second system architecture 1412 .
  • an embodiment of the present application further provides a computer system 1500 , where the computer system 1500 includes a processor 1510 , a policy library 1520 , a service process 1530 , and an application program (APP) 1540 .
  • Service processes can be part of kernel functionality, for example, for file systems, memory management, system services, or other services.
  • the policy library 1520 is used to store policies for switching the system architecture.
  • the policy for switching the system architecture stored in the policy library 1520 includes the service process split variant, the service process merge variant, the service process privilege escalation variant, and the service process privilege downgrade variant as mentioned in the above embodiments.
  • the service process 1530 is pre-divided into a plurality of independent components, and data between the components is not coupled.
  • the processor 1510 selects an appropriate system architecture switching strategy according to the input and the strategy stored in the strategy library 1520, and controls the deformation of the service process 1530 according to the selected system architecture switching strategy, so as to realize the dynamic switching of the system architecture (or called dynamic switching). adjust).
  • the input here can be the system architecture requirements of the application scenario.
  • the processor 1510 may also be referred to as a core.
  • the processor 1510 is configured to execute the methods in the above embodiments, for example, the method shown in FIG. 3 or the method shown in FIG. 10 .
  • the communication interface of the service process 1530 and the communication interface between the multiple independent components pre-divided in the service process 1530 are unified in parameter transmission specifications.
  • these communication interfaces include any one or more of the following: a function call communication interface, an inter-privilege level communication interface, and an inter-process communication interface.
  • the parameter transmission specifications of all communication interfaces in the computer system 1500 are unified.
  • Embodiments of the present application further provide a computer-readable medium, where the computer-readable medium stores program codes for device execution, where the program codes include the methods for executing the foregoing embodiments.
  • the embodiments of the present application further provide a computer program product containing instructions, when the computer program product runs on a computer, the computer program product causes the computer to execute the method of the above embodiment.
  • An embodiment of the present application further provides a chip, the chip includes a processor and a data interface, and the processor reads an instruction stored in a memory through the data interface, and executes the method of the above embodiment.
  • the chip may further include a memory, the memory stores instructions, the processor is configured to execute the instructions stored in the memory, and when the instructions are executed, the processor is configured to execute the methods in the foregoing embodiments.
  • the disclosed system, apparatus and method may be implemented in other manners.
  • the apparatus embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented.
  • the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.
  • the functions, if implemented in the form of software functional units and sold or used as independent products, may be stored in a computer-readable storage medium.
  • the technical solution of the present application can be embodied in the form of a software product in essence, or the part that contributes to the prior art or the part of the technical solution.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.
  • the aforementioned storage media include: Universal Serial Bus flash disk (USB flash disk, UFD) (UFD may also be referred to as U disk or USB flash drive), mobile hard disk, read-only memory (read-only memory, ROM), random access Memory (random access memory, RAM), magnetic disk or optical disk and other media that can store program code.
  • USB flash disk UFD
  • UFD Universal Serial Bus flash disk
  • mobile hard disk mobile hard disk
  • read-only memory read-only memory
  • RAM random access Memory
  • magnetic disk or optical disk and other media that can store program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请提供一种切换系统架构的方法与装置，该方法包括：在需要切换系统架构的情况下，将第一系统架构变形为第二系统架构，第一系统架构表示切换之前的系统架构；使用第二系统架构，为用户提供服务。通过可变形的系统架构实现系统架构的动态切换，使得可以只需一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。

Description

切换系统架构的方法与装置
本申请要求于2020年7月16日提交中国专利局、申请号为202010687260.6、申请名称为“切换系统架构的方法与装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，尤其涉及一种切换系统架构的方法与装置。
背景技术
不同的应用场景对计算机系统的安全与通信性能的要求不同。例如，在系统与用户交互的场景下，需要防范异常的输入或攻击，即这种应用场景对系统安全的要求较高，这时的系统架构应该为高安全架构；在系统与用户交互完成后，需要进行大量计算，即这种应用场景对通信效率的要求较高，这时的系统架构应该为高性能架构。因此，面对不同的应用需求，需要设计不同的系统架构。
现有技术提出一种方案，是在计算机系统内设计多种系统架构，根据应用场景使能所需的系统架构。但是，多实现一套系统架构就需要多一倍的代码，这导致代码开销较大，在物联网(internet of things，IoT)这类资源紧张的场景下，这是不可接受的。
发明内容
本申请提供一种切换系统架构的方法与装置，通过可变形的系统架构实现系统架构的动态切换，使得可以只需一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。
第一方面，提供一种切换系统架构的方法，所述方法包括：将第一系统架构变形为第二系统架构，所述第二系统架构表示切换之前的系统架构，所述第一系统架构表示切换之后的系统架构；使用所述第二系统架构，为用户提供服务。
所述第一系统架构与所述第二系统架构之间可互相变形，其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。
应理解，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。
可选地，可以根据应用场景对系统架构的需求，确定是否需要切换系统架构，在需要切换系统的情况下，使能系统架构的变形，即实现动态切换系统架构。这样可以在系统运行时动态满足应用场景对不同的系统架构的需求。
由第一系统架构到第二系统架构的变形方式可以有多种。
结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述将第一系统架构变形为第二系统架构，包括：改变所述第一服务进程的特权级。
特权表示在计算机中执行与安全相关的功能的能力。具有执行安全相关功能特权的进程，被认为运行于特权态。不具有执行安全相关功能特权的进程，被认为运行于非特权态。特权态与非特权态是不同的特权级，不同级别的特权态也是不同的特权级。
改变所述第一服务进程的特权级包括提权处理与降权处理。提权处理表示提升服务进程的特权级。降权处理表示降低服务进程的特权级。
在本实现方式中，通过改变第一服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中第一服务进程的特权级与第二系统架构中第一服务进程的特权级不同。
应理解，通过改变服务进程的特权级，实现了系统架构的动态切换。
可选地，在本实现方式中，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。
代码段支持地址无关的重定位的机制表示，无论服务进程的代码段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与代码段的地址无关。
数据段支持地址无关的重定位的机制表示，表示，无论服务进程的数据段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与数据段的地址无关。
可选地，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。
可选地，第一特权级态与第二特征级态中的一个表示非特权态，另一个表示特权态。
可选地，第一特权级态与第二特征级态均为特权态，其中一个的特权级高于另一个的特权级。
高地址、低地址是计算机领域里通用的概念。高地址与低地址是相对而言的，即相对地址编码的大小而言。
所述将所述第一服务进程的数据段始终映射在所述低地址的操作包括：静态配置与动态维持。静态配置指的是，在所述第一服务进程运行之前，通过静态配置将所述第一服务进程的数据段映射在低地址。动态维护指的是，当在运行过程中所述第一服务进程的特权级发生变化(即引起数据段地址变化)，动态维持数据段仍然映射在低地址。
可选地，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。
可以采用硬件或软件的方式，对所述第一服务进程的代码段与数据段进行地址翻译处理。
现有技术中，改变进程的特权级的方式为，先销毁旧的进程，再重新生效新的进程。即现有技术无法实现在服务进程运行过程中改变服务进程的特权级。
在本申请中，通过采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制来创建服务进程，可以支持在服务进程的运行过程中动态改变服务进程的特权级，从而可以通过动态改变服务进程的特权级实现系统架构的动态切换。
可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实现方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。
应理解，通过服务进程的特权级的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。
结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述将第一系统架构变形为第二系统架构，包括：基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
第一服务进程被预先划分为的多个组件之间的数据不耦合，表示，这多个组件之间进行访问时，通过函数接口进行成员访问，而不是对资源进行直接访问，或者对共享变量进行直接访问。
基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，可以视为，所述多个组件作为一个整体被拆分为多个子集，每个子集可隔离为一个新的服务进程(即由第一服务进程拆分得到的子服务进程)。
在本实现方式中，通过将所述第一服务进程拆分为多个子服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。
应理解，通过服务进程的拆分变形，实现了系统架构的动态切换。
结合第一方面，在一种可能的实现方式中，第一系统架构包括第二服务进程与第三服务进程，所述将第一系统架构变形为第二系统架构，包括：将第二服务进程与第三服务进程合并为第一服务进程。其中，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；且第二服务进程与第三服务进程分别是由该多个组件中的部分组件构成的，第二服务进程与第三服务进程所包括的组件不同。
将第二服务进程与第三服务进程合并为第一服务进程，可以视为，所述第二服务进程中的组件与所述第三服务进程中的组件合并为所述第一服务进程。
在本实现方式中，通过将所述第二服务进程与所述第三服务进程合并为所述第一服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。
应理解，通过服务进程的合并变形，实现了系统架构的动态切换。
还应理解，通过服务进程的数量的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。
结合第一方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述将第一系统架构变形为第二系统架构，包括：基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得 所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，也属于第一服务进程的特权级发生变化的情形。在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。关于数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制，参见前文描述，这里不再赘述。
在本实现方式中，通过将第一服务进程拆分为所述多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同，并且，第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级也不同。
应理解，通过服务进程的数量与特权级的动态变化，实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。
实际应用中，采取上述哪一种或多种变形方式进行系统架构的切换，可以根据应用场景而确定。
在本申请中，服务进程在运行时能够动态变形，例如，拆分变形、合并变形、提权变形或降权变形，这可以实现系统架构的动态变形。因此，本申请可以根据应用场景的变化自适应调整系统架构，从而可以在运行时动态满足应用场景对不同系统架构的需求。
此外，在本申请中，一个系统架构能够支持不同种架构的变形，因此只需用于实现这一个系统架构的一份代码即可，从而可以减小代码开销。应理解，一份代码能够在服务不中断、业务不下线的前提下，针对应用场景较细粒度地调整系统架构，从而使得系统架构的切换更加灵活，底噪更小。
结合第一方面，在一种可能的实现方式中，涉及到变形的服务进程的所有通信接口的参数传递规范(可简称为，传参规范)统一。该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
函数调用通信接口表示函数调用对应的通信接口。特权级间通信接口表示特权级之间进行通信的通信接口。进程间通信接口表示进程之间进行通信的通信接口。
涉及到变形的服务进程的所有通信接口的参数传递规范统一表示，所述服务进程的所有通信接口进行请求调用的传参规范统一，所有通信接口进行结果返回的传参规范也统一。或者，涉及到变形的服务进程的所有通信接口的参数传递规范统一还可以表述为，所述服务进程的各个通信接口的请求调用与结果返回的传参规范统一。
本文提及的“传参规范统一”也可以表述为“传参规范一致”。
在现有的在系统内实现多种系统架构的方案中，当切换系统架构时，原先的服务会先被停掉，新的服务重复重新启动。从业务侧来看，原先的服务请求会被打断，需要重新发起新的服务请求，服务也会有短暂的中断以同步之前的状态，即，现有技术在切换系统架构时无法做到业务的无感知。
在本申请中，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。
还应理解，通过设计参数传递规范统一的通信接口(例如，函数调用通信接口、特权级间通信接口、进程间通信接口)，这样可以摆脱在服务进程发生改变(即系统架构发生改变)后，通信上下文需要同步的问题。因为无需同步通信上下文，因此，可以实现业务无感知。
此外，在系统架构切换时，因为无需进行状态同步，也可以避免引入额外的状态拷贝开销。
可选地，在通过服务进程的拆分变形或合并变形实现系统架构动态切换的实现方式中，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
可选地，在通过服务进程的特权级变化实现系统架构动态切换的实现方式中，所述第一服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
结合第一方面，在一种可能的实现方式中，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
第二方面，提供一种切换系统架构的装置，所述装置包括切换单元与处理单元。所述切换单元，用于将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构。所述处理单元，用于使用所述第二系统架构，为用户提供服务。其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。
结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述切换单元用于，改变所述第一服务进程的特权级。
可选地，在本实现方式中，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。
可选地，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。
可选地，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。
可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实现方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。
结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述切 换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；其中，所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程；其中，所述切换单元用于，改变所述第一服务进程的特权级；其中，所述第一服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
结合第二方面，在一种可能的实现方式中，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。其中，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
结合第二方面，在一种可能的实现方式中，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；其中，所述通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
第三方面，提供一种计算机系统，所述计算系统包括：系统架构，所述系统架构可变形为多种架构；处理器，用于控制所述系统架构的变形，并使用所述系统架构的一种变形架构提供服务。
结合第三方面，在一种可能的实现方式中，所述处理器用于：将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构；使用所述第二系统架构，为用户提供服务。其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。
所述处理器用于执行第一方面提供的方法，具体描述详见第一方面的描述，这里不再赘述。
第四方面，提供一种数据处理的装置，该装置包括：存储器，用于存储程序；处理器，用于执行存储器存储的程序，当存储器存储的程序被执行时，处理器用于执行上述第一方面中的方法。
第五方面，提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述第一方面中的方法。
第六方面，提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述第一方面中的方法。
第七方面，提供一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行上述第一方面中的方法。
可选地，作为一种实现方式，所述芯片还可以包括存储器，所述存储器中存储有指令，所述处理器用于执行所述存储器上存储的指令，当所述指令被执行时，所述处理器用于执行上述第一方面中的方法。
基于上述描述可知，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。
此外，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。
附图说明
图1为高安全系统架构的示意图。
图2为高性能系统架构的示意图。
图3为本申请实施例提供的切换系统架构的方法的示意性流程图。
图4为本申请实施例中通过服务进程的拆分变形或合并变形实现系统架构切换的示意图。
图5为本申请实施例中通过服务进程的特权级的变化实现系统架构切换的示意图。
图6为本申请实施例提供的支持地址无关的重定位的机制的示意图。
图7为本申请实施例中通过服务进程的拆分变形或合并变形，以及服务进程的特权级的变化来实现系统架构切换的示意图。
图8为本申请实施例中设置传参规范统一的通信接口的示意图。
图9为本申请实施例提供的一个切换系统架构的例子的示意图。
图10为本申请实施例提供的切换系统架构的方法的另一示意性流程图。
图11为本申请实施例应用于文件系统的架构动态切换的示意图。
图12为本申请实施例提供的切换系统架构的装置的示意性框图。
图13为本申请实施例提供的切换系统架构的装置的另一示意性框图。
图14为本申请实施例提供的计算机系统的示意图。
图15为本申请实施例提供的计算机系统的另一示意图。
具体实施方式
不同的应用场景对计算机系统(下文简称为系统)的安全与通信性能的要求不同。例如，在系统与用户交互的场景下，需要防范异常的输入或攻击，即这种应用场景对计算机系统的安全的要求较高；在系统与用户交互完成后，需要进行大量计算，即这种应用场景对通信效率的要求较高。
为了满足高安全的要求，系统架构需要保证较细粒度的错误隔离，目的是，当异常发 生时，异常的服务进程行为不会影响到其他服务进程，或者，系统架构需要保证服务进程运行在非特权态。为了满足高通信性能的要求，系统架构需要保证服务进程之间具有一定的耦合，或者将服务进程运行在特权态，目的是，提高通信效率，和/或降低通信开销。因此，面对不同的应用需求，需要设计不同的系统架构。
传统技术中，系统架构通常是静态的，即系统架构确定后，在系统运行时系统架构便不再改变。例如，系统架构固定为图1所示的高安全系统架构，或者，系统架构固定为图2所示的高性能系统架构。
图1为高安全系统架构的示意图。在图1中，每个实线部分拥有独立的地址空间，相互隔离。该高安全系统架构包括微内核、内存、驱动、文件系统(file system，FS)、系统服务、其他服务与应用程序(application，APP)，其中，微内核运行在特权态，内存、驱动、文件系统、系统服务与其他服务与APP运行在非特权态。内存、文件系统、系统服务与其他服务均可以为服务进程。因为服务进程运行在非特权态，则可以保障系统安全。在图1所示系统架构中，内存、文件系统、系统服务与其他服务具有独立的地址空间，互相隔离。即在图1所示系统架构中，各个服务进程之间隔离(或称为解耦)，当异常发生时，异常的服务进程行为不会影响到其他服务进程，这可以保障系统安全。但是，隔离的各个服务进程之间的通信方式为进程间通信(inter-process call，IPC)，这会增大通信开销，降低通信性能。
图2为高性能系统架构的示意图。在图2中，每个实线部分拥有独立的地址空间，相互隔离。该系统架构包括为微内核、内存、文件系统、系统服务、其他服务与APP，其中，微内核、内存、文件系统、系统服务、其他服务运行在特权态，APP运行在非特权态。内存、文件系统、系统服务与其他服务均可以为服务进程。服务进程运行在特权态，使得服务进程可以直接访问某些硬件寄存器，这可以降低通信开销。在图2所示系统架构中，内存、文件系统、系统服务与其他服务位于相同地址空间中。即在图2所示系统架构中，服务进程之间是耦合的，这可以提高通信性能。但是，因为服务进程之间是耦合的，当某一服务进程行为出错时，与之耦合的其他服务进程都会受到影响，从而造成系统崩溃，降低安全韧性。
固定的系统架构可以应对单一的应用场景，但是随着应用场景的复杂多变，可能会出现固定的系统架构无法满足应用场景的变化的问题。
例如，在系统与用户交互(记为应用场景1)时，需要防范异常的输入或攻击，因此需要交互的服务进程之间解耦或隔离；当交互完成后，需要使用服务进程的数据进行大量计算(记为应用场景2)，这时需要尽可能提高与该服务进程的通信效率。若系统架构固定为图1所示的高安全系统架构，该系统架构可以满足应用场景1的需求，但是，不能满足应用场景2的需求。若系统架构固定为图2所示的高性能系统架构，该系统架构可以满足应用场景2的需求，但是不能满足应用场景1的需求。
为了满足复杂多变的应用场景对系统架构的要求，一种在系统内实现多种系统架构的方案被提出来。具体为，在计算机系统内设计多种系统架构，根据应用场景使能所需的系统架构。但是，多实现一套系统架构就需要多一倍的代码，这导致代码开销较大，在物联网(internet of things，IoT)这类资源紧张的场景下，这是不可接受的。
本申请提供一种切换系统架构的方案，通过可变形的系统架构实现系统架构的动态切 换，使得可以只需一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。
为了更好地理解本申请实施例，先描述一些本申请实施例相关的术语。
1、进程(process)
计算机的核心是中央处理器(central processing unit，CPU)，它承担了所有的计算任务，而操作系统是计算机的管理者，它负责任务的调度，资源的分配和管理，统领整个计算机硬件。应用程序(application，APP)是具有某种功能的程序，程序是运行于操作系统之上的。
进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。
进程具有如下特征：
动态性：进程是程序的一次执行过程，是临时的，有生命期的，是动态产生，动态消亡的；
并发性：任何进程都可以同其他进程一起并发执行；
独立性：进程是系统进行资源分配和调度的一个独立单位；
结构性：进程由程序，数据和进程控制块三部分组成。
2、进程上下文
如前文对进程的概念介绍，进程运行是动态的。进程上下文是，进程运行这一动态过程中某一时刻的静态描述。例如，某一时刻的静态描述包括这一时刻与进程相关的CPU所有状态，例如，通常包括这一时刻该进程的通用寄存器、状态寄存器(saved program status register，SPSR)的状态等。SPSR表示ARM中保存程序状态(含特权级)的寄存器/程序状态寄存器。
换句话说，进程运行这一动态若被暂定，则进程上下文为这一时刻与该进程相关的CPU所有状态。
进程上下文被恢复时，CPU可以继续从被暂定的状态继续执行。
3、服务
传统技术中，一个进程对应一个服务。
服务对应的进程可以称为服务进程。应理解，服务进程区别于应用程序(APP)对应的进程。
本申请实施例涉及的是服务对应的进程，因此，在本文中将进程记为“服务进程”。也就是说，本申请实施例中提及的服务进程表示服务对应的进程。
4、组件
本申请实施例中提及的组件表示，进程中最小粒度的处理单元。组件是代码和数据的集合。
在本申请的一些实施例中，一个服务进程可以被划分为多个组件，这多个组件中的部分组件可以形成一个新的服务进程，其余的组件可以形成另一个新的服务进程。换言之，通过将一个服务进程划分为多个组件，可以实现将该服务进程变形(拆分)为多个新的服务进程，反之，拆分出来的多个服务进程也可以逆变(合并)为原服务进程。即一个服务进程内的组件的拆分与合并是可逆的。
假设一个服务进程1被划分为组件1.1、组件1.2、组件1.3、组件1.4。一种变形过程为，组件1.1与组件1.2形成服务进程1.1，组件1.3与组件1.4形成服务进程1.2，即服务进程1被拆分为服务进程1.1与服务进程1.2。逆变形过程为，组件1.1、组件1.2、组件1.3、组件1.4可以重新合并为服务进程1，即服务进程1.1与服务进程1.2合并为服务进程1。具体参加下文中关于实施方式一的描述。
应理解，服务是逻辑概念，服务进程与组件是实体概念。
5、特权级、特权态与非特权态
特权表示在计算机中执行与安全相关的功能的能力。具有执行安全相关功能特权的进程，被认为运行于特权态。不具有执行安全相关功能特权的进程，被认为运行于非特权态。特权态与非特权态是不同的特权级。
在不同操作系统中，特权级的划分与定义不同，特权态与非特权态的含义不同。
例如，在ARM系统中，特权级包括用户态(exception level 0，EL0)与内核态(exception level 1，EL1)，或者，可信执行环境(trusted execution environment，TEE)与通用执行环境(rich execution environment，REE)。
又例如，在x86系统中，特权级包括或用户模式权限(ring3)与特权模式权限(ring0)，Intel系统的还可以划分特权级为根模式(Root mode)与非根模式(Non-root mode)等。
再例如，AMD系统的特权级可以包括访客模式(guest mode)与主机模式(host mode)。
需要说明的是，对于一个操作系统，其特权级、特权态与非特权态的定义与规范为现有技术，本文对此不作详述。
根据操作系统的不同，特权级间通信的命令也不同。例如，ARM系统中的特权级间通信的命令为可以为SVC(supervisor call)、HVC(hypervisor call)或SMC(secure monitor call)；x86系统中的特权级间通信的命令为INT 80或系统调用(syscall)指令等。
SVC为ARM架构下的用户内(EL0)与内核态(EL1)的通信方式，例如，系统调用的通信方式。HVC为ARM架构下EL0、EL1与EL2的通信方式。SMC为ARM架构下EL0、EL1与EL3的通信方式。EL表示ARM架构下的权限级别的限制，其中，EL0表示用户态，EL1、EL2与EL3表示内核态下的不同权限的限制。
6、进程间通信(inter-process call，IPC)
进程间通信表示，计算机系统中不同进程间传播或交换消息的方式。
由于进程之间地址空间隔离，内核需要提供进程间通信的实现。
进程之间进行通信的通信接口可以称为进程间通信接口(可以简称为IPC接口)。
7、特权级间通信
特权级间通信表示，特权态与非特权态之间的通信。
特权级之间进行通信的通信接口可以称为特权级间通信接口。
8、函数调用
函数调用，表示计算机编译或运行时，使用某个函数来完成相关命令。
函数调用对应的通信接口可以称为函数调用通信接口。
下面将结合附图，对本申请中的技术方案进行描述。
图3为本申请实施例提供的切换系统架构的方法的示意性流程图。例如，该方法的执行主体为处理器。该方法包括步骤S310与步骤S320。
S310，将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构。
第一系统架构与第二系统架构之间可互相变形，其中，第一系统架构与第二系统架构之间的关系为下列情况中的任一种或多种：第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级不同，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同。
在当前系统架构为第一系统架构的情况下，当需要由第一系统架构切换为第二系统架构时，将第一系统架构变形为第二系统架构，从而实现由第一系统架构到第二系统架构的切换。这种情况下，第一系统架构表示切换之前的系统架构，第二系统架构表示切换之后的系统架构。
应理解，在当前系统架构为第二系统架构的情况下，当需要由第二系统架构切换为第一系统架构时，将第二系统架构变形为第一系统架构，从而实现由第二系统架构到第一系统架构的切换。这种情况下，第二系统架构表示切换之前的系统架构，第一系统架构表示切换之后的系统架构。
本文中以将第一系统架构变形为第二系统架构为例进行描述。
将第一系统架构变形为第二系统架构，表示，第二系统架构是在第一系统架构的基础上变形得到的。第一系统架构与第二系统架构可以视为是同一个系统架构的不同变形。
应理解，在本申请实施例中，只需实现一个系统架构，该系统架构可以支持多种变形。
需要说明的是，在本申请实施例中，一个系统架构可以支持多种变形，例如两种或两种以上的变形。为了便于描述与理解，本申请实施例中以第一系统架构与第二系统架构这两种变形为例进行描述。
还需要说明的是，第一系统架构与第二系统架构的命名仅为区分切换之前与之后的系统架构，没有特殊限定。例如，第一系统架构表示高安全系统架构，第二系统架构表示高性能系统架构，或者，反过来。实际应用中，可以根据应用需求确定系统架构的切换方式。
S320，使用第二系统架构，为用户提供服务。
本文提及的为用户提供服务，也可以表述为向应用程序(APP)提供服务。
应理解，在系统架构切换之前，是第一系统架构中的服务进程(记为服务进程1)提供服务，在系统架构切换之后，是第二系统架构中的服务进程(记为服务进程2)提供服务。服务进程1提供的服务与服务进程2提供的服务对应逻辑上的同一个服务。例如，系统架构切换之前，由服务进程1向APP1提供服务，系统架构切换之后，由服务进程2向该APP1提供服务。这里提及的服务进程1与服务进程2之间可互相变形，下文将描述。
在本申请实施例中，通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构的代码，相对于现有技术，可以减小代码开销。
应理解，本申请实施例相对于现有技术，不仅可以实现系统架构的动态切换，还可以降低代码开销。
可选地，在步骤S310中，可以根据应用场景，确定是否需要切换系统架构，在需要切换系统的情况下，使能系统架构的变形。
例如，在当前系统架构为第一系统架构的情况下，根据应用场景确定需要由第一系统 架构切换为第二系统架构，则将第一系统架构变形为第二系统架构。
作为一个示例。假设第一系统架构(即当前系统架构)表示高安全系统架构，第二系统架构表示高性能系统架构。若当前应用场景对系统的通信效率要求较高，则当前需要切换系统架构，即由第一系统架构变形为第二系统架构。应理解，若当前应用场景对系统的安全的要求较高，这种情况下无需切换系统架构。
应理解，本申请可以在系统运行时动态满足应用场景对不同的系统架构的需求。
第二系统架构为第一系统架构的变形，也就是说，第二系统架构与第一系统架构不同。第二系统架构与第一系统架构之间的不同之处可以包括下列情况中的任一种或多种：服务进程的数量不同，服务进程的特权级不同。
由第一系统架构到第二系统架构的变形方式可以有多种。例如，可以包括下列任一种或多种：服务进程的拆分或合并，服务进程的特权级的改变(提权或降权)。具体如下文将描述的实施方式一、实施方式二与实施方式三。
实施方式一：服务进程的拆分变形或合并变形
可选地，在一些实施例中，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；步骤S310包括：基于该多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
第一服务进程被预先划分为的多个组件之间的数据不耦合，表示，这多个组件之间进行调用时，通过函数接口进行成员访问，而不是对资源进行直接访问，或者对共享变量进行直接访问。
基于该多个组件，将第一服务进程拆分为多个子服务进程，可以视为，该多个组件作为一个整体被拆分为多个子集，每个子集可隔离为一个新的服务进程(即由第一服务进程拆分得到的子服务进程)。
需要说明的是，为了区分而非限定，将第一服务进程拆分得到的多个服务进程记为多个子服务进程。
作为示例，如图4所示。服务进程1预先被划分为3个组件：组件1、组件2与组件3，其中，组件1、组件2与组件3之间的数据不耦合。组件1与组件2可以形成一个新的服务进程：服务进程1.1，组件3可以形成一个新的服务进程：服务进程1.2。因为不同进程的地址不同，即进程之间是隔离的，因此，可以视为，组件1与组件2隔离为服务进程1.1，组件3隔离为服务进程1.2。如图4所示，服务进程1可以拆分变形为服务进程1.1与服务进程1.2。服务进程1到服务进程1.1与服务进程1.2的变形是可逆的，即服务进程1.1与服务进程1.2也可逆变形为服务进程1。如图4所示，服务进程1.1与服务进程1.2可以合并变形为服务进程1。
图4中的服务进程1可以对应第一服务进程，图4中的服务进程1.1与服务进程1.2可以对应由第一服务进程拆分成的多个子服务进程。
应理解，服务进程的数量增加，必然导致系统架构发生变化。
在本实施例中，将第一服务进程未拆分变形时的系统架构视为第一系统架构，将第一服务进程进行拆分变形后的系统架构视为第二系统架构。也就是说，通过服务进程的拆分变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。
在本实施例中，通过将所述第一服务进程拆分为多个子服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。
应理解，通过服务进程的拆分变形，实现了系统架构的动态切换。
如前文描述，服务进程之间的变形是可逆的，即可以拆分变形，也可以合并变形。
可选地，在一些实施例中，第一系统架构包括第二服务进程与第三服务进程，步骤S310包括：将第二服务进程与第三服务进程合并为第一服务进程，以将第一系统架构变形为第二系统架构。其中，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；且第二服务进程与第三服务进程分别是由该多个组件中的部分组件构成的，第二服务进程与第三服务进程所包括的组件不同。
将第二服务进程与第三服务进程合并为第一服务进程，可以视为，所述第二服务进程中的组件与所述第三服务进程中的组件合并为所述第一服务进程。
继续参见图4，图4中的服务进程1.1可以对应第二服务进程，图4中的服务进程1.2可以对应第三服务进程，图4中的服务进程1可以对应第一服务进程。也就是说，第二服务进程与第三服务进程合并变形为第一服务进程。
应理解，服务进程的数量减少，必然导致系统架构发生变化。
在本实施例中，将第二服务进程与第三服务进程未合并变形时的系统架构视为第一系统架构，将第二服务进程与第三服务进程进行合并变形后的系统架构视为第二系统架构。也就是说，通过服务进程的合并变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。
在本实施例中，通过将所述第二服务进程与所述第三服务进程合并为所述第一服务进程，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量不同于第二系统架构中服务进程的数量。
应理解，通过服务进程的合并变形，实现了系统架构的动态切换。
因此，在本申请实施例中，通过服务进程的数量的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。
还应理解，一个服务进程被预先划分为彼此之间数据不耦合的多个组件，且基于这些多个组件，服务进程可以进行拆分变形与合并变形，这为一个系统架构既可以变形为高安全系统架构，又可以变形为高性能系统架构，提供了可能性。
实施方式二：服务进程的特权级的改变(提权变形或降权变形)
可选地，在一些实施例中，第一系统架构包括第一服务进程；步骤S310包括：改变第一服务进程的特权级。
改变所述第一服务进程的特权级包括提权处理与降权处理。提权处理表示提升服务进程的特权级。降权处理表示降低服务进程的特权级。
假设第一服务进程初始的特权级为非特权态，在需要切换系统架构时，可以将第一服务进程的特权级改为特权态。第一服务进程的这种变形可以称为提权变形。
假设第一服务进程初始的特权级为特权态，在需要切换系统架构时，可以将第一服务进程的特权级改为非特权态。第一服务进程的这种变形可以称为降权变形。
作为示例，如图5所示。在图5中，为了区分而非限定，将位于特权态的服务进程2 记为服务进程2，将位于非特权态的服务进程2记为服务进程2'。如图5所示，服务进程2可以进行提权变形，即服务进程2的特权级由非特权态变为特权态；服务进程2也可以进行降权变形，即服务进程2的特权级由特权态变为非特权态。
应理解，服务进程的特权级发生变化，必然导致系统架构发生变化。
在本实施例中，将第一服务进程的特权级未发生变化时的系统架构视为第一系统架构，将第一服务进程的特权级发生变化后的系统架构视为第二系统架构。也就是说，通过服务进程的提权变形或降权变形，实现了系统架构的切换(由第一系统架构切换为第二系统架构)。
在实施方式二中，通过改变第一服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中第一服务进程的特权级与第二系统架构中第一服务进程的特权级不同。
在本申请实施例中，通过改变服务进程的特权级，实现了系统架构的动态切换。
在某些系统架构下，不同特权级的地址不同，这种情况下，服务进程的特权级改变(降权变形或提权变形)，引起服务进程的地址(包括代码地址与数据地址)发生改变，因此会涉及到服务进程的重新加载与重定向的问题。例如，在ARM架构下，内核态(EL1)运行在高地址，用户态(EL0)运行在低地址，当服务进程的特权级由内核态降权至用户态，其地址发生改变，即由高地址变为低地址。
高地址、低地址是计算机领域里通用的概念。高地址与低地址是相对而言的，即相对地址编码的大小而言。本文对此不作详述。
可选地，在涉及服务进程的特权级发生变化的实施例(例如，在上文描述的实施方式二或实施例方式三)中，在不同特权级的地址不同的情况下，第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。
代码段支持地址无关的重定位的机制表示，无论服务进程的代码段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与代码段的地址无关。
数据段支持地址无关的重定位的机制表示，表示，无论服务进程的数据段的地址是否发生变化，都可以保证服务进程的运行。换句话说，服务进程的运行与数据段的地址无关。
例如，可以根据系统架构，选择合适的地址无关的重定位的机制来创建服务进程。
可选地，第一服务进程的特权级包括第一特权级态与第二特权级态，其中，第一特权级态使用低地址，第二特权级态使用高地址；其中，数据段支持地址无关的重定位的机制包括，将第一服务进程的数据段始终映射在低地址。
可选地，第一特权级态与第二特征级态中的一个表示非特权态，另一个表示特权态。
可选地，第一特权级态与第二特征级态均为特权态，其中一个的特权级高于另一个的特权级。
将第一服务进程的数据段始终映射在低地址的操作包括：静态配置与动态维持。静态配置指的是，在第一服务进程运行之前，通过静态配置将第一服务进程的数据段映射在低地址。动态维护指的是，当在运行过程中第一服务进程的特权级发生变化(即引起数据段地址变化)，动态维持数据段仍然映射在低地址。
作为示例，如图6中(b)所示。配置MMU，使得EL0使用低地址的页表0，EL1使用高地址的页表1。对于代码段，利用类似位置无关可执行程序(position independent  executable，PIE)的手段生成地址无关的代码段。对于数据段，则始终保持映射在低地址的页表0中。在ARM架构中，当服务进程运行时，高地址页表1中的代码可以直接访问低地址页表0中的数据，反之则会被阻止。通过利用这一点，在本申请实施例中，通过保持数据段在低地址，并设置代码段地址无关，则可以在运行时对服务进程进行动态降权与提权，且不会影响程序执行。
换句话说，在图6中的(b)所示的方法中，使用PIE技术生成地址无关可执行文件时，数据段始终映射为低地址。当进程运行在不同特权级EL1/EL0时，仅代码段发生地址改变，数据段始终映射为低地址。
因此，通过图6中(b)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。
可选地，数据段支持地址无关的重定位的机制包括对第一服务进程的数据段进行地址翻译处理，使得第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；代码段支持地址无关的重定位的机制包括对第一服务进程的代码段进行地址翻译处理，使得第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。
可以采用硬件或软件的方式，对所述第一服务进程的代码段与数据段进行地址翻译处理。
作为示例，如图6中(c)与(d)所示。
如图6中(c)所示，在非特权态使用低地址，特权态使用高地址的情况下，在硬件中引入地址处理模块(如图6中(c)所示的地址处理的方框)，使得高地址的代码段经过地址处理模块的处理后能够与低地址的代码段映射到同样的物理页中，使得高地址的数据段经过地址处理模块的处理后能够与低地址的数据段映射到同样的物理页中。这样，在第一服务进程运行时，第一服务进程地址的改变不会对硬件产生影响。
因此，通过图6中(c)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。
应理解，图6中(c)所示方法为采用硬件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理。
如图6中(d)所示，通过对代码和数据进行软件层面的翻译(对应于，图6(d)中所示的“中间翻译/地址处理”为中间翻译)，使得服务进程运行在不同特权级时，代码段与地地址段的地址经过软件层面的翻译，处理为正确的高地址与低地址，再利用翻译后的地址访问硬件的MMU。
例如，对代码和数据进行软件层面的翻译的手段包括但不限于，利用虚拟化技术的影子页表、二级页表、或直接利用软件实现翻译表等手段。
继续参见图6中的(d)，也可以通过对代码与数据进行硬件层面的翻译(对应于，图6(d)中所示的“中间翻译/地址处理”为地址处理)，使得服务进程运行在不同特权级时，代码段与地地址段的地址经过硬件层面的翻译，处理为正确的高地址与低地址，再利用翻译后的地址访问硬件的MMU。
应理解，在图6中(d)中，若通过对代码和数据进行软件层面的翻译，则该方法为采用软件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理；若通过硬件模块对 代码和数据的地址进行处理，以到达翻译地址的目的，则该方法为采用硬件的方式对所述第一服务进程的代码段与数据段进行地址翻译处理。
因此，通过图6中(d)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。
现有技术中，改变进程的特权级的方式为，先销毁旧的进程，再重新生效新的进程。即现有技术无法实现在服务进程运行过程中改变服务进程的特权级。
在本申请中，通过采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制来创建服务进程，可以支持在服务进程的运行过程中动态改变服务进程的特权级，从而可以通过动态改变服务进程的特权级实现系统架构的动态切换。
可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实施方式中，可以配置系统架构本身允许不同特权级使用相同的地址空间。
支持地址无关的重定位的机制包括：通过系统配置，使得系统架构本身允许不同特权级使用相同的地址空间。
如图6中(a)所示，配置内存管理单元(memory management unit，MMU)，使得用户态(EL0)与内核态(EL1)均使用同样的页表和基址寄存器。在这种方案下，不需要对编译的二进制进行特殊处理，改变进程的特权级不会产生异常影响。
因此，通过图6中(a)所示方法，能够保证在进程运行时改变进程的特权级，对代码和数据的访问不受影响。
应理解，图6中(a)所示的方案，使得用户态(EL0)与内核态(EL1)均使用同样的页表和基址寄存器，该方案可能会牺牲硬件提供的安全特性。
应理解，可以采用图6中(a)、(b)、(c)、(d)所示的四种方法中的任一种方法来创建第一服务进程，这样可以支持在第一服务进程运行过程中动态改变第一服务进程的特权级。
通过支持地址无关的重定位的机制，可以支持在运行时调整服务进程的特权级，即可以支持通过调整服务进程的特权级来切换系统架构。
因此，在本实施例中，通过服务进程的特权级的动态变化实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。例如，根据应用场景的变化，在进程运行时对进程进行提权处理或降权处理。
实施方式三，实施方式一与实施方式二的组合
可选地，在一些实施例中，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；步骤S310包括：基于多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得该一个或多个子服务进程的特权级与第一服务进程的特权级不同，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
作为示例，如图7所示。服务进程3预先被划分为3个组件：组件1、组件2与组件3，其中，组件1、组件2与组件3之间的数据不耦合。服务进程3的特权级为特权态。如图7所示，服务进程3可变形为服务进程3.1与服务进程3.2，其中，服务进程3.1的特权级为特权态，服务进程3.2的特权级为非特权态。服务进程3.1由组件1与组件2形成，服务进程3.2由组件3形成。因为不同进程的地址不同，即进程之间是隔离的，因此，可以视为，组件1与组件2隔离为服务进程3.1，组件3隔离为服务进程3.2。可以理解到， 关于服务进程3.2，不仅进行了拆分变形，还进行了降权变形。即，在图7的示例中，服务进程的变形既包括服务进程数量的变化，还包括特权级的变化。
在图7中，服务进程3到服务进程3.1与服务进程3.2的变形是可逆的，即服务进程3.1与服务进程3.2也可逆变形为服务进程3。该逆变形过程包括服务进程的合并变形与提权变形。
应理解，本文中提及的逆变形是个相对概念。例如，在图7中，也可以将服务进程3.1与服务进程3.2的变形视为正变形，相应地，将服务进程3到服务进程3.1与服务进程3.2的变形视为逆变形。
还应理解，服务进程的数量以及特权级发生变化，必然导致系统架构发生变化。
在实施方式三中，第一服务进程拆分得到的一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，也属于第一服务进程的特权级发生变化的情形。在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。关于数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制，参见前文相关描述，这里不再赘述。
在本实施例中，通过将第一服务进程拆分为所述多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，实现了将所述第一系统架构切换为所述第二系统架构。其中，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同，并且，第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级也不同。
因此，在本实施例中，通过服务进程的数量与特权级的动态变化，实现了服务进程的动态变形，从而实现了系统架构的动态变形，因此，可以实现系统架构的动态切换。
应理解，图4、图5与图7仅为示例而非限定。
实际应用中，采取上述实施方式一、实施方式二与实施方式三中的哪一种方式进行系统架构的切换，可以根据应用场景确定。
例如，应用场景对系统架构的安全的要求较高，而当前系统架构为高性能系统架构，这种情形下，可以采用如下操作中的任一种进行系统架构的切换。
1)采用实施方式一进行服务进程的拆分变形，以保证更细粒度的错误隔离，例如，当异常发生时，出错的服务进程行为不会影响到其他服务进程。
2)采用实施方式二进行服务进程的降权变形，使得服务进程运行在非特权态。
3)采用实施方式三进行服务进程的拆分变形与降权变形(或二者之一)。
又例如，应用场景对系统架构的通信效率的要求较高，而当前系统架构为高安全系统架构，这种情形下，可以采用如下操作中的任一种进行系统架构的切换。
1)采用实施方式一进行服务进程的合并变形，可以实现服务进程之间具有耦合，减小通信开销，使得系统达到较好的性能。
2)采用实施方式二进行服务进程的提权变形，使得服务进程运行在特权态。例如，使服务进程可以直接访问某些硬件寄存器，以降低通信的开销，
3)采用实施方式三进行服务进程的合并变形与提权变形(或二者之一)。
基于上述描述可知，在本申请实施例中，服务进程在运行时能够动态变形，例如，拆分变形、合并变形、提权变形或降权变形，这可以实现系统架构的动态变形。因此，本申请可以根据应用场景的变化自适应调整系统架构，从而可以在运行时动态满足应用场景对 不同系统架构的需求。
此外，在本申请实施例中，一个系统架构能够支持不同种架构的变形，因此只需用于实现这一个系统架构的一份代码即可，从而可以减小代码开销。应理解，一份代码能够在服务不中断、业务不下线的前提下，针对应用场景较细粒度地调整系统架构，从而使得系统架构的切换更加灵活，底噪更小。
在现有的在系统内实现多种系统架构的方案中，当切换系统架构时，原先的服务会先被停掉，新的服务重复重新启动。从业务侧来看，原先的服务请求会被打断，需要重新发起新的服务请求，服务也会有短暂的中断以同步之前的状态，即，现有技术在切换系统架构时无法做到业务的无感知。
针对该问题，本申请实施例提出，通过设置通信接口的参数传递规范(calling convention)统一来解决。下面将进行描述。下文中，将参数传递规范简称为传参规范。本文提及的“传参规范统一”也可以表述为“传参规范一致”。
可选地，在上述一些实施例中，涉及到变形的服务进程的所有通信接口的传参规范统一。该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
函数调用通信接口表示函数调用对应的通信接口。特权级间通信接口表示特权级之间进行通信的通信接口。进程间通信接口表示进程之间进行通信的通信接口。
涉及到变形的服务进程的所有通信接口的参数传递规范统一表示，服务进程的所有通信接口进行请求调用的传参规范统一，所有通信接口进行结果返回的传参规范也统一。或者，涉及到变形的服务进程的所有通信接口的参数传递规范统一还可以表述为，服务进程的各个通信接口的请求调用与结果返回的传参规范统一。
通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。下面参照图8进行说明。
如图8中的(a)所示，当服务进程1在内核态(Kernel态，如图8中的EL1)时，服务进程1中的组件1与组件2之间通过函数调用进行通信。例如，组件1通过函数调用的方式向组件2调度请求，组件2通过函数调用的方式向组件1返回结果。当函数调用发起后，参数传递依据ARM函数调用标准(ARM procedure call standard，APCS)规范进行传递，被调用者根据调用信息开始进行计算。
作为一个示例。当发生系统架构调整时，如图8中的(b)所示，服务进程1被拆分为服务进程1.1与服务进程1.2，其中，服务进程1.1由组件1形成，服务进程1.2由组件2形成，并且，服务进程1.2(例如，可以视为服务进程1中的组件2部分)被降权到用户态(EL0)。当服务进程1.2完成计算后需要返回结果时，无法通过函数调用直接将返回结果返回到组件1(如图8中(b)所示的“结果返回受阻”)。
如果设置进程间调用通信接口、特权级间调用通信接口、函数调用通信接口的参数传递规范统一(或称为参数传递规范统一)，则服务进程1.2的返回结果可以通过特权级间调用的形式返回到服务进程1.1，如图8中的(c.1)所示。
作为另一个示例。当发生系统架构调整时，如图8中的(c.2)所示，服务进程1被拆分为服务进程1.1与服务进程1.2，其中，服务进程1.1由组件1形成，服务进程1.2由组件 2形成，并且，服务进程1.1(例如，可以视为服务进程1中的组件1部分)与服务进程1.2(例如，可以视为服务进程1中的组件2部分)均被降权到用户态(EL0)。在现有技术中，若发生如图8中的(c.2)所示的系统架构动态切换，服务进程1.2完成计算后是无法直接通过函数调用将结果返回到组件1的。但是，如果设置进程间调用通信接口、特权级间调用通信接口、函数调用通信接口的参数传递规范统一(或称为参数传递规范统一)，则服务进程1.2的返回结果可以通过进程间调用(IPC)的形式返回到服务进程1.1，如图8中的(c.2)所示。
从上文结合图8的描述可知，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，因此，针对应用程序(APP)的服务请求，可以使用不同的通信方式进行请求调用与结果返回，从而可以实现在系统架构动态切换时业务无感知。
还应理解，通过设计参数传递规范统一的通信接口(例如，函数调用通信接口、特权级间通信接口、进程间通信接口)，这样可以摆脱在服务进程发生改变(即系统架构发生改变)后，通信上下文需要同步的问题。因为无需同步通信上下文，因此，可以实现业务无感知。
例如，在系统架构切换时已经处理到一半的请求，可以在系统架构切换后继续处理。
此外，在系统架构切换时，因为无需进行状态同步，也可以避免引入额外的状态拷贝开销。
服务进程的通信接口的传参规范统一的实施例可以应用于上述的实施方式一、实施方式二与实施方式三。
可选地，在上述实施方式一中，第一服务进程的所有通信接口、多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
在本实施例中，第一服务进程预先被划分为多个独立的组件，且各个组件之间的通信接口的传参规范统一(即各个组件之间使用统一传参规范的通信接口进行通信)。多个独立的组件表示，各个组件之间的数据不耦合，互相之间不直接访问资源，而是通过通信接口进行成员访问。
应理解，在本实施例中，在通过服务进程的拆分变形或合并变形实现系统架构的动态切换时，可以实现业务无感知。
可选地，在上述实施方式二中，第一服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
应理解，在本实施例中，在通过服务进程的特权级的变化实现系统架构的动态切换时，可以实现业务无感知。
可选地，在上述实施方式三中，第一服务进程的所有通信接口、多个服务进程中每个服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
作为示例，如图9所示。图9中示出两种互相可变形的系统架构：第一系统架构与第二系统架构。图9中的A1、A4、B4表示特权级间调用；A2、A3、B3、B5表示进程间调 用。在图9中，以APP向服务进程2请求服务为例。服务进程2预先被划分为组件1与组件2，其中，组件1与组件2之间的数据不耦合(即解耦)。在图9中，通信接口A1、A4、B4、A2、A3、B3、B5以及服务进程2在未拆分变形之前所包括的组件1与组件2之间的函数调用通信接口的传参规范统一。
参见图9中左图。在第一系统架构中，APP通过特权级间调用A1向服务进程2请求服务；服务进程2通过进程间调用A2请求服务进程1；服务进程1在完成APP所请的服务后，通过进程间调用A3将服务响应结果返回给服务进程2，服务进程2通过特权级间调用A4将服务响应结果返回给APP。
参见图9中左图与右图可知，第一系统架构到第二系统架构的变形方式为，服务进程2拆分变形为服务进程2.1与服务进程2.2，其中，服务进程2.1由组件1构成，服务进程2.2由组件2构成，服务进程2.1继续运行在内核态(EL1)，服务进程2.2被进行了降权处理，运行在用户态(EL0)。
假设在服务进程2中，是由组件2负责处理APP的请求。在第一系统架构下，在APP通过特权级间调用A1向服务进程2请求服务后，组件2通过函数调用(图9中未画出)请求组件1，组件1通过进程间调用A2请求服务进程1。假设在此时，动态发生由图9中左图所示第一系统架构变形为图9中右图所示第二系统架构的架构调整。由于函数调用通信接口(组件1与组件2的通信接口，图9中未示出)、进程间调用通信接口(A2、A3、B3、B5)、特权级间调用通信接口(A1、A4、B4)的传参规范统一，因此，在系统架构调整结束时，服务进程1可以直接通过进程间调用B3将服务响应结果返回给服务进程2.1，服务进程2.1通过特权级间调用B4将服务响应结果返回给服务进程2.2，服务进程2.2可以直接通过进程间调用B5将服务响应结果最终返回给APP。对于APP来说，虽然特权级间调用A1与进程间调用B5所使用的通信接口的实现不同(应理解，这是由系统架构的动态调整引起的)，但这对APP来说，是无感知的。也就是说，由图9中左图所示第一系统架构变形为图9中右图所示第二系统架构的架构调整，是业务无感知的。
可知，在图9的示例中，服务进程2中的组件1与组件2之间通过函数调用互相访问，当服务进程2拆分变形为服务进程2.1与服务进程2.2后，服务进程2.1与服务进程2.2之间的通信方式为特权级间调用，可以理解为，服务进程2中的组件1与组件2之间的通信方式由函数调用切换为了特权级间调用。
需要说明的是，在第二系统架构中，APP也可以直接通过进程间调用访问服务进程2.2。
在图9的示例中，系统架构调整之前，即在第一系统架构中，服务进程2中的组件1与组件2运行在内核态(EL1)的同一地址空间中，相互之间使用函数调用进行访问，此时通信开销最小，仅为一个函数调用的时间开销。在系统架构调整之后，即在第二系统架构中，组件1与组件2之间的通信方式由函数调用变为特权级间通信，此时通信开销会略微增大，但是，组件1与组件2分别隔离为服务进程2.1与服务进程2.2，且服务进程2.2被降权至用户态，这样可以有效提升系统整体的安全韧性。
例如，图9中所示的第一系统架构可以视为高性能系统架构，图9中所示的第二系统架构可以视为高安全系统架构。
从图9的示例可知，通过将通信接口的传参规范设置为一致，可以实现，针对同一个 服务请求，可以使用不同的通信方式进行请求调用与结果返回，并且这个过程是业务无感知的。
应理解，在本实施例中，在通过服务进程的拆分变形或合并变形，以及特权级的变化来实现系统架构的动态切换时，可以实现业务无感知。
可选地，在上述一些实施例中，第一系统架构中所有通信接口以及第二系统架构中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
基于上述描述，在本申请实施例中，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。
例如，本申请实施例提供的系统架构可以应用于IoT等资源受限的应用场景。
为了更好地理解本申请实施例，下面结合图10描述一个本申请实施例中实现系统架构动态切换的例子。如图10所示，实现系统架构动态切换的过程可以包括线下的静态部分与运行时的动态部分，其中线下的静态部分是运行时进行动态切换的基础。
线下的静态部分包括：传参规范统一的通信接口设计实现、组件资源划分、地址无关方案选型与对应实现。
运行时的动态部分主要包括：服务进程进行拆分变形或合并变形时对资源映射的调整，服务进程进行降权变形或提权变形时对服务进程的特权级的调整，以及调整前后通信接口的切换。
S1010，设计传参规范统一的通信接口。
以ARM系统为例。ARM现有的函数调用规范APCS或AAPCS(procedure call standard for the ARM architecture)规定了函数传参与返回的顺序，同时规定了调用者(Caller)与被调用(Callee)分别负责保存的寄存器。AAPCS为ARM架构新的函数调用标准，用于arm64。
类似地，本申请实施例设计了相同参数传递规范的特权级间调用与进程间调用。
例如，设计使得涉及到变形的服务进程的所有通信接口的参数传递规范统一，其中，该通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
又例如，设计使得系统中所有的函数调用通信接口、特权级通信接口与进程间通信接口的参数传递规范统一。
当保证进程间调用、特权级间调用、函数调用的函数传递规范一致时，调用者的调用和被调用者的返回可以使用不同的接口。
具体描述，详见前文结合图8的描述，这里不再赘述。
S1020，划分进程资源。
为了满足运行时的动态拆分，进程资源需要提前划分为各个组件。各个组件之间的数据不耦合，调用时统一通过暴露的函数接口进行成员访问(即取消对共享变量的直接访问)。在编译时各组件的代码和数据各自集中映射。
例如，图4中的服务进程1的资源被静态划分为3个组件：组件1、组件2与组件3。各个组件的代码数据各自集中映射。
S1030，实现地址无关。
在某些架构下，当服务进程的特权级改变时会进行重定位加载，其地址会发生改变。例如，在ARM架构下，内核态(EL1)运行在高地址，用户态(EL0)运行在低地址。例如，当服务进程的特权级由内核态降权至用户态，其地址由高地址变为低地址。
为了应对运行时服务进程的特权级发生动态变化，需要结合系统架构选择合适的地址无关方案来编译生成对应的可执行文件。
例如，可以采用图6中(a)、(b)、(c)、(d)所示的四种方法中的任一种来编译生成对应的可执行文件。具体描述详见前文描述，为了简洁，这里不再赘述。
S1050，替换通信接口状态。
拆分变形前，服务进程可能已处于服务APP的状态中，假设该服务进程中正在服务的组件为图4中的组件3；当步骤S1040完成后，组件3位于服务进程1.2中。服务进程1.1由于已不再需要服务APP，因此，进程上下文被重新初始化为等待服务状态。服务进程1.2则依照拆分变形前的进程上下文继续进行服务处理，处理结束后，服务进程1.2负责将结果返回给用户态APP。
S1060，服务进程在变形时，对特权级的调整。
当内核决定对服务进程进行提权处理或降权处理时，需要修改对应服务进程的状态寄存器调整对应的特权级。由于经过步骤S1030，进程可以直接运行在EL0或EL1，因此当进程的特权级被调整后，可以继续运行而不受影响。
S1070，切换服务进程的特权级。
由于一般各特权级使用各自的页表寄存器、上下文寄存器，因此，当进程的特权级被修改后，调度器在调度到不同特权级的进程时，需要更换使用对应特权级的上下文寄存器与页表寄存器。例如当服务进程被从EL1调整为EL0时，在下次调度器调度到该进程时，会选择切换EL1的页表基址寄存器，切换上下文时，选择对应特权级的栈寄存器等。
S1080，替换通信接口状态。
该步骤类似步骤S1050，在调整特权级前，进程可能已处于服务APP状态中，假设要调整特权级的进程为图8中(c.1)与(c.2)中的服务进程1.1。在调整特权级前，服务运行在EL1，用户态APP或其他服务通过特权级间调用访问服务进程1.1。此时，服务进程1.1被调整到了EL0，如图8中(c.2)，由于原有服务为特权级间调用(例如，系统调用)，调整为EL0之后内核需要修改服务进程1.1的上下文状态，当服务进程1.1完成服务后会利用进程间调用(IPC)将返回结果传入内核，然后，返回结果会继续通过进程间调用(IPC)返回给调用者APP。
S1090，切换通信接口。
当通信接口的状态被替换完成后，系统会依据调整后的架构切换后续服务的通信接口。不同特权级间、进程间与进程内的通信方式如图8所示，详见前文描述。
需要说明的是，图10仅为示例。
例如，图10中的步骤S1030、S1060、S1070与S1080是可选的。例如，仅通过服务进程的拆分变形或合并变形来实现系统架构的动态切换。
又例如，图10中的步骤S1020、S1040与S1050是可选的。例如，仅通过服务进程的特权级的改变(提权变形或降权变形)来实现系统架构的动态切换。
实际应用中，可以根据应用需求灵活设计一个可变形的系统架构。只要是通过一个可变形的系统架构实现系统架构的动态切换的方案，都落入本申请的保护范围。
本申请实施例可以应用于各种计算机系统的架构调整。
下面以本申请实施例应用于无线RRU场景RTOSv3版本中文件系统的架构调整为例，进行说明。
在无线RRU场景RTOSv3版本中，采用的是微内核架构。微内核提供IPC、中断和最基础的调度功能，其中内核管理、进程管理、文件系统、驱动均以单独的进程形式独立运行。通过将各个服务进程隔离为单独的进程，服务进程之间的错误会被隔离而不会影响到系统的其它部分。而微内核本身经过了形式化验证，其稳定性与安全性是远高于其它服务进程的，通过这种方式可以保证系统能够稳定运行。
在业务运行过程中，一个常见的流程是用户态的应用程序(APP)需要写日志(Log)或请求驱动服务进程(drivers)的功能，其路径如图11所示。APP将文件描述符号(file descriptor，fd)发送给DEV文件系统服务进程(devfs)，请求向该fd中写入日志，devfs会根据自身的知识解析fd并找到drivers，调用drivers的功能，drivers本身再调用FAT文件系统服务进程(fatfs)的接口请求向闪存(Flash)中写入文件。
如图11所示，fatfs为闪存(Flash)文件系统，devfs为驱动文件系统(file system，FS)，微内核为验证过的安全可信的内核，drivers为运行在用户态的驱动，APP为RRU业务软件。
当业务需要进行大量日志读写时，为了提高效率，系统可以使用文件系统耦合的系统架构(FS Merged架构)，如图11中左图所示。通过将devfs与fatfs合并，两者可以协同使用文件系统中的缓存页，提高缓存利用率；通过将devfs提权到内核态，devfs可以直接访问app的数据，在FS Merged架构下，应用请求方向为特权级间调用A1→特权级间调用A2→特权级间调用A3。在ARM架构下，该过程只需要3次特权级间通信即可完成。
当业务不需要集中进行大量文件写入时，系统架构可在运行时调整为文件系统解耦的系统架构(FS Split架构)，如图11中右图所示。在此场景下，devfs被降权到用户态，调用过程为进程间调用B1→进程间调用B2→特权级间调用B3。可知，在FS Split架构下，需要2次IPC和一次特权级间通信，其中，2次IPC的开销要高于特权级间通信的开销，且fatfs与devfs无法通过函数调用进行协作。虽然牺牲了些许性能，但FS Split架构能够避免devfs中发生错误时影响整个文件系统。例如，在此场景下，即使devfs出错，写错数据也丝毫不会影响Flash中文件的正确性。
在RTOSv2版本中，内核使用的是Linux宏内核，Linux宏内核架构与图11所示的Fs Merge架构、FS Split架构在系统安全方面的对比结果如表1所示。
表1
对比项 (Linux内核的RTOSv2) (微内核RTOSv3)
Fs Split架构 (微内核RTOSv3)
Fs Merge架构
Drivers出错 影响整个系统 仅影响驱动 仅影响驱动
Devfs出错 影响整个系统 仅影响devfs 影响整个fs
Fatfs出错 影响整个系统 仅影响fatfs 影响整个fs
表1表明，图11所示实施例使用微内核RTOSv3的Fs Merge架构与FS Split架构，首先可以保证内核的稳定。在现有技术方案(RTOSv2 Linux内核)中，由于整个内核为宏内核，且驱动与文件系统均运行在内核中，因此驱动或任意文件系统的错误都会影响整个系统，造成系统崩溃、文件系统上日志、用户数据的损坏等严重后果。本实施例中可以细粒度控制服务的拆分或合并。例如，在FS Split架构策略下，各文件系统服务隔离，驱动也隔离降权，因此文件系统中或驱动的错误只会影响对应的驱动或文件系统。又例如，在FS Merge架构策略下，文件系统的错误会影响到整个文件系统，但内核与驱动仍可靠。
虽然FS Merge架构策略可能会导致错误的影响扩大，但是，考虑到业务应用场景具有在业务启动、升级、退出过程中才需要大量的文件读写的特点，在这些场景下已经不存在与用户的交互，因此出错概率可以大大降低。此外，考虑到，此时系统需要尽快完成升级或重启以减少通信服务宕机时间，因而此时使用FS Merge架构以提高处理能力是更为符合场景需求的。
当系统在正常运行过程中，对FS的读写请求减少并且伴有与用户态的大量交互，此时系统更关注服务的可靠性与系统的安全性，因此当系统在升级完成或启动初始化结束后，可以动态将架构调整为FS Split，从而达到更好的错误隔离效果。
Linux宏内核架构与图11所示的Fs Merge架构、FS Split架构在文件系统读写性能方面的对比结果如表2所示。
表2
对比项 (Linux内核RTOSv2) (微内核RTOSv3)
FS Split架构 (微内核RTOSv3)
FS Merge架构
同步写 2M File 72KB/s 62KB/s 72KB/s
同步读 2M File 7478KB/s 5433KB/s 6367KB/s
同步随机写 2M File 82KB/s 66KB/s 80KB/s
同步随机读 2M File 6426KB/s 2784KB/s 3028KB/s
同步写 128K File 81KB/s 80KB/s 105KB/s
同步读 128K File 8247KB/s 5913KB/s 7234KB/s
同步随机写 128K File 78KB/s 87KB/s 103/s
同步随机读 128K File 6402KB/s 5522KB/s 6468KB/s
表2展示了当前架构下文件系统的读写性能。从表2可以看出，当系统架构调整为FS Merge架构后，性能整体能够提升20％左右。从表2还可以看出，在FS Merge架构下，在小块文件读写上与现有技术差别不大，在大块文件的写方面与现有方案持平，这说明FS Merge架构更符合业务场景的大文件写(Log大量写入)与随机读写(各模块Log打点)。本申请实施例提供的方案，在运行时可以随时调整系统架构，从而可以更细致的对产品业务场景进行自适应，例如，可以在业务性能不下降的前提下大大提升产品的安全韧性。
基于上文描述，本申请实施例通过可变形的系统架构实现系统架构的动态切换，使得可以只需实现一个系统架构即可实现不同架构的切换，因此只需用于实现这一个系统架构 的代码，相对于现有技术，可以减小代码开销。
此外，通过设置传参规范统一的通信接口，可以使得不同通信接口(不同通信接口的传参参数规范一致)的请求调用与结果返回可以相互替换，且这种替换不会造成服务中断，从而可以实现在系统架构动态切换时业务无感知。
本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。
上文描述了本申请提供的方法实施例，下文将描述本申请提供的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。
如图12所示，本申请实施例提供一种切换系统架构的装置1200，该装置1200包括：切换单元1210与处理单元1220。
切换单元1210，用于将第一系统架构变形为第二系统架构，第一系统架构表示切换之前的系统架构，第二系统架构表示切换之后的系统架构。其中，第一系统架构与第二系统架构之间的关系为下列情况中的任一种或多种：第一系统架构中服务进程的特权级与第二系统架构中服务进程的特权级不同，第一系统架构中服务进程的数量与第二系统架构中服务进程的数量不同。
处理单元1220，用于使用第二系统架构，为用户提供服务。
可选地，作为一个实施例，第一系统架构包括第一服务进程；其中，切换单元1210用于，改变第一服务进程的特权级。
可选地，在本实施例中，在不同特权级的地址不同的情况下，第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。
可选地，第一服务进程的特权级包括第一特权级态与第二特权级态，其中，第一特权级态使用低地址，第二特权级态使用高地址；其中，数据段支持地址无关的重定位的机制包括，将第一服务进程的数据段始终映射在低地址。
可选地，数据段支持地址无关的重定位的机制包括对第一服务进程的数据段进行地址翻译处理，使得第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；代码段支持地址无关的重定位的机制包括对第一服务进程的代码段进行地址翻译处理，使得第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。
可选地，在通过动态改变服务进程的特权级来实现系统架构的动态切换的实施例中，可以配置系统架构本身允许不同特权级使用相同的地址空间。
可选地，作为另一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
可选地，作为又一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得一个或多个子服务进程的特权级与第一服务进程的特权级不同，其中， 每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
可选地，作为又一个实施例，第一系统架构包括第一服务进程；其中，切换单元1210用于，改变第一服务进程的特权级；其中，第一服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
可选地，作为又一个实施例，第一系统架构包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；切换单元1210用于，基于多个组件，将第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。其中，第一服务进程的所有通信接口、多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
可选地，作为又一个实施例，第一系统架构中所有通信接口以及第二系统架构中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
例如，本申请实施例提供的切换系统架构的装置1200可以为计算机系统中的内核。
如图13所示，本申请实施例还提供一种数据处理的装置1300。该装置1300包括处理器1310，处理器1310与存储器1320耦合，存储器1320用于存储计算机程序或指令，处理器1310用于执行存储器1320存储的计算机程序或指令，使得上文方法实施例中的方法被执行。
可选地，如图13所示，该装置1300还可以包括存储器1320。
可选地，如图13所示，该装置1300还可以包括数据接口1330，数据接口1330用于与外界进行数据的传输。
如图14所示，本申请实施例还提供一种计算机系统1400，该计算机系统1400包括系统架构1410与处理器1420。系统架构1410可以支持多种架构的变形。本实施例中以系统架构1410的两种变形第一系统架构1411与第二系统架构1412为例进行描述。系统架构1411与第二系统架构1412可互相变形。
处理器1420，用于控制系统架构1410的变形，并使用系统架构1410的一种变形架构提供服务。
可选地，处理器1420用于，将第一系统架构1411变形为第二系统架构1412，第一系统架构1411表示切换之前的系统架构，第二系统架构1412表示切换之后的系统架构；使用第二系统架构1412，为用户提供服务。其中，第一系统架构1411与第二系统架构1412之间的关系为下列情况中的任一种或多种：第二系统架构1412中服务进程的特权级与第二系统架构1412中服务进程的特权级不同，第二系统架构1412中服务进程的数量与第二系统架构1412中服务进程的数量不同。
可选地，处理器1420可以采用上文方法实施例中的方法300，将第一系统架构1411变形为第二系统架构1412。
可选地，作为一个实施例，第一系统架构1411包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，处理器1420用于，基于该多个组件，将第一服务进程拆分为多个子服务进程，从而将第一系统架构1411切换为第二 系统架构1412，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
具体参见上文对实施方式一的描述，这里不再赘述。
可选地，作为另一个实施例，第一系统架构1411包括第一服务进程；其中，处理器1420用于，改变第一服务进程的特权级，从而将第一系统架构1411切换为第二系统架构1412。
具体参见上文对实施方式二的描述，这里不再赘述。
可选地，作为又一个实施例，第一系统架构1411包括第一服务进程，第一服务进程被预先划分为多个组件，多个组件之间的数据不耦合；其中，处理器1420用于，基于该多个组件，将第一服务进程拆分为多个子服务进程，并改变多个子服务进程中一个或多个子服务进程的特权级，使得该一个或多个子服务进程的特权级与第一服务进程的特权级不同，从而将第一系统架构1411切换为第二系统架构1412，其中，每个子服务进程包括多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
具体参见上文对实施方式三的描述，这里不再赘述。
可选地，第一服务进程的所有通信接口、多个服务进程中每个服务进程的所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
可选地，第一系统架构1411中所有通信接口以及第二系统架构1412中所有通信接口的参数传递规范统一；其中，通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
具体参见前文相关描述，这里不再赘述。
可选地，处理器1420可以采用图10所示的方法，将第一系统架构1411变形为第二系统架构1412。具体描述，详见上文，这里不在赘述。
如图15所示，本申请实施例还提供一种计算机系统1500，该计算机系统1500包括处理器1510、策略库1520、服务进程1530、应用程序(APP)1540。服务进程可以为内核功能的一部分，例如，为文件系统、内存管理、系统服务或其他服务等。
策略库1520，用于存储切换系统架构的策略。
例如，策略库1520存储的切换系统架构的策略，包括如上文实施例提及的服务进程拆分变形、服务进程合并变形、服务进程提权变形与服务进程降权变形。
服务进程1530被预先划分为多个独立的组件，各个组件之间的数据不耦合。
处理器1510，根据输入与策略库1520存储的策略，选择合适的系统架构切换策略，并根据选出的系统架构切换策略控制服务进程1530的变形，以实现系统架构的动态切换(或称为动态调整)。这里的输入可以为应用场景对系统架构的要求。
处理器1510也可以称为内核。
例如，处理器1510用于执行上文实施例中的方法，例如，图3所示的方法或图10所示的方法。
可选地，服务进程1530的通信接口，以及服务进程1530中预先划分的多个独立组件之间的通信接口传参规范统一。例如，这些通信接口包括下列中任一种或多种：函数调用通信接口、特权级间通信接口与进程间通信接口。
可选地，计算机系统1500内的所有通信接口的传参规范统一。
本申请实施例还提供一种计算机可读介质，该计算机可读介质存储用于设备执行的程序代码，该程序代码包括用于执行上述实施例的方法。
本申请实施例还提供一种包含指令的计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述实施例的方法。
本申请实施例还提供一种芯片，该芯片包括处理器与数据接口，处理器通过数据接口读取存储器上存储的指令，执行上述实施例的方法。
可选地，作为一种实现方式，该芯片还可以包括存储器，存储器中存储有指令，处理器用于执行存储器上存储的指令，当指令被执行时，处理器用于执行上述实施例中的方法。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。
需要说明的是，本文中涉及的第一、第二、第三或第四等各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：通用串行总线闪存盘(USB flash disk，UFD)(UFD也可以简称为U盘或者优盘)、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储 器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (23)

  1. 一种切换系统架构的方法，其特征在于，包括：
    将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构；
    使用所述第二系统架构，为用户提供服务，
    其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。
  2. 如权利要求1所述的方法，其特征在于，所述第一系统架构包括第一服务进程；
    其中，所述将第一系统架构变形为第二系统架构，包括：
    改变所述第一服务进程的特权级。
  3. 如权利要求1所述的方法，其特征在于，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；
    其中，所述将第一系统架构变形为第二系统架构，包括：
    基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
  4. 如权利要求1所述的方法，其特征在于，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；
    其中，所述将第一系统架构变形为第二系统架构，包括：
    基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
  5. 如权利要求2所述的方法，其特征在于，所述第一服务进程的所有通信接口的参数传递规范统一；
    其中，所述通信接口包括下列中任一种或多种：
    函数调用通信接口、特权级间通信接口与进程间通信接口。
  6. 如权利要求3或4所述的方法，其特征在于，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；
    其中，所述通信接口包括下列中任一种或多种：
    函数调用通信接口、特权级间通信接口与进程间通信接口。
  7. 如权利要求1-4中任一项所述的方法，其特征在于，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；
    其中，所述通信接口包括下列中任一种或多种：
    函数调用通信接口、特权级间通信接口与进程间通信接口。
  8. 如权利要求2、4或5中任一项所述的方法，其特征在于，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持 地址无关的重定位的机制创建的。
  9. 如权利要求8所述的方法，其特征在于，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；
    其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。
  10. 如权利要求8所述的方法，其特征在于，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；
    所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。
  11. 一种切换系统架构的装置，其特征在于，包括：
    切换单元，用于将第一系统架构变形为第二系统架构，所述第一系统架构表示切换之前的系统架构，所述第二系统架构表示切换之后的系统架构；
    处理单元，用于使用所述第二系统架构，为用户提供服务，
    其中，所述第一系统架构与所述第二系统架构之间的关系为下列情况中的任一种或多种：所述第一系统架构中服务进程的特权级与所述第二系统架构中服务进程的特权级不同，所述第一系统架构中服务进程的数量与所述第二系统架构中服务进程的数量不同。
  12. 如权利要求11所述的装置，其特征在于，所述第一系统架构包括第一服务进程；
    其中，所述切换单元用于，改变所述第一服务进程的特权级。
  13. 如权利要求11所述的装置，其特征在于，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；
    其中，所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
  14. 如权利要求11所述的装置，其特征在于，所述第一系统架构包括第一服务进程，所述第一服务进程被预先划分为多个组件，所述多个组件之间的数据不耦合；
    其中，所述切换单元用于，基于所述多个组件，将所述第一服务进程拆分为多个子服务进程，并改变所述多个子服务进程中一个或多个子服务进程的特权级，使得所述一个或多个子服务进程的特权级与所述第一服务进程的特权级不同，其中，每个子服务进程包括所述多个组件中的一个或多个组件，不同子服务进程所包括的组件不同。
  15. 如权利要求12所述的装置，其特征在于，所述第一服务进程的所有通信接口的参数传递规范统一；
    其中，所述通信接口包括下列中任一种或多种：
    函数调用通信接口、特权级间通信接口与进程间通信接口。
  16. 如权利要求13或14所述的装置，其特征在于，所述第一服务进程的所有通信接口、所述多个子服务进程中每个子服务进程的所有通信接口的参数传递规范统一；
    其中，所述通信接口包括下列中任一种或多种：
    函数调用通信接口、特权级间通信接口与进程间通信接口。
  17. 如权利要求11-14中任一项所述的装置，其特征在于，所述第一系统架构中所有通信接口以及所述第二系统架构中所有通信接口的参数传递规范统一；
    其中，所述通信接口包括下列中任一种或多种：
    函数调用通信接口、特权级间通信接口与进程间通信接口。
  18. 如权利要求12、14或15中任一项所述的装置，其特征在于，在不同特权级的地址不同的情况下，所述第一服务进程是采用数据段支持地址无关的重定位的机制与代码段支持地址无关的重定位的机制创建的。
  19. 如权利要求18所述的装置，其特征在于，所述第一服务进程的特权级包括第一特权级态与第二特权级态，其中，所述第一特权级态使用低地址，所述第二特权级态使用高地址；
    其中，所述数据段支持地址无关的重定位的机制包括，将所述第一服务进程的数据段始终映射在所述低地址。
  20. 如权利要求18所述的装置，其特征在于，所述数据段支持地址无关的重定位的机制包括对所述第一服务进程的数据段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的数据段与在特权级改变之前的数据段映射至相同的地址；
    所述代码段支持地址无关的重定位的机制包括对所述第一服务进程的代码段进行地址翻译处理，使得所述第一服务进程在特权级改变之后的代码段与在特权级改变之前的代码段映射至相同的地址。
  21. 一种数据处理的装置，其特征在于，包括：
    存储器，用于存储可执行指令；
    处理器，用于调用并运行所述存储器中的所述可执行指令，以执行权利要求1至10中任一项所述的方法。
  22. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有程序指令，当所述程序指令由处理器运行时，实现权利要求1至10中任一项所述的方法。
  23. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序代码，当所述计算机程序代码在计算机上运行时，实现权利要求1至10中任一项所述的方法。
PCT/CN2021/097850 2020-07-16 2021-06-02 切换系统架构的方法与装置 Ceased WO2022012201A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21843079.1A EP4184338A4 (en) 2020-07-16 2021-06-02 METHOD AND DEVICE FOR SYSTEM ARCHITECTURE SWITCHING
US18/154,560 US12050896B2 (en) 2020-07-16 2023-01-13 System architecture switching method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010687260.6A CN113946528B (zh) 2020-07-16 2020-07-16 切换系统架构的方法与装置
CN202010687260.6 2020-07-16

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/154,560 Continuation US12050896B2 (en) 2020-07-16 2023-01-13 System architecture switching method and apparatus

Publications (1)

Publication Number Publication Date
WO2022012201A1 true WO2022012201A1 (zh) 2022-01-20

Family

ID=79326895

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/097850 Ceased WO2022012201A1 (zh) 2020-07-16 2021-06-02 切换系统架构的方法与装置

Country Status (4)

Country Link
US (1) US12050896B2 (zh)
EP (1) EP4184338A4 (zh)
CN (1) CN113946528B (zh)
WO (1) WO2022012201A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113946528B (zh) * 2020-07-16 2024-07-30 华为技术有限公司 切换系统架构的方法与装置
CN116775171B (zh) * 2023-08-25 2023-12-05 太平金融科技服务(上海)有限公司深圳分公司 一种架构切换方法、装置、电子设备及存储介质
CN119988037B (zh) * 2025-04-14 2025-06-20 成都秦川物联网科技股份有限公司 基于工业物联网数据中心的计算调度系统、方法及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1505497A1 (en) * 2003-08-06 2005-02-09 Alcatel A method, a computer software product, and a telecommunication device for dynamically and automatically loading software components
CN101763265A (zh) * 2010-01-19 2010-06-30 湖南大学 一种过程级软硬件协同设计自动化开发方法
CN105022954A (zh) * 2015-07-07 2015-11-04 中国人民解放军国防科学技术大学 飞腾cpu上三态操作系统安全内核服务动态运行方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8028295B2 (en) * 2005-09-30 2011-09-27 Intel Corporation Apparatus, system, and method for persistent user-level thread
CN1801101A (zh) * 2006-01-17 2006-07-12 浙江大学 Java操作系统中线程的实现和线程状态切换的方法
US20150052616A1 (en) * 2013-08-14 2015-02-19 L-3 Communications Corporation Protected mode for securing computing devices
CN104598303B (zh) 2013-10-31 2018-04-10 中国电信股份有限公司 基于kvm的虚拟机间在线迁移方法与装置
CN104778022B (zh) * 2014-01-09 2019-07-26 联想(北京)有限公司 一种数据处理方法及电子设备
CN103905553A (zh) * 2014-04-04 2014-07-02 江苏林洋电子股份有限公司 一种能效管理系统的云架构及其运行方法
CN105204933A (zh) * 2015-09-18 2015-12-30 上海斐讯数据通信技术有限公司 基于单进程的多任务切换执行方法、系统及处理器
CN109787943B (zh) * 2017-11-14 2022-02-22 华为技术有限公司 一种抵御拒绝服务攻击的方法及设备
CN108182263A (zh) * 2018-01-05 2018-06-19 郑州云海信息技术有限公司 一种数据中心综合管理系统的数据存储方法
JP7243326B2 (ja) * 2019-03-15 2023-03-22 オムロン株式会社 コントローラシステム
CN113946528B (zh) * 2020-07-16 2024-07-30 华为技术有限公司 切换系统架构的方法与装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1505497A1 (en) * 2003-08-06 2005-02-09 Alcatel A method, a computer software product, and a telecommunication device for dynamically and automatically loading software components
CN101763265A (zh) * 2010-01-19 2010-06-30 湖南大学 一种过程级软硬件协同设计自动化开发方法
CN105022954A (zh) * 2015-07-07 2015-11-04 中国人民解放军国防科学技术大学 飞腾cpu上三态操作系统安全内核服务动态运行方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DING MING: "Research on Reconfiguration and Verification Methods for Integrated Modular Avionics", CHINESE DOCTORAL DISSERTATIONS FULL-TEXT DATABASE, UNIVERSITY OF CHINESE ACADEMY OF SCIENCES, CN, no. 1, 15 January 2020 (2020-01-15), CN , XP055887115, ISSN: 1674-022X *
See also references of EP4184338A4

Also Published As

Publication number Publication date
CN113946528A (zh) 2022-01-18
EP4184338A4 (en) 2024-02-14
CN113946528B (zh) 2024-07-30
EP4184338A1 (en) 2023-05-24
US20230153088A1 (en) 2023-05-18
US12050896B2 (en) 2024-07-30

Similar Documents

Publication Publication Date Title
US9495183B2 (en) Instruction set emulation for guest operating systems
JP5452660B2 (ja) 仮想化されたオペレーティングシステムのためのダイレクトメモリアクセスフィルター
US6199181B1 (en) Method and system for maintaining restricted operating environments for application programs or operating systems
US12050896B2 (en) System architecture switching method and apparatus
CN104111897B (zh) 一种数据处理方法、装置及计算机系统
US10157268B2 (en) Return flow guard using control stack identified by processor register
US20210124822A1 (en) Function execution based on data locality and securing integration flows
US9235435B2 (en) Direct memory access filter for virtualized operating systems
US10592434B2 (en) Hypervisor-enforced self encrypting memory in computing fabric
US20050251806A1 (en) Enhancement of real-time operating system functionality using a hypervisor
US8539499B1 (en) Symmetric multiprocessing with virtual CPU and VSMP technology
US11163597B2 (en) Persistent guest and software-defined storage in computing fabric
US11734048B2 (en) Efficient user space driver isolation by shallow virtual machines
US11586549B2 (en) Method and apparatus for managing memory in memory disaggregation system
US10754796B2 (en) Efficient user space driver isolation by CPU page table switching
WO2017012339A1 (zh) 资源管理方法及装置
EP4660794A1 (en) Instance startup acceleration method and related apparatus
WO2022022708A1 (zh) 一种进程间通信的方法、装置及计算机存储介质
US20200201691A1 (en) Enhanced message control banks
CN116701258A (zh) 一种硬盘控制器、控制方法、设备及介质
US11003488B2 (en) Memory-fabric-based processor context switching system
WO2026007725A1 (zh) 数据处理方法及系统、计算设备、计算机可读存储介质、计算机程序产品
CN121349596A (zh) 一种基于ZVM的HyperVHE虚拟机系统及方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21843079

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021843079

Country of ref document: EP

Effective date: 20230215