|
|
Поясните, для чего положили такую граблеобразную конструкцию в механизм защиты с независимыми lock-битами.
Типичная задача - пусть мы хотим написать Boot-Loader и защитить его от несанкционированного чтения Application-секцией. Для этого программируем бит защиты BLB12. Но одновременно с этим запрещаются прерывания, если при работе программы Boot-Loader-а таблица векторов прерываний находится в Application-секции.
Вопрос - зачем запрещаются прерывания ?
Возможно, по замыслу разработчиков из Атмела, каждая секция (Boot и Application) должна иметь свою таблицу векторов и при получении управления исполняемый код каждой секции должен устанавливать IVSEL на себя. Тогда запрещение прерываний - это простой аппаратный способ избежать ошибок, если программист забыл на входной точке переключиться на свою таблицу векторов.
Однако, раз это запрещение прерываний жёстко увязано с битами секретности, напрашивается другая мысль: это запрещение прерываний должно предотвратить возможную утечку информации о чужой программе. Первое, что приходит в голову: если бы прерывания не запрещались, то потенциальный нарушитель авторских прав, дабы исследовать чужой код, мог бы аппаратным путём сделать какой-либо источник прерывания постоянно активным (например, EEPROM Ready или INT0 по низкому уровню), написать свой обработчик и использовать это прерывание как трассировочное - оно вызывалось бы после выполнения каждой инструкции, и можно было бы прочитать адрес текущей инструкции (из стека) и содержимое всех флагов, регистров и ячеек памяти (всё как в отладчике, только не видно самой инструкции). Прогнав таким образом анализируемую программу "по шагам", можно было бы восстановить алгоритм: по содержимому флагов, регистров и всех ячеек памяти "до" и "после" можно догадаться, какая инструкция там была, особенно если эта инструкция выполняется несколько раз за время работы программы с разными начальными значениями регистров. Более того, можно искусственно подставлять неизвестной инструкции разные комбинации флагов, регистров и ячеек памяти (в том числе портов в/в), изменяя каждый раз в стеке адрес возврата на эту инструкцию и анализируя её необходимое количество раз. А если окажется, что Boot-Loader имеет свои таблицы констант в своей секции флеша, то значит в нём есть инструкция LPM для чтения этих таблиц, и найдя её (например, перебором всех адресов секции Boot-Loader), считаем весь Boot-Loader многократой трассировкой этого LPM. Короче, увлекательное занятие для любопытного пионера, который за один день таким неинвазивным методом прочтёт Вашу программу в Boot-Loader секции. :-)
Однако, даже с запрещением прерываний всё равно остаются дыры в защите. Пусть Application-секция обслуживает некоторое устройство (напр., UART) и должна своевременно обрабатывать возникающие там прерывания. И если Application-секция вызовет некоторую функцию из Boot-секции (по заранее фиксированной точке входа), то во время работы этой функции обслуживать прерывания UART по-прежнему должен обработчик из Application. Для этого вектора UARTа в таблице Boot-Loader-а должны фактически представлять собой jmp на соответствующие позиции таблицы векторов секции Application, поэтому возможность вышеописанного анализа чужой программы по-прежнему будет существовать (постоянно активного источника прерывания может не быть, но это можно обойти: достаточно не выходить из Application-обработчика прерывания, пока снова не взведётся флажок этого же прерывания, чтобы выполнилась только одна инструкция Boot-Loader-а и управление вернулось в тот же Application-обработчик).
Получается, что ухищрение с запрещением прерываний, если и ставило своей целью препятствовать анализу программы, этой цели не достигло. Ведь чтобы воспрепятствовать любопытному пионеру, придётся свести взаимодействие между Application и Boot-Loader секциями к минимуму: все вызываемые сервисы (по фиксированным точкам входа в Boot-Loader) должны выполняться очень быстро и при запрещённых прерываниях, что рубит на корню многие проекты, подразумевающие параллельную работу Application и Boot-Loader частей программы (разумеется, только в случае, если разные секции пишутся разными людьми). Было бы естественно потребовать, чтобы Boot-Loader перехватывал одни прерывания, а Application-секция - остальные, и чтобы ничто не мешало обеим секциям своевременно их обрабатывать. Получается, что в AVR такое возможно только в ущерб секретности. (Ещё раз не могу удержаться от похвалы архитектуры 80386 - там всё задумано грамотно, без дыр в защите)
Так всё-таки, зачем запрещаются прерывания, если при работе скрытой от чтения программы Boot-Loader-а таблица векторов прерываний находится в Application-секции ? Смысл этого шаманства в даташите не объясняется.
|
|
E-mail: 
info@telesys.ru
