RU2641226C1

RU2641226C1 - Method of secureos functioning on multiprocessor systems in mobile devices

Info

Publication number: RU2641226C1
Application number: RU2017104527A
Authority: RU
Inventors: Александр Николаевич Матвеев; Владимир Васильевич Подъяпольский
Original assignee: Самсунг Электроникс Ко., Лтд.
Priority date: 2017-02-13
Filing date: 2017-02-13
Publication date: 2018-01-16
Also published as: KR20180093769A; KR102333693B1

Abstract

FIELD: information technology.

SUBSTANCE: method comprises the steps of: after activating the thread in a secure operating system (SecureOS), assigning in SecureOS this thread to the Core Processing Unit (CPU), which purpose includes the step of changing the CPU mask. The CPU mask is a data structure supported in SecureOS to inform the unprotected operating system (RichOS) of the current needs of SecureOS in the CPU cores; CPU mask is transferred via SecureOS in RichOS for requesting RichOS to provide SecureOS control on the CPU core; on the basis of the CPU mask, the core of the CPU is enabled via RichOS, if the CPU core is disabled; and CPU core is switched via the RichOS to the protected mode, providing SecureOS control on the CPU core. Mobile device contains CPU, which has many CPU cores, each of which functions either in protected or in unprotected mode, and installed on the mobile device RichOS and SecureOS support multithreading and communicate with each-other through a predefined interface.

EFFECT: improved performance of a protected operating system.

30 cl, 5 dwg

Description

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕFIELD OF THE INVENTION

Настоящее изобретение в целом относится к области техники мобильных устройств и, в частности, к функционированию SecureOS на многопроцессорных системах в мобильных устройствах.The present invention generally relates to the field of mobile device technology and, in particular, to the operation of SecureOS on multiprocessor systems in mobile devices.

УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯBACKGROUND OF THE INVENTION

Использование мобильных устройств во всем мире значительно возросло за последние 15-20 лет. В то же время мобильные устройства эволюционировали из обычного мобильного телефона, предназначенного только для выполнения голосовой связи и обмена SMS-сообщениями, в смартфон, который, по существу, представляет собой компактное мощное вычислительное устройство, выполненное с возможностью предоставления, помимо основных возможностей связи, различной расширяемой основанной на Интернете функциональности. В частности, аппаратное обеспечение современного смартфона в целом включает в себя мощный CPU, содержащий множество ядер CPU, и многоуровневую систему памяти, имеющую большую емкость хранения. Каждое современное мобильное устройство обладает установленной в нем операционной системой (OS), и большинство функций предоставляется мобильным устройством пользователям посредством приложений, которые устанавливаются через Интернет и затем функционируют под управлением OS. Самыми популярными операционными системами в смартфонах являются Android и IOS, и мобильные приложения обычно разрабатываются, чтобы, по меньшей мере, иметь версии, функционирующие на каждой из этих двух OS.The use of mobile devices around the world has increased significantly over the past 15-20 years. At the same time, mobile devices evolved from a conventional mobile phone, designed only for voice communication and SMS messaging, into a smartphone, which, in essence, is a compact powerful computing device made with the possibility of providing, in addition to the main communication capabilities, various extensible web-based functionality. In particular, the hardware of a modern smartphone as a whole includes a powerful CPU containing many CPU cores, and a multi-level memory system with a large storage capacity. Each modern mobile device has an operating system (OS) installed in it, and most of the functions are provided by the mobile device to users through applications that are installed over the Internet and then operate under OS control. The most popular operating systems in smartphones are Android and IOS, and mobile applications are usually designed to at least have versions that work on each of these two OSs.

Технология многопоточности, ранее реализованная в компьютерах, в настоящее время применяется к мобильным устройствам. Упомянутая технология была разработана для повышения производительности посредством разделения исполнения приложения на потоки исполнения и предоставления возможности исполнения множества потоков приложения параллельно на множестве CPU или ядер CPU. Данное улучшение особенно полезно для интенсивных в вычислительном отношении приложений. С этой целью, мобильные операционные системы (OS) и многие из мобильных приложений в настоящее время разрабатываются с поддержкой многопоточности, принимая во внимание, что на современных мобильных устройствах обеспечена возможность функционирования таким интенсивным приложениям, как различные игры с активными действиями, мультимедийные приложения и т.д.The multithreading technology previously implemented in computers is currently applied to mobile devices. The technology was developed to improve performance by splitting application execution into execution threads and allowing multiple application threads to run in parallel on multiple CPUs or CPU cores. This improvement is especially useful for computationally intensive applications. To this end, mobile operating systems (OS) and many of the mobile applications are currently being developed with multithreading support, taking into account that modern mobile devices provide the ability to operate such intensive applications as various games with active actions, multimedia applications, etc. .d.

Ввиду наращивания вычислительной мощности, как обсуждалось выше, эффективное управление энергопотреблением является актуальным для смартфонов, и обычной в настоящее время является ситуация, когда батарея смартфона, заряженная утром полностью, разряжается к вечеру, тем самым причиняя неудобства пользователям. В контексте данной актуальной проблемы операционные системы (OS) современных мобильных устройств выполнены с возможностью отключать отдельные ядра CPU, когда они не нагружены, с тем чтобы ими не потреблялась никакая энергия, и последовательно включать ядра CPU по мере увеличения вычислительной нагрузки в устройстве.In view of the increase in computing power, as discussed above, efficient energy management is relevant for smartphones, and it is now common for a smartphone battery that is fully charged in the morning to be discharged in the evening, thereby causing inconvenience to users. In the context of this urgent problem, the operating systems (OS) of modern mobile devices are capable of disconnecting individual CPU cores when they are not loaded so that they do not consume any energy, and sequentially turning on the CPU cores as the computing load in the device increases.

Другая большая проблема, с которой сталкиваются современные мобильные устройства, заключается в обеспечении безопасности. Как замечено выше, современные мобильные операционные системы (OS) (например, Android) являются расширяемыми, и, при обновлении или расширении такой OS или приложений, исполняющихся на ней, может быть загружено вредоносное программное обеспечение, которое может скомпрометировать OS вплоть до уровня ядра. В частности, в настоящее время вполне обычно, когда пользователи хранят конфиденциальные данные в своих смартфонах, следовательно, нежелательный контроль над такими данными может быть получен вредоносным программным обеспечением.Another big problem that modern mobile devices face is security. As noted above, modern mobile operating systems (OSs) (such as Android) are extensible, and when updating or expanding such an OS or applications running on it, malicious software can be downloaded that can compromise the OS down to the kernel level. In particular, at present it is quite common for users to store confidential data in their smartphones, therefore, unwanted control over such data can be obtained by malicious software.

В 2003 компания ARM, которая известна по всему миру разработкой архитектур процессоров, представила технологию TrustZone («Доверенная Зона») для решения последней из вышеуказанных проблем. В целом, TrustZone предоставляет, с точки зрения ресурсов мобильного устройства, две среды: защищенную среду («Защищенное Окружение» («Secure World»)) и незащищенную среду («Незащищенное Окружение» («Non-Secure World»)), которые изолированы друг от друга на уровне аппаратного обеспечения. С этой целью, две независимых операционных системы установлены в мобильном устройстве - одна функционирует в Защищенном Окружении и упоминается как SecureOS («Защищенная ОС»), в то время как другая функционирует в Незащищенном Окружении и упоминается как RichOS («Полнофункциональная ОС»). Каждое CPU или ядро CPU выполнено с возможностью функционирования либо в защищенном режиме, либо в незащищенном режиме, и может быть инициировано его переключение из одного режима в другой. Каждый из этих режимов имеет свои собственные версии банков системных регистров. Когда ядро CPU переключается в защищенный режим, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в Защищенном Окружении. В то же время, когда ядро CPU находится в незащищенном режиме, RichOS получает управление на этом ядре CPU и способна использовать ресурсы, которые предназначены быть доступными в Незащищенном Окружении. То есть, каждая из незащищенной среды и защищенной среды задействуется из расчета на CPU: например, в то время как одно ядро CPU функционирует в защищенном режиме и, следовательно, находится под управлением SecureOS в Защищенном Окружении, другое ядро CPU может функционировать в незащищенном режиме под управлением RichOS в Незащищенном Окружении.In 2003, ARM, known worldwide for its processor architecture, introduced TrustZone technology to solve the last of the above problems. In general, TrustZone provides, in terms of mobile device resources, two environments: a secure environment (“Secure World”) and an insecure environment (“Non-Secure World”) that are isolated apart at the hardware level. To this end, two independent operating systems are installed in the mobile device - one operates in a Protected Environment and is referred to as SecureOS (“Protected OS”), while the other operates in an Unsecured Environment and is referred to as RichOS (“Full Functional OS”). Each CPU or CPU core is configured to function either in protected mode or in unprotected mode, and it can be initiated from one mode to another. Each of these modes has its own version of the banks of system registers. When the CPU core switches to protected mode, SecureOS gains control on that CPU core and is able to use the resources of the mobile device that are intended to be available in a Protected Environment. At the same time, when the CPU core is in unprotected mode, RichOS gains control on this CPU core and is able to use resources that are intended to be available in an Unprotected Environment. That is, each of the unprotected environment and the protected environment is used based on the CPU: for example, while one CPU core operates in protected mode and, therefore, is managed by SecureOS in a Protected Environment, the other CPU core can operate in unprotected mode under running RichOS in an Unprotected Environment.

Характерными примерами RichOS являются Android и Tizen. То есть, RichOS является полнофункциональной OS, с которой непосредственно взаимодействует пользователь либо с помощью интерфейсов OS и вспомогательных программ (утилит), либо с помощью приложений, исполняющихся под ее управлением. Общие функциональные аспекты RichOS, следовательно, широко известны. Кроме того, RichOS реализует большинство драйверов, включая те, которые непосредственно манипулируют аппаратными средствами мобильного устройств, в частности, включают и отключают ядра CPU.Typical examples of RichOS are Android and Tizen. That is, RichOS is a fully functional OS, with which the user interacts directly either with the help of OS interfaces and auxiliary programs (utilities), or with the help of applications running under its control. The general functional aspects of RichOS are therefore widely known. In addition, RichOS implements most drivers, including those that directly manipulate the hardware of mobile devices, in particular, enable or disable the CPU core.

В отличие от RichOS, SecureOS имеет довольно небольшой размер и очень ограниченную функциональность, так чтобы SecureOS была по минимуму подвержена ошибкам. SecureOS ответственна только за выполнение задач, которые фактически являются конфиденциальными в смысле безопасности. Существуют приложения, исполняющиеся только под управлением SecureOS (доверенные приложения).Unlike RichOS, SecureOS has a fairly small size and very limited functionality so that SecureOS is minimally error prone. SecureOS is only responsible for tasks that are actually confidential in the sense of security. There are applications that run only under SecureOS (trusted applications).

Некоторые ресурсы мобильного устройства, которые доступны в Защищенном Окружении, физически не доступны из Незащищенного Окружения. Например, SecureOS использует части хранилища мобильного устройства (например, DRAM), к которому никоим образом нельзя осуществить доступ из Незащищенного Окружения. Это делает возможным безопасное хранение информации, которая очень конфиденциальна (например, ключи, коды и т.д.). Даже если человек обладает неавторизованным удаленным управлением над RichOS вплоть до уровня ее ядра, то этот человек будет, однако, неспособен осуществить доступ к упомянутой очень конфиденциальной информации.Some mobile device resources that are available in a Protected Environment are not physically accessible from an Unsecured Environment. For example, SecureOS uses parts of the storage of a mobile device (for example, DRAM), which can in no way be accessed from the Unsecured Environment. This makes it possible to safely store information that is very confidential (e.g. keys, codes, etc.). Even if a person has unauthorized remote control over RichOS up to the level of its core, then this person will, however, be unable to access the aforementioned very confidential information.

Как следует из вышесказанного, SecureOS и RichOS функционируют одновременно в мобильном устройстве. В некоторых вариантах реализации, когда происходит начальная загрузка мобильного устройства, то после выполнения последовательности начальной загрузки сначала инициализируется SecureOS, тогда как RichOS инициализируется после нее.As follows from the above, SecureOS and RichOS operate simultaneously in a mobile device. In some implementations, when the mobile device is booted, then after the bootstrap sequence is executed, SecureOS is initialized first, while RichOS is initialized after it.

Несмотря на строгую изоляцию друг от друга, предусмотрен специальный интерфейс для сообщения между SecureOS и RichOS. В частности, RichOS имеет специализированный системный компонент, драйвер RichOS, а SecureOS имеет специализированный системный компонент, планировщик SecureOS. Эти компоненты выполнены с возможностью сообщения друг с другом через упомянутый интерфейс. Помимо обеспечения связи с SecureOS, драйвер RichOS выполняет другие функции: в частности, он включает и отключает ядра CPU. Планировщик SecureOS планирует исполнение потоков SecureOS посредством поддержания очереди их исполнения. Следует отметить, что RichOS также имеет свой планировщик RichOS, функционирующий, по существу, аналогичным образом.Despite the strict isolation from each other, there is a special interface for communication between SecureOS and RichOS. In particular, RichOS has a specialized system component, the RichOS driver, and SecureOS has a specialized system component, the SecureOS scheduler. These components are configured to communicate with each other via said interface. In addition to providing communication with SecureOS, the RichOS driver performs other functions: in particular, it turns on and off the CPU core. The SecureOS Scheduler schedules the execution of SecureOS threads by maintaining a queue for their execution. It should be noted that RichOS also has its own RichOS scheduler, which functions in essentially the same way.

Вследствие ограниченной функциональности, как обсуждено выше, SecureOS изначально неспособна самостоятельно непосредственно выделять вычислительные ресурсы для исполнения потоков SecureOS, следовательно, SecureOS информирует RichOS о своей потребности в ресурсе(ах), в то время как RichOS выполняет выделение. С этой целью используется механизм сообщения, кратко описанный в общих чертах выше.Due to the limited functionality, as discussed above, SecureOS is initially unable to directly allocate computing resources to execute SecureOS streams, therefore, SecureOS informs RichOS about its resource (s) requirements, while RichOS performs allocation. For this purpose, the communication mechanism briefly described above is used.

Больше подробностей относительно технологии, кратко обсужденной выше, может быть найдено в документе «ARM Security Technology. Building a Secure System using TrustZone® Technology», ARM, 2009 (доступен в Интернете по адресу http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf).More details on the technology briefly discussed above can be found in ARM Security Technology. Building a Secure System using TrustZone® Technology ”, ARM, 2009 (available online at http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper .pdf).

Теперь будет рассмотрен частный пример функционирования смартфона, который известным образом поддерживает Защищенное Окружение и Незащищенное Окружение. Данный пример относится к вводу пользователем пароля на заблокированном сенсорном экране смартфона для разблокирования сенсорного экрана. Когда пользователь начинает вводить свой пароль на экране смартфона, то связанное с этим клиентское приложение RichOS посылает команду, которая переносится в коммуникационный процесс. Коммуникационный процесс является системной службой RichOS, содержащей набор коммуникационных потоков, количество которых равно количеству ядер CPU в смартфоне. Каждый коммуникационный поток может быть привязан к конкретному ядру CPU, так что этот коммуникационный поток исполняется на данном ядре CPU. Такая привязка обычно реализуется посредством соответственной установки свойства affinity (‘cродство’) коммуникационного потока (данная функциональность известна с SMP (Симметричной Мультипроцессорной Обработки)). Когда коммуникационный поток начинает исполняться на ядре CPU, то он переключает ядро CPU в защищенный режим. Поэтому, по приему команды, коммуникационный процесс разблокирует один из своих коммуникационных потоков для назначения ему команды, данный коммуникационный поток исполняется на некотором ядре CPU и переключает это ядро CPU в защищенный режим. SecureOS получает управление на данном ядре CPU, планировщик SecureOS начинает исполняться на нем и разблокирует по меньшей мере один поток доверенного приложения, ответственного за защищенную обработку ввода с сенсорного экрана. Этот поток исполняется в ядре CPU для обработки упомянутой команды, и в течение исполнения все контроллеры сенсорного экрана смартфона функционируют только в Защищенном Окружении: то есть, ни приложение RichOS, исполняющееся на другом ядре CPU, ни сама RichOS не имеет физического доступа к контроллерам сенсорного экрана. Данный отказ доступа реализуется на уровне шин, обслуживающих эти контроллеры. Следует подчеркнуть, что другое аппаратное обеспечение смартфона может стать недоступным для Незащищенного Окружения схожим образом в других контекстах. После завершения обработки команды поток блокируется, результат обработки передается планировщиком SecureOS драйверу RichOS, наряду с переключением ядра CPU обратно в незащищенный режим, и результат пересылается коммуникационным процессом клиентскому приложению RichOS. Как видно, такая конфиденциальная операция, как аутентификация по паролю, выполняется защищенным от вмешательства образом.Now we will consider a particular example of the functioning of a smartphone that in a known manner supports a Protected Environment and an Unprotected Environment. This example refers to the user entering a password on the locked touch screen of a smartphone to unlock the touch screen. When the user begins to enter his password on the smartphone screen, the associated RichOS client application sends a command that is transferred to the communication process. The communication process is a RichOS system service containing a set of communication flows, the number of which is equal to the number of CPU cores in the smartphone. Each communication stream can be associated with a specific CPU core, so this communication stream runs on a given CPU core. Such a binding is usually implemented by appropriately setting the affinity (‘affinity’) property of the communication stream (this functionality is known with SMP (Symmetric Multiprocessor Processing)). When the communication flow begins to run on the CPU core, it switches the CPU core to protected mode. Therefore, upon receiving a command, the communication process unlocks one of its communication flows for assigning a command to it, this communication stream is executed on some CPU core and switches this CPU core to protected mode. SecureOS gains control on this CPU core, the SecureOS scheduler starts to run on it and unlocks at least one thread of the trusted application responsible for the secure processing of input from the touch screen. This thread is executed in the CPU core to process the mentioned command, and during execution all the touch screen controllers of the smartphone function only in the Protected Environment: that is, neither the RichOS application running on the other CPU core nor RichOS itself has physical access to the touch screen controllers . This access denial is implemented at the bus level serving these controllers. It should be emphasized that other smartphone hardware may become inaccessible to the Unprotected Environment in a similar way in other contexts. After processing the command, the flow is blocked, the processing result is transmitted by the SecureOS scheduler to the RichOS driver, along with the CPU core switching back to insecure mode, and the result is sent by the communication process to the RichOS client application. As you can see, such a confidential operation as password authentication is performed in a way that is protected from interference.

Должно быть очевидно, что обработка ввода пароля не является интенсивной в вычислительном отношении задачей. Однако в настоящее время существуют другие технологии аутентификации, реализованные в современных мобильных устройствах, которые намного более интенсивны в вычислительном отношении. Например, биометрическая аутентификация, основанная на распознавании радужной оболочки глаза, является очень сложной и сильно потребляющей ресурсы задачей, и она должна быть полностью реализована в Защищенном Окружении. Существуют также другие примеры исполнения интенсивных в вычислительном отношении задач в Защищенном Окружении: например, может потребоваться исполнение в нем воспроизведения видео высокой четкости.It should be obvious that password entry processing is not computationally intensive. However, there are currently other authentication technologies implemented in modern mobile devices that are much more computationally intensive. For example, biometric authentication based on recognition of the iris is a very complex and resource-consuming task, and it must be fully implemented in a Protected Environment. There are also other examples of computationally intensive tasks in a Protected Environment: for example, it may be necessary to perform high-definition video playback in it.

Следует отметить, что производительность исполнения под управлением SecureOS не вызывала большой озабоченности в предшествующем уровне техники. Однако в настоящее время существует проблема, которая вызывает сложности с производительностью SecureOS и, следовательно, всего мобильного устройства. В соответствии с вышесказанным, SecureOS изначально неспособна непосредственно физически выделять ядра CPU потокам SecureOS - она только обращается к RichOS, в то время как в RichOS коммуникационные потоки активируются и соответственно назначаются ядрам CPU. Фактически, планировщик RichOS может назначать все активированные коммуникационные потоки одному и тому же ядру CPU. В таком случае SecureOS будет выполнять исполнение, которое «распараллелено» на одном ядре CPU. Кроме того, SecureOS не способна ни включать неактивные ядра CPU самостоятельно, ни запрашивать RichOS выполнить такое включение с целью оптимизации функционирования SecureOS. То есть, RichOS не может включать ранее отключенные ядра CPU для исполнения потоков SecureOS, в каковом случае возникает упомянутое «распараллеливание на одном ядре» (здесь следует отметить, что такая ситуация обычна для современных мобильных устройств). Описанная проблема, очевидно, приводит в результате к значительному ухудшению производительности.It should be noted that performance performance under SecureOS was not a major concern in the prior art. However, there is currently a problem that is causing performance issues with SecureOS, and therefore the entire mobile device. In accordance with the foregoing, SecureOS is initially incapable of directly physically allocating CPU cores to SecureOS threads - it only accesses RichOS, while in RichOS communication flows are activated and assigned to the CPU cores accordingly. In fact, the RichOS scheduler can assign all activated communication threads to the same CPU core. In this case, SecureOS will execute the execution, which is “parallelized” on one core of the CPU. In addition, SecureOS is neither able to turn on inactive CPU cores on its own, nor ask RichOS to perform such a switch in order to optimize the operation of SecureOS. That is, RichOS cannot include previously disabled CPU cores for executing SecureOS threads, in which case the aforementioned “parallelization on one core” occurs (it should be noted that this situation is common for modern mobile devices). The described problem obviously results in a significant performance degradation.

В US 8375221 предложен способ задействования доверенной среды исполнения в вычислительных устройствах без какого-либо аппаратного модуля доверенной платформы, однако, никакого внимания не уделено функционированию в многопроцессорных системах. Далее, в US 2015/0059007 предложен способ инициализации SecureOS в многопроцессорной среде; однако, это техническое решение сфокусировано только на времени начальной загрузки.US 8375221 proposes a method of enabling a trusted execution environment in computing devices without any hardware module of a trusted platform, however, no attention has been paid to functioning in multiprocessor systems. Further, in US 2015/0059007, a method for initializing SecureOS in a multiprocessor environment is proposed; however, this technical solution focuses only on boot time.

СУЩНОСТЬ ИЗОБРЕТЕНИЯSUMMARY OF THE INVENTION

Ввиду недостатков технических решений предшествующего уровня техники, описанных в общих чертах выше, задача настоящего изобретения заключается в предоставлении технологии, которая обеспечила бы SecureOS возможность управлять выделением ядер CPU потокам SecureOS, в частности, управлять количеством ядер CPU, доступных для SecureOS, с тем чтобы существующие ресурсы использовались более полно в SecureOS и производительность SecureOS для критичных ко времени операций (например, распознавания радужной оболочки глаза) была повышена.Due to the drawbacks of the technical solutions of the prior art described in general terms above, the object of the present invention is to provide a technology that enables SecureOS to control the allocation of CPU cores to SecureOS threads, in particular, to control the number of CPU cores available for SecureOS so that existing resources were used more fully in SecureOS and SecureOS performance for time-critical operations (for example, iris recognition) was improved.

В соответствии с первым аспектом настоящего изобретения предложен способ функционирования мобильного устройства. Мобильное устройство содержит по меньшей мере один процессор (CPU), имеющий множество ядер CPU, причем каждое ядро CPU приспособлено для функционирования либо в защищенном режиме, либо в незащищенном режиме. В мобильном устройстве установлены незащищенная операционная система (RichOS) и защищенная операционная система (SecureOS), причем как RichOS, так и SecureOS поддерживают многопоточность. SecureOS и RichOS, будучи изолированными друг от друга вплоть до уровня аппаратного обеспечения, выполнены с возможностью сообщаться друг с другом через по меньшей мере один предварительно заданный интерфейс. Способ содержит этапы, на которых: после активации потока в SecureOS, назначают, в SecureOS, поток ядру CPU, причем упомянутое назначение включает в себя этап, на котором изменяют маску CPU, при этом маска CPU является структурой данных, поддерживаемой в SecureOS для информирования RichOS о текущих потребностях SecureOS в ядрах CPU; передают, посредством SecureOS, маску CPU в RichOS для запрашивания RichOS предоставить SecureOS управление на ядре CPU; на основе маски CPU, включают, посредством RichOS, ядро CPU, если ядро CPU отключено; и переключают, посредством RichOS, ядро CPU в защищенный режим, тем самым предоставляя SecureOS управление на ядре CPU.In accordance with a first aspect of the present invention, a method for operating a mobile device is provided. A mobile device comprises at least one processor (CPU) having a plurality of CPU cores, each CPU core being adapted to function either in a secure mode or in an unprotected mode. The mobile device has an unsecured operating system (RichOS) and a secure operating system (SecureOS), and both RichOS and SecureOS support multi-threading. SecureOS and RichOS, being isolated from each other up to the level of hardware, are configured to communicate with each other via at least one predefined interface. The method comprises the steps of: after activating the thread in SecureOS, the thread is assigned, in SecureOS, to the CPU core, said destination including the step of changing the CPU mask, the CPU mask being the data structure supported by SecureOS to inform RichOS About the current SecureOS needs for CPU cores; transmit, via SecureOS, the CPU mask to RichOS to request RichOS to provide SecureOS control on the CPU core; based on the CPU mask, include, through RichOS, the CPU core if the CPU core is disabled; and switch, via RichOS, the CPU core to protected mode, thereby providing SecureOS control on the CPU core.

В соответствии с вариантом осуществления настоящего изобретения, изоляция реализована, в смысле ресурсов мобильного устройства, в виде незащищенной среды и защищенной среды. Каждая из незащищенной среды и защищенной среды задействуется из расчета на ядро CPU (на поядровой основе): когда ядро CPU находится в защищенном режиме, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в защищенной среде, а когда ядро CPU находится в незащищенном режиме, RichOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в незащищенной среде. Мобильное устройство содержит ресурсы аппаратного обеспечения, которые при их использовании в защищенной среде становятся недоступными из незащищенной среды. SecureOS содержит планировщик SecureOS, выполненный с возможностью планирования исполнения потоков SecureOS. RichOS содержит: планировщик RichOS, выполненный с возможностью планирования исполнения потоков RichOS; драйвер RichOS, выполненный с возможностью сообщения с планировщиком SecureOS, причем драйвер RichOS выполнен с возможностью включения ядер CPU; и коммуникационный процесс. Коммуникационный процесс содержит набор коммуникационных потоков, при этом каждый коммуникационный поток привязан к отличному от других ядру CPU, так что этот коммуникационный поток может исполняться только на данном ядре CPU. Каждый коммуникационный поток выполнен с возможностью, при его исполнении на ядре CPU, к которому этот коммуникационный поток привязан, переключать это ядро CPU в защищенный режим. Привязка предпочтительно содержит соответственную установку свойства affinity коммуникационного потока. Мобильное устройство предпочтительно имеет области памяти, которые доступны только посредством SecureOS.According to an embodiment of the present invention, isolation is implemented, in the sense of the resources of a mobile device, as an insecure environment and a secure environment. Each of the unprotected environment and the protected environment is used based on the CPU core (on a core basis): when the CPU core is in protected mode, SecureOS gains control on this CPU core and is able to use the resources of a mobile device that are designed to be available in a protected environment, and when the CPU core is in unprotected mode, RichOS gains control on this CPU core and is able to use the resources of the mobile device that are designed to be available in an insecure environment. A mobile device contains hardware resources that, when used in a secure environment, become inaccessible from an insecure environment. SecureOS contains a SecureOS scheduler configured to schedule the execution of SecureOS threads. RichOS contains: RichOS scheduler, configured to schedule execution of RichOS threads; a RichOS driver configured to communicate with the SecureOS scheduler, wherein the RichOS driver is configured to include CPU cores; and communication process. The communication process contains a set of communication streams, with each communication stream tied to a different core CPU, so that this communication stream can only be executed on a given CPU core. Each communication stream is configured to, when executed on the CPU core, to which this communication stream is attached, switch this CPU core to protected mode. The binding preferably contains a corresponding setting of the affinity property of the communication flow. The mobile device preferably has memory areas that are accessible only through SecureOS.

В соответствии с вариантом осуществления настоящего изобретения, упомянутый поток является одним из одного или более потоков SecureOS, созданных доверенным приложением, исполняющимся в защищенной среде, при этом упомянутая активация содержит этапы, на которых: после выдачи клиентом RichOS команды, подлежащей обработке доверенным приложением, коммуникационный процесс помещает команду в его очередь и назначает команде соответственный коммуникационный поток; и после запуска коммуникационного потока на ядре CPU, переключают ядро CPU в защищенный режим, и планировщик SecureOS исполняется на ядре CPU и разблокирует, по меньшей мере, упомянутый поток.According to an embodiment of the present invention, said stream is one of one or more SecureOS streams created by a trusted application running in a secure environment, said activation comprising the steps of: after a RichOS client issues a command to be processed by the trusted application, communication the process puts the team in its turn and assigns the corresponding communication flow to the team; and after starting the communication stream on the CPU core, the CPU core is switched to the protected mode, and the SecureOS scheduler is executed on the CPU core and unlocks at least said stream.

В соответствии с вариантом осуществления настоящего изобретения, упомянутая структура данных содержит битовое поле, при этом упомянутое изменение содержит этапы, на которых, посредством планировщика SecureOS: устанавливают, в битовом поле, битовую запись, соответствующую ядру CPU, если ни одного потока SecureOS доверенного приложения не было ранее назначено ядру CPU. Способ дополнительно содержит этап, на котором: помещают поток в очередь планировщика SecureOS и выделяют временную квоту для исполнения потока.According to an embodiment of the present invention, said data structure comprises a bit field, said change comprising the steps of setting the bit record corresponding to the CPU core in the bit field using the SecureOS scheduler: if no trustedOS trusted application thread is was previously assigned to the CPU core. The method further comprises the step of: placing the stream in the SecureOS scheduler queue and allocating a temporary quota for the execution of the stream.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, после изменения маски CPU в SecureOS, каковое изменение не связано с потоком SecureOS, исполняющимся в настоящее время в ядре CPU: вытесняют исполняющийся в настоящее время поток SecureOS из ядра CPU и возвращают данный поток SecureOS в очередь планировщика SecureOS.According to an embodiment of the present invention, the method further comprises the steps of, after changing the CPU mask in SecureOS, which change is not related to the SecureOS thread currently executing in the CPU core: crowding out the currently running SecureOS thread from the CPU core and return the given SecureOS stream to the SecureOS scheduler queue.

В соответствии с вариантом осуществления настоящего изобретения, упомянутая передача содержит этапы, на которых, посредством планировщика SecureOS: после завершения исполнения/вытеснения какого-либо потока SecureOS в ядре CPU, в случае завершения, блокируют поток SecureOS, если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновляют маску CPU посредством сбрасывания битовой записи, соответствующей ядру CPU, и вставляют маску CPU в результат упомянутого исполнения и возвращают этот результат в RichOS; в случае вытеснения, либо вставляют маску CPU в результат, указывающий незавершенное исполнение, и возвращают этот результат в RichOS, либо помещают маску CPU в разделяемую память. После этого, управление на ядре CPU переводится обратно в незащищенную среду впоследствии.In accordance with an embodiment of the present invention, said transfer comprises the steps in which, through the SecureOS scheduler: after completion of execution / crowding out of any SecureOS thread in the CPU core, if completed, block the SecureOS thread if no other SecureOS threads are currently not assigned to the CPU core, update the CPU mask by discarding the bit record corresponding to the CPU core, and insert the CPU mask into the result of the mentioned execution and return this result to RichOS; in case of crowding out, either insert the CPU mask into the result indicating incomplete execution, and return this result to RichOS, or put the CPU mask in shared memory. After that, control on the CPU core is transferred back to the insecure environment afterwards.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, посредством драйвера RichOS: извлекают маску CPU либо из результата, либо из разделяемой памяти; сопоставляют маску CPU с включенными на текущий момент ядрами CPU и, если ядро CPU в настоящее время отключено, включают ядро CPU; и сохраняют маску CPU так, чтобы она была доступной коммуникационному процессу.According to an embodiment of the present invention, the method further comprises the steps of, by means of the RichOS driver: extracting the CPU mask from either the result or the shared memory; match the CPU mask with the currently active CPU cores and, if the CPU core is currently disabled, turn on the CPU core; and save the CPU mask so that it is available to the communication process.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, посредством коммуникационного процесса, отслеживают маску CPU и разблокируют коммуникационный поток, который привязан к ядру CPU, и помещают, посредством планировщика RichOS, коммуникационный поток в очередь планировщика RichOS; запускают исполнение коммуникационного потока из очереди планировщика RichOS на ядре CPU и переключают, посредством коммуникационного потока, ядро CPU в защищенный режим, тем самым переводя управление на ядре CPU в защищенную среду; и начинают исполнение планировщика SecureOS на ядре CPU и переключают планировщик SecureOS на исполнение упомянутого потока.According to an embodiment of the present invention, the method further comprises the steps of, by means of a communication process, monitoring the CPU mask and unlocking the communication stream that is attached to the CPU core, and placing, through the RichOS scheduler, the communication stream into the RichOS scheduler queue; start the execution of the communication stream from the RichOS scheduler queue on the CPU core and switch, through the communication stream, the CPU core to protected mode, thereby transferring control on the CPU core to a protected environment; and start the execution of the SecureOS scheduler on the CPU core and switch the SecureOS scheduler to execute said thread.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, после завершения исполнения потока на ядре CPU, посредством планировщика SecureOS: блокируют поток; вставляют маску CPU в результат исполнения; и предоставляют результат драйверу RichOS и переводят управление на ядре CPU обратно в незащищенную среду. Предпочтительно, способ дополнительно содержит этап, на котором, после блокирования потока: если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновляют, посредством планировщика SecureOS, маску CPU посредством сбрасывания битовой записи. Предпочтительно, способ дополнительно содержит этап, на котором: пересылают, посредством коммуникационного процесса, результат, принятый от драйвера RichOS, клиенту RichOS для последующей обработки.In accordance with an embodiment of the present invention, the method further comprises the steps of, upon completion of execution of the thread on the CPU core, via the SecureOS scheduler: blocking the thread; insert the CPU mask into the execution result; and provide the result to the RichOS driver and transfer control on the CPU core back to the insecure environment. Preferably, the method further comprises, after blocking the stream: if no other SecureOS threads are currently assigned to the CPU core, update, via the SecureOS scheduler, the CPU mask by resetting the bit record. Preferably, the method further comprises the step of: transferring, through a communication process, the result received from the RichOS driver to the RichOS client for subsequent processing.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этап, на котором, после вытеснения потока из ядра CPU по истечении временной квоты или по прерыванию, принятому из RichOS, посредством планировщика SecureOS возвращают поток в очередь планировщика SecureOS для завершения исполнения позже.According to an embodiment of the present invention, the method further comprises the step of, after expelling the thread from the CPU core after a time quota or interrupt received from RichOS, the thread is returned to the SecureOS scheduler queue by means of the SecureOS scheduler to complete execution later.

В соответствии с вариантом осуществления настоящего изобретения, RichOS выполнена с возможностью последовательного включения отключенных в настоящее время ядер CPU, по мере увеличения вычислительной нагрузки в мобильном устройстве, в предварительно установленном порядке, определяемом номерами ядер CPU, и планировщик SecureOS выполнен с возможностью выделения ядер CPU потокам SecureOS в соответствии с упомянутым порядком.According to an embodiment of the present invention, RichOS is configured to sequentially turn on currently disabled CPU cores as the computing load in the mobile device increases in a predetermined order determined by the numbers of the CPU cores, and the SecureOS scheduler is configured to allocate CPU cores to threads SecureOS in accordance with the above procedure.

Согласно второму аспекту настоящего изобретения, предложено мобильное устройство. Мобильное устройство содержит по меньшей мере один процессор (CPU), имеющий множество ядер CPU, причем каждое ядро CPU приспособлено для функционирования либо в защищенном режиме, либо в незащищенном режиме. В мобильном устройстве установлены незащищенная операционная система (RichOS) и защищенная операционная система (SecureOS), причем как RichOS, так и SecureOS поддерживают многопоточность. SecureOS и RichOS, будучи изолированными друг от друга вплоть до уровня аппаратного обеспечения, выполнены с возможностью сообщения друг с другом через по меньшей мере один предварительно заданный интерфейс. SecureOS выполнена с возможностью: после активации потока в SecureOS, назначать поток ядру CPU, причем данное назначение включает в себя изменение маски CPU, при этом маска CPU является структурой данных, поддерживаемой в SecureOS для информирования RichOS о текущих потребностях SecureOS в ядрах CPU; и передавать маску CPU в RichOS для запрашивания RichOS предоставить SecureOS управление на ядре CPU. RichOS выполнена с возможностью: на основе маски CPU, включать ядро CPU, если ядро CPU отключено; и переключать ядро CPU в защищенный режим, тем самым предоставляя SecureOS управление на ядре CPU.According to a second aspect of the present invention, there is provided a mobile device. A mobile device comprises at least one processor (CPU) having a plurality of CPU cores, each CPU core being adapted to function either in a secure mode or in an unprotected mode. The mobile device has an unsecured operating system (RichOS) and a secure operating system (SecureOS), and both RichOS and SecureOS support multi-threading. SecureOS and RichOS, being isolated from each other up to the hardware level, are configured to communicate with each other via at least one predefined interface. SecureOS is configured to: after activating the thread in SecureOS, assign the thread to the CPU core, and this assignment includes changing the CPU mask, and the CPU mask is a data structure supported by SecureOS to inform RichOS about the current SecureOS needs in CPU cores; and pass the CPU mask to RichOS to request RichOS to provide SecureOS control on the CPU core. RichOS is configured to: enable the CPU core based on the CPU mask if the CPU core is disabled; and switch the CPU core to protected mode, thereby providing SecureOS control on the CPU core.

В отличие от методов предшествующего уровня техники, настоящее изобретение дает возможность оптимизации количества ядер CPU, доступных единовременно для использования со стороны SecureOS, и, следовательно, ускорения операций SecureOS и минимизации задержки откликов SecureOS, тем самым повышая производительность SecureOS.Unlike prior art methods, the present invention enables optimization of the number of CPU cores available at one time for use by SecureOS, and therefore, accelerates SecureOS operations and minimizes SecureOS response latency, thereby improving SecureOS performance.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙBRIEF DESCRIPTION OF THE DRAWINGS

На Фиг.1 показано схематическое изображение смартфона, содержащего CPU, имеющий четыре ядра CPU, одно из которых отключено.Figure 1 shows a schematic representation of a smartphone containing a CPU having four CPU cores, one of which is disabled.

На Фиг.2 показана блок-схема последовательности операций, изображающая общие аспекты функционирования SecureOS и RichOS в мобильном устройстве согласно настоящему изобретению.2 is a flowchart depicting general aspects of the operation of SecureOS and RichOS in a mobile device according to the present invention.

На Фиг.3 показано схематическое изображение примерного варианта реализации маски CPU в виде битового поля.Figure 3 shows a schematic representation of an exemplary embodiment of a CPU mask in the form of a bit field.

На Фиг.4 показано схематическое изображение компонентов SecureOS и RichOS, задействуемых в функционировании согласно настоящему изобретению.Figure 4 shows a schematic representation of the components of SecureOS and RichOS involved in the operation according to the present invention.

На Фиг.5 показана блок-схема последовательности операций способа функционирования SecureOS и RichOS в мобильном устройстве согласно варианту осуществления настоящего изобретения.5 is a flowchart of a method for operating SecureOS and RichOS in a mobile device according to an embodiment of the present invention.

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯDETAILED DESCRIPTION OF EMBODIMENTS

Настоящее изобретение направлено на мобильное устройство, имеющее улучшенную реализацию SecureOS, и способ его функционирования.The present invention is directed to a mobile device having an improved implementation of SecureOS, and a method for its operation.

Мобильное устройство согласно настоящему изобретению содержит, помимо других широко известных компонентов аппаратного обеспечения, по меньшей мере один процессор (CPU), имеющий множество ядер CPU. Каждое ядро CPU может быть физически включено/отключено (см. Фиг.1) и выполнено с возможностью работы либо в защищенном режиме, либо в незащищенном режиме. В мобильном устройстве установлены две операционные системы: RichOS и SecureOS. Как RichOS, так и SecureOS поддерживают многопоточность и выполнены с возможностью одновременного функционирования в мобильном устройстве. В соответствии с предыдущим раскрытием, SecureOS и RichOS изолированы друг от друга вплоть до уровня аппаратного обеспечения, тем не менее, для сообщения между этими двумя OS известным образом предусмотрен по меньшей мере один предварительно заданный интерфейс. Упомянутый интерфейс описан, например, в http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf.The mobile device according to the present invention contains, in addition to other well-known hardware components, at least one processor (CPU) having a plurality of CPU cores. Each core of the CPU can be physically turned on / off (see Figure 1) and is configured to operate either in protected mode or in unprotected mode. The mobile device has two operating systems: RichOS and SecureOS. Both RichOS and SecureOS support multithreading and are designed to operate simultaneously on a mobile device. In accordance with the previous disclosure, SecureOS and RichOS are isolated from each other up to the hardware level, however, at least one predefined interface is provided for communication between the two OSs in a known manner. The interface is described, for example, in http://infocenter.arm.com/help/topic/com.arm.doc.prd29-genc-009492c/PRD29-GENC-009492C_trustzone_security_whitepaper.pdf.

Такие широко известные мобильные операционные системы (OS), как Android и Tizen, относятся к RichOS, в то время как Google Trusty является примером SecureOS.Well-known mobile operating systems (OSs) like Android and Tizen are all RichOS, while Google Trusty is an example of SecureOS.

Вышеупомянутая изоляция предпочтительно реализуется, в смысле ресурсов мобильного устройства, в виде незащищенной среды («Незащищенного Окружения») и защищенной среды («Защищенного Окружения»). Как описано в общих чертах выше, каждая из незащищенной среды и защищенной среды задействуется на поядровой основе. То есть, когда ядро CPU находится в защищенном режиме, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в Защищенном Окружении. Когда ядро CPU находится в незащищенном режиме, то RichOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в Незащищенном Окружении. Здесь следует напомнить, что некоторые ресурсы аппаратного обеспечения мобильного устройства, когда они используются в защищенной среде, становятся абсолютно недоступными из незащищенной среды. В частности, как упомянуто выше, существуют области в запоминающем устройстве мобильного устройства (например, DRAM), которые доступны только посредством SecureOS.The aforementioned isolation is preferably implemented, in the sense of the resources of a mobile device, in the form of an unprotected environment (“Unprotected Environment”) and a protected environment (“Protected Environment”). As described generally above, each of the unprotected environment and the protected environment is deployed on a core basis. That is, when the CPU core is in protected mode, SecureOS gains control on this CPU core and is able to use the resources of the mobile device that are designed to be available in a Protected Environment. When the CPU core is in unprotected mode, RichOS gains control on this CPU core and is able to use the resources of the mobile device that are designed to be available in the Unsecured Environment. It should be recalled here that some hardware resources of a mobile device, when used in a secure environment, become completely inaccessible from an insecure environment. In particular, as mentioned above, there are areas in the storage device of a mobile device (eg, DRAM) that are accessible only through SecureOS.

Далее со ссылкой на Фиг. 2 будут описаны основные этапы способа 200 функционирования SecureOS и RichOS в мобильном устройстве согласно настоящему изобретению.Next, with reference to FIG. 2, the basic steps of a method 200 for operating SecureOS and RichOS in a mobile device according to the present invention will be described.

На этапе 201 после активации некоторого потока исполнения (обозначенного в данном документе как поток A) в SecureOS, поток A назначается в SecureOS ядру CPU (обозначенному в данном документе как ядро A CPU). Специальная структура данных поддерживается в SecureOS с этой целью в соответствии с настоящим изобретением. Эта структура данных обозначена как «маска CPU» по всей заявке. SecureOS использует маску CPU для информирования RichOS о текущих потребностях SecureOS в ядрах CPU. Маска CPU является, по существу, производной от известных структур данных, разработанных для связывания потоков SecureOS с ядрами CPU.In step 201, after activating some thread of execution (referred to as thread A in this document) in SecureOS, thread A is assigned to the CPU core in SecureOS (designated as CPU core A in this document). A special data structure is maintained in SecureOS for this purpose in accordance with the present invention. This data structure is designated as “CPU mask” throughout the application. SecureOS uses a CPU mask to inform RichOS about the current SecureOS needs in CPU cores. The CPU mask is essentially a derivative of well-known data structures designed to associate SecureOS threads with CPU cores.

Предпочтительный вариант реализации маски CPU согласно одному варианту осуществления является битовым полем (см. Фиг.3). Здесь следует пояснить, что в известной структуре данных, которая описывает поток (более конкретно, поток SecureOS), имеется поле, содержащее номер ядра CPU, которому этот поток назначен (или специальное значение, если поток заблокирован и никакому ядру CPU не назначен). Кроме того, известным образом поддерживается массив контрольных счетчиков, при этом каждый контрольный счетчик подсчитывает, сколько потоков в настоящее время назначено соответственному ядру CPU. Когда некоторый поток назначается некоторому ядру CPU, то соответственный счетчик, связанный с этим ядром CPU, увеличивается на единицу в массиве; иначе, если поток отвязывается от ядра CPU, то счетчик соответственно уменьшается на единицу. В соответствии с вариантом осуществления, когда контрольный счетчик достигает 0, битовая запись (то есть, бит), соответствующая ядру CPU, сбрасывается (например, обнуляется) в маске CPU.A preferred embodiment of a CPU mask according to one embodiment is a bit field (see FIG. 3). It should be explained here that in the known data structure that describes the stream (more specifically, the SecureOS stream), there is a field containing the number of the CPU core to which this stream is assigned (or a special value if the stream is blocked and not assigned to any CPU core). In addition, an array of control counters is supported in a known manner, with each control counter calculating how many threads are currently assigned to the corresponding CPU core. When a thread is assigned to a CPU core, the corresponding counter associated with that CPU core is incremented by one in the array; otherwise, if the thread is untied from the CPU core, then the counter accordingly decreases by one. According to an embodiment, when the reference counter reaches 0, the bit record (i.e., bit) corresponding to the CPU core is reset (e.g., reset to zero) in the CPU mask.

В рассматриваемом случае маска CPU может быть изменена на этапе 201 посредством установки битовой записи, соответствующей ядру A CPU, для указания тем самым того, что SecureOS требуется ядро A CPU для исполнения, по меньшей мере, потока A.In the present case, the CPU mask can be changed in step 201 by setting a bit record corresponding to the CPU core A, thereby indicating that SecureOS requires the CPU core A to execute at least stream A.

Следует подчеркнуть, что вышеупомянутый вариант реализации маски CPU в виде битового поля не является ограничивающим примером, и другие возможные варианты реализации структуры данных маски CPU должны быть очевидными специалисту.It should be emphasized that the aforementioned implementation of the CPU mask in the form of a bit field is not a limiting example, and other possible embodiments of the data structure of the CPU mask should be obvious to a person skilled in the art.

На этапе 202 SecureOS передает маску CPU в RichOS для запрашивания у RichOS предоставить SecureOS управление на ядре CPU. Данная передача переносится через вышеупомянутый известный интерфейс. Следует подчеркнуть, что битовая запись, установленная в маске CPU для ядра A CPU, если она не сброшена, запрещает RichOS отключать ядро A CPU.At step 202, SecureOS passes the CPU mask to RichOS to request RichOS to provide SecureOS control on the CPU core. This transmission is carried through the aforementioned known interface. It should be emphasized that the bit record set in the CPU mask for core A CPU, if it is not reset, prevents RichOS from disconnecting core A CPU.

На этапе 203 RichOS включает, на основе принятой маски CPU, ядро А CPU, если это ядро CPU было ранее отключено.At step 203, RichOS includes, based on the received CPU mask, the CPU core A, if that CPU core was previously disabled.

На этапе 204 RichOS переключает ядро А CPU в защищенный режим. Управление на ядре A CPU тем самым предоставляется в SecureOS.At step 204, RichOS switches the core A of the CPU to protected mode. Management on the core A CPU is thus provided in SecureOS.

Следует понимать, что способ 200, описанный выше, схожим образом выполняется для любого потока SecureOS, а не только потока A.It should be understood that the method 200 described above is similarly performed for any SecureOS stream, not just stream A.

Теперь компоненты SecureOS и RichOS, вовлеченные в выполнение этапов 201-204, обсужденных выше, а также конкретные действия, выполняемые этими компонентами, будут описаны в отношении предпочтительного варианта осуществления настоящего изобретения со ссылкой на Фиг.4.Now, the SecureOS and RichOS components involved in steps 201-204 discussed above, as well as the specific actions performed by these components, will be described with respect to a preferred embodiment of the present invention with reference to FIG. 4.

Как уже обсуждено выше, SecureOS содержит планировщик 401 SecureOS. Основная функция планировщика 401 SecureOS заключается в планировании исполнения потоков SecureOS. Согласно предпочтительному варианту осуществления, планировщик 401 SecureOS ответственен за ведение маски CPU в SecureOS и выполнен с возможностью назначения потоков SecureOS ядрам CPU, и, в соответствии с вышесказанным, маска CPU может соответственным образом изменяться в контексте данного назначения. Другими словами, этап 201 выполняется планировщиком 401 SecureOS, согласно предпочтительному варианту осуществления.As discussed above, SecureOS includes the SecureOS Scheduler 401. The primary function of the 401 SecureOS scheduler is to schedule the execution of SecureOS threads. According to a preferred embodiment, the SecureOS scheduler 401 is responsible for maintaining the CPU mask in SecureOS and is configured to assign SecureOS streams to the CPU kernels, and, as described above, the CPU mask can accordingly be changed in the context of this assignment. In other words, step 201 is performed by SecureOS scheduler 401, according to a preferred embodiment.

Следует отметить, что RichOS по умолчанию выполнена с возможностью последовательного включения отключенных в настоящее время ядер CPU, по мере увеличения вычислительной нагрузки в мобильном устройстве, в предварительно установленном порядке, определяемом номерами ядер CPU. Согласно предпочтительному варианту осуществления, планировщик 401 SecureOS выделяет ядра CPU потокам SecureOS в соответствии с этим предустановленным порядком.It should be noted that RichOS is by default configured to sequentially turn on currently disabled CPU cores, as the computing load in the mobile device increases, in a predefined order determined by the numbers of the CPU cores. According to a preferred embodiment, the SecureOS scheduler 401 allocates CPU cores to SecureOS threads in accordance with this predefined order.

RichOS также содержит планировщик RichOS (не показан), который выполнен с возможностью планирования исполнения потоков RichOS известным образом, подобно планировщику SecureOS. RichOS дополнительно содержит драйвер 410 RichOS. Как описано в общих чертах выше, драйвер 410 RichOS по умолчанию выполнен с возможностью, помимо его других возможностей, физического включения ядер CPU; кроме того, сообщение между SecureOS и RichOS выполняется, в частности, между планировщиком 401 SecureOS и драйвером 410 RichOS через вышеупомянутый предварительно заданный интерфейс 405.RichOS also contains a RichOS scheduler (not shown) that is configured to schedule execution of RichOS threads in a known manner, similar to the SecureOS scheduler. RichOS additionally contains the 410 RichOS driver. As described generally above, the RichOS driver 410 is by default configured to, in addition to its other capabilities, physically enable CPU cores; in addition, communication between SecureOS and RichOS is performed, in particular, between the SecureOS scheduler 401 and the RichOS driver 410 via the aforementioned predefined interface 405.

Еще одним компонентом RichOS, непосредственно задействуемым в обсуждаемом здесь предпочтительном варианте осуществления настоящего изобретения, является коммуникационный процесс (не изображен). Как описано в общих чертах выше, коммуникационный процесс является системной службой RichOS, по умолчанию содержащей набор коммуникационных потоков, количество которых равно количеству ядер CPU в мобильном устройстве, и каждый коммуникационный поток может быть соотнесен с конкретным ядром CPU, так чтобы данный коммуникационный поток исполнялся именно на этом ядре CPU. Всякий коммуникационный поток, когда он начинает исполнение на ядре CPU, к которому этот коммуникационный поток привязан, переключает данное ядро CPU в защищенный режим. Помимо коммуникационных потоков (для сообщения с Защищенным Окружением), коммуникационный процесс может содержать поток(и) для сообщения с клиентами RichOS.Another RichOS component directly involved in the preferred embodiment of the present invention discussed herein is a communication process (not shown). As described in general terms above, the communication process is a RichOS system service, by default containing a set of communication flows, the number of which is equal to the number of CPU cores in the mobile device, and each communication stream can be associated with a specific CPU core, so that this communication stream is executed exactly on this CPU core. Any communication stream, when it starts execution on the CPU core, to which this communication stream is attached, switches this CPU core to protected mode. In addition to communication flows (for communication with a Protected Environment), the communication process may contain flow (s) for communication with RichOS clients.

Как указано выше, упомянутая привязка реализуется известным образом посредством соответственной установки свойства affinity коммуникационного потока. Например, ‘weak affinity’ (‘слабое сродство’) может быть установлено для некоторого коммуникационного потока, тем самым указывая, что данному коммуникационному потоку разрешается исполняться на любом ядре CPU, если нет никаких ядер CPU, на которых данный поток назначен исполняться. Другой пример относится к big.LITTLE системам – технологии, также представленной компанией ARM. Упомянутая технология подразумевает два кластера ядер CPU, среди которых большой (big) кластер состоит из высокопроизводительных ядер, в то время как малый (little) кластер состоит из энергоэффективных ядер CPU, которые не очень производительны. Это обеспечивает возможность балансировать между производительностью и энергопотреблением. Если свойство affinity некоторого потока установлено таким образом, что он назначен на ядра CPU big-кластера, то поток будет исполняться на более быстрых ядрах CPU.As indicated above, said binding is implemented in a known manner by appropriately setting the affinity property of the communication flow. For example, ‘weak affinity’ can be set for some communication thread, thereby indicating that this communication thread is allowed to run on any CPU core if there are no CPU cores on which this thread is assigned to run. Another example relates to big.LITTLE systems - a technology also introduced by ARM. The mentioned technology implies two clusters of CPU cores, among which a large cluster consists of high-performance cores, while a small cluster consists of energy-efficient CPU cores, which are not very productive. This provides the ability to balance between performance and power consumption. If the affinity property of a thread is set in such a way that it is assigned to the CPU cores of a large cluster, then the thread will execute on faster CPU cores.

В соответствии с предпочтительным вариантом осуществления настоящего изобретения, коммуникационному процессу предписывается устанавливать свойство affinity своих коммуникационных потоков таким образом, чтобы каждый коммуникационный поток был привязан к ядру CPU, отличному от других ядер CPU. Другими словами, в предпочтительном варианте осуществления свойство affinity устанавливается таким образом, чтобы между коммуникационными потоками и ядрами CPU было задано взаимно-однозначное соответствие. В результате этого, при такой установке любому из коммуникационных потоков разрешается исполняться только на том ядре CPU, которому он назначен посредством установленного свойства affinity. То есть, планировщик RichOS видит установку коммуникационного потока и направляет его на ядро CPU, которому этот поток назначен. Если ядро CPU отключено драйвером 410 RichOS, то планировщик RichOS сбрасывает привязку соответственного коммуникационного потока к этому ядру CPU в RichOS посредством соответственного изменения свойства affinity данного коммуникационного потока. Следует отметить что, если требуемое ядро(а) CPU недоступно, то планировщик RichOS может проигнорировать affinity и исполнять соответственный поток(и) на доступном ядре(ах) CPU. Напротив, если ранее отключенное ядро CPU повторно включается, то свойство affinity изменяется для восстановления привязки соответственного коммуникационного потока к повторно включенному ядру CPU.In accordance with a preferred embodiment of the present invention, the communication process is required to set the affinity property of its communication flows so that each communication stream is associated with a CPU core different from other CPU cores. In other words, in a preferred embodiment, the affinity property is set so that a one-to-one correspondence is established between the communication flows and the CPU cores. As a result of this, with such an installation, any of the communication flows is allowed to run only on the CPU core to which it is assigned through the set affinity property. That is, the RichOS scheduler sees the installation of a communication stream and directs it to the core of the CPU to which this stream is assigned. If the CPU core is disabled by the 410 RichOS driver, the RichOS scheduler resets the binding of the corresponding communication stream to this CPU core in RichOS by changing the affinity property of this communication stream accordingly. It should be noted that if the required core (s) of the CPU is not available, then the RichOS scheduler can ignore affinity and execute the corresponding thread (s) on the available core (s) of the CPU. In contrast, if a previously disabled CPU core is re-enabled, the affinity property is changed to re-establish the binding of the corresponding communication stream to the re-enabled CPU core.

Теперь ссылкой на Фиг.2, 4, 5 будет рассмотрен конкретный вариант осуществления настоящего изобретения. На Фиг.5 показана примерная последовательность 500 операций, имеющая место при функционировании мобильного устройства согласно предпочтительному варианту осуществления настоящего изобретения.Now, with reference to FIGS. 2, 4, 5, a specific embodiment of the present invention will be considered. 5 shows an exemplary process flow 500 that occurs during operation of a mobile device according to a preferred embodiment of the present invention.

На этапе 501 клиентское приложение 420 RichOS, исполняющееся в Незащищенном Окружении, выдает команду. Клиент 420 RichOS может быть приложением, которое выполнено с возможностью предоставления GUI пользователю для ввода текстового и/или графического пароля или сканирования радужной оболочки глаза пользователя для разблокирования сенсорного экрана мобильного устройства и дополнительно выполнено с возможностью получения вводимой информации. Команда выдается клиентским приложением 420 RichOS в ответ на начало взаимодействия пользователя с GUI в его/ее попытке разблокировать сенсорный экран. В рассматриваемом конкретном варианте осуществления предполагается, что команда должна быть обработана доверенным приложением 402 SecureOS, исполняющимся в Защищенном Окружении, которое ответственно за авторизацию пользователя. Доверенное приложение 402 может быть приложением, которое верифицирует текстовые пароли пользователей, в каковом случае его потребность в ресурсах будет довольно скромной, либо же приложение 402 может быть приложением, сконфигурированным для распознавания и верификации радужных оболочек глаз пользователей, в каковом случае оно очень интенсивно использует ресурсы. То есть, команда, по существу, предназначена для предписания доверенному приложению 402 соответственно обрабатывать введенную информацию и возвращать результат обработки клиентскому приложению 420 RichOS.At step 501, the RichOS client application 420 running in the Unsecured Environment issues a command. RichOS client 420 may be an application that is configured to provide a GUI to a user to enter a text and / or graphic password, or scan the user's iris to unlock the touch screen of a mobile device, and is further configured to receive input information. A command is issued by the 420 RichOS client application in response to the start of user interaction with the GUI in his / her attempt to unlock the touch screen. In this particular embodiment, it is contemplated that the command should be processed by a trusted SecureOS application 402 running in a Secure Environment that is responsible for authorizing the user. A trusted application 402 may be an application that verifies users 'text passwords, in which case its resource requirements will be quite modest, or application 402 may be an application configured to recognize and verify users' irises, in which case it uses resources very intensively . That is, the command is essentially intended to direct the trusted application 402 to process the input information accordingly and return the processing result to the RichOS client application 420.

Доверенное приложение 402 является многопоточным приложением. Другими словами, им создаются один или более потоков SecureOS. В отсутствии вышеупомянутой команды (например, когда мобильное устройство находится в режиме ожидания и в настоящее время не используется пользователем, или когда пользователь пользуется мобильным устройством после успешной разблокировки его сенсорного экрана), потоки доверенного приложения заблокированы.Trusted Application 402 is a multi-threaded application. In other words, it creates one or more SecureOS threads. In the absence of the aforementioned command (for example, when the mobile device is in standby mode and is not currently used by the user, or when the user uses the mobile device after successfully unlocking its touch screen), the threads of the trusted application are blocked.

После того, как клиент RichOS выдал команду, на этапе 502 коммуникационный процесс принимает команду и разблокирует один из своих коммуникационных потоков для назначения ему данной команды. Как следствие, коммуникационный поток помещается в очередь исполнения планировщика RichOS.After the RichOS client issued the command, at step 502, the communication process receives the command and unlocks one of its communication flows to assign it the given command. As a result, the communication flow is placed in the execution queue of the RichOS scheduler.

Затем, на этапе 502, когда коммуникационный поток начинает исполняться на ядре CPU, назначенном ему (в дальнейшем обозначаемом как ядро O CPU для наглядности) планировщиком RichOS, коммуникационный поток переключает ядро O CPU в защищенный режим. После переключения планировщик 401 SecureOS начинает исполняться на ядре O CPU и разблокирует по меньшей мере один поток исполнения, среди упомянутых одного или более потоков SecureOS доверенного приложения 402, который ответственен за обработку команды.Then, at step 502, when the communication flow begins to execute on the CPU core assigned to it (hereinafter referred to as the O CPU core for clarity) by the RichOS scheduler, the communication flow switches the O CPU core to the protected mode. After the switch, SecureOS scheduler 401 starts to run on the O CPU core and unlocks at least one execution thread, among the one or more SecureOS threads of the trusted application 402, which is responsible for processing the command.

Теперь будет рассмотрен случай, когда множество потоков доверенного приложения 402 были разблокированы, и поток A, рассмотренный выше, является одним из этого множества потоков.Now, a case will be considered where a plurality of threads of a trusted application 402 have been unlocked, and thread A discussed above is one of this plurality of threads.

На этапе 503 планировщик 401 SecureOS выделяет ядра CPU разблокированным потокам, и маска CPU обновляется при выполнении этого выделения. В частности, как описано в общих чертах выше, битовая запись, соответствующая ядру A CPU, устанавливается в маске CPU планировщиком 401 SecureOS, если ни одного потока SecureOS доверенного приложения не было ранее назначено ядру A CPU. В данном случае битовая запись предпочтительно изменяется с «0» на «1». Другие потоки исполнения обрабатываются таким же образом. Иными словами, битовые записи, установленные внутри маски CPU таким образом, показывают текущую потребность SecureOS в ядрах CPU. Затем планировщик SecureOS помещает каждый из разблокированных потоков в очередь планировщика SecureOS и выделяет временную квоту для исполнения этого потока.At 503, SecureOS scheduler 401 allocates CPU cores to unlocked threads, and the CPU mask is updated when this allocation is performed. In particular, as described generally above, the bit record corresponding to the A core of the CPU is set in the CPU mask by the SecureOS scheduler 401, if no SecureOS thread of the trusted application has been previously assigned to the A core of the CPU. In this case, the bit record preferably changes from “0” to “1”. Other threads of execution are handled in the same way. In other words, the bit records set inside the CPU mask in this way show the current SecureOS demand for CPU cores. Then, the SecureOS scheduler places each of the unlocked threads in the SecureOS scheduler queue and allocates a temporary quota for this thread to execute.

Как объяснено выше, планировщик 401 SecureOS переключается впоследствии на исполнение одного из множества потоков, который находится на вершине его очереди (в дальнейшем называемого потоком O), в ядре O CPU. В данном случае поток O исполняется в ядре O CPU, которое может отличаться от ядра CPU, в настоящее время назначенного потоку O в маске CPU. Предполагается, что поток A находится в настоящее время в очереди планировщика SecureOS. Следует напомнить в данном месте, что в течение исполнения потоков доверенного приложения определенное аппаратное обеспечение мобильного устройства (например, все контроллеры сенсорного экрана) функционирует только в Защищенном Окружении.As explained above, the SecureOS scheduler 401 subsequently switches to executing one of the plurality of threads that is at the top of its queue (hereinafter referred to as the O thread), in the O core of the CPU. In this case, thread O is executed in the CPU core O, which may be different from the CPU core currently assigned to thread O in the CPU mask. It is assumed that thread A is currently in the SecureOS scheduler queue. It should be recalled at this point that during the execution of threads of a trusted application, certain hardware of a mobile device (for example, all touch screen controllers) operates only in a Protected Environment.

Как должно быть понятно специалисту, этапы 501-503 по Фиг.5, по существу, охватываются этапом 201 с Фиг.2.As should be understood by one skilled in the art, steps 501-503 of FIG. 5 are essentially covered by step 201 of FIG. 2.

Этап 504 относится к возможным сценариям исполнения потока O.Step 504 relates to possible flow execution scenarios for O.

С одной стороны, может возникнуть вытеснение исполняющегося в настоящее время потока O из ядра O CPU, и поток O возвращается в очередь планировщика SecureOS, с тем чтобы исполнение данного потока было возобновлено впоследствии. В таком случае, поток O, по существу, не отличается от потока A, который используется, только для нвглядности, в качестве примерного репрезентативного потока исполнения по всему раскрытию, в то время как действия, связанные с потоком A, будут рассмотрены ниже.On the one hand, a thread O that is currently executing may be forced out of the CPU O core, and thread O will return to the SecureOS scheduler queue so that execution of this thread resumes later. In this case, thread O is essentially no different from thread A, which is used for illustrative purposes only, as an exemplary representative thread of execution throughout the disclosure, while actions related to thread A will be discussed below.

Вытеснение может возникнуть по следующим причинам. Во-первых, исполняющийся поток O может быть вытеснен планировщиком 401 SecureOS по истечении временной квоты, выделенной этому потоку. Во-вторых, вытеснение может возникнуть по прерыванию из RichOS - данный механизм по умолчанию предусмотрен в таких основанных на SecureOS/RichOS мобильных системах. В последнем случае, как только произошло вытеснение, управление на ядре CPU переводится в Незащищенное Окружение, с тем чтобы прерывание было обработано в RichOS, и затем оно возвращается обратно в Защищенное Окружение.Extrusion can occur for the following reasons. Firstly, the running thread O can be replaced by the SecureOS scheduler 401 after the time quota allocated to this thread has elapsed. Secondly, crowding out may occur upon interruption from RichOS - this mechanism is by default provided in such SecureOS / RichOS-based mobile systems. In the latter case, as soon as the crowding-out occurs, the control on the CPU core is transferred to the Unsecured Environment, so that the interrupt is processed in RichOS, and then it returns back to the Protected Environment.

После вытеснения, в соответствии с вариантом осуществления настоящего изобретения, специальный результат, указывающий незавершенное исполнение, возвращается планировщиком 401 SecureOS драйверу 410 RichOS через интерфейс 405, и, согласно настоящему изобретению, текущая маска CPU присоединяется к этому специальному результату. В альтернативном варианте осуществления вытеснение приводит к помещению текущей маски CPU в разделяемую память.After crowding out, in accordance with an embodiment of the present invention, a special result indicating incomplete execution is returned by the SecureOS scheduler 401 to the RichOS driver 410 via interface 405, and according to the present invention, the current CPU mask is attached to this special result. In an alternate embodiment, preemption places the current CPU mask in shared memory.

С другой стороны, может возникнуть успешное завершение исполнения потока O на ядре O CPU, либо после вышеупомянутого начального запуска потока O, либо после его последующего запуска(ов) из очереди планировщика SecureOS. В данном случае планировщик 401 SecureOS блокирует поток O, затем, если никаких других потоков SecureOS в настоящее время не назначено ядру O CPU (то есть, если контрольный счетчик, связанный с ядром O CPU, является нулевым), обновляет маску CPU посредством обнуления битовой записи, соответствующей ядру O CPU, и, согласно настоящему изобретению, вставляет текущую маску CPU в результат исполнения. После этого, результат упомянутого успешного исполнения возвращается планировщиком 401 SecureOS драйверу 410 RichOS через интерфейс 405, и управление на ядре O CPU переводится обратно в Незащищенное Окружение.On the other hand, a successful execution of thread O may occur on the CPU O core, either after the aforementioned initial start of thread O, or after its subsequent launch (s) from the SecureOS scheduler queue. In this case, the SecureOS scheduler 401 blocks the O thread, then, if no other SecureOS threads are currently assigned to the O CPU core (that is, if the checkout counter associated with the O CPU core is zero), updates the CPU mask by resetting the bit record corresponding to the O core of the CPU, and according to the present invention, inserts the current CPU mask into the execution result. After that, the result of the mentioned successful execution is returned by the 401 SecureOS scheduler to the 410 RichOS driver via the 405 interface, and the control on the O CPU core is transferred back to the Unsecured Environment.

Следует отметить, что причины вытеснения, как описано в общих чертах выше, не являются единственно возможными, и другие причины должны быть очевидными специалистам. В частности, согласно варианту осуществления настоящего изобретения, может быть предусмотрен следующий механизм. Каждый раз, когда маска CPU изменяется в SecureOS, причем изменение не связано с потоком SecureOS, в настоящее время исполняющимся в ядре CPU, этот исполняющийся в настоящее время поток SecureOS вытесняется из данного ядра CPU и помещается в очередь планировщика SecureOS. Этот механизм обеспечивает возможность переноса измененной маски CPU, любым из относящихся к вытеснению путей, обсужденных выше, в RichOS более оперативно, чтобы RichOS своевременно обладала самой актуальной версией маски CPU.It should be noted that the reasons for crowding out, as described in general terms above, are not the only possible ones, and other reasons should be obvious to specialists. In particular, according to an embodiment of the present invention, the following mechanism may be provided. Each time the CPU mask changes to SecureOS, and the change is not related to the SecureOS thread currently running in the CPU core, this currently running SecureOS thread is pushed out of that CPU core and placed in the SecureOS scheduler queue. This mechanism provides the ability to transfer the modified CPU mask, any of the extrusion paths discussed above, to RichOS more quickly so that RichOS has the most current version of the CPU mask in a timely manner.

Как должно быть понятно специалисту, этап 504 с Фиг.5 соответствует этапу 202 с Фиг.2. Следует дополнительно пояснить, в контексте обсуждения этапа 202 по Фиг.2 выше, что драйвер RichOS приспособлен для запрещения отключения ядра CPU, пока соответственный бит установлен в маске CPU. Это реализуется через систему уведомлений в ядре RichOS. Когда ядро RichOS собирается отключить аппаратное ядро CPU, проверяется «мнение» всех субъектов, подписанных на уведомления в отношении событий «горячего» включения/отключения (hotplug) CPU (как это осуществляется в ядре Linux, используемом всеми версиями Android).As should be understood by one skilled in the art, step 504 of FIG. 5 corresponds to step 202 of FIG. 2. It should be further clarified, in the context of the discussion of step 202 of FIG. 2 above, that the RichOS driver is adapted to prohibit disabling the CPU core while the corresponding bit is set in the CPU mask. This is implemented through the notification system in the RichOS kernel. When the RichOS kernel is about to disconnect the hardware core of the CPU, it checks the “opinion” of all entities subscribed to notifications regarding events of the “hot” on / off (hotplug) of the CPU (as is done in the Linux kernel used by all versions of Android).

После завершения этапа 504 последовательность 500 операций переходит в Незащищенное Окружение.After completion of step 504, the sequence of 500 operations goes into the Unsecured Environment.

На этапе 505 драйвер 410 RichOS извлекает маску CPU либо из результата, возвращенного планировщиком 401 SecureOS, либо из разделяемой памяти. Затем драйвер 410 RichOS сопоставляет маску CPU с включенными на текущий момент ядрами CPU, и, если ядро A CPU в настоящее время отключено, включает ядро A CPU. Наконец, драйвер 410 RichOS сохраняет маску CPU в местоположении хранения данных внутри Незащищенного Окружения, которое доступно коммуникационному процессу. Снова следует подчеркнуть, что ядро A CPU используется по всему описанию в качестве репрезентативного ядра CPU для наглядности, и, как должно быть ясно специалисту, любое другое ядро CPU может быть включено обсужденным выше образом.At 505, the RichOS driver 410 retrieves the CPU mask from either the result returned by SecureOS scheduler 401 or from shared memory. Then, the RichOS driver 410 maps the CPU mask to the currently enabled CPU cores, and if the A core of the CPU is currently disabled, it turns on the A core of the CPU. Finally, the RichOS driver 410 stores the CPU mask at the data storage location inside the Unsecured Environment that is accessible to the communication process. Again, it should be emphasized that the A CPU core is used throughout the description as a representative CPU core for clarity, and as one skilled in the art will appreciate, any other CPU core can be included in the manner discussed above.

На этапе 506 коммуникационный процесс, который отслеживает маску CPU, разблокирует коммуникационный поток, который привязан к ядру A CPU, и затем планировщик RichOS помещает разблокированный коммуникационный поток в очередь планировщика RichOS. После запуска исполнения коммуникационного потока из очереди планировщика RichOS на ядре A CPU, коммуникационный поток переключает ядро A CPU в защищенный режим, тем самым переводя управление на ядре CPU в Защищенное Окружение. На этапе 506 коммуникационный процесс дополнительно пересылает результат, принятый от драйвера 410 RichOS, клиентскому приложению 420 RichOS для последующей обработки.At step 506, the communication process that monitors the CPU mask unlocks the communication stream that is bound to CPU core A, and then the RichOS scheduler places the unlocked communication stream on the RichOS scheduler queue. After starting the execution of the communication stream from the RichOS scheduler queue on the A CPU core, the communication flow switches the A CPU core to the protected mode, thereby transferring the control on the CPU core to the Protected Environment. At step 506, the communication process further forwards the result received from the RichOS driver 410 to the RichOS client application 420 for subsequent processing.

После завершения этапа 506 последовательность 500 операций переходит обратно в Защищенное Окружение.Upon completion of step 506, the flow of 500 proceeds back to the Protected Environment.

На этапе 507 планировщик 401 SecureOS начинает исполняться на ядре A CPU и затем переключается на исполнение потока SecureOS доверенного приложения 420, который в настоящее время находится наверху очереди планировщика SecureOS. Это может быть поток A, однако, как должно быть понятно специалисту, это не является ограничительным примером.At step 507, SecureOS scheduler 401 starts running on the CPU A core and then switches to running the SecureOS thread of the trusted application 420, which is currently at the top of the SecureOS scheduler queue. This may be stream A, however, as one skilled in the art will appreciate, this is not a restrictive example.

Этап 508 выполняется после успешного завершения исполнения потока А на ядре A CPU. На данном этапе планировщик 401 SecureOS блокирует поток A, вставляет маску CPU в результат его исполнения и подает этот результат в драйвер 410 RichOS. Управление на ядре A CPU переводится обратно в Незащищенное Окружение. Следует отметить, что до вставки маски CPU в результат исполнения битовая запись ядра А CPU сбрасывается (например, обнуляется), если контрольный счетчик, связанный с ядром A CPU, равен 0. После этого, на этапе 509 упомянутый результат, как отмечено выше, пересылается коммуникационным процессом, по приему от драйвера 410 RichOS, клиентскому приложению 420 RichOS для последующей обработки.Step 508 is performed after the successful execution of thread A on core A of the CPU. At this point, SecureOS Scheduler 401 blocks thread A, inserts the CPU mask into the result of its execution, and feeds that result to the RichOS 410 driver. The control on the core of the A CPU is transferred back to the Unsecured Environment. It should be noted that before inserting the CPU mask into the execution result, the bit record of the kernel A of the CPU is reset (for example, it is reset to zero) if the check counter associated with the core A of the CPU is 0. After this, at step 509, the above result is sent, as noted above, the communication process, upon receipt from the driver 410 RichOS, client application 420 RichOS for further processing.

Варианты осуществления, обсужденные выше, могут быть реализованы на практике известным образом на типичной платформе смартфона, например, Samsung Galaxy J2 Prime.The embodiments discussed above can be put into practice in a known manner on a typical smartphone platform, for example, Samsung Galaxy J2 Prime.

Следует понимать, что проиллюстрированные варианты осуществления являются всего лишь предпочтительными, а не единственно возможными примерными вариантами реализации настоящего изобретения. Точнее, объем настоящего изобретения определяется нижеследующей формулой изобретения и ее эквивалентами.It should be understood that the illustrated embodiments are merely preferred, and not the only possible exemplary embodiments of the present invention. More specifically, the scope of the present invention is defined by the following claims and their equivalents.

Claims

1. A method of operating a mobile device, the mobile device comprising at least one processor (CPU) having a plurality of CPU cores, each CPU core being adapted to function either in a secure mode or in an unprotected mode, while the mobile device has an unprotected operating room system (RichOS) and a secure operating system (SecureOS), both RichOS and SecureOS support multithreading, while SecureOS and RichOS, being isolated from each other up to the level of hardware, you olneny with the ability to communicate with each other through at least one predetermined interface, the method comprising the steps of:

after activating a thread in SecureOS, this thread is assigned, in SecureOS, to the CPU core, which purpose includes the stage of changing the CPU mask, while the CPU mask is a data structure supported by SecureOS to inform RichOS about the current SecureOS needs in CPU cores ;

transmit, via SecureOS, the CPU mask to RichOS to request RichOS to provide SecureOS control on the CPU core;

based on the CPU mask, include, through RichOS, the CPU core if the CPU core is disabled; and

switch, by means of RichOS, the CPU core into protected mode, thereby providing SecureOS control on the CPU core.

2. The method according to claim 1, in which

mentioned isolation is implemented, in the sense of mobile device resources, in the form of an unprotected environment and a protected environment, with each of the unprotected environment and a protected environment being used based on the CPU core: when the CPU core is in protected mode, SecureOS gains control on this CPU core and able to use the resources of a mobile device that are designed to be accessible in a protected environment, and when the CPU core is in unprotected mode, RichOS gains control on this CPU core and is able to use the resources of a mobile devices that are designed to be accessible in an insecure environment, while the mobile device contains hardware resources that, when used in a secure environment, become inaccessible from an insecure environment;

SecureOS contains a SecureOS scheduler configured to schedule execution of SecureOS threads;

RichOS contains:

RichOS scheduler, configured to schedule execution of RichOS threads,

a RichOS driver configured to communicate with the SecureOS scheduler, wherein the RichOS driver is configured to include CPU cores, and

a communication process, the communication process comprising a set of communication streams, with each communication stream tied to a different core CPU so that this communication stream can only be executed on a given CPU core, and each communication stream is configured to, when executed on the CPU core to which this communication stream is attached, switch this CPU core to protected mode.

3. The method according to claim 2, wherein said binding comprises a corresponding setting of the affinity property of the communication stream.

4. The method according to claim 2, in which the mobile device has memory areas that are accessible only through SecureOS.

5. The method according to claim 2, in which said stream is one of one or more SecureOS streams created by a trusted application running in a secure environment, said activation comprising the steps of:

after the RichOS client submits a command to be processed by a trusted application, the communication process places the command in its turn and assigns the corresponding communication flow to the team; and

after starting the communication flow on the CPU core, the CPU core is switched to protected mode, and the SecureOS scheduler runs on the CPU core and unlocks at least the mentioned flow.

6. The method according to claim 5, wherein said data structure comprises a bit field, wherein said change comprises the step of setting the SecureOS scheduler to: set a bit record in the bit field corresponding to the CPU core if no trustedOS trusted application thread was previously assigned to the CPU core; and

the method further comprises the step of placing the thread in the SecureOS scheduler queue and allocating a temporary quota for the thread to execute.

7. The method according to claim 6, additionally containing a stage in which, after changing the CPU mask in SecureOS, the change is not related to the SecureOS stream currently running in the CPU core:

push the currently running SecureOS thread from the CPU core and return that SecureOS thread to the SecureOS scheduler queue.

8. The method according to claim 6, in which said transfer comprises the steps of, by means of the SecureOS scheduler:

after completion / execution of any SecureOS thread in the CPU core,

in case of completion,

block the flow of SecureOS,

if no other SecureOS threads are currently assigned to the CPU core, update the CPU mask by discarding the bit record corresponding to the CPU core, and

insert the CPU mask into the execution result and return this result to RichOS;

in case of crowding out, either insert the CPU mask into the result indicating incomplete execution, and return this result to RichOS, or put the CPU mask in shared memory; and

transfer control on the CPU core back to an insecure environment.

9. The method of claim 8, further comprising the steps of, using the RichOS driver:

extracting the CPU mask from either the result or shared memory;

match the CPU mask with the currently active CPU cores and, if the CPU core is currently disabled, turn on the CPU core; and

save the CPU mask so that it is accessible to the communication process.

10. The method according to claim 9, further comprising stages in which:

by means of the communication process, they monitor the CPU mask and unlock the communication stream, which is attached to the CPU core, and put, through the RichOS scheduler, the communication stream into the RichOS scheduler queue;

start the execution of the communication stream from the RichOS scheduler queue on the CPU core and switch, through the communication stream, the CPU core to protected mode, thereby transferring control on the CPU core to a protected environment; and

start the execution of the SecureOS scheduler in the CPU core and switch the SecureOS scheduler to the execution of the mentioned thread.

11. The method according to claim 10, further comprising stages, at which, upon completion of execution of the thread on the CPU core, through the SecureOS scheduler:

block the flow;

insert the CPU mask into the execution result; and

provide this result to the RichOS driver and transfer control on the CPU core back to the insecure environment.

12. The method according to claim 11, further comprising the step of, after blocking the thread, if no other SecureOS threads are currently assigned to the CPU core, update, using the SecureOS scheduler, the CPU mask by resetting the bit record.

13. The method according to claim 11, further comprising transmitting, through the communication process, the result received from the RichOS driver to the RichOS client for subsequent processing.

14. The method of claim 10, further comprising the step of, after displacing the thread from the CPU core after a time quota or interrupt received from RichOS, returns the thread to the SecureOS scheduler queue to complete execution later through the SecureOS scheduler.

15. The method according to claim 2, in which RichOS is configured to sequentially enable currently disabled CPU cores, as the computing load in the mobile device increases, in a predetermined order determined by the CPU core numbers, and the SecureOS scheduler is configured to allocate cores CPU threads SecureOS in accordance with the above order.

16. A mobile device comprising at least one processor (CPU) having a plurality of CPU cores, each CPU core being adapted to function either in secure mode or in insecure mode, wherein the mobile device has an unprotected operating system (RichOS) and a secure operating system (SecureOS), both RichOS and SecureOS support multi-threading, while SecureOS and RichOS, being isolated from each other up to the hardware level, are made with the ability to communicate with each other h at least one predefined interface, while:

SecureOS is configured to:

after activating the thread in SecureOS, assign the thread to the CPU core, which purpose includes changing the CPU mask, while the CPU mask is a data structure supported by SecureOS to inform RichOS about the current SecureOS needs in the CPU cores; and

transfer the CPU mask to RichOS to request RichOS to provide SecureOS control on the CPU core,

RichOS is configured to:

based on the CPU mask, enable the CPU core if the CPU core is disabled; and

switch the CPU core to protected mode, thereby providing SecureOS control on the CPU core.

17. The mobile device according to clause 16, in which

RichOS contains:

RichOS scheduler, configured to schedule execution of RichOS threads,

18. The mobile device according to 17, in which said binding contains a corresponding setting affinity properties of the communication stream.

19. The mobile device according to 17, wherein the mobile device has memory areas that are accessible only through SecureOS.

20. The mobile device according to 17, in which the stream is one of one or more SecureOS streams created by a trusted application that runs in a secure environment, while:

the communication process is performed with the ability, after the RichOS client submits a command to be processed by a trusted application, place the command in its queue and assign the corresponding communication flow to the team; and

after starting the communication flow on the CPU core, the CPU core switches to protected mode and the SecureOS scheduler runs on the CPU core and unlocks at least the mentioned thread, whereby this thread is activated.

21. The mobile device according to claim 20, wherein said data structure comprises a bit field, wherein the SecureOS scheduler, for making said change, is configured to set a bit record in the bit field corresponding to the CPU core if no trustedOS trusted application thread was previously assigned to the CPU core; and

however, the SecureOS scheduler is additionally configured to place the thread in the SecureOS scheduler queue and allocate a temporary quota for the thread to execute.

22. The mobile device according to item 21, in which the SecureOS scheduler is further configured to, after changing the CPU mask in SecureOS, which change is not associated with the SecureOS thread currently running in the CPU core:

oust the currently running SecureOS thread from the CPU core and return the given SecureOS thread to the SecureOS scheduler queue.

23. The mobile device according to item 21, in which the SecureOS scheduler, to perform the aforementioned transfer, is configured to, after completion of execution / crowding out any SecureOS thread in the CPU core,

in case of completion,

block SecureOS flow,

if no other SecureOS threads are currently assigned to the CPU core, update the CPU mask by flushing the bit record corresponding to the CPU core, and

insert the CPU mask into the execution result and return this result to RichOS;

transfer control on the CPU core back to an insecure environment.

24. The mobile device according to item 23, in which the RichOS driver is additionally configured to:

extract the CPU mask from either the result or shared memory;

save the CPU mask so that it is accessible to the communication process.

25. The mobile device according to paragraph 24, in which

the communication process is additionally configured to monitor the CPU mask and unlock the communication stream that is tied to the CPU core, and the RichOS scheduler is further configured to place the communication stream in the RichOS scheduler queue;

the communication stream is configured to, after starting the execution of the communication stream from the RichOS scheduler queue in the CPU core, switch the CPU core to protected mode, thereby transferring control on the CPU core to a secure environment so that the execution of the SecureOS scheduler starts on the CPU core, and the scheduler SecureOS switches to execution of the mentioned thread.

26. The mobile device according A.25, in which the SecureOS scheduler is additionally configured to, after completion of the thread on the CPU core:

block a stream;

embed the CPU mask in the result of execution; and

provide this result to the RichOS driver and transfer control on the CPU core back to an insecure environment.

27. The mobile device of claim 26, wherein the SecureOS scheduler is further configured to, after blocking the thread, if no other SecureOS threads are currently assigned to the CPU core, update the CPU mask by resetting the bit record.

28. The mobile device according to item 27, in which the communication process is further configured to forward the result received from the RichOS driver to the RichOS client for further processing.

29. The mobile device of claim 25, wherein the SecureOS scheduler is further configured to, after displacing the thread from the CPU core after a time quota or interrupt received from RichOS, return the thread to the SecureOS scheduler queue to complete execution later.

30. The mobile device according to claim 28, wherein RichOS is configured to sequentially turn on currently disabled CPU cores as the computing load in the mobile device increases, in a predetermined order determined by the numbers of the CPU cores, and the SecureOS scheduler is configured to allocate CPU cores SecureOS threads in accordance with the above order.