Виртуализация исполнения машинного кода процессорной архитектуры ARM в Android-x86 окружении (1187396), страница 6
Текст из файла (страница 6)
К сожалению даже использование даже такого сравнительнонизкоуровневого языка программирования как С не обеспечивает достаточнокомпактный с точки зрения количества машинных инструкций код.Характерная величина функции эмуляции — 150-200 ассемблерныхинструкций x86, что уже гарантирует просадку в производительности науровне двух порядков. Если добавить к этому то что одни из наиболее частовстречающихся инструкций — инструкции для работы с памятью, тостановится понятно, что суммарный оверхед на эмуляцию настолькосущественен, что не позволяет использовать эмуляцию в качествеполноценного способа виртуализации исполнения ARM машинного кода наAndroid-x86.Исходя из этого было решено найти более производительный способрешения поставленной задачи, по возможности минимизировав при этомнеобходимуюработуипредоставив39возможностиповалидациипредлагаемого решения.
Логичным решением в данном случае сталабинарная трансляция, как наиболее производительный и компактный способпроизвести вышеобозначенные манипуляции. Сильные и слабые стороныданного подхода были описаны ранее, поэтому в первую очередь будетописан путь и конкретные подходы бинарной трансляции, с помощьюкоторых были решены поставленные задачи по виртуализации.7. 1 Декомпозиция задачи бинарной трансляцииВ первую очередь стоит оговориться, что задача бинарной трансляцииксожалениютрансляционногонеявляетсяподхода(кактривиальной,статического,иреализациялюбоготак и динамического)сопряжено с трудностями. Заключаются он в первую очередь в различияхпроцессорных платформ.
В нашем случае задача осложнялась тем, что сточки зрения интерфейса целевой процессор принадлежал так называемомусемейству RISC — архитектуре процессора, в котором быстродействиеувеличивается за счёт упрощения инструкций, чтобы их декодирование былоболее простым, а время выполнения — меньшим.В это же время хостовой процессор, то есть x86 или, иначе говоряIA-32 принадлежит семейству CISC, являющуюся в некотором родепротивоположностью RISC. Наиболее значимыми особенностями, которыевстают на пути при трансляции являются:1) Переменные значения длины команды.
В нашем случае эта длина можетколебаться от 1-го до 15-ти байт. Это создаёт трудности в первуюочередь при выделении памяти под исполняемый код, сгенерированнойв процессе трансляции — становится невозможным заранее узнатьсколько страниц памяти понадобится.2) Небольшое число регистров, каждый из которых выполняет строго40определённую функцию.
В случае х86 принято говорить, что враспоряжении программиста находятся 8 регистров общего назначения,а именно {EAX, EBX, ECX, EDX, ESI, EDI, ESP, EBP}, что во-первыхменьше 16-ти регистров общего назначения в архитектуре ARMv7, аво-вторых — регистры х86 в отличие от их RISC-собратьев не являютсясимметричными, некоторые инструкции, такие как к примеру длинноецелочисленное умножение (IMUL) можно произвести только надопределенным и четко фиксированным набором регистров (EAX, EBX,EDX).Таким образом уже на уровне постановки задачи наметилисьпроблемы, которые было необходимо решать на архитектурном уровне, ещедо детальной имплементации всех необходимых для решения задачимодулей. Заметим отдельно, что решено было выбрать путь динамическойбинарной трансляции, так как такой подход:1.
Позволял реализовать задуманное в более короткие сроки. В отличиеот динамического подхода статическая бинарная трансляцияподразумевает, что весь исполняемый машинный код целевогобинарника будет транслирован еще до непосредственного запускаисполняемого кода, а возможно и до этапа загрузки. Таким образомвозникает проблема, связанная с тем, что внешние зависимости длялюбого ELF-файла, очевидно разрешаются на этапе загрузки его впамять, мы же не могли полноценно реализовать такой подход. Придинамическом же подходе можно было воспользоваться ужесуществующим загрузчиком, который способен корректно разрешатьвсе внешние зависимости целевых исполняемых файлов, и ужеполученные разрешённые релокации использовать при генерации41кода для внешних библиотечных вызовов из транслируемого кода.2.
Обеспечивал возможность применения итерационного подхода, тоестьреализациябинарнойтрансляции для примеру самогораспространенного подмножества ARM-инструкций, а оставшуюсяих часть всё так же виртуализировать за счет эмуляции. Также,учитывая что эмуляция машинного кода уже была достаточнохорошо проверена — появилась возможность использовать такойподходдлявалидацииоттранслированногокодазасчётпараллельного исполнения его с эмуляцией и сравнивая результаты.Закрепив динамическую трансляцию как основной способ реализациивиртуализированного выполнения машинного кода ARM необходимо былоразделить процесс на определенные стадии, которые позволили бы упроститьзадачу. В конечном счете архитектурно были выявлены следующие стадии:1.
Модуль анализа так называемого code-flow машинного кода. Инымисловами модуль анализировал целевой машинный код ARM, ужезагруженный в память и с полностью разрешёнными релокациями. Втекущей реализации на выходе из данного модуля мы получаем наборблоков машинного кода, которые выполняются строго последовательнои с соответствующей информацией о связях между ними. Даннаязадача осложняется тем, что каждый опкод в наборе машинныхинструкций ARM содержит блок бит, отвечающих за так называемоеусловное исполнение (conditional execution). Эта битовая маскапозволяет выполнять или же не выполнять инструкции в зависимостиот содержащихся данных в регистре флагов ARM процессора.Условное исполнение дополняет возможности ветвления машинногокода наравне с условиями условных и безусловных прыжков (или42branch, ветвей в ARM-терминологии).2.
Модуль анализа использования регистров. Так как набор и свойстварегистров целевой и хостовой платформы существенно отличаются, тоданная информация является необходимой для следующей стадии. Наданномэтапеявляетсявозможнымреализоватьследующуюоптимизацию — для каждого опкода целевого машинного кода непросто хранить информацию об используемых данной командойрегистров, а также разделять это множество на множество тех, которыеиспользуются только для чтения и тех, которые используются также идля записи. Это позволит в дальнейшем при необходимостипереупорядочить инструкции для исполнения для того, чтобысгруппировать их по принципу локальности использования регистровцелевой платформы, что приводит к возможности уменьшенияперераспределениярегистровхостовогопроцессоравнутринепрерывного блока машинного кода [18].3.
Регистровый аллокатор. Данный модуль отвечает за установлениекорректного соответствия между регистрами x86 и ARM передгенерацией машинного кода хостовой платформы. В данном случаезадача сходна с решением распространенной задачи, которая решаетсяприпостроениикомпиляторов—какоптимальнымобразомрасположить переменные некоторого языка программирования понативным регистрам целевой платформы таким образом, чтобыминимизировать с одной стороны обращение к памяти и стеку, а сдругой не допустить неконсистентности и некорректного поведения.4. Непосредственнобинарныйтранслятор.Знаяинформациюоиспользуемых регистрах, а также о том, каким регистрам целевой х86платформы они соответствуют данный модуль генерирует для каждойARM инструкции некоторый по возможности оптимальный и43минимальный набор инструкций, который реализует её полностьюнативно без необходимости прибегать к какой бы то ни было эмуляции.Минимальной единицей трансляции в данном случае является блокмашинного кода ARM (соответствующий блоку, полученному послеэтапа CFA или code-flow analysis).5.
Модуль, отвечающий за связывание блоков между собой. Как уже былосказано ранее блоки кода являются непрерывными с точки зренияисполнения, то есть точка исполнения программы гарантированновыполнит блок до конца, попав в некоторую его точку. Заметим, что внастоящей имплементации модуль CFA разбивает целевой машинныйкод на блоки, в которых невозможны прыжки в середину блока (еслитакой блок возникает, то его разбивают на несколько). Такой подходможет гарантировать, что после этапа регистровой аллокации схемасоответствия регистров для блока машинного кода будет валидной.
Этопозволяет отказаться от загрузки/сохранения регистров до и послекаждой оттранслированной инструкции и ограничиться такимиучастками шаблонного кода до и после непрерывных блоков, а также вслучае, если необходимо некоторое фиксированное соответствиерегистров (к примеру как в случае с операцией длинного умножения).Рассмотрим каждый из представленных этапов бинарной трансляцииотдельно, а затем опишем каким образом была реализована композицияпредлагаемых подходов.7.2 Модуль code-flow анализа архитектуры ARMКак уже было сказано ранее модуль code-flow (или CFA - code-flowanalysis) был необходим для корректного разделения исполняемого кода44ARM на непрерывные блоки машинных инструкций, которые подчинялисьбы простым правилам.1. Для каждого блока возможна лишь единственная точка входа в данныйблок, то есть гарантируется, что в исполняемом файле не будетсуществовать инструкций условных или безусловных переходов,которые отправляли бы процессор исполнять инструкции из серединыблока.2.
Блок сам по себе может закончиться как инструкцией перехода, так инет. В данном случае подразумевается, что в данном месте возможенпрыжок на данную позицию в коде извне. В случае же, если этого непроисходит, то блок заканчивается инструкцией перехода. При этомнужно оговорить отдельно, что так как архитектура ARM являетсясимметричной с точки зрения процессорных регистров (к примеруREGLR REGPC могут использоваться в арифметических операцияхнаравне с остальными регистрами) возникает сложность с тем, какпонимать такие команды как переход по адресу в REGLR или загрузканекоторой константы в REGPC.Отдельно заметим, что в данном подходе модуль CFA работает сразупосле стадии загрузки исполняемого кода в память, то есть в тот момент,когда все внешние релокации уже разрешены и в машинном коде и GOTтаблице находятся валидные значения адресов.
Рассмотрим часть структурыданных, которую использует модуль для выполнения своих функций.typedef struct source_block {SLIST_ENTRY(source_block) list;addr_t begin, end;struct source_block *next_block;struct source_block *branch_block;45int is_referenced : 1;} source_block_t;Непрерывны блок машинного кода может закончиться по разнымпричинам. Например если при анализе будет обнаружена инструкцияусловного или безусловного перехода в середину существующего блока,который уже был анализирован ранее. В этом случае блок кода будетразделён на два блока (А и В), причём блок В начнётся с целевого адресаинструкции перехода. В этом случае указатели в приведённой структуреданных будут сформированы следующим образом:A->next_block == B; A->branch_block == NULLЕщё один случай это условные инструкции. Отдельно укажем, что вданном случае имеются в виду не только инструкции условных прыжков, нои обычные ARM инструкции, которые в своём машинном опкоде в полеусловного исполнения содержат бинарную маску, отличную от 0x0111 (Тоесть выполнять всегда).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
