KR20180093769A - Method and apparatus for operating multi-processor system in electronic device - Google Patents

Abstract

A method and an apparatus for operating a multi-processor system in an electronic apparatus are provided. The electronic apparatus includes a memory for storing operation commands for running a secure operating system (OS) and a non-secure OS; and at least one processor including a plurality of processor cores. Upon generation of at least one secure OS thread in the secure OS installed on the electronic apparatus, the at least one processor generates information indicating a secure mode operation request by assigning at least one of the plurality of processors cores in the secure OS, and executes the secure OS thread on the at least one processor core assigned in a secure mode based on the information.

Description

[0001] METHOD AND APPARATUS FOR OPERATING MULTI-PROCESSOR SYSTEM IN ELECTRONIC DEVICE [0002]

The present disclosure relates to a multiprocessor system of an electronic device, and more particularly, to a method and apparatus for operating a multiprocessor system with a secure operating system (OS) of an electronic device and a non-secure OS.

BACKGROUND OF THE INVENTION In the last few decades, mobile electronic devices, such as electronic devices, have increased in use around the world, and electronic devices have evolved from conventional mobile phones to voice messaging and exchange of short message service (SMS) Computing devices, and in addition to basic communication capabilities, various extensible Internet-based functions have been included. In particular, current smartphone hardware typically includes a robust processor or CPU, including a plurality of processors or a plurality of central processing unit (CPU) cores, and a multilevel memory system having a large amount of write capacity.

In addition, the latest electronic apparatuses are provided with an operating system (OS), and most application programs, i.e., applications or apps, are installed over the Internet, and operate under the OS of the electronic apparatuses to provide various functions to the users. The most popular mobile operating systems on smartphones are Android and iOS, and mobile apps are generally developed in versions that can run on both OSs.

As electronic devices have emerged as compact computing devices, there has been a move to apply the multithreading technology previously implemented in computers to electronic devices. Multi-aid threading technology is designed to improve performance by dividing the execution of an application into multiple execution threads and executing multiple execution threads of the application in parallel on multiple CPUs or multiple CPU cores. Multithreading technology is particularly advantageous for compute-intensive apps. The mobile OS of modern electronic devices is designed to support multithreading to support these compute-intensive apps, which can support the smooth operation of compute-intensive apps, such as a variety of action games, multimedia apps, and the like.

On the other hand, the problem of efficient power management has arisen due to the improvement of the computing ability of electronic devices. In recent smartphones, it is common for users to feel uncomfortable because the buffered battery does not last for half a day. As a result, the mobile OS of modern electronic devices reduces power consumption by disabling individual CPU cores for multiple CPU cores, if necessary, and activates individual CPU cores sequentially when necessary.

The problem is security. Recently, since electronic devices can expand not only a large number of apps but also mobile OS itself, the system destroying software such as a malicious code which can damage the OS to the kernel level when updating or expanding an OS or an app through the Internet is downloaded . As a result, the security of the data is also considerably weakened.

According to TrustZone technology, a technology known in the field of processor architecture design, there are two independent environments, a security environment ('security world') and an unsecured environment ('non-security world' ) Is proposed. In order to realize two independent environments, a secure OS that operates in a secure environment and a rich OS (RichOS) that operates in an unsecured environment are respectively implemented so that each of the CPUs or CPU cores can perform a secure mode or a non- Mode (non-secure mode). When one CPU core is switched to secure mode, the secure OS can obtain control over that CPU core and use the resources of the electronic device specified for use in the secure environment. In addition, if the other CPU core is in the unsecured mode, the rich OS can obtain control over the CPU core and use the resources specified for use in an insecure environment.

Typical examples of rich operating systems are Android and Tizen. Rich OS is a full-featured operating system that interacts directly with the user, regardless of the OS interface and utilities, or any application running below it. . The general operating aspect of a rich OS is well known, and the rich OS implements most of the drivers, especially drivers, that directly manipulate the hardware means of the electronic device, and in particular enable and disable the CPU core.

Unlike Rich OS, Secure OS runs applications that run only on secure OSs, for example, reliable applications, because they are small in size and very limited in functionality, are prone to errors, perform only sensitive work on real security. Due to the limited functionality of the Secure OS, the secure OS can not directly allocate computational resources for the execution of the secure OS thread. The secure OS uses the resources allocated according to the rich OS's own communication process through the rich OS. Therefore, it is impossible to allocate as much CPU core as necessary according to the secure OS thread. In addition, a secure OS can not activate an idle CPU core and can not request a rich OS to perform such an activation to optimize the operation of the secure OS.

As a result, a secure OS may incur a single core parallelism that must be handled by only one CPU core, even if there is an execution that requires parallelism. In the past, performance problems in the secure OS were not a big concern in the technology field, but the number of compute-intensive security applications is increasing, which causes performance problems in the entire electronic device as well as in the performance of the secure OS itself.

Based on the foregoing discussion, the disclosure provides a method and apparatus for operating a multiprocessor system of an electronic device.

The present disclosure also provides a method and apparatus for operating a multiprocessor system of an electronic device that overcomes the problems of the prior art described above.

According to the present disclosure, a method of operating an electronic device is provided. The electronic device includes at least one processor having a plurality of central processing unit (CPU) cores. Each CPU core operates in a secure or non-secure mode. Electronic devices have an unsecured operating system and a secure operating system that support multithreading. The secure operating system (OS) and non-secure OS are separated from each other up to the hardware level and can communicate with each other via at least one predefined interface. When the OS calls the thread, the security OS assigns the thread to the CPU core and modifies the CPU mask accordingly. The CPU mask is a data structure that transfers information indicating a request for CPU cores in the secure OS to the non-secure OS to maintain control over the CPUs. The CPU mask modified by the security OS is transmitted to the non-secure OS. On the basis of this, the non-secure OS activates the CPU core when the CPU core is deactivated, .

In accordance with an embodiment of the present disclosure, isolation of an insecure environment and a secure environment is implemented in terms of resources of the electronic device. Unsecured environment and security environment are implemented for each CPU core. When the CPU core is in secure mode, the secure OS acquires control of the CPU core and operates the resources of the electronic device for use in a secure environment. When the CPU core is in the non-secure mode, the non-secure OS can gain control over the CPU core and operate the resources of the electronic devices available in an insecure environment. The apparatus includes hardware resources that are implemented such that they can not be used in an unsecured environment when operating in a secure environment. And a secure OS scheduler configured to schedule execution of a secure OS thread. The non-secure OS includes an insecure OS scheduler configured to schedule execution of an insecure OS thread and an insecure OS driver configured to communicate with a secure OS scheduler. The non-secure OS driver is configured to activate the CPU core. The communication process includes a set of communication threads and each communication thread is mapped to a different CPU core so that when the CPU core is executed, the CPU core is switched to the security mode. The mapping can be implemented by setting the preference attribute of the communication thread. The electronic device has a memory area accessible only by the secure OS.

According to an embodiment of the present disclosure, a thread is one of one or more secure OS threads created by a trusted application running in a secure environment. When a non-secure OS client provides a command to be performed by a trusted application, the communication process places the command in a queue and allocates a communication thread for the command. When the communication thread is started on the CPU core, the CPU core is switched to the security mode, and the security OS scheduler is executed in the CPU core to unblock at least the thread.

According to an embodiment of the present disclosure, the data structure maintained by the secure OS scheduler includes a bit field. The bit field is modified by the secure OS scheduler. Modification of the bit field includes setting a bit entry corresponding to the CPU core if the trusted OS thread of the trusted application has not been previously assigned. As a result, the thread is placed in the secure OS scheduler queue, and time is allocated for execution of the thread.

According to the communication process by the security OS scheduler, completion or preemption of the security OS thread executed in the CPU core occurs. When the security OS thread is completed, the security OS thread is blocked. If no security OS thread is currently executed in the corresponding CPU core, the corresponding CPU mask is updated by discarding the bit entry corresponding to the corresponding CPU core, The CPU mask is embedded in the result of the execution and delivered to the non-secure OS. When a preemption occurs, the CPU mask is embedded in the result indicating that the execution is not completed, and the result is transmitted to the non-secure OS or the CPU mask is stored in the shared memory. Accordingly, control for the CPU core is switched to an insecure environment.

According to the communication process according to the present disclosure, the non-secure OS driver retrieves the CPU mask from the result or from the shared memory and matches the CPU mask to the currently active CPU cores. If a particular CPU core is currently inactive, activate that CPU core. The CPU mask is stored and used by the communication processor.

According to the communication process according to the present disclosure, the CPU mask is monitored and the communication thread mapped to the CPU core is unblocked so that the communication thread is placed in the non-secure OS scheduler queue by the non-secure OS scheduler. When the execution of the communication thread from the non-secure OS scheduler queue is started in the corresponding CPU core, the corresponding CPU core is switched to the security mode by the communication thread. Thus, the control in the CPU core is switched to the security environment, the operation of the security OS scheduler is started in the CPU core, and the security OS scheduler executes the thread.

When the execution of the thread in the CPU core is completed, the thread is blocked by the security OS scheduler, the CPU mask is updated and embedded in the execution result, the result is provided to the non-secure OS driver, . Blocking of threads may be updated by discarding bit entries by the secure OS scheduler if no other secure OS thread is currently allocated to that CPU core. In addition, the result received from the secure OS driver according to the communication process is transferred to the non-secure OS client application for further processing.

According to an embodiment of the present disclosure, it is possible for a secure OS scheduler to send a thread to a secure OS scheduler queue for execution at a later time, upon preemption of a thread from the CPU core by an interrupt due to timeout or from an unsecured OS .

According to an embodiment of the present disclosure, the non-secure OS is configured to sequentially activate the currently disabled CPU core as the computational load of the electronic device increases in a predefined order by the CPU core number, and the secure OS scheduler And to allocate CPU cores to the secure OS threads in order.

An electronic device is provided in accordance with an embodiment of the present disclosure. The electronic device includes at least one processor or CPU having a plurality of CPU cores. Each CPU core operates in either secure or non-secure mode. Non-secure operating systems (OS) and secure operating systems (OS) are installed in electronic devices, and non-secure OS and secure OS support multithreading. The secure OS includes allocating CPU cores for threads originating in the secure OS, and allocating includes modifying CPU masks. The CPU mask is a security OS maintained data structure that informs the current needs of the secure OS for the CPU cores. The CPU mask is transferred to the non-security OS to request the non-security OS to provide control to the security OS by the corresponding CPU core, so that the CPU core is switched to the security mode and the security OS acquires control from the corresponding CPU core do.

There is provided an operating method of an electronic device including at least one processor having a plurality of processor cores in accordance with the present disclosure. At least one secure OS thread is created in a security operating system installed in the electronic device and at least one processor core among the plurality of processor cores is specified in the secure OS to generate information indicating a request for performing a secure mode operation And transmits the information and executes the secure OS thread in the secure mode in the at least one processor core allocated based on the information. When a thread is created, a first processor core for executing the first secure OS thread and a second processor core for executing the second secure OS thread, respectively, are created when a first secure OS thread and a second secure OS thread are created And generates the information indicating the request for performing the secure mode operation. And generates the information including the activation request for the designated processor core when the designated processor core is in the inactive state. And determine the at least one processor to execute the secure OS thread among the plurality of processor cores based on usage information for the plurality of processor cores. Determines the at least one processor core to execute the secure OS thread among the plurality of processor cores based on the preference attribute of the secure OS thread. In this case, different security OS threads may determine the at least one processor to run on different processor cores. In addition, the at least one processor core may be determined such that the secure OS thread is executed in a processor core in which the smallest number of secure OS threads among the plurality of processor cores are executing.

According to the present disclosure, there is provided at least one processor having a memory and a plurality of processor cores storing operating instructions for operating a secure OS and a non-secure OS. Wherein at least one processor is configured to perform at least one of a plurality of processor cores in the secure OS to perform a secure mode operation when at least one secure OS thread is created in a security OS installed in the electronic device Generates and transmits information indicative of the request, and executes the secure OS thread in secure mode in the at least one processor core allocated based on the information.

An apparatus and method in accordance with various embodiments of the present disclosure optimizes the number of usable CPU cores depending on the context of the security environment by enabling use of CPUs (central processing unit cores) by a secure OS In addition, the operation speed of the security OS can be improved and the response delay of the security OS can be minimized, thereby improving the performance of the security OS.

The effects obtainable from the present disclosure are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the description below will be.

1 is a schematic diagram of an electronic device including a CPU having four central processing unit (CPU) cores.
2 is a flow chart illustrating a secure operating system (OS) and non-secure OS operating mechanism performed in the electronic apparatus of the present disclosure.
3 is a diagram for explaining an implementation example of a CPU mask.
4 is a diagram for explaining a configuration for performing operations of the secure OS and the non-secure OS according to the present disclosure.
5 is a flow chart illustrating a method of operating a secure OS and an unsecured OS in an electronic device according to an embodiment of the present disclosure.

The terms used in this disclosure are used only to describe certain embodiments and may not be intended to limit the scope of other embodiments. The singular expressions may include plural expressions unless the context clearly dictates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as commonly understood by one of ordinary skill in the art. The general predefined terms used in this disclosure may be interpreted as having the same or similar meaning as the contextual meanings of the related art and, unless explicitly defined in the present disclosure, include ideally or in an excessively formal sense . In some cases, the terms defined in this disclosure can not be construed to exclude embodiments of the present disclosure.

In the various embodiments of the present disclosure described below, a hardware approach is illustrated by way of example. However, the various embodiments of the present disclosure do not exclude a software-based approach, since various embodiments of the present disclosure include techniques that use both hardware and software.

This disclosure relates to a method of operating a multiprocessor system of an electronic device and an electronic device having an improved implementation of the device secure operating system (OS) and method of operation thereof. The terms referring to components of the apparatuses used in the following description, terms referring to the use environment, and the like are illustrated for convenience of explanation. Accordingly, the present disclosure is not limited to the following terms, and other terms having equivalent technical meanings can be used.

The electronic device according to the present disclosure includes at least one CPU or processor having a plurality of CPU cores in addition to other known hardware components. The term CPU core in the electronic device according to the present disclosure is not limited to a term for convenience of description and means a plurality of CPUs or a plurality of processors or at least one CPU or at least one processor having a plurality of CPU cores . That is, in the present disclosure, the CPU core can be applied to an electronic apparatus having a plurality of such unit bodies as a processing unit for performing the functions described below.

1 is a schematic diagram of a smartphone including a CPU having four central processing unit (CPU) cores.

Referring to FIG. 1, an electronic device includes a CPU 110 and a memory 120. The CPU 110 includes a plurality of CPU cores 112-1 to 112-4. Each CPU core may be physically enabled or disabled, e.g., switched on or off, and adapted to operate in a secure mode or a non-secure mode, respectively. There are two operating systems installed in electronic devices: RichOS, an insecure OS, and SecureOS, a secure OS. That is, the memory 120 stores an operation command for executing the secure OS and the non-secure OS. Here, for convenience of explanation, a secure OS is shown as an example of a secure OS, and a rich OS is shown as an example of a non-secure OS. However, the present disclosure is not limited to this, and embodiments of the present disclosure include two operating systems The present invention can be applied to any electronic apparatus that operates by using a computer.

The present disclosure can be implemented by operating each CPU or each processor when an electronic device employs a plurality of CPUs or processors, and will be described below by way of example for the convenience of description for each CPU core or processor core. In each mode of the secure OS and the non-secure OS, each OS has its own system register. When one CPU core is switched to security mode, the security OS obtains control over the CPU core and can use the resources of the electronic device specified for use in the secure environment. At the same time, when another CPU core is in non-secure mode, an insecure OS can gain control over that CPU core and use resources specified for use in an insecure environment. That is, the non-secure environment and the secure environment are activated in units of CPU core, respectively. For example, while one CPU core is operating in secure mode and the security OS is controlling the CPU core in a secure environment, the other CPU core may operate in an unsecured mode under non-secure OS control in an insecure environment.

Both non-secure OS and secure OS support multi-threading and are configured to operate simultaneously in electronic devices. Secure OS and non-secure OS are strictly isolated from each other up to the hardware level. At least one predefined interface is provided for communication between the two OSs. The interface is defined, for example, in the following document.

http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf

Google Trusty is an example of a known security OS, and known mobile operating systems such as Android and Tizen are examples of non-secure OSs.

The two isolated operating systems are implemented as a 'non-secure world' and a 'secure world' in terms of the resources of the electronic device. As described above, each of the non-secure environment and the secure environment can be applied to each CPU core. That is, as described above, when one CPU core is in the security mode, the security OS obtains control from the CPU core and can operate resources of the electronic device set to be available in the security environment. Further, when one CPU core is in the non-security mode, the non-security OS acquires the control from the CPU core and can operate the resources of the electronic device set to be available in the non-security environment. In this case, when a specific hardware resource of the electronic device is used in a security environment, the resource is set to be disabled in an unsecured environment. In particular, there is an area of electronic device memory (e.g., DRAM) accessible only by a secure OS. In this way, the resources of electronic devices accessible only by the secure OS are never physically accessible in an insecure environment. Thus, highly sensitive information such as, for example, a security key or a security code can be securely maintained. Even when the non-security OS is controlled by the remote control authority at the kernel level, it can not access the resources that are accessible only by the security OS.

On the other hand, when the electronic device is booted in the present disclosure, when the boot sequence is completed, the secure OS can be initialized first and the non-secure OS can be initialized thereafter. The non-security OS driver is implemented as a system component specific to a non-security OS, and a security OS scheduler is implemented as a system component specific to a security OS. The non-secure OS driver and the secure OS scheduler are implemented to communicate with each other via the interface described above. In addition to providing communication with the security OS, the non-security OS driver functions to activate and deactivate the CPU core. The secure OS scheduler maintains an execution queue of the secure OS thread to schedule the execution of the secure OS thread. On the other hand, an unsecured OS scheduler is implemented in the non-security mode, and the execution of the non-secure OS thread is scheduled by maintaining the execution queue of the non-secure OS thread.

For example, if the electronic device is implemented as a smart phone, for example, when the user begins to enter a password on the locked touch screen of the smartphone to unlock the touch screen, Quot ;. The communication process consists of the same number of communication threads as the number of CPU cores of the smartphone and is a function provided by the non-secure OS. Each communication thread is mapped to a specific CPU core so that the communication thread can be executed on the CPU core. This mapping has been introduced by symmetric multiprocessing techniques. When the communication thread starts executing on the CPU core, the CPU core is switched to the security mode. Thus, when a command is received, the communication process unblocks one of the communication threads to allocate the command, and the communication thread runs on some CPU cores and switches the CPU cores to secure mode. The security OS thereby obtains control from the CPU core, and the secure OS scheduler begins execution and unblocks the thread of the trusted application responsible for the secure touch-screen input. The thread of the trust application is executed to process commands in the CPU core in secure mode, and all touch screen controllers of the smartphone operate only in the secure environment during execution. In other words, non-secure OS applications running on different CPU cores, as well as non-secure OS itself, can not physically access the touch screen. This access denial is implemented at the bus level servicing the controller. Other hardware on the smartphone can also become unusable under non-secure circumstances in other situations. When the command processing is completed, the thread is interrupted, the CPU core is switched back to the non-secure mode, and the processing result is transferred to the non-secure OS driver by the secure OS scheduler and transferred to the non-secure OS client application by the communication process. Thus, sensitive operations such as password authentication can be performed in a manner that is secure from tampering.

2 is a flow chart for illustrating a secure OS and a non-secure OS operating mechanism performed in the electronic apparatus of the present disclosure;

2, a method 200 for operating a secure OS and an unsecured OS in an electronic device according to the present disclosure is described.

According to step 201, at least one secure OS execution thread indicated by thread A is created for execution of an instruction executed in the secure OS in the secure environment. Here, thread A is described by way of example, but a plurality of threads, for example, thread A and thread B, may be generated simultaneously or sequentially, and the steps described below may be performed concurrently or sequentially when thread A and thread B are generated simultaneously or sequentially Can be performed sequentially.

In step 203, as the thread A is created in the secure OS, the security OS specifies the CPU core indicated by, for example, CPU core A among the CPU cores of the secure OS and executes the thread A on the designated CPU core A, A < / RTI > to request to be assigned to perform an operation in secure mode. The information indicating the security mode operation execution request is information for notifying the non-secure OS that the security OS designates the CPU core A and allocates control to the security mode for the designated CPU core A, and designates one or more CPUs Information about the core, e.g., identification of the required CPU core, the number of required CPU cores, current usage information of the requested CPU core, and the like.

According to an embodiment of the present disclosure, a specific data structure for indicating request information in a secure OS is suggested as an example of security mode operation execution request information. Hereinafter, this data structure is referred to as a " CPU mask ". The security OS can use the CPU mask to inform the nonsecure OS about the current requirements of the secure OS on the CPU core. The CPU mask is a data structure designed by way of example in accordance with this disclosure to allocate individual secure OS threads to a particular CPU core.

3 is a diagram for explaining an implementation example of a CPU mask. Figure 3 shows an example in which a CPU mask according to one embodiment of the present disclosure is implemented as one bit field per CPU core. In this case, the communication processing process for the predefined bit field according to the implemented structure is negotiated by the security OS and the non-security OS in advance. Referring to FIG. 3, from among data structures representing threads, more specifically, a secure OS thread, at least one bit field may be used to indicate information requesting to allocate a corresponding secure OS thread to a specific CPU core. For example, the CPU core indicated by each bit field is predefined and can be implemented to indicate an allocation request of the CPU core by an entry of a bit field corresponding to a specific CPU core, for example, a bit value. Alternatively, a predefined identification number corresponding to each CPU core may be input as a bit field entry to indicate an allocation request of the corresponding CPU core. In the example of FIG. 3, it indicates an allocation request for CPU 0 or CPU N-2. On the other hand, when the thread is blocked and is not allocated to any CPU core, a specific value, for example, 0, is implemented to include as an entry in the bit field, for example, a bit value.

Also, the secure OS scheduler may implement a reference counter array that includes a plurality of reference counters, e.g., a number of reference counters corresponding to the total number of CPU cores, and determines how many threads are currently allocated to each CPU core Can be counted by the reference counter of the reference value. Accordingly, each reference counter can indicate usage information of each CPU core. When a particular thread is assigned to a particular CPU core, the reference counter corresponding to that CPU core in the reference counter array is incremented by one. Conversely, when a thread is deallocated from its CPU core, the counter is decremented by one. According to one embodiment of the present disclosure, when the reference counter becomes 0, the bit entry corresponding to the CPU core in the CPU mask may be discarded to 0, for example. The CPU mask illustrated in FIG. 3 may be modified to indicate usage information of each CPU core indicated by each reference counter in addition to indicating a security mode execution request for each CPU core.

When a security OS requests a CPU core for a thread, the current usage information for a plurality of CPU cores may be used to allocate, for example, the smallest number of threads allocated in order of allocated CPU cores. Further, in order to map a specific thread to a specific CPU core, an affinity property of the thread can be used. The preference attribute may be set, for example, such that each thread is mapped to a different CPU core. Also, a " weak affinity " may be set for a particular thread, indicating that the thread is allowed to run on any CPU core unless the thread has specified a CPU core to run on. Also, each of the threads can be implemented to be executed only on the CPU core allocated according to the set preference attribute. As another example, if the electronic device is composed of two or more CPU cores with different performance, the thread's preference information may be set to be assigned to either a high-performance CPU core or a low-performance CPU core. The security OS identifies the usage information, including the thread's preference attribute settings, and maps the CPU core to that thread based on that information. Therefore, by using the preference attribute, the thread processing ability can be improved, and at the same time, the processing efficiency can be improved and the power consumption can be lowered by meeting the demands of the thread having high performance and the thread having not high performance. Alternatively, the thread's preference attribute may be ignored or modified by the secure OS scheduler.

In step 203 described above, the secure OS, or secure OS scheduler, sets a bit entry in the bit field corresponding to CPU core A to set the CPU mask to indicate that the secure OS requires CPU core A for execution of thread A Modify it.

It should be apparent to those skilled in the art that the above example of implementing a CPU mask as a bit field does not limit the present disclosure and that other implementations of the CPU mask data structure are possible.

In step 205, the secure OS transmits the generated request information, for example a CPU mask, to the non-secure OS to request the control OS to allocate control to the secure OS. At this time, communication is performed through the above-described interface between the secure OS and the non-secure OS. The bit entry set in the CPU mask corresponding to the CPU core A ensures that the non-secure OS does not deactivate the CPU core A unless the bit entry is discarded as 0, for example.

In step 207, based on the CPU core allocation request information for performing the secure mode, for example, the CPU mask, the non-secure OS allocates the CPU core A to operate in the security mode. For this, the non-security OS can switch CPU core A to security mode. For example, an insecure OS may block non-secure OS thread allocation to CPU core A and cause its CPU core A to switch to secure mode. At this time, when the CPU core A is currently inactivated, the non-security OS activates the CPU core A based on the received CPU mask. Thus, control of CPU core A is provided to the security OS, and the security OS operates the allocated CPU core A in the security mode and executes the security OS thread A.

The method 200 described above is not limited to thread A and can be performed equally for any secure OS thread. It can also be executed against a plurality of secure OS threads.

4 is a diagram for explaining the operation of the secure OS and the non-secure OS according to the present disclosure.

Hereinafter, with reference to FIG. 4, the configuration of the secure OS and the non-secure OS and the operations performed according to the configuration will be described in connection with the execution of steps 201 to 207 according to the embodiment of the present disclosure.

The secure OS includes a secure OS scheduler 401. The basic function of the secure OS scheduler 401 is to schedule the execution of the secure OS thread. According to one embodiment, the secure OS scheduler 401 is configured to maintain a CPU mask in the secure OS and use it to allocate a secure OS thread to the CPU core, as described above. The CPU mask can be appropriately modified according to the assigned contents. That is, step 203 may be performed by the secure OS scheduler 401 in the embodiment of the present disclosure.

The non-secure OS is configured to sequentially activate the currently disabled CPU cores in a predetermined order defined by the CPU core number as the computing load increases in the electronic device. According to an embodiment, the secure OS scheduler 401 may cause the secure OS thread to allocate a CPU core according to the predetermined order. In addition, according to the embodiment, the secure OS scheduler 401 can preferentially allocate a secure OS thread to a CPU core having a low usage amount in descending order of CPU cores, for example, based on usage information of each CPU core have.

The non-secure OS includes a non-secure OS scheduler (not shown), and the non-secure OS scheduler is configured to schedule the execution of the non-secure OS thread similarly to the secure OS scheduler.

The non-secure OS includes an insecure OS driver 410. As described above, the non-secure OS driver 410 is configured to communicate with the secure OS scheduler 401 to physically activate or deactivate the requested CPU cores. In addition, the CPU core requested by the secure OS scheduler 401 is switched to the security mode and provided to the security OS. The communication between the secure OS and the insecure OS is performed between the secure OS scheduler 401 and the insecure OS driver 410 through the predefined interface 405 as described above.

A communication process according to an embodiment of the present disclosure will be described. The communication process described in the embodiments of the present disclosure is performed by an insecure OS system based on communication between a secure OS and an insecure OS. Accordingly, the nonsecure OS driver 410 is able to process a corresponding OS thread in a CPU core granted a time slice to a communication thread for communication with a secure environment for processing a secure OS thread, To the security mode.

The number of communication threads included in one communication thread set is equal to the number of CPU cores of the electronic device and each communication thread is mapped to each CPU core so that the communication thread is executed in the mapped CPU core. When a communication thread for communication between a secure OS and an insecure OS for execution of an insecure OS thread starts to execute on a mapped CPU core, the mapped CPU core is switched to the security mode.

The communication process performed by the non-secure OS system may include a thread for interaction with the non-secure OS client, in addition to the communication thread for communicating with the secure environment described in this disclosure.

The mapping as described above may also be implemented by setting the affinity property of the communication thread. For example, a 'weak affinity' may be set for a communication thread, which indicates that the communication thread is allowed to run on any CPU core if the CPU core on which the communication thread is to be executed is not specified. Another example applies when the electronic device comprises two different CPU core clusters, the larger clusters are composed of high performance CPU cores, and the smaller clusters are composed of power efficient low performance CPU cores which are not very productive. In this case, if the affinity property for a communication thread is set to be allocated to the CPU core of a large cluster, if the communication thread is set to run on a high-performance CPU core and a specific communication thread is assigned to a CPU core of a small cluster, Run on a low-performance CPU core. Therefore, a balance between performance and power consumption can be achieved using the preference property.

According to an embodiment of the present disclosure, the preference attribute of a communication thread can be set in such a way that each communication thread is mapped to a different CPU core. That is, the preference attribute for each communication thread may be set to be defined to correspond one-to-one between the communication thread and the CPU core. In this setup, each of the communication threads can be made to run only on the CPU core assigned according to the set preference attribute. The non-secure OS driver or non-secure OS scheduler checks the configuration of the communication thread and maps the communication thread to the CPU core assigned to the communication thread.

On the other hand, the preference attribute of the communication thread can be ignored or modified if necessary in the non-secure OS. When a specific CPU core is deactivated by the non-secure OS driver 310, the non-secure OS scheduler can modify the preference attribute of the corresponding communication thread to discard the mapping of the communication thread corresponding to the corresponding CPU core of the non-secure OS. Also, if the required CPU cores are not available, the non-secure OS scheduler can ignore the preference attribute and run the thread on the currently available CPU core. Conversely, if the previously deactivated CPU core is reactivated, the preference attribute may be modified to restore the mapping of the communication thread corresponding to the re-activated CPU core.

Hereinafter, an embodiment of the present disclosure will be described with reference to Figs. 2, 4 and 5. Fig. 5 is a flow diagram illustrating an operational process 500 of an electronic device according to an embodiment of the present disclosure.

In step 501, the non-secure OS client application 320 executing in an insecure environment issues an instruction. The non-secure OS client 320 may be an application configured to provide a user with a GUI for entering text and / or graphics passwords or a GUI for scanning a user's iris to unlock the touch screen of the wireless terminal, And can be configured to obtain input information. The command is issued by the non-secure OS client application 420 in response to the user's attempt to unlock the touch screen and in response to the start of the user's interaction with the GUI. It is assumed that the command is processed by a secure OS trusted application 402 running in a secure environment that is responsible for user authentication. The trust application 402 may be an application program that confirms a user's textual password with a relatively small demand for resources, or an application program configured to identify a user's iris with a very high demand for resources. That is, the command is configured such that the trusted application 402 properly processes the input information and returns the processing result to the non-secure OS client application 420.

Trust application 402 is a multi-threaded application. Thus, one or more secure OS threads are created. In the absence of the above-mentioned command, for example, when the electronic device is in stanby mode and the current user is not using it, or when the user operates the electronic device after the lock of the touch screen is successfully released, The application thread is blocked.

After the non-secure OS client issues the command, in step 502 the communication process receives the command and unblocks one of the communication threads to allocate the received command, thereby causing the communication thread to communicate with the non-secure OS scheduler Place it in the run queue.

Then, at step 502, when the communication thread starts executing in the CPU core (hereinafter referred to as CPU core O) allocated thereto by the non-secure OS scheduler, the communication thread switches the CPU core O to the security mode . Upon switching, the secure OS scheduler 401 begins execution on CPU core O and unblocks at least one execution thread of the secure OS threads of one or more trusted applications 402 responsible for command processing.

Hereinafter, an example is described in which a plurality of threads of the trust application 402 are unblocked and thread A is one of the plurality of threads.

In step 503, the secure OS scheduler 401 allocates CPU core A to the unblocked thread A, and updates the CPU mask when performing the allocation. As described above, in particular, if the secure OS thread of the trusted application has not been previously assigned to CPU core A, the secure OS scheduler 401 sets the bit entry corresponding to CPU core A in the CPU mask. In this case, the bit entry is modified from '0' to '1', for example. Other execution threads are handled identically. That is, it sets the bit entries in the CPU mask in this manner to indicate the current security OS requirement for the CPU cores. The secure OS scheduler then places each unblocked thread in the secure OS scheduler queue and allocates a time quote for each thread execution.

As described above, the secure OS scheduler 401 then switches to execution of one of a plurality of threads (hereinafter referred to as thread O) at the top of the corresponding queue of CPU core O. In this case, thread O is executed on the CPU core O different from the CPU core currently assigned to thread O in the CPU mask. It is assumed that thread A is currently in the secure OS scheduler queue. On the other hand, certain hardware of an electronic device, such as a touch screen controller, etc., can only operate in a secure environment while running a trusted application thread.

Steps 501 to 503 of FIG. 5 may be substantially included in steps 201 and 203 of FIG.

Step 504 relates to an executable scenario of thread O. On the other hand, a preemption may occur for the thread O currently executing in the CPU core O. In this case, thread O is returned to the secure OS scheduler queue, causing execution of thread O to resume later. Thread O is not substantially different from Thread A used for clarity of illustration as an example reference run thread throughout this disclosure and is for convenience of description only. Hereinafter, the operation will be described with reference to thread A. [

Preemption can occur for the following reasons. First, the execution thread O may be preempted by the secure OS scheduler 401 upon expiration of the time quote allocated thereto. Second, preemption can occur when an interruption occurs in a non-secure OS, and this mechanism is provided basically in a secure OS / non-secure OS based wireless system. In the latter case, once the preemption occurs, control of the CPU core is switched to an insecure environment, an interrupt can be handled by the insecure OS, and then switched back to the secure environment.

According to the present disclosure, the security OS scheduler 401, upon occurrence of a preemption, returns a specific result, via interface 405, to the non-secure OS driver 410 indicating an unfinished execution. The current CPU mask can be passed along with the specific result. In another embodiment, the secure OS scheduler 401 may forward the current CPU mask to the non-secure OS driver 410 by placing it in a shared memory.

On the other hand, the execution of thread O in CPU core O can be successfully completed at the initial execution time of thread O, or at the subsequent execution time in the secure OS scheduler queue. In this case, the security OS scheduler 401 blocks the thread O, and if there is no other secure OS thread assigned to the current CPU core, for example, if the reference counter associated with the CPU core O is 0, the bit corresponding to the CPU core O The entry is set to 0 to update the CPU mask, and the current CPU mask is included in the execution result. Thereafter, the successful execution result is transmitted to the non-secure OS driver 410 via the interface 405 by the secure OS scheduler 401, and the control of the CPU core O is switched back to the non-secure environment.

The reason for the preemption as described above is not the only reason, and other reasons are also possible. In particular, the following mechanisms may be provided in accordance with embodiments of the present disclosure. When the CPU mask is modified in the secure OS, if the modification is not associated with a secure OS thread running on the current CPU core, the currently executing secure OS thread is preempted from that CPU core and placed in the secure OS scheduler queue. With this mechanism, the modified CPU mask can be more effectively delivered to the non-secure OS in any of the above-described preemption-related schemes, thereby allowing the non-secure OS to verify the latest version of the CPU mask in a timely manner.

Step 504 of FIG. 5 corresponds to step 205 of FIG. In addition to step 203 described with reference to Figure 2, the non-secure OS driver is configured to prohibit deactivation of the CPU core while each bit of the CPU mask is set. It is implemented through a notification system in the non-secure OS kernel. An insecure OS kernel can be implemented to try to disable the hardware CPU core, for example, to check the 'feedback' of all objects subscribed to the notification for that event.

When step 504 is completed, the process 500 is switched to an insecure environment.

In step 505, the non-secure OS driver 410 retrieves the CPU mask from the shared memory or from the result passed by the secure OS scheduler 401. Accordingly, the non-secure OS driver 410 matches the currently active CPU cores with the CPU mask, and activates the CPU core A if the CPU core A is currently inactive. Finally, the non-secure OS driver 410 stores the CPU mask in the storage location in the non-secure environment usable in the communication process. CPU core A is used throughout this disclosure as a reference CPU core only for convenience of explanation, and other CPU cores may be activated in the manner described above.

According to the communication process, the CPU mask is checked, and in step 506 the non-secure OS scheduler unblocks the communication thread mapped to CPU core A, and then places the unblocked communication thread in the non-secure OS scheduler queue. When a communication thread from the non-secure OS scheduler queue starts executing on CPU core A, the communication thread turns CPU core A into secure mode and switches control from CPU core A to the secure environment. In step 506, according to the communication process, the result received from the non-secure OS driver 410 is delivered to the non-secure OS client application 420 for further processing.

Upon completion of step 506, the process 500 is switched back to the secure environment.

At step 507, the secure OS scheduler 401 begins execution at CPU core A and executes the secure OS thread of the trust application 420 at the top of the current secure OS scheduler queue. The thread to be executed may be thread A, but is not limited thereto.

Step 508 is performed if execution of thread A in CPU core A is successfully completed. In step 508, the secure OS scheduler 401 intercepts thread A, updates the CPU mask to embed it in the execution result, and provides the result to the non-secure OS driver 410. At this time, when the reference counter associated with the CPU core A is 0, the bit entry of the CPU core A is set to 0, for example, and discarded. Thereby, the control in the CPU core A is switched again to the non-security environment. Thereafter, according to the communication process, the result received in the non-secure OS driver 410 as described above in step 509 is passed to the non-secure OS client application 420 for further processing.

According to the present disclosure, a secure OS may request a CPU core allocation for a secure OS thread. Thus, the security OS is able to manage the CPU core allocation for the secure OS thread. In addition, the security OS can control the number of available CPU cores. Therefore, the security OS can use existing resources more efficiently as needed. In addition, the performance of a secure OS is improved to quickly perform computationally intensive tasks such as biometrics.

Methods according to the claims of the present disclosure or the embodiments described in the specification may be implemented in hardware, software, or a combination of hardware and software.

When implemented in software, a computer-readable storage medium storing one or more programs (software modules) may be provided. One or more programs stored on a computer-readable storage medium are configured for execution by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to perform the methods in accordance with the embodiments of the present disclosure or the claims of the present disclosure.

Such programs (software modules, software) may be stored in a computer readable medium such as a random access memory, a non-volatile memory including flash memory, a read only memory (ROM), an electrically erasable programmable ROM but are not limited to, electrically erasable programmable read only memory (EEPROM), magnetic disc storage device, compact disc-ROM (CD-ROM), digital versatile discs An optical storage device, or a magnetic cassette. Or a combination of some or all of these. In addition, a plurality of constituent memories may be included.

The program may also be stored on a communication network, such as the Internet, an Intranet, a local area network (LAN), a wide area network (WAN), a communication network such as a storage area network (SAN) And can be stored in an attachable storage device that can be accessed. Such a storage device may be connected to an apparatus performing an embodiment of the present disclosure via an external port. Further, a separate storage device on the communication network may be connected to an apparatus performing the embodiments of the present disclosure.

In the specific embodiments of the present disclosure described above, the elements included in the disclosure have been expressed singular or plural, in accordance with the specific embodiments shown. It should be understood, however, that the singular or plural representations are selected appropriately according to the situations presented for the convenience of description, and the present disclosure is not limited to the singular or plural constituent elements, And may be composed of a plurality of elements even if they are expressed.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not limited to the disclosed embodiments. Therefore, the scope of the present disclosure should not be limited to the embodiments described, but should be determined by the scope of the appended claims, as well as the appended claims.

401: Security OS Scheduler
402: Trusted Application
410: Non-secure OS driver
420: Client application

Claims (14)

A method of operating an electronic device comprising at least one processor having a plurality of processor cores,
Creating at least one secure OS thread in a secure operating system (OS) installed in the electronic device;
Designating at least one processor core among the plurality of processor cores in the secure OS to generate information indicating a request for performing a secure mode operation;
Transmitting the information; And
And executing the secure OS thread in a secure mode in the at least one processor core allocated based on the information.
The method according to claim 1,
Wherein the step of generating the information comprises:
A first processor core for executing the first security OS thread and a second processor core for executing the second security OS thread are specified and a security mode And generating the information indicative of an action execution request.
The method according to claim 1,
Wherein the step of generating the information comprises:
Generating the information including an activation request for the designated processor core if the designated processor core is in an inactive state.
The method according to claim 1,
Wherein the step of generating the information comprises:
Determining the at least one processor core to execute the secure OS thread among the plurality of processor cores based on usage information for the plurality of processor cores.
The method of claim 4,
Wherein the step of generating the information comprises:
Determining the at least one processor core to execute the secure OS thread among the plurality of processor cores based on the preference attribute of the secure OS thread.
The method according to any one of claims 4 and 5,
Wherein determining the at least one processor core comprises:
Wherein the different security OS threads comprise determining the at least one processor core to run at different processor cores.
The method according to any one of claims 4 and 5,
Wherein determining the at least one processor core comprises:
Determining the at least one processor core to execute the secure OS thread at a processor core in which the smallest number of secure OS threads of the plurality of processor cores are running.
In an electronic device,
A memory for storing an operation command for executing a security OS and an insecure OS; And
And at least one processor having a plurality of processor cores,
Wherein the at least one processor comprises:
When at least one secure OS thread is created in a security operating system installed in the electronic device,
Generating and transmitting information indicating a request for performing a secure mode operation by designating at least one processor core among the plurality of processor cores in the secure OS,
And executes the secure OS thread in a secure mode in the at least one processor core allocated based on the information.
The method of claim 8,
Wherein the at least one processor comprises:
When the first security OS thread and the second security OS thread are generated,
A first processor core for executing the first security OS thread and a second processor core for executing the second security OS thread, respectively, to generate the information indicating a request for performing a secure mode operation.
The method of claim 8,
Wherein the at least one processor generates the information comprising an activation request for the at least one processor core if the at least one processor core is in an inactive state.
The method of claim 8,
Wherein the at least one processor determines the at least one processor core to execute the secure OS thread among the plurality of processor cores based on usage information for the plurality of processor cores.
The method of claim 8,
Wherein the at least one processor determines the at least one processor core to execute the secure OS thread among the plurality of processor cores based on a preference attribute of the secure OS thread.
The method according to any one of claims 11 and 12,
Wherein the at least one processor determines the at least one processor core such that different secure OS threads run on different processor cores.
The method according to any one of claims 11 and 12,
Wherein the at least one processor determines the at least one processor core such that the secure OS thread is executed in a processor core in which the smallest number of secure OS threads of the plurality of processor cores are executing.

Images