Защита секция кода во FLASH в ATmega, Как защититься от несанкционированного выполнения кода Опции

[Дон Амброзио]

А кто как защищает код в MCU от несанкционированного выполнения в результате случайного перехода из одной точки программы в другую от воздействия помехонесущего электромагнитного поля (искажения записанного в счётчике команд значения). А?

Приведу пример
--------------------
lab_1_input: ldi R16 , $00
mov R16 , $98
...
lab_1_output: mov R17 , R5
-----------------------
lab_2_1_input: mov R18, R17


Т.е. допустим программа предусматривает переход к выполнению кодового фрагмента, начинающегося с метки lab_2_1_input только после отработки до конца фрагмента [lab_1_input;lab_1_output]

А представим , что от помехи произошёл случайный переход из произвольной точки 1-го фрагмента кода в произвольную точку 2-го фрагмента кода....

Как вы ПРОГРАММНО отлавливаете такие ситуации?

Т.е. как Вы реализовываете в своих программах для микроконтроллеров ATmega механизм защиты FLASH-памяти от несанкционированного выполнения кода. Ну т.е. как контролировать, что в данный фрагмент кода вошли не где попало, а через строго определённые на этапе проектирования программы, точки

А кто как защищает код в MCU от несанкционированного выполнения в результате случайного перехода из одной точки программы в другую от воздействия помехонесущего электромагнитного поля (искажения записанного в счётчике команд значения).

Кстати, причины такого случайного джампа могут быть не только в разрушении PC.
Может также случайным образом измениться содержимое ячейки FLASH или содержимое хранимой в ОЗУ таблицы переходов... В любом случае МОЖЕТ произойти переход в точку некоторого логического сегмента кода, которая не предусмотрена данным логическим сегментом FLASH

[Kris2007]

А че такое бывает чтобы из-за электромагнитных помех грохнулся счетчик команд?
По моему это неудачные попытки нати существующую ошибку в коде. Не нашли списали на э.м помехи.

Импульсник на 3квт делали на атмеге. Там тАкие помехи идут и все ок. Я уж не говорю о других устройствах. Если некая помеха по питанию и на пине это еще понятно но случайная запись в PC ..

Сообщение отредактировал Kris2007 - Feb 12 2008, 13:26

[Дон Амброзио]

А че такое бывает чтобы из-за электромагнитных помех грохнулся счетчик команд?

Бывает, бывает. Молодой человек. Я написал тестовую прогу для ATmega8 которая представляет собой следующее:

.cseg
.org 0
;-----------------
.set Number = 0
;-----------------
Begin_Loop :
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------------
......
......
......
;-----------------
.set Number = Number +1
ldi R16 , Number
nop
...
nop
cpi R16 , Number
breq PC+0x02
rjmp Crash
;-----------------------
rjmp Begin_Loop
;-----------------------
Crash :

; Зажечь светодиод
...

; Остановиться
;------------------------
После подачи помехи в виде электромагнитной наводки от пьёзозажигалки мне удавалось как зажечь светодиод

Импульсник на 3квт делали на атмеге. Там тАкие помехи идут и все ок. Я уж не говорю о других устройствах. Если некая помеха по питанию и на пине это еще понятно но случайная запись в PC ..

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

А с какими ты работал? Сейчас практически все AVR "такие"

Не звизди..
"Все такие" говоришь? А как же ATmega 8, 8515, 8535, 64, 128..А?

А как же ATmega 8, 8515, 8535, 64, 128..А?

В них по WDT происходит полноценный сброс, а не прерывание

Просто к моменту когда ты начал обдумывать свои "правильные" методики борьбы, человечество с этим уже работало и над этим думало не один десяток лет. И WDT оказался одним из самых эффективных методов борьбы с зависаниями и сбоями.

Дык с зависаниями или сбоями? Вы уж определитесь.. Ибо понятие "сбой" гораздо шире понятия "зависание"

раз уж ты уходишь от переписывания моей процедуры.

Странный ты.. Ну на тебе твою переделанную процедуру (хотя я же объяснял тебе выше как это сделать. Неужели для тебя это так сложно? )

...
ldi R25 , high ( Border_Counter)
ldi R24 , low ( Border_Counter)
ReadLptEPP:
sbiw R25:R24 , 1
breq Crash
sbic pinc,LptSTB ; Строб пришёл?
rjmp ReadLptEPP ; иначе повторить
...

[adc]

Странный ты.. Ну на тебе твою переделанную процедуру (хотя я же объяснял тебе выше как это сделать. Неужели для тебя это так сложно? )
...
ldi R25 , high ( Border_Counter)
ldi R24 , low ( Border_Counter)
ReadLptEPP:
sbiw R25:R24 , 1
breq Crash
sbic pinc,LptSTB ; Строб пришёл?
rjmp ReadLptEPP ; иначе повторить
...

Всегда пишу именно так, но хочу заметить что попав в результате сбоя, к примеру, на метку ReadLptEPP (не загрузив константы в регистры) можно превысить допустимое значение ожидание со всеми вытекающими из этого последствиями.
Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

[Дон Амброзио]

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

Согласен.. Просто я привык уже работать в среде мной же разработанной RTOS, где любой поток может быть вытеснен другим более высокоприоритетным потоком вообще говоря на случайное время. И как в этом случае Вы рассчитаете на сколько должен быть запрограммирован WDT? Поэтому в этом случае счётчик ограничитель количества итераций выглядит более предпочтитетельным. Тем более бывают задачи, где важно именно количество итерация цикла, а не время его выполнения

Предпочитаю использовать WDT + обязательный выход из цикла по переполнению описанный Вами.

Хорошее решение.. Но только для программ не работающих в RTOS с вытесняющей многозадачностью.
Я же использую в многозадачной среде виртуальные таймеры и WDT, которые фактически являются обратными счётчиками CPU_Time потока. Т.е. у меня любой поток может посмотреть в любой момент своё CPU_Time - время, которое бы он выполнялся если бы он были один в системе. Фактически CPU_Time - это счётчик тактов выполнения кода потока. Отсюда можно делать следующее. Вы прикидываете сколько максимальное количество тактов будет выполняться поток от точки A до точки B. Инициализируете в точке A виртуальный WDT, а в точке B его реинициализируете новым значением. Если этот виртуальный WDT обнулиться до прихода CPU в точку B потока, то это сбой и система это отработает. Кроме максимального времени работы некоторого участка кода, которое контролируется виртуальным WDT. Я ещё контролирую минимальное.. Ведь если известно, например, что подсчёт CRC 256-ти байтного пакета не может быть меньше 547788 тактов (цифры взяты просто для иллюстрации примера) и мы попадаем на точку завершения подсчёта и видим, что этот участок кода выполнился за 10790 тактов - то ясно же что имеет место сбой....

хорошо что не подрались...

Да млин, всё-таки неприятно, когда человек не врубившись "что почём" начинает меня "мордой тыкать" в такую элементарщину, что создаётся впечатление, что либо человек меня принимает за полного ламера (и это с моим-то более чем 15-ти летним опытом разработчика девайсов на базе MCU) либо сам таковым и является

может для начала определить с какими сбоими в работе мк боремся ...

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

Среди основных причин этого сбоя можно назвать следующие:
1) Случайное изменение значение счётчика команд из-за помех
2) Случайное изменение содержимого в ячейке ОЗУ в области, где храниться таблица переходов
3) Случайное изменение ОЗУ стека или указателся стека, в результате чего после команд ret/reri мы "улетаем" не пойми куда


СЮДА Я НЕ ОТНОШУ те сбои в командах перехода, когда в программе содержиться ошибка, проявляющаяся в том, что при не которых наборах данных она вычисляет не верный адрес точки перехода

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

Среди основных причин этого сбоя можно назвать следующие:
1) Случайное изменение значение счётчика команд из-за помех
2) Случайное изменение содержимого в ячейке ОЗУ в области, где храниться таблица переходов
3) Случайное изменение ОЗУ стека или указателся стека, в результате чего после команд ret/reri мы "улетаем" не пойми куда
СЮДА Я НЕ ОТНОШУ те сбои в командах перехода, когда в программе содержиться ошибка, проявляющаяся в том, что при не которых наборах данных она вычисляет не верный адрес точки перехода

Если сказать короче: здесь рассматривается сбой, проявлящийся в том, что происходит переход от одной точки программы к другой и этот переход не относиться к множеству всех возможных переходов, определённых на этапе разработки программы

Сообщение отредактировал Дон Амброзио - Feb 13 2008, 09:05

[adc]

В этой теме я рассматриваю только один вид сбоев: несанкционированное выполнение код во FLASH, вызванное аппаратным сбоем.
Этот сбой проявляется в том, что осуществляется переход в запрещённую точку секции кода , либо в разрешённую, но тогда, когда условия для выполнения этой секции кода не наступили.
Если сказать короче: здесь рассматривается сбой, проявлящийся в том, что происходит переход от одной точки программы к другой и этот переход не относиться к множеству всех возможных переходов, определённых на этапе разработки программы

Вы спрашивали почему тут все уперлись в WDT?. Объясняется это тем что это решение практически на уровни железа. Как можно программными методами отследить случайный переход на случайную точку программы? Даже если в программе большая часть функций направлена на контроль правильности выполнения кода, ни что не защитит программу от перехода на случайный адрес с последующим нарушением нормальной работы устройства.
Как мне кажется решение должно быть на уровне железа.. (внешние контролирующие устройства(тотже только внешний WDT), дублирующий контроллер(возможно выполняющий туже задачу) и т.п.) Это мое ИМХО.

[Дон Амброзио]

Как можно программными методами отследить случайный переход на случайную точку программы?

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

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

Согласен, что программа от таких сбоев не защищает, но она может помочь в их обнаружении и оповещении о них.

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ

Как мне кажется решение должно быть на уровне железа.. (внешние контролирующие устройства(тотже только внешний WDT), дублирующий контроллер(возможно выполняющий туже задачу) и т.п.) Это мое ИМХО.

Моё ИМХО такое же.. Но всё же лучше "соломки подстелить". Ибо лучше перебдеть, чем недобдеть

За темой следить не вижу ни малейшего смысла.

А я никого и не заставляю читать эту тему или чтото писать в ней. Так же как оставляю за собой право НЕ ЧИТАТЬ и НЕ ОТВЕЧАТЬ в неинтересных мне темах

[galjoen]

Согласен, что программа от таких сбоев не защищает, но она может помочь в их обнаружении и оповещении о них.

Ибо нафига мне "суперпупернадёжная" система, у которой происходит один сбой в год, но он НЕ ОБНАРУЖИВАЕТСЯ СИСТЕМОЙ. Я лучше возьму систему, у которой сбои происходят каждый день, ну у которой эти сбои НЕ ПРОХОДЯТ НЕЗАМЕЧЕННЫМИ СИСТЕМОЙ

+1

Как можно программными методами отследить случайный переход на случайную точку программы?
Я от этого контролем данных защищаюсь - см. мой предыдущий пост. Подсчётом их CRC, сравнением с инверсией и т.д.
ИМХО в случае несанкционированного перехода, данные и в регистрах и в ОЗУ, несоответствующие программе будут.
Это не 100% конечно. Но и CRC у порченных данных тоже совпасть может!
А если программа хотя-бы диапазоны данных проверяет - то и больших бед не натворит. И восстановиться потом можно будет!