М.М. Илипов Особенности программирования

Л.Н. Гумилев атындағы ЕҰУ Хабаршысы - Вестник ЕНУ им. Л.Н. Гумилева, 2011, №6
М.М. Илипов
Особенности программирования микропроцессорных карт
(Евразийский национальный университет имени Л.Н. Гумилева, г. Астана, Казахстан)
В данной статьи проводиться обзор и особенности программирования микропроцессорных карт
Микропроцессорные карты, изобретенные более четверти века назад, нашли широкое
применение в IT-индустрии, включающей в себя такие направления, как разработка
операционных систем, прикладных программных средств, сетевые технологии, защита
информации и электронные платежи.
Для расширения функциональности и набора команд микропроцессорной карты
применяются так называемые карточные скрипты, состоящие из определенного набора
команд, интерпретируемые т.н. виртуальной машиной (ВМ), реализуемой внутри
операционной системы. Как правило, код интерпретатора ВМ занимает достаточно много
места в масочном ПЗУ и является едва ли не самым крупным блоком во всем коде
операционной системы карты. Целью данной статьи является рассмотрение возможности
реализовывать карточные скрипты не в системе команд ВМ, а непосредственно в системе
команд контроллера карты, доверяя выполнение скрипта самому контроллеру, поскольку
большинство карт является мультипликационными и на них может быть несколько
независимых приложений. Поэтому эти приложения должны быть изолированы друг от
друга, т.е. ни одно приложение не должно иметь доступ на чтение параметров или
модификацию вычислительной среды другого. Если же выполняется скрипт в системе команд
контроллера, он будет иметь доступ ко всем без исключения ресурсам микропроцессорной
карты, в том числе, к ЭСППЗУ, хранящему параметры других приложений. Именно это
является одной из причин реализации громоздких интерпретаторов карточных скриптов.
Кроме того, система команд скриптов содержит как низкоуровневые команды, например,
арифметические пересылки данных и т.п., так и высокоуровневые, содержащие обращения к
различным модулям операционной системы карты, например, такие как чтение/запись
файла, осуществление криптографических операций, выполнение штатной команды ОС и
много другое. Попробуем реализовать модификацию системы команд контроллера карты в
аппаратную вычислительную среду, позволяющую выполнять программный код,
гарантировано изолированный от других приложений, как это, например делается в больших
многозадачных вычислительных системах. Нужно создать некий аналог режима v86
микропроцессоров i80386 фирмы Intel, тем самым освободить место в масочном ПЗУ, убрав
из него масочный интерпретатор скриптов виртуальной машины.
Рассмотрим контроллер на кристалле РИК КБ5004ВЕI (Аn15M04) выпускаемый ОАО
"Ангстрем"(Россия). Его описание недоступно в открытом виде, однако, на официальном
сайте ОАО "Ангстрем"[1] можно найти описание представителей семейства
микроконтроллеров Тесей: КР1878Ве1 (An15Е03) и КР 1878ВЕ2 (An15M05), имеющих
схожую с КБ5004ВЕ1 архитектуру.
Ядром микроконтроллера КБ5004ВЕI является восьмиразрядный RISC - процессор с
внутренним тактовым генератором частотой до15 МГц и одноуровневым конвейером на три
команды, позволяющим выполнить любую команды за два такта. Микроконтроллер также
имеет следующие компоненты:
1) Интерфейс ввода-вывода в соответствии с ISO 7816;
2) Встроенный программно - аппаратный датчик случайных чисел;
3) ОЗУ размером 256 байт;
4) Масочное ПЗУ размером 16 Кб, состоящее из 8192 двухбайтовых командных слов;
5) ЭСППЗУ размером 2 кб, состоящее из 128 блоков по 16 байт, обеспечивающее 100 тыс.
операций перезаписи и гарантированное хранение информации сроком до 10 лет.
Организация полноценного виртуального режима на данном кристалле, включающего,
52
М.М. Илипов
например, такие механизмы, как атрибуты доступа к памяти - слишком дорогостоящая
задача, сравнивая, пожалуй, мс разработкой нового кристалла. Поэтому ограничиться лишь
минимальным достаточным набором модификаций в архитектуре кристалла:
"введение флага наличия виртуального режима в регистре состояния процессора
"объединение адресного пространства масочного ПЗУ и ЭСППЗУ в одноадресное
пространство, для того, чтобы программный код, хранимый в ЭСППЗУ, был доступен для
выполнения кристаллом;
"разделение набора команд на привилегированные и непривилегированные;
"введение в систему команд кристалла дополнительной команды переключения на
супервизор;
"использование двух прерываний под нарушение защиты и под супервизор.
В регистре состояния процессора, хранимого по адресу 0h ОЗУ кристалла, есть единственный
незадействованный бит -b7. Назовем его VM (от VirtualMode). При выполнении кода ОС
VM=0, при выполнении скрипта, т.е. кода приложения,VM=1. Скорее всего, разработчики
кристалла зарезервировали этот флаг для будущих кристаллов с большим объемом
масочного ПЗУ, в этом случае для добавления флага VM можно расширить регистр
состояния процессора до двух байт, храня его старшую часть в одном из свободных байтов
младших адресов ОЗУ. Теперь необходимо решить вопрос с обеспечением возможности
выполнения кода приложения из ЭСППЗУ. Проблема в том, что масочное ПЗУ и ЭСППЗУ
имеют различные адресные пространства, кроме того, присоединение адресного пространства
ЭСППЗУ к адресному пространству масочного ПЗУ приведет к выходу за пределы разрядов
адресного пространства масочного ПЗУ. Решение этой проблемы возможно следующим
образом. Будем считать введенный нами флаг VM тоже элементом адресного пространства,
осуществляющего выбор между масочным ПЗУ (VM=0) и ЭСППЗУ (VM=1). Как будет
изложено далее коду приложения будет запрещено совершать передачу управления
напрямую в код операционной системы, поэтому такой метод адресации вполне возможен.
Следующей проблемой является то, что в силу схемотехнических особенностей реализации
ЭСППЗУ процессору будет сложно осуществлять выборку из ЭСППЗУ блоков с кодом
приложения. Поэтому код приложения можно перемещать в ОЗУ, осуществляя выполнение
кода при взведенном флаге VM уже не из ЭСППЗУ, а из ОЗУ кристалла; а задачу по
загрузке необходимых блоков из ЭСППЗУ в ОЗУ можно переложить на супервизор подсистему, осуществляющую диспетчеризацию процессора кода приложения и сервисные
функции, связанные с этим. Кроме того, это позволит решить вопросы, возникающие в
случае нелинейной организации файловой структуры в ЭСППЗУ и, соответственно,
нелинейного хранения кода приложения в ЭСППЗУ. Кроме того, участок памяти,
содержащий код приложения, должен обрамлять командами переключения на супервизор,
дабы управление, переданное коду приложения, не вышло за его пределы.
Теперь поделим команды кристалла на две группы: разрешенные и неразрешенные для
выполнения кодом приложения.
Команды кристалла делятся на следующие типы:
"двухоперандные команды: пересылки, сравнения, арифметические и логические команды;
"литерные команды: пересылка, сравнение, арифметические и логические команды с
использованием константных аргументов - литер;
"однооперандные команды: обмен тетрад, смена знака, логическая инверсия, логические,
арифметические и циклические сдвиги, сложение/вычитание с переносом;
"команды работы со служебными регистрами и регистром состояния: загрузка адреса и
служебных регистров, запись/чтение служебных регистров, операции со стеком данных,
установка/сброс разрядов RS , проверка переполнения и тетрадного переноса;
"команды передачи управления: безусловный, косвенные и условные переходы, переходы к
подпрограмме, возвраты из подпрограммы и прерывания;
"специальные команды: отсутствие операции, ожидание, сброс, уменьшение указателя стека
53
Л.Н. Гумилев атындағы ЕҰУ Хабаршысы - Вестник ЕНУ им. Л.Н. Гумилева, 2011, №6
команд.
Критерием разрешения применения команды будут условия отсутствия влияния команды на
служебные регистры и отсутствия передачи управления.
Поэтому при взведенном флаге VM разрешается выполнение команд лишь из первых трех
групп: двухоперандные команды, литерные команды, однооперандные команды. Также
можно разрешить такие команды, как NOP - отсутствие операции, TOF - проверка
переполнения, TDC - проверка тетрадного переноса.
Таким образом, код приложения самостоятельно сможет выполнять лишь пересылки в
пределах доступной оперативной памяти, сравнения, арифметические и логические команды,
сдвиги и т.п. для проведения всех остальных операций, таких как передача управления,
смена доступной области памяти, установление режима косвенной адресации, выполнение
высокоуровневых операций, таких как, криптографические преобразования, ввод/вывод,
чтение/запись файлов и т.п. потребуется обращение к супервизору.
Для обращения к супервизору можно или ввести отдельную команду, с мнемоникой,
например JSV (от JumpSuperVisor). В системе команд микропроцессора не задействованы
коды команд 0000 0000 0000 10ХХ, поэтому команде JSV можно присвоить код, например,
0000 0000 0000 1000. Если же вводить в архитектуру кристалла дополнительную команду по
схемотехническим соображениям сложно, можно назначить ее функциональность на одну из
служебных команд, например, на команду RESET. Если флаг VM равен нулю, команда будет
выполняться, какэто предусмотрено текущей архитектурой кристалла, а приVM, равном
единице, будет происходить переключение на подпрограмму-супервизор.
Во всех остальных случаях при попытке выполнения запрещенной команды в режиме кода
приложения, должно возникать прерывание, скажем, номер 4, он пока свободен. Также, для
передачи управления супервизору, необходимо еще одно прерывание - прерывание
супервизора. Ему можно присвоить тоже пока свободный номер - 5.
Появление в архитектуре флага VM требует внесение изменений в функционирование
механизма прерываний: при возникновении прерывания и передачи управления на
обработчик этого прерывания, флаг VM должен сбрасываться и автоматически
восстанавливаться из стека при возврате из прерывания. Очевидно, что для кода приложения
не должно быть способа модифицировать флаг VM, т.к. на этом основывается безопасность
всех остальных приложений, находящихся на карте. Также крайне важно в целях
безопасности запретить в режиме выполнения кода приложения использование косвенной
адресации, регистры D6 и D7 по функциональности не должны отличаться от остальных. В
противном случае код приложения сможет получать доступ ко всему ОЗУ и даже масочному
ПЗУ. Если же разработчику карточного приложения потребуется косвенная адресация - это
можно будет сделать через сервисный вызов супервизора.
Итак, описан весь набор модификаций, требующихся на аппаратном уровне. Таким образом,
была реализована модификация систем команд контроллера карты в аппаратную
вычислительную среду, позволяющую выполнять программный код, гарантировано
изолированный от других приложений. Данная методика применима в smart-картам и дает
возможность реализовывать карточные скрипты не в системе команд ВМ, а непосредственно
в системе команд контроллера карты.
ЛИТЕРАТУРА
1. Атанов С.К., Программные средства реализации адаптивных моделей с нечеткой
логикой"Вестник науки КазАТУ им. С.Сейфуллина", №2, 2009., C. 27, Астана
2. Тимур Палташев "Электроника как основа инновационной экономики России. Взгляд из
Кремниевой Долины", Промышленные Ведомости, №3, март
2007http://www.promved.ru/articles/article.phtml?id=1115&nomer=41
3. Федунов Б.Е. Максимально быстрое торможение объекта, осуществляющего управляемое
движение под действием сил аэродинамического торможения и тяжести.//ПММ.
54
М.М. Илипов
Том54.Вып.5,1990.
Iлiпов М.М.
Мақалада микропроцессорлық карталарға шолу және программалаудың ерекшелiктерi көрсетiлген
Ilipov M. M.
Features of programming of microprocessor cards
In given articles to be spent the review and features of programming of microprocessor cards
Поступила в редакцию 11.10.2011
Рекомендована к печати 17.10.2011
55