Комментарии 9
вызов монитора SMC позволяет коду гостевой ОС (Non-Secure PL1) вызвать функцию TEE (Secure PL1).
SMC не зря значит Secure Monitor Call. Некоторые SMC обрабатываются самим монитором, без переключения в S-PL1. Например — всё что связанно с PSCI.
R3 – начальный адрес буфера, куда упадет подпись. Считаем, что, если буфера не хватит, это не проблема TEE.
Всё же проблема REE, мне кажется.
Еще раз: все вызовы из Non-Secure World попадают на обработку в Secure, а Secure Monitor сам ничего не обрабатывает. Привратник.
Это не верно в общем случае. Посмотрите на ARM Trusted Firmware.
И зря вы упоминаете термин «гостевой режим». Он всё-таки используется в ARM Virtualization Extensions.
Что касается обработки PSCI — приведите пример, пожалуйства. Специально посмотрел сейчас ARM Trusted Firmware (https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl1/aarch32/bl1_exceptions.S) и не вижу там выполнения собственно кода вызова в режиме Secure Monitor.
Насколько я вижу, код Secure Monitor переключается в режим Secure, находит соответствующую номеру вызова Entry point и перенаправляет исполнение на нее при выходе из режима Monitor. А уж entry point может указывать как на точку входа ОС, либо на точку входа в Fastcall — для управления питания.
Если я не прав — приведите пример, пожалуйста.
Насколько я вижу, код Secure Monitor переключается в режим Secure, находит соответствующую номеру вызова Entry point и перенаправляет исполнение на нее при выходе из режима Monitor. А уж entry point может указывать как на точку входа ОС, либо на точку входа в Fastcall — для управления питания.
Если я не прав — приведите пример, пожалуйста.
Во первых вы смотрите код bl1, хотя надо смотреть bl32. Во вторых даже в коде bl1 нигде не трогается CPSR.
Простите, но ваш ответ напоминает крылатую фразу про «Вы уже перестали пить коньяк по утрам?»
Писать статьи и связно излагать свои выводы довольно трудно, но я постарался максимально прозрачно написать.
Вы не согласны с написанным. Попробуйте тогда так же понятно пояснить.
Мне непонятен ваш комментарий. Почему нужно смотреть не bl1, а bl32, что там нужно увидеть. И к чему замечание про CPSR? Я про него не говорил.
Писать статьи и связно излагать свои выводы довольно трудно, но я постарался максимально прозрачно написать.
Вы не согласны с написанным. Попробуйте тогда так же понятно пояснить.
Мне непонятен ваш комментарий. Почему нужно смотреть не bl1, а bl32, что там нужно увидеть. И к чему замечание про CPSR? Я про него не говорил.
А, извините, просто я думал вы знаете как работает ARM TF.
BL1 — это загрузчик первой стадии. Он живет очень не долго. Основным Secure Monitor служит BL31 или BL32.
При исполнении SMC процессор переключается в EL3 (или в monitor mode в терминологии ARMv7) и вызывается handle_smc из кода bl32.
handle_smc сбрасывает бит NS, переводя процессор в режим Secure (но оставаясь при этом в monitor mode) и вызывает сишный хендлер handle_runtime_svc(). Тот ищет в таблицах зарегистрированных обработчиков нужный обработчик (согласно SMCCC Function ID) и вызывает его. Например, если это был запрос к PSCI 0.2 то он обрабатывается в std_svc_setup.c, если это был вызов OP-TEE, то он обрабатывается в opteed_smc_handle() в opteed_main.c. opteed_smc_handle() интересен тем, что он изменяет вызывающий контекст таким образом, что после выхода из режима Monitor, мы попадем не в PL1/PL2 (как должны были бы), а в S-PL1, где и исполняется OP-TEE. Поэтому, после того мы возвратимся обратно в handle_runtime_svc(), а оттуда в handle_smc, мы сделаем Exception return и наконец-то переключимся в S-PL1.
А если бы вызывался не OP-TEE, а PSCI (или какие-то платформенные вызовы), то мы бы обработали их в Secure Monitor Mode и вернулись бы прямиком в PL1/PL2, не переключаясь в S-PL1 вообще.
Поэтому Secure Monitor — это не только переключалка режимов. Это полноценная часть системы. А ещё туда сейчас заходит SCPI, и его функциональность расширится ещё больше.
BL1 — это загрузчик первой стадии. Он живет очень не долго. Основным Secure Monitor служит BL31 или BL32.
При исполнении SMC процессор переключается в EL3 (или в monitor mode в терминологии ARMv7) и вызывается handle_smc из кода bl32.
handle_smc сбрасывает бит NS, переводя процессор в режим Secure (но оставаясь при этом в monitor mode) и вызывает сишный хендлер handle_runtime_svc(). Тот ищет в таблицах зарегистрированных обработчиков нужный обработчик (согласно SMCCC Function ID) и вызывает его. Например, если это был запрос к PSCI 0.2 то он обрабатывается в std_svc_setup.c, если это был вызов OP-TEE, то он обрабатывается в opteed_smc_handle() в opteed_main.c. opteed_smc_handle() интересен тем, что он изменяет вызывающий контекст таким образом, что после выхода из режима Monitor, мы попадем не в PL1/PL2 (как должны были бы), а в S-PL1, где и исполняется OP-TEE. Поэтому, после того мы возвратимся обратно в handle_runtime_svc(), а оттуда в handle_smc, мы сделаем Exception return и наконец-то переключимся в S-PL1.
А если бы вызывался не OP-TEE, а PSCI (или какие-то платформенные вызовы), то мы бы обработали их в Secure Monitor Mode и вернулись бы прямиком в PL1/PL2, не переключаясь в S-PL1 вообще.
Поэтому Secure Monitor — это не только переключалка режимов. Это полноценная часть системы. А ещё туда сейчас заходит SCPI, и его функциональность расширится ещё больше.
Спасибо, теперь понятно. Я отмечу это в теле статьи! Кстати, не хотите написать об этом на хабре? Начало уже положено.
Ну я как-то писал обзорную статью, типа вашей. А такие технические нюансы практически никому не нужны. Тем более на русском. Кому надо — тот всегда может посмотреть ARM Architecture Reference Manual, SMCCC и другие документы, благо они в открытом доступе.
Мда, я к сожалению уже малость подзабыл терминологию ARMv7. Дело в том что PLx не тождественно ELx.
Поэтому вместо «PL1» следует читать «Supervisor Mode», а вместо «PL2» — «Hypervisor mode». Так будет правильнее.
Дело в том, что согласно ARMv7 ARM, Monitor Mode действительно имеет уровень привилегий PL1. Правда, это хитрый PL1, который позволяет видеть регистры процессора и в Secure Mode и в Non-Secure Mode. Тут они провтыкали конечно. Хорошо что они исправили это в ARMv8, переименовав Monitor Mode в EL3
Поэтому вместо «PL1» следует читать «Supervisor Mode», а вместо «PL2» — «Hypervisor mode». Так будет правильнее.
Дело в том, что согласно ARMv7 ARM, Monitor Mode действительно имеет уровень привилегий PL1. Правда, это хитрый PL1, который позволяет видеть регистры процессора и в Secure Mode и в Non-Secure Mode. Тут они провтыкали конечно. Хорошо что они исправили это в ARMv8, переименовав Monitor Mode в EL3
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование под ARM TrustZone. Secure Monitor