Защита секция кода во 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

[Rst7]

А у вас как с ЭМС? С наносекундными импульсами? Если скажете, что от них не сбивается (класс A) - не поверю!!!

У меня стандарт на оборудование (EN54) требует не сбиваться, максимум - кратковременное нарушение индикации (ну типа, когда статразряд влетает в светодиод, он подмигивает ). И работает.

[galjoen]

У меня стандарт на оборудование (EN54) требует не сбиваться, максимум - кратковременное нарушение индикации (ну типа, когда статразряд влетает в светодиод, он подмигивает ). И работает.

Рискну предположить, что у вас всё работает из-за того, что всё это достаточно большое, и в железном корпусе. Я это условие как-то в том посте упустил.
У меня-то пластмассовый корпус 120*60*32 мм. И когда они этот гвоздик, в котором 8 кВ за единицы наносекунд нарастает, к корпусу подносят (к разным местам), то до процессора и других микросхем - от него менее 15 мм расстояние. Это почище той зажигалки, которой Дон Амброзио свои процессоры тестирует. Пробовали экраны металлические делать - эффект 0-й, а удорожание не 0-е. И всё равно это не поможет т.к. кабеля-то наружу торчат. От них тоже сбивается.

Но всё само восстанавливается (класс B )

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

У меня тоже бутлоадер есть в области загрузчика. Перед тем как программировать я CRC переменных проверяю. Согласен, что защита не 100%. Может ведь и после проверки прыгнуть. Но 99.9%. А если быть точным - то отношение кол-ва команд с которых бутлоадер несанкционированно запустится к 65536 (столько слов у AVR с 128 в конце).

[defunct]

Может ведь и после проверки прыгнуть. Но 99.9%. А если быть точным - то отношение кол-ва команд с которых бутлоадер несанкционированно запустится к 65536 (столько слов у AVR с 128 в конце).

угу, прыжек же "случайный" можно папасть в любую точку, по законам Мерфи попадем ровно на erase sequence после всех проверок. Защититься тут никак нельзя, а вот предотвратить "командировку для устранения последствий" - можно. Например, можно хранить копию основной прошивки во внешней eeprom'ке, при старте бутлоадером проверить CRC прошивки, если не совпадает - то попытаться загрузить прошивку из внешней eeprom.

Я собсно хочу отметить, что задача автора ветки - нерешаемая. Ее можно только обойти, но не решить.