Способ функционирования secureos на многопроцессорных системах в мобильных устройствах

Изобретение относится к способу функционирования защищенной операционной системы (SecureOS) на многопроцессорных системах в мобильных устройствах. Технический результат заключается в повышении производительности SecureOS. Способ содержит этапы, на которых: после активации потока в SecureOS назначают в SecureOS этот поток ядру процессора (CPU), каковое назначение включает в себя этап, на котором изменяют маску CPU, при этом маска CPU является структурой данных, поддерживаемой в SecureOS для информирования незащищенной операционной системы (RichOS) о текущих потребностях SecureOS в ядрах CPU; передают посредством SecureOS маску CPU в RichOS для запрашивания RichOS предоставить SecureOS управление на ядре CPU; на основе маски CPU включают посредством RichOS ядро CPU, если ядро CPU отключено; и переключают посредством RichOS ядро CPU в защищенный режим, предоставляя SecureOS управление на ядре CPU, причем мобильное устройство содержит CPU, имеющий множество ядер CPU, каждое из которых функционирует либо в защищенном, либо в незащищенном режиме, и установленные в мобильном устройстве RichOS и SecureOS поддерживают многопоточность и сообщаются друг с другом через предварительно заданный интерфейс. 2 н. и 28 з.п. ф-лы, 5 ил.

 

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

Настоящее изобретение в целом относится к области техники мобильных устройств и, в частности, к функционированию SecureOS на многопроцессорных системах в мобильных устройствах.

УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ

Использование мобильных устройств во всем мире значительно возросло за последние 15-20 лет. В то же время мобильные устройства эволюционировали из обычного мобильного телефона, предназначенного только для выполнения голосовой связи и обмена SMS-сообщениями, в смартфон, который, по существу, представляет собой компактное мощное вычислительное устройство, выполненное с возможностью предоставления, помимо основных возможностей связи, различной расширяемой основанной на Интернете функциональности. В частности, аппаратное обеспечение современного смартфона в целом включает в себя мощный CPU, содержащий множество ядер CPU, и многоуровневую систему памяти, имеющую большую емкость хранения. Каждое современное мобильное устройство обладает установленной в нем операционной системой (OS), и большинство функций предоставляется мобильным устройством пользователям посредством приложений, которые устанавливаются через Интернет и затем функционируют под управлением OS. Самыми популярными операционными системами в смартфонах являются Android и IOS, и мобильные приложения обычно разрабатываются, чтобы, по меньшей мере, иметь версии, функционирующие на каждой из этих двух OS.

Технология многопоточности, ранее реализованная в компьютерах, в настоящее время применяется к мобильным устройствам. Упомянутая технология была разработана для повышения производительности посредством разделения исполнения приложения на потоки исполнения и предоставления возможности исполнения множества потоков приложения параллельно на множестве CPU или ядер CPU. Данное улучшение особенно полезно для интенсивных в вычислительном отношении приложений. С этой целью, мобильные операционные системы (OS) и многие из мобильных приложений в настоящее время разрабатываются с поддержкой многопоточности, принимая во внимание, что на современных мобильных устройствах обеспечена возможность функционирования таким интенсивным приложениям, как различные игры с активными действиями, мультимедийные приложения и т.д.

Ввиду наращивания вычислительной мощности, как обсуждалось выше, эффективное управление энергопотреблением является актуальным для смартфонов, и обычной в настоящее время является ситуация, когда батарея смартфона, заряженная утром полностью, разряжается к вечеру, тем самым причиняя неудобства пользователям. В контексте данной актуальной проблемы операционные системы (OS) современных мобильных устройств выполнены с возможностью отключать отдельные ядра CPU, когда они не нагружены, с тем чтобы ими не потреблялась никакая энергия, и последовательно включать ядра CPU по мере увеличения вычислительной нагрузки в устройстве.

Другая большая проблема, с которой сталкиваются современные мобильные устройства, заключается в обеспечении безопасности. Как замечено выше, современные мобильные операционные системы (OS) (например, Android) являются расширяемыми, и, при обновлении или расширении такой OS или приложений, исполняющихся на ней, может быть загружено вредоносное программное обеспечение, которое может скомпрометировать OS вплоть до уровня ядра. В частности, в настоящее время вполне обычно, когда пользователи хранят конфиденциальные данные в своих смартфонах, следовательно, нежелательный контроль над такими данными может быть получен вредоносным программным обеспечением.

В 2003 компания ARM, которая известна по всему миру разработкой архитектур процессоров, представила технологию TrustZone («Доверенная Зона») для решения последней из вышеуказанных проблем. В целом, TrustZone предоставляет, с точки зрения ресурсов мобильного устройства, две среды: защищенную среду («Защищенное Окружение» («Secure World»)) и незащищенную среду («Незащищенное Окружение» («Non-Secure World»)), которые изолированы друг от друга на уровне аппаратного обеспечения. С этой целью, две независимых операционных системы установлены в мобильном устройстве - одна функционирует в Защищенном Окружении и упоминается как SecureOS («Защищенная ОС»), в то время как другая функционирует в Незащищенном Окружении и упоминается как RichOS («Полнофункциональная ОС»). Каждое CPU или ядро CPU выполнено с возможностью функционирования либо в защищенном режиме, либо в незащищенном режиме, и может быть инициировано его переключение из одного режима в другой. Каждый из этих режимов имеет свои собственные версии банков системных регистров. Когда ядро CPU переключается в защищенный режим, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в Защищенном Окружении. В то же время, когда ядро CPU находится в незащищенном режиме, RichOS получает управление на этом ядре CPU и способна использовать ресурсы, которые предназначены быть доступными в Незащищенном Окружении. То есть, каждая из незащищенной среды и защищенной среды задействуется из расчета на CPU: например, в то время как одно ядро CPU функционирует в защищенном режиме и, следовательно, находится под управлением SecureOS в Защищенном Окружении, другое ядро CPU может функционировать в незащищенном режиме под управлением RichOS в Незащищенном Окружении.

Характерными примерами RichOS являются Android и Tizen. То есть, RichOS является полнофункциональной OS, с которой непосредственно взаимодействует пользователь либо с помощью интерфейсов OS и вспомогательных программ (утилит), либо с помощью приложений, исполняющихся под ее управлением. Общие функциональные аспекты RichOS, следовательно, широко известны. Кроме того, RichOS реализует большинство драйверов, включая те, которые непосредственно манипулируют аппаратными средствами мобильного устройств, в частности, включают и отключают ядра CPU.

В отличие от RichOS, SecureOS имеет довольно небольшой размер и очень ограниченную функциональность, так чтобы SecureOS была по минимуму подвержена ошибкам. SecureOS ответственна только за выполнение задач, которые фактически являются конфиденциальными в смысле безопасности. Существуют приложения, исполняющиеся только под управлением SecureOS (доверенные приложения).

Некоторые ресурсы мобильного устройства, которые доступны в Защищенном Окружении, физически не доступны из Незащищенного Окружения. Например, SecureOS использует части хранилища мобильного устройства (например, DRAM), к которому никоим образом нельзя осуществить доступ из Незащищенного Окружения. Это делает возможным безопасное хранение информации, которая очень конфиденциальна (например, ключи, коды и т.д.). Даже если человек обладает неавторизованным удаленным управлением над RichOS вплоть до уровня ее ядра, то этот человек будет, однако, неспособен осуществить доступ к упомянутой очень конфиденциальной информации.

Как следует из вышесказанного, SecureOS и RichOS функционируют одновременно в мобильном устройстве. В некоторых вариантах реализации, когда происходит начальная загрузка мобильного устройства, то после выполнения последовательности начальной загрузки сначала инициализируется SecureOS, тогда как RichOS инициализируется после нее.

Несмотря на строгую изоляцию друг от друга, предусмотрен специальный интерфейс для сообщения между SecureOS и RichOS. В частности, RichOS имеет специализированный системный компонент, драйвер RichOS, а SecureOS имеет специализированный системный компонент, планировщик SecureOS. Эти компоненты выполнены с возможностью сообщения друг с другом через упомянутый интерфейс. Помимо обеспечения связи с SecureOS, драйвер RichOS выполняет другие функции: в частности, он включает и отключает ядра CPU. Планировщик SecureOS планирует исполнение потоков SecureOS посредством поддержания очереди их исполнения. Следует отметить, что RichOS также имеет свой планировщик RichOS, функционирующий, по существу, аналогичным образом.

Вследствие ограниченной функциональности, как обсуждено выше, SecureOS изначально неспособна самостоятельно непосредственно выделять вычислительные ресурсы для исполнения потоков SecureOS, следовательно, SecureOS информирует RichOS о своей потребности в ресурсе(ах), в то время как RichOS выполняет выделение. С этой целью используется механизм сообщения, кратко описанный в общих чертах выше.

Больше подробностей относительно технологии, кратко обсужденной выше, может быть найдено в документе «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).

Теперь будет рассмотрен частный пример функционирования смартфона, который известным образом поддерживает Защищенное Окружение и Незащищенное Окружение. Данный пример относится к вводу пользователем пароля на заблокированном сенсорном экране смартфона для разблокирования сенсорного экрана. Когда пользователь начинает вводить свой пароль на экране смартфона, то связанное с этим клиентское приложение RichOS посылает команду, которая переносится в коммуникационный процесс. Коммуникационный процесс является системной службой RichOS, содержащей набор коммуникационных потоков, количество которых равно количеству ядер CPU в смартфоне. Каждый коммуникационный поток может быть привязан к конкретному ядру CPU, так что этот коммуникационный поток исполняется на данном ядре CPU. Такая привязка обычно реализуется посредством соответственной установки свойства affinity (‘cродство’) коммуникационного потока (данная функциональность известна с SMP (Симметричной Мультипроцессорной Обработки)). Когда коммуникационный поток начинает исполняться на ядре CPU, то он переключает ядро CPU в защищенный режим. Поэтому, по приему команды, коммуникационный процесс разблокирует один из своих коммуникационных потоков для назначения ему команды, данный коммуникационный поток исполняется на некотором ядре CPU и переключает это ядро CPU в защищенный режим. SecureOS получает управление на данном ядре CPU, планировщик SecureOS начинает исполняться на нем и разблокирует по меньшей мере один поток доверенного приложения, ответственного за защищенную обработку ввода с сенсорного экрана. Этот поток исполняется в ядре CPU для обработки упомянутой команды, и в течение исполнения все контроллеры сенсорного экрана смартфона функционируют только в Защищенном Окружении: то есть, ни приложение RichOS, исполняющееся на другом ядре CPU, ни сама RichOS не имеет физического доступа к контроллерам сенсорного экрана. Данный отказ доступа реализуется на уровне шин, обслуживающих эти контроллеры. Следует подчеркнуть, что другое аппаратное обеспечение смартфона может стать недоступным для Незащищенного Окружения схожим образом в других контекстах. После завершения обработки команды поток блокируется, результат обработки передается планировщиком SecureOS драйверу RichOS, наряду с переключением ядра CPU обратно в незащищенный режим, и результат пересылается коммуникационным процессом клиентскому приложению RichOS. Как видно, такая конфиденциальная операция, как аутентификация по паролю, выполняется защищенным от вмешательства образом.

Должно быть очевидно, что обработка ввода пароля не является интенсивной в вычислительном отношении задачей. Однако в настоящее время существуют другие технологии аутентификации, реализованные в современных мобильных устройствах, которые намного более интенсивны в вычислительном отношении. Например, биометрическая аутентификация, основанная на распознавании радужной оболочки глаза, является очень сложной и сильно потребляющей ресурсы задачей, и она должна быть полностью реализована в Защищенном Окружении. Существуют также другие примеры исполнения интенсивных в вычислительном отношении задач в Защищенном Окружении: например, может потребоваться исполнение в нем воспроизведения видео высокой четкости.

Следует отметить, что производительность исполнения под управлением SecureOS не вызывала большой озабоченности в предшествующем уровне техники. Однако в настоящее время существует проблема, которая вызывает сложности с производительностью SecureOS и, следовательно, всего мобильного устройства. В соответствии с вышесказанным, SecureOS изначально неспособна непосредственно физически выделять ядра CPU потокам SecureOS - она только обращается к RichOS, в то время как в RichOS коммуникационные потоки активируются и соответственно назначаются ядрам CPU. Фактически, планировщик RichOS может назначать все активированные коммуникационные потоки одному и тому же ядру CPU. В таком случае SecureOS будет выполнять исполнение, которое «распараллелено» на одном ядре CPU. Кроме того, SecureOS не способна ни включать неактивные ядра CPU самостоятельно, ни запрашивать RichOS выполнить такое включение с целью оптимизации функционирования SecureOS. То есть, RichOS не может включать ранее отключенные ядра CPU для исполнения потоков SecureOS, в каковом случае возникает упомянутое «распараллеливание на одном ядре» (здесь следует отметить, что такая ситуация обычна для современных мобильных устройств). Описанная проблема, очевидно, приводит в результате к значительному ухудшению производительности.

В US 8375221 предложен способ задействования доверенной среды исполнения в вычислительных устройствах без какого-либо аппаратного модуля доверенной платформы, однако, никакого внимания не уделено функционированию в многопроцессорных системах. Далее, в US 2015/0059007 предложен способ инициализации SecureOS в многопроцессорной среде; однако, это техническое решение сфокусировано только на времени начальной загрузки.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Ввиду недостатков технических решений предшествующего уровня техники, описанных в общих чертах выше, задача настоящего изобретения заключается в предоставлении технологии, которая обеспечила бы SecureOS возможность управлять выделением ядер CPU потокам SecureOS, в частности, управлять количеством ядер CPU, доступных для SecureOS, с тем чтобы существующие ресурсы использовались более полно в SecureOS и производительность SecureOS для критичных ко времени операций (например, распознавания радужной оболочки глаза) была повышена.

В соответствии с первым аспектом настоящего изобретения предложен способ функционирования мобильного устройства. Мобильное устройство содержит по меньшей мере один процессор (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.

В соответствии с вариантом осуществления настоящего изобретения, изоляция реализована, в смысле ресурсов мобильного устройства, в виде незащищенной среды и защищенной среды. Каждая из незащищенной среды и защищенной среды задействуется из расчета на ядро CPU (на поядровой основе): когда ядро CPU находится в защищенном режиме, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в защищенной среде, а когда ядро CPU находится в незащищенном режиме, RichOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в незащищенной среде. Мобильное устройство содержит ресурсы аппаратного обеспечения, которые при их использовании в защищенной среде становятся недоступными из незащищенной среды. SecureOS содержит планировщик SecureOS, выполненный с возможностью планирования исполнения потоков SecureOS. RichOS содержит: планировщик RichOS, выполненный с возможностью планирования исполнения потоков RichOS; драйвер RichOS, выполненный с возможностью сообщения с планировщиком SecureOS, причем драйвер RichOS выполнен с возможностью включения ядер CPU; и коммуникационный процесс. Коммуникационный процесс содержит набор коммуникационных потоков, при этом каждый коммуникационный поток привязан к отличному от других ядру CPU, так что этот коммуникационный поток может исполняться только на данном ядре CPU. Каждый коммуникационный поток выполнен с возможностью, при его исполнении на ядре CPU, к которому этот коммуникационный поток привязан, переключать это ядро CPU в защищенный режим. Привязка предпочтительно содержит соответственную установку свойства affinity коммуникационного потока. Мобильное устройство предпочтительно имеет области памяти, которые доступны только посредством SecureOS.

В соответствии с вариантом осуществления настоящего изобретения, упомянутый поток является одним из одного или более потоков SecureOS, созданных доверенным приложением, исполняющимся в защищенной среде, при этом упомянутая активация содержит этапы, на которых: после выдачи клиентом RichOS команды, подлежащей обработке доверенным приложением, коммуникационный процесс помещает команду в его очередь и назначает команде соответственный коммуникационный поток; и после запуска коммуникационного потока на ядре CPU, переключают ядро CPU в защищенный режим, и планировщик SecureOS исполняется на ядре CPU и разблокирует, по меньшей мере, упомянутый поток.

В соответствии с вариантом осуществления настоящего изобретения, упомянутая структура данных содержит битовое поле, при этом упомянутое изменение содержит этапы, на которых, посредством планировщика SecureOS: устанавливают, в битовом поле, битовую запись, соответствующую ядру CPU, если ни одного потока SecureOS доверенного приложения не было ранее назначено ядру CPU. Способ дополнительно содержит этап, на котором: помещают поток в очередь планировщика SecureOS и выделяют временную квоту для исполнения потока.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, после изменения маски CPU в SecureOS, каковое изменение не связано с потоком SecureOS, исполняющимся в настоящее время в ядре CPU: вытесняют исполняющийся в настоящее время поток SecureOS из ядра CPU и возвращают данный поток SecureOS в очередь планировщика SecureOS.

В соответствии с вариантом осуществления настоящего изобретения, упомянутая передача содержит этапы, на которых, посредством планировщика SecureOS: после завершения исполнения/вытеснения какого-либо потока SecureOS в ядре CPU, в случае завершения, блокируют поток SecureOS, если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновляют маску CPU посредством сбрасывания битовой записи, соответствующей ядру CPU, и вставляют маску CPU в результат упомянутого исполнения и возвращают этот результат в RichOS; в случае вытеснения, либо вставляют маску CPU в результат, указывающий незавершенное исполнение, и возвращают этот результат в RichOS, либо помещают маску CPU в разделяемую память. После этого, управление на ядре CPU переводится обратно в незащищенную среду впоследствии.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, посредством драйвера RichOS: извлекают маску CPU либо из результата, либо из разделяемой памяти; сопоставляют маску CPU с включенными на текущий момент ядрами CPU и, если ядро CPU в настоящее время отключено, включают ядро CPU; и сохраняют маску CPU так, чтобы она была доступной коммуникационному процессу.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, посредством коммуникационного процесса, отслеживают маску CPU и разблокируют коммуникационный поток, который привязан к ядру CPU, и помещают, посредством планировщика RichOS, коммуникационный поток в очередь планировщика RichOS; запускают исполнение коммуникационного потока из очереди планировщика RichOS на ядре CPU и переключают, посредством коммуникационного потока, ядро CPU в защищенный режим, тем самым переводя управление на ядре CPU в защищенную среду; и начинают исполнение планировщика SecureOS на ядре CPU и переключают планировщик SecureOS на исполнение упомянутого потока.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этапы, на которых, после завершения исполнения потока на ядре CPU, посредством планировщика SecureOS: блокируют поток; вставляют маску CPU в результат исполнения; и предоставляют результат драйверу RichOS и переводят управление на ядре CPU обратно в незащищенную среду. Предпочтительно, способ дополнительно содержит этап, на котором, после блокирования потока: если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновляют, посредством планировщика SecureOS, маску CPU посредством сбрасывания битовой записи. Предпочтительно, способ дополнительно содержит этап, на котором: пересылают, посредством коммуникационного процесса, результат, принятый от драйвера RichOS, клиенту RichOS для последующей обработки.

В соответствии с вариантом осуществления настоящего изобретения, способ дополнительно содержит этап, на котором, после вытеснения потока из ядра CPU по истечении временной квоты или по прерыванию, принятому из RichOS, посредством планировщика SecureOS возвращают поток в очередь планировщика SecureOS для завершения исполнения позже.

В соответствии с вариантом осуществления настоящего изобретения, RichOS выполнена с возможностью последовательного включения отключенных в настоящее время ядер CPU, по мере увеличения вычислительной нагрузки в мобильном устройстве, в предварительно установленном порядке, определяемом номерами ядер CPU, и планировщик SecureOS выполнен с возможностью выделения ядер CPU потокам SecureOS в соответствии с упомянутым порядком.

Согласно второму аспекту настоящего изобретения, предложено мобильное устройство. Мобильное устройство содержит по меньшей мере один процессор (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.

В отличие от методов предшествующего уровня техники, настоящее изобретение дает возможность оптимизации количества ядер CPU, доступных единовременно для использования со стороны SecureOS, и, следовательно, ускорения операций SecureOS и минимизации задержки откликов SecureOS, тем самым повышая производительность SecureOS.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

На Фиг.1 показано схематическое изображение смартфона, содержащего CPU, имеющий четыре ядра CPU, одно из которых отключено.

На Фиг.2 показана блок-схема последовательности операций, изображающая общие аспекты функционирования SecureOS и RichOS в мобильном устройстве согласно настоящему изобретению.

На Фиг.3 показано схематическое изображение примерного варианта реализации маски CPU в виде битового поля.

На Фиг.4 показано схематическое изображение компонентов SecureOS и RichOS, задействуемых в функционировании согласно настоящему изобретению.

На Фиг.5 показана блок-схема последовательности операций способа функционирования SecureOS и RichOS в мобильном устройстве согласно варианту осуществления настоящего изобретения.

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

Настоящее изобретение направлено на мобильное устройство, имеющее улучшенную реализацию SecureOS, и способ его функционирования.

Мобильное устройство согласно настоящему изобретению содержит, помимо других широко известных компонентов аппаратного обеспечения, по меньшей мере один процессор (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.

Такие широко известные мобильные операционные системы (OS), как Android и Tizen, относятся к RichOS, в то время как Google Trusty является примером SecureOS.

Вышеупомянутая изоляция предпочтительно реализуется, в смысле ресурсов мобильного устройства, в виде незащищенной среды («Незащищенного Окружения») и защищенной среды («Защищенного Окружения»). Как описано в общих чертах выше, каждая из незащищенной среды и защищенной среды задействуется на поядровой основе. То есть, когда ядро CPU находится в защищенном режиме, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в Защищенном Окружении. Когда ядро CPU находится в незащищенном режиме, то RichOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в Незащищенном Окружении. Здесь следует напомнить, что некоторые ресурсы аппаратного обеспечения мобильного устройства, когда они используются в защищенной среде, становятся абсолютно недоступными из незащищенной среды. В частности, как упомянуто выше, существуют области в запоминающем устройстве мобильного устройства (например, DRAM), которые доступны только посредством SecureOS.

Далее со ссылкой на Фиг. 2 будут описаны основные этапы способа 200 функционирования SecureOS и RichOS в мобильном устройстве согласно настоящему изобретению.

На этапе 201 после активации некоторого потока исполнения (обозначенного в данном документе как поток A) в SecureOS, поток A назначается в SecureOS ядру CPU (обозначенному в данном документе как ядро A CPU). Специальная структура данных поддерживается в SecureOS с этой целью в соответствии с настоящим изобретением. Эта структура данных обозначена как «маска CPU» по всей заявке. SecureOS использует маску CPU для информирования RichOS о текущих потребностях SecureOS в ядрах CPU. Маска CPU является, по существу, производной от известных структур данных, разработанных для связывания потоков SecureOS с ядрами CPU.

Предпочтительный вариант реализации маски CPU согласно одному варианту осуществления является битовым полем (см. Фиг.3). Здесь следует пояснить, что в известной структуре данных, которая описывает поток (более конкретно, поток SecureOS), имеется поле, содержащее номер ядра CPU, которому этот поток назначен (или специальное значение, если поток заблокирован и никакому ядру CPU не назначен). Кроме того, известным образом поддерживается массив контрольных счетчиков, при этом каждый контрольный счетчик подсчитывает, сколько потоков в настоящее время назначено соответственному ядру CPU. Когда некоторый поток назначается некоторому ядру CPU, то соответственный счетчик, связанный с этим ядром CPU, увеличивается на единицу в массиве; иначе, если поток отвязывается от ядра CPU, то счетчик соответственно уменьшается на единицу. В соответствии с вариантом осуществления, когда контрольный счетчик достигает 0, битовая запись (то есть, бит), соответствующая ядру CPU, сбрасывается (например, обнуляется) в маске CPU.

В рассматриваемом случае маска CPU может быть изменена на этапе 201 посредством установки битовой записи, соответствующей ядру A CPU, для указания тем самым того, что SecureOS требуется ядро A CPU для исполнения, по меньшей мере, потока A.

Следует подчеркнуть, что вышеупомянутый вариант реализации маски CPU в виде битового поля не является ограничивающим примером, и другие возможные варианты реализации структуры данных маски CPU должны быть очевидными специалисту.

На этапе 202 SecureOS передает маску CPU в RichOS для запрашивания у RichOS предоставить SecureOS управление на ядре CPU. Данная передача переносится через вышеупомянутый известный интерфейс. Следует подчеркнуть, что битовая запись, установленная в маске CPU для ядра A CPU, если она не сброшена, запрещает RichOS отключать ядро A CPU.

На этапе 203 RichOS включает, на основе принятой маски CPU, ядро А CPU, если это ядро CPU было ранее отключено.

На этапе 204 RichOS переключает ядро А CPU в защищенный режим. Управление на ядре A CPU тем самым предоставляется в SecureOS.

Следует понимать, что способ 200, описанный выше, схожим образом выполняется для любого потока SecureOS, а не только потока A.

Теперь компоненты SecureOS и RichOS, вовлеченные в выполнение этапов 201-204, обсужденных выше, а также конкретные действия, выполняемые этими компонентами, будут описаны в отношении предпочтительного варианта осуществления настоящего изобретения со ссылкой на Фиг.4.

Как уже обсуждено выше, SecureOS содержит планировщик 401 SecureOS. Основная функция планировщика 401 SecureOS заключается в планировании исполнения потоков SecureOS. Согласно предпочтительному варианту осуществления, планировщик 401 SecureOS ответственен за ведение маски CPU в SecureOS и выполнен с возможностью назначения потоков SecureOS ядрам CPU, и, в соответствии с вышесказанным, маска CPU может соответственным образом изменяться в контексте данного назначения. Другими словами, этап 201 выполняется планировщиком 401 SecureOS, согласно предпочтительному варианту осуществления.

Следует отметить, что RichOS по умолчанию выполнена с возможностью последовательного включения отключенных в настоящее время ядер CPU, по мере увеличения вычислительной нагрузки в мобильном устройстве, в предварительно установленном порядке, определяемом номерами ядер CPU. Согласно предпочтительному варианту осуществления, планировщик 401 SecureOS выделяет ядра CPU потокам SecureOS в соответствии с этим предустановленным порядком.

RichOS также содержит планировщик RichOS (не показан), который выполнен с возможностью планирования исполнения потоков RichOS известным образом, подобно планировщику SecureOS. RichOS дополнительно содержит драйвер 410 RichOS. Как описано в общих чертах выше, драйвер 410 RichOS по умолчанию выполнен с возможностью, помимо его других возможностей, физического включения ядер CPU; кроме того, сообщение между SecureOS и RichOS выполняется, в частности, между планировщиком 401 SecureOS и драйвером 410 RichOS через вышеупомянутый предварительно заданный интерфейс 405.

Еще одним компонентом RichOS, непосредственно задействуемым в обсуждаемом здесь предпочтительном варианте осуществления настоящего изобретения, является коммуникационный процесс (не изображен). Как описано в общих чертах выше, коммуникационный процесс является системной службой RichOS, по умолчанию содержащей набор коммуникационных потоков, количество которых равно количеству ядер CPU в мобильном устройстве, и каждый коммуникационный поток может быть соотнесен с конкретным ядром CPU, так чтобы данный коммуникационный поток исполнялся именно на этом ядре CPU. Всякий коммуникационный поток, когда он начинает исполнение на ядре CPU, к которому этот коммуникационный поток привязан, переключает данное ядро CPU в защищенный режим. Помимо коммуникационных потоков (для сообщения с Защищенным Окружением), коммуникационный процесс может содержать поток(и) для сообщения с клиентами RichOS.

Как указано выше, упомянутая привязка реализуется известным образом посредством соответственной установки свойства affinity коммуникационного потока. Например, ‘weak affinity’ (‘слабое сродство’) может быть установлено для некоторого коммуникационного потока, тем самым указывая, что данному коммуникационному потоку разрешается исполняться на любом ядре CPU, если нет никаких ядер CPU, на которых данный поток назначен исполняться. Другой пример относится к big.LITTLE системам – технологии, также представленной компанией ARM. Упомянутая технология подразумевает два кластера ядер CPU, среди которых большой (big) кластер состоит из высокопроизводительных ядер, в то время как малый (little) кластер состоит из энергоэффективных ядер CPU, которые не очень производительны. Это обеспечивает возможность балансировать между производительностью и энергопотреблением. Если свойство affinity некоторого потока установлено таким образом, что он назначен на ядра CPU big-кластера, то поток будет исполняться на более быстрых ядрах CPU.

В соответствии с предпочтительным вариантом осуществления настоящего изобретения, коммуникационному процессу предписывается устанавливать свойство affinity своих коммуникационных потоков таким образом, чтобы каждый коммуникационный поток был привязан к ядру CPU, отличному от других ядер CPU. Другими словами, в предпочтительном варианте осуществления свойство affinity устанавливается таким образом, чтобы между коммуникационными потоками и ядрами CPU было задано взаимно-однозначное соответствие. В результате этого, при такой установке любому из коммуникационных потоков разрешается исполняться только на том ядре CPU, которому он назначен посредством установленного свойства affinity. То есть, планировщик RichOS видит установку коммуникационного потока и направляет его на ядро CPU, которому этот поток назначен. Если ядро CPU отключено драйвером 410 RichOS, то планировщик RichOS сбрасывает привязку соответственного коммуникационного потока к этому ядру CPU в RichOS посредством соответственного изменения свойства affinity данного коммуникационного потока. Следует отметить что, если требуемое ядро(а) CPU недоступно, то планировщик RichOS может проигнорировать affinity и исполнять соответственный поток(и) на доступном ядре(ах) CPU. Напротив, если ранее отключенное ядро CPU повторно включается, то свойство affinity изменяется для восстановления привязки соответственного коммуникационного потока к повторно включенному ядру CPU.

Теперь ссылкой на Фиг.2, 4, 5 будет рассмотрен конкретный вариант осуществления настоящего изобретения. На Фиг.5 показана примерная последовательность 500 операций, имеющая место при функционировании мобильного устройства согласно предпочтительному варианту осуществления настоящего изобретения.

На этапе 501 клиентское приложение 420 RichOS, исполняющееся в Незащищенном Окружении, выдает команду. Клиент 420 RichOS может быть приложением, которое выполнено с возможностью предоставления GUI пользователю для ввода текстового и/или графического пароля или сканирования радужной оболочки глаза пользователя для разблокирования сенсорного экрана мобильного устройства и дополнительно выполнено с возможностью получения вводимой информации. Команда выдается клиентским приложением 420 RichOS в ответ на начало взаимодействия пользователя с GUI в его/ее попытке разблокировать сенсорный экран. В рассматриваемом конкретном варианте осуществления предполагается, что команда должна быть обработана доверенным приложением 402 SecureOS, исполняющимся в Защищенном Окружении, которое ответственно за авторизацию пользователя. Доверенное приложение 402 может быть приложением, которое верифицирует текстовые пароли пользователей, в каковом случае его потребность в ресурсах будет довольно скромной, либо же приложение 402 может быть приложением, сконфигурированным для распознавания и верификации радужных оболочек глаз пользователей, в каковом случае оно очень интенсивно использует ресурсы. То есть, команда, по существу, предназначена для предписания доверенному приложению 402 соответственно обрабатывать введенную информацию и возвращать результат обработки клиентскому приложению 420 RichOS.

Доверенное приложение 402 является многопоточным приложением. Другими словами, им создаются один или более потоков SecureOS. В отсутствии вышеупомянутой команды (например, когда мобильное устройство находится в режиме ожидания и в настоящее время не используется пользователем, или когда пользователь пользуется мобильным устройством после успешной разблокировки его сенсорного экрана), потоки доверенного приложения заблокированы.

После того, как клиент RichOS выдал команду, на этапе 502 коммуникационный процесс принимает команду и разблокирует один из своих коммуникационных потоков для назначения ему данной команды. Как следствие, коммуникационный поток помещается в очередь исполнения планировщика RichOS.

Затем, на этапе 502, когда коммуникационный поток начинает исполняться на ядре CPU, назначенном ему (в дальнейшем обозначаемом как ядро O CPU для наглядности) планировщиком RichOS, коммуникационный поток переключает ядро O CPU в защищенный режим. После переключения планировщик 401 SecureOS начинает исполняться на ядре O CPU и разблокирует по меньшей мере один поток исполнения, среди упомянутых одного или более потоков SecureOS доверенного приложения 402, который ответственен за обработку команды.

Теперь будет рассмотрен случай, когда множество потоков доверенного приложения 402 были разблокированы, и поток A, рассмотренный выше, является одним из этого множества потоков.

На этапе 503 планировщик 401 SecureOS выделяет ядра CPU разблокированным потокам, и маска CPU обновляется при выполнении этого выделения. В частности, как описано в общих чертах выше, битовая запись, соответствующая ядру A CPU, устанавливается в маске CPU планировщиком 401 SecureOS, если ни одного потока SecureOS доверенного приложения не было ранее назначено ядру A CPU. В данном случае битовая запись предпочтительно изменяется с «0» на «1». Другие потоки исполнения обрабатываются таким же образом. Иными словами, битовые записи, установленные внутри маски CPU таким образом, показывают текущую потребность SecureOS в ядрах CPU. Затем планировщик SecureOS помещает каждый из разблокированных потоков в очередь планировщика SecureOS и выделяет временную квоту для исполнения этого потока.

Как объяснено выше, планировщик 401 SecureOS переключается впоследствии на исполнение одного из множества потоков, который находится на вершине его очереди (в дальнейшем называемого потоком O), в ядре O CPU. В данном случае поток O исполняется в ядре O CPU, которое может отличаться от ядра CPU, в настоящее время назначенного потоку O в маске CPU. Предполагается, что поток A находится в настоящее время в очереди планировщика SecureOS. Следует напомнить в данном месте, что в течение исполнения потоков доверенного приложения определенное аппаратное обеспечение мобильного устройства (например, все контроллеры сенсорного экрана) функционирует только в Защищенном Окружении.

Как должно быть понятно специалисту, этапы 501-503 по Фиг.5, по существу, охватываются этапом 201 с Фиг.2.

Этап 504 относится к возможным сценариям исполнения потока O.

С одной стороны, может возникнуть вытеснение исполняющегося в настоящее время потока O из ядра O CPU, и поток O возвращается в очередь планировщика SecureOS, с тем чтобы исполнение данного потока было возобновлено впоследствии. В таком случае, поток O, по существу, не отличается от потока A, который используется, только для нвглядности, в качестве примерного репрезентативного потока исполнения по всему раскрытию, в то время как действия, связанные с потоком A, будут рассмотрены ниже.

Вытеснение может возникнуть по следующим причинам. Во-первых, исполняющийся поток O может быть вытеснен планировщиком 401 SecureOS по истечении временной квоты, выделенной этому потоку. Во-вторых, вытеснение может возникнуть по прерыванию из RichOS - данный механизм по умолчанию предусмотрен в таких основанных на SecureOS/RichOS мобильных системах. В последнем случае, как только произошло вытеснение, управление на ядре CPU переводится в Незащищенное Окружение, с тем чтобы прерывание было обработано в RichOS, и затем оно возвращается обратно в Защищенное Окружение.

После вытеснения, в соответствии с вариантом осуществления настоящего изобретения, специальный результат, указывающий незавершенное исполнение, возвращается планировщиком 401 SecureOS драйверу 410 RichOS через интерфейс 405, и, согласно настоящему изобретению, текущая маска CPU присоединяется к этому специальному результату. В альтернативном варианте осуществления вытеснение приводит к помещению текущей маски CPU в разделяемую память.

С другой стороны, может возникнуть успешное завершение исполнения потока O на ядре O CPU, либо после вышеупомянутого начального запуска потока O, либо после его последующего запуска(ов) из очереди планировщика SecureOS. В данном случае планировщик 401 SecureOS блокирует поток O, затем, если никаких других потоков SecureOS в настоящее время не назначено ядру O CPU (то есть, если контрольный счетчик, связанный с ядром O CPU, является нулевым), обновляет маску CPU посредством обнуления битовой записи, соответствующей ядру O CPU, и, согласно настоящему изобретению, вставляет текущую маску CPU в результат исполнения. После этого, результат упомянутого успешного исполнения возвращается планировщиком 401 SecureOS драйверу 410 RichOS через интерфейс 405, и управление на ядре O CPU переводится обратно в Незащищенное Окружение.

Следует отметить, что причины вытеснения, как описано в общих чертах выше, не являются единственно возможными, и другие причины должны быть очевидными специалистам. В частности, согласно варианту осуществления настоящего изобретения, может быть предусмотрен следующий механизм. Каждый раз, когда маска CPU изменяется в SecureOS, причем изменение не связано с потоком SecureOS, в настоящее время исполняющимся в ядре CPU, этот исполняющийся в настоящее время поток SecureOS вытесняется из данного ядра CPU и помещается в очередь планировщика SecureOS. Этот механизм обеспечивает возможность переноса измененной маски CPU, любым из относящихся к вытеснению путей, обсужденных выше, в RichOS более оперативно, чтобы RichOS своевременно обладала самой актуальной версией маски CPU.

Как должно быть понятно специалисту, этап 504 с Фиг.5 соответствует этапу 202 с Фиг.2. Следует дополнительно пояснить, в контексте обсуждения этапа 202 по Фиг.2 выше, что драйвер RichOS приспособлен для запрещения отключения ядра CPU, пока соответственный бит установлен в маске CPU. Это реализуется через систему уведомлений в ядре RichOS. Когда ядро RichOS собирается отключить аппаратное ядро CPU, проверяется «мнение» всех субъектов, подписанных на уведомления в отношении событий «горячего» включения/отключения (hotplug) CPU (как это осуществляется в ядре Linux, используемом всеми версиями Android).

После завершения этапа 504 последовательность 500 операций переходит в Незащищенное Окружение.

На этапе 505 драйвер 410 RichOS извлекает маску CPU либо из результата, возвращенного планировщиком 401 SecureOS, либо из разделяемой памяти. Затем драйвер 410 RichOS сопоставляет маску CPU с включенными на текущий момент ядрами CPU, и, если ядро A CPU в настоящее время отключено, включает ядро A CPU. Наконец, драйвер 410 RichOS сохраняет маску CPU в местоположении хранения данных внутри Незащищенного Окружения, которое доступно коммуникационному процессу. Снова следует подчеркнуть, что ядро A CPU используется по всему описанию в качестве репрезентативного ядра CPU для наглядности, и, как должно быть ясно специалисту, любое другое ядро CPU может быть включено обсужденным выше образом.

На этапе 506 коммуникационный процесс, который отслеживает маску CPU, разблокирует коммуникационный поток, который привязан к ядру A CPU, и затем планировщик RichOS помещает разблокированный коммуникационный поток в очередь планировщика RichOS. После запуска исполнения коммуникационного потока из очереди планировщика RichOS на ядре A CPU, коммуникационный поток переключает ядро A CPU в защищенный режим, тем самым переводя управление на ядре CPU в Защищенное Окружение. На этапе 506 коммуникационный процесс дополнительно пересылает результат, принятый от драйвера 410 RichOS, клиентскому приложению 420 RichOS для последующей обработки.

После завершения этапа 506 последовательность 500 операций переходит обратно в Защищенное Окружение.

На этапе 507 планировщик 401 SecureOS начинает исполняться на ядре A CPU и затем переключается на исполнение потока SecureOS доверенного приложения 420, который в настоящее время находится наверху очереди планировщика SecureOS. Это может быть поток A, однако, как должно быть понятно специалисту, это не является ограничительным примером.

Этап 508 выполняется после успешного завершения исполнения потока А на ядре A CPU. На данном этапе планировщик 401 SecureOS блокирует поток A, вставляет маску CPU в результат его исполнения и подает этот результат в драйвер 410 RichOS. Управление на ядре A CPU переводится обратно в Незащищенное Окружение. Следует отметить, что до вставки маски CPU в результат исполнения битовая запись ядра А CPU сбрасывается (например, обнуляется), если контрольный счетчик, связанный с ядром A CPU, равен 0. После этого, на этапе 509 упомянутый результат, как отмечено выше, пересылается коммуникационным процессом, по приему от драйвера 410 RichOS, клиентскому приложению 420 RichOS для последующей обработки.

Варианты осуществления, обсужденные выше, могут быть реализованы на практике известным образом на типичной платформе смартфона, например, Samsung Galaxy J2 Prime.

Следует понимать, что проиллюстрированные варианты осуществления являются всего лишь предпочтительными, а не единственно возможными примерными вариантами реализации настоящего изобретения. Точнее, объем настоящего изобретения определяется нижеследующей формулой изобретения и ее эквивалентами.

1. Способ функционирования мобильного устройства, причем мобильное устройство содержит по меньшей мере один процессор (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.

2. Способ по п.1, в котором

упомянутая изоляция реализована, в смысле ресурсов мобильного устройства, в виде незащищенной среды и защищенной среды, при этом каждая из незащищенной среды и защищенной среды задействуется из расчета на ядро CPU: когда ядро CPU находится в защищенном режиме, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в защищенной среде, а когда ядро CPU находится в незащищенном режиме, RichOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в незащищенной среде, при этом мобильное устройство содержит ресурсы аппаратного обеспечения, которые, при их использовании в защищенной среде, становятся недоступными из незащищенной среды;

SecureOS содержит планировщик SecureOS, выполненный с возможностью планирования исполнения потоков SecureOS;

RichOS содержит:

планировщик RichOS, выполненный с возможностью планирования исполнения потоков RichOS,

драйвер RichOS, выполненный с возможностью сообщения с планировщиком SecureOS, причем драйвер RichOS выполнен с возможностью включения ядер CPU, и

коммуникационный процесс, причем коммуникационный процесс содержит набор коммуникационных потоков, при этом каждый коммуникационный поток привязан к отличному от других ядру CPU, с тем чтобы этот коммуникационный поток мог исполняться только на данном ядре CPU, причем каждый коммуникационный поток выполнен с возможностью, при его исполнении на ядре CPU, к которому этот коммуникационный поток привязан, переключать данное ядро CPU в защищенный режим.

3. Способ по п.2, в котором упомянутая привязка содержит соответственную установку свойства affinity коммуникационного потока.

4. Способ по п.2, в котором мобильное устройство имеет области памяти, которые доступны только посредством SecureOS.

5. Способ по п.2, в котором упомянутый поток является одним из одного или более потоков SecureOS, созданных доверенным приложением, исполняющимся в защищенной среде, при этом упомянутая активация содержит этапы, на которых:

после подачи клиентом RichOS команды, подлежащей обработке доверенным приложением, коммуникационный процесс помещает команду в его очередь и назначает команде соответственный коммуникационный поток; и

после запуска коммуникационного потока на ядре CPU переключают ядро CPU в защищенный режим, и планировщик SecureOS исполняется на ядре CPU и разблокирует по меньшей мере упомянутый поток.

6. Способ по п.5, в котором упомянутая структура данных содержит битовое поле, при этом упомянутое изменение содержит этап, на котором посредством планировщика SecureOS: устанавливают в битовом поле битовую запись, соответствующую ядру CPU, если ни одного потока SecureOS доверенного приложения не было ранее назначено ядру CPU; и

при этом способ дополнительно содержит этап, на котором помещают поток в очередь планировщика SecureOS и выделяют временную квоту для исполнения потока.

7. Способ по п.6, дополнительно содержащий этап, на котором, после изменения маски CPU в SecureOS, причем изменение не связано с потоком SecureOS, в настоящее время исполняющимся в ядре CPU:

вытесняют исполняющийся в настоящее время поток SecureOS из ядра CPU и возвращают этот поток SecureOS в очередь планировщика SecureOS.

8. Способ по п.6, в котором упомянутая передача содержит этапы, на которых, посредством планировщика SecureOS:

после завершения исполнения/вытеснения какого-либо потока SecureOS в ядре CPU,

в случае завершения,

блокируют поток SecureOS,

если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновляют маску CPU посредством сбрасывания битовой записи, соответствующей ядру CPU, и

вставляют маску CPU в результат исполнения и возвращают этот результат в RichOS;

в случае вытеснения либо вставляют маску CPU в результат, указывающий незавершенное исполнение, и возвращают этот результат в RichOS, либо помещают маску CPU в разделяемую память; и

переводят управление на ядре CPU обратно в незащищенную среду.

9. Способ по п.8, дополнительно содержащий этапы, на которых, посредством драйвера RichOS:

извлекают маску CPU либо из результата, либо из разделяемой памяти;

сопоставляют маску CPU с включенными на текущий момент ядрами CPU и, если ядро CPU в настоящее время отключено, включают ядро CPU; и

сохраняют маску CPU так, чтобы она была доступной коммуникационному процессу.

10. Способ по п.9, дополнительно содержащий этапы, на которых:

посредством коммуникационного процесса отслеживают маску CPU и разблокируют коммуникационный поток, который привязан к ядру CPU, и помещают, посредством планировщика RichOS, коммуникационный поток в очередь планировщика RichOS;

запускают исполнение коммуникационного потока из очереди планировщика RichOS на ядре CPU и переключают, посредством коммуникационного потока, ядро CPU в защищенный режим, тем самым переводя управление на ядре CPU в защищенную среду; и

начинают исполнение планировщика SecureOS в ядре CPU и переключают планировщик SecureOS на исполнение упомянутого потока.

11. Способ по п.10, дополнительно содержащий этапы, на которых, по завершении исполнения потока на ядре CPU, посредством планировщика SecureOS:

блокируют поток;

вставляют маску CPU в результат исполнения; и

предоставляют этот результат драйверу RichOS и переводят управление на ядре CPU обратно в незащищенную среду.

12. Способ по п.11, дополнительно содержащий этап, на котором после блокировки потока, если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновляют, посредством планировщика SecureOS, маску CPU путем сбрасывания битовой записи.

13. Способ по п.11, дополнительно содержащий этап, на котором пересылают, посредством коммуникационного процесса, результат, принятый от драйвера RichOS, клиенту RichOS для последующей обработки.

14. Способ по п.10, дополнительно содержащий этап, на котором, после вытеснения потока из ядра CPU по истечении временной квоты или по прерыванию, принятому из RichOS, посредством планировщика SecureOS возвращают поток в очередь планировщика SecureOS для завершения исполнения позже.

15. Способ по п.2, в котором RichOS выполнена с возможностью последовательного включения отключенных на текущий момент ядер CPU, по мере увеличения вычислительной нагрузки в мобильном устройстве, в предварительно установленном порядке, определяемом номерами ядер CPU, и планировщик SecureOS выполнен с возможностью выделения ядер CPU потокам SecureOS в соответствии с упомянутым порядком.

16. Мобильное устройство, содержащее по меньшей мере один процессор (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.

17. Мобильное устройство по п.16, в котором

упомянутая изоляция реализована, в смысле ресурсов мобильного устройства, в виде незащищенной среды и защищенной среды, при этом каждая из незащищенной среды и защищенной среды задействуется из расчета на ядро CPU: когда ядро CPU находится в защищенном режиме, SecureOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в защищенной среде, а когда ядро CPU находится в незащищенном режиме, RichOS получает управление на этом ядре CPU и способна использовать ресурсы мобильного устройства, которые предназначены быть доступными в незащищенной среде, при этом мобильное устройство содержит ресурсы аппаратного обеспечения, которые, при их использовании в защищенной среде, становятся недоступными из незащищенной среды;

SecureOS содержит планировщик SecureOS, выполненный с возможностью планирования исполнения потоков SecureOS;

RichOS содержит:

планировщик RichOS, выполненный с возможностью планирования исполнения потоков RichOS,

драйвер RichOS, выполненный с возможностью сообщения с планировщиком SecureOS, причем драйвер RichOS выполнен с возможностью включения ядер CPU, и

коммуникационный процесс, причем коммуникационный процесс содержит набор коммуникационных потоков, при этом каждый коммуникационный поток привязан к отличному от других ядру CPU, с тем чтобы этот коммуникационный поток мог исполняться только на данном ядре CPU, причем каждый коммуникационный поток выполнен с возможностью, при его исполнении на ядре CPU, к которому этот коммуникационный поток привязан, переключать данное ядро CPU в защищенный режим.

18. Мобильное устройство по п.17, в котором упомянутая привязка содержит соответственную установку свойства affinity коммуникационного потока.

19. Мобильное устройство по п.17, при этом мобильное устройство имеет области памяти, которые доступны только посредством SecureOS.

20. Мобильное устройство по п.17, в котором поток является одним из одного или более потоков SecureOS, созданных доверенным приложением, исполняющимся в защищенной среде, при этом:

коммуникационный процесс выполнен с возможностью, после подачи клиентом RichOS команды, подлежащей обработке доверенным приложением, помещать команду в его очередь и назначать команде соответственный коммуникационный поток; и

после запуска коммуникационного потока на ядре CPU, ядро CPU переключается в защищенный режим и планировщик SecureOS исполняется на ядре CPU и разблокирует по меньшей мере упомянутый поток, посредством чего данный поток активируется.

21. Мобильное устройство по п.20, в котором упомянутая структура данных содержит битовое поле, при этом планировщик SecureOS, для выполнения упомянутого изменения, выполнен с возможностью установки в битовом поле битовой записи, соответствующей ядру CPU, если ни одного потока SecureOS доверенного приложения не было ранее назначено ядру CPU; и

при этом планировщик SecureOS дополнительно выполнен с возможностью помещать поток в очередь планировщика SecureOS и выделять временную квоту для исполнения потока.

22. Мобильное устройство по п.21, в котором планировщик SecureOS дополнительно выполнен с возможностью, после изменения маски CPU в SecureOS, каковое изменение не связано с потоком SecureOS, в настоящее время исполняющимся в ядре CPU:

вытеснять исполняющийся в настоящее время поток SecureOS из ядра CPU и возвращать данный поток SecureOS в очередь планировщика SecureOS.

23. Мобильное устройство по п.21, в котором планировщик SecureOS, для выполнения упомянутой передачи, выполнен с возможностью, после завершения исполнения/вытеснения какого-либо потока SecureOS в ядре CPU,

в случае завершения,

блокировать поток SecureOS,

если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновлять маску CPU посредством сбрасывания битовой записи, соответствующей ядру CPU, и

вставлять маску CPU в результат исполнения и возвращать этот результат в RichOS;

в случае вытеснения, либо вставлять маску CPU в результат, указывающий незавершенное исполнение, и возвращать этот результат в RichOS, либо помещать маску CPU в разделяемую память; и

переводить управление на ядре CPU обратно в незащищенную среду.

24. Мобильное устройство по п.23, в котором драйвер RichOS дополнительно выполнен с возможностью:

извлекать маску CPU либо из результата, либо из разделяемой памяти;

сопоставлять маску CPU с включенными на текущий момент ядрами CPU и, если ядро CPU в настоящее время отключено, включать ядро CPU; и

сохранять маску CPU так, чтобы она была доступной коммуникационному процессу.

25. Мобильное устройство по п.24, в котором

коммуникационный процесс дополнительно выполнен с возможностью отслеживать маску CPU и разблокировать коммуникационный поток, который привязан к ядру CPU, и планировщик RichOS дополнительно выполнен с возможностью помещения коммуникационного потока в очередь планировщика RichOS;

коммуникационный поток выполнен с возможностью, после запуска исполнения коммуникационного потока из очереди планировщика RichOS в ядре CPU, переключать ядро CPU в защищенный режим, тем самым переводя управление на ядре CPU в защищенную среду, с тем чтобы исполнение планировщика SecureOS началось на ядре CPU, и планировщик SecureOS переключается на исполнение упомянутого потока.

26. Мобильное устройство по п.25, в котором планировщик SecureOS дополнительно выполнен с возможностью, после завершения исполнения потока на ядре CPU:

блокировать поток;

вставлять маску CPU в результат исполнения; и

предоставлять этот результат драйверу RichOS и переводить управление на ядре CPU обратно в незащищенную среду.

27. Мобильное устройство по п.26, в котором планировщик SecureOS дополнительно выполнен с возможностью после блокирования потока, если никаких других потоков SecureOS на текущий момент не назначено ядру CPU, обновлять маску CPU посредством сбрасывания битовой записи.

28. Мобильное устройство по п.27, в котором коммуникационный процесс дополнительно выполнен с возможностью пересылки результата, принятого от драйвера RichOS, клиенту RichOS для последующей обработки.

29. Мобильное устройство по п.25, в котором планировщик SecureOS дополнительно выполнен с возможностью, после вытеснения потока из ядра CPU по истечении временной квоты или по прерыванию, принятому из RichOS, возвращать поток в очередь планировщика SecureOS для завершения исполнения позже.

30. Мобильное устройство по п.28, в котором RichOS выполнена с возможностью последовательного включения отключенных в настоящее время ядер CPU, по мере увеличения вычислительной нагрузки в мобильном устройстве, в предварительно установленном порядке, определяемом номерами ядер CPU, и планировщик SecureOS выполнен с возможностью выделения ядер CPU потокам SecureOS в соответствии с упомянутым порядком.