имеется устройство с процессором arm946es.
его родной firmware позволяет запускать бинарные файлы с SD карточки.
в результате запуска стартует не родная операционная система, а код из бинарного файла.

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

вопрос: как к нашему коду вернется управление после старта операционной системы?
ответ: используя Protection Unit мы пытаемся не позволить операционной системе установить ее родной abort handler
проблема в том, что минимальный размер страницы при использовании Protection Unit - 4kb
a нам нужно не позволить записать только 4(8?) байтов в vector table (data abort handler и prefetch abort handler )

тоесть наш обработчик должен иметь возможность узнать, что и куда в этом сегменте пытались записать.
если записываемый адрес не наш abort handler - нам нужно записать эти данные как и предполагал их записать "чужой" код.
получается, что нам нужен парсер инструкциЙ STR.
изобретать велосипед не хочется. скорее всего этот код давно существует.
мне не удалось этот код найти.
я смотрел проекты: qemu, skyeye, softgun, swarm
немного тяжело анализировать такие большие проекты, когда мне всего лишь нужен парсер для двух инструкций STR.

вопрос: где такой код искать, который позволяет узнать, по какому адресу предполагалась запись?
также возможно мы используем совершенно не правильный подход для решения нашей проблемы.


выслушаю и приму любые дикие идеи.

Такая штука реализована в Linux. Ссылка на код есть в этой теме:

http://electronix.ru/forum/index.php?showtopic=36258&hl=

Извините, но вопрос описан мутно.
Толи вы хотите вернуться из ОС к вашему коду по исключению?!
То ли не дать установить операционке обработчики исключений?


Так запускайте средствами операционной системы.



Вам нужно вопрос изложить более четко.


Для начала почитать про MMU,
залочить cтраницу от записи, в ARM9 мин размер 4kb, ARM11 - 1kb.
По DABT'у будете иметь в LR адрес иструкции которая пыталась записать и регистровый файл USER/SVSR. Обработчик может либо сэмулировать выполнение записи, либо трактовать такую запись как фатальный краш системы.

scifi - спасибо за идею

defunct

подробнее:

1) штатных средст, позволяющих запустить исполняемый файл из операционной системы - нету
2) можно запустить исполняемый код ВМЕСТО операционной системы.
3) мы предположили, что единственный способ запуска нашего кода внутри операционной системы :
- попытаться запустить операционную систему из нашего кода.
- "что-то" зделать, чтобы операционная система наш код не стерла в оперативной памяти.
- получить "как-то" после запуска операционной системы управление назад на наш код. это позволит нам полноценно использовать все функции операционной системы.


наш еще нереализованный вариант решения данной проблемы:
поставить свой Data Abort Handler и запретить запись на первые 4кб (и на область памяти, в которой находится тело нашего обработчика), чтобы операционная система не смогла поставить свой хандлер.
поэтому на наш хандлер ложится ответственность записи той области памяти внутри наблюдаемого сегмента, которая не затрагивает наш код - эмуляция той инструкции.

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




поскольку у меня знания в области архитектуры ARM не большие , я надеялся услышать альтернативные варианты решения проблемы


PS: операционная система живет в ROM (Flash)

Сообщение отредактировал max sagaydachny - Oct 25 2007, 12:37

Это уже сродни вирусописательству. Там тоже решаются задавчи, как "приклеиться" к чужому коду.

И что?! Вы думаете достаточно будет только один обработчик подменить?
А IRQ, а FIQ? Для того чтобы не терять контроль над системой вам придется эмулировать не только DABT, а все исключения.
Надеюсь вы понимаете, чем это может грозить системе?


Это даже не вопрос, просто берете таблицу команд (ARM instruction set) с arm.com, там все расписано.


Альтернативный и на мой взгляд правильный вариант - подправить ОС так, как требуется для работы вашего проекта, либо взять такой ОС который удовлетворяет вашим требованиям сразу. Раз ОС на Flash, значит перезаписать можно.

давайте назовем это по другому - модификация системы для выполнения дополнительных действий... :-)

Для этого можно пойти простым путем - добавить выполение доп действий в исходниках ОС.
Или ОС закрытая? ;>
что за ОС кстати?

defunct
я думаю, что родной дата аборт хандлер там висит просто "на всякий случай".
я думаю, что его подмена не повлияет на работу операционной системы.
зачем менять обработчики IRQ и FIQ?

устройства, на которые нацелен проект: Canon камеры, на которых работает vxWorks

перезаписывать Flash, даже если бы это было возможно, не хочется по многим причинам (если что-то пойдет не так, я нехотел бы пытаться объяснять в сервисном центре , почему в моем аппарате не правильный образ Flash).




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

Для чего тогда его менять?


А как вы себе представляете процесс передачи управления из ОС вашему процессу?
На основе сказанного вами выше мне видится только такой сценарий - ваш процесс обслуживает все исключения и решает, что передавать на обработку ОС, а что обрабатывать самому.

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

мы его собираемся менять, чтобы иметь возможность получить управление обратно.

А как вы себе представляете процесс передачи управления из ОС вашему процессу?
используя data abort handler
я примерно знаю, с какими адресами оперирует операционная система.
на основе этого я могу написать свой data abort handler

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

Сообщение отредактировал max sagaydachny - Oct 25 2007, 14:28

Все верно, но некоторые операционки используют DABT для определения объема подключенной памяти при стартапе. Если вы его тупо подмените - ОС может неверно определить объем памяти и девайс будет неверно работать.



Data Abort происходит когда система находится в действительно плохом состоянии - в результате порчи какого-то указателя. Такая ситуация для отлаженного девайса - артефактная, т.о. управление назад вы получите ровно с такой же вероятностью, с какой девайс может сбойнуть.


Ну предположим написали, и что он вам даст? Ведь DABT это считайте краш системы.

2 defunct

На мой взгляд автор хочет подменить Дата Аборт не для вызовов через него. Дата Аборт необходим для перехвата доступа к таблице векторов прерывания (задав первые хх Кб как Read Only). Что в свою очередь необходимо для того чтобы ОС не смогла модифицировать заранее записанные туда "свои" вектора. Через котрые уже можно (но оч. сложно) получить управление. Для того и спрашивалось про парсер инструкций и их эмуляцию... ИМХО.

Я тоже так вначале подумал, но афтар пишет:


тобиш FIQ/IRQ, он хочет оставить оригинальные "ОСовые"

Ну а дальше все чудесатее и чудесатее: