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

[Schtirlitz]

Надо отделить мух от котлет. Ибо проблема надежности устройства не ограничивается только ПО микроконтроллера. Если у вас программные сбои происходят от разряда пьезозажигалки, то программа тут совершенно не причем- все проблемы решаются правильной трассировкой. Для этого и существуют испытания на ЭМС и разные группы жесткости устройств.

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

Вероятность отказа устройства 10 в минус 9 степени - это попахивает авиацией, резервированием и прочими усложнениями:-))
Для "гражданских" устройств 10 в минус 5 степени уже хорошо.

Сообщение отредактировал Schtirlitz - Feb 13 2008, 09:32

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

Надо отделить мух от котлет. Ибо проблема надежности устройства не ограничивается только ПО микроконтроллера. Если у вас программные сбои происходят от разряда пьезозажигалки, то программа тут совершенно не причем- все проблемы решаются правильной трассировкой. Для этого и существуют испытания на ЭМС и разные группы жесткости устройств.

Я в курсе. Но повторю:
Как говорится: лучше перебдеть, чем недобдеть.

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

[Schtirlitz]

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

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

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

А как быть с вероятностью сбоя программы обнаружения сбоев?

А для этого я использую такую организацию кода, когда все участки друг друга тестируют. Т.е. когда вся программа предстваляет собой как бы детектор сбоев и вся её организация направлена на то, чтобы как можно раньше определить наличие и причину сбоя. Хотя конечно разумеется никакие программные навороты не дадут 100% обнаружения сбоев.

Не нужно изобретать велосипед: если нужна вероятность отказа устройства 10 в минус 9-й степени - применяйте резервирование, мажоритарные схемы итд.

Я в курсе.

Но даже если Вы грамотным проектированием железа сделаете вероятность сбоя 10 в минус 15-й, то всё равно используя программые методы можно ещё увеличить такой параметр надёжности как вероятность обнаружения имевших места сбоев

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

И как же ? По вашему мнению?


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

Возвращаясь к первоначальному вопросу могу посоветовать применить при написании программы теорию графов.
Нужно нумеровать состояния программы. При переходе в новое состояние, анализировать предыдущее и т.д.
На практике ввести переменную STATE, задавать ей значение только перед переходом в новое состояние.

Спасибо... Что-то подобное и делаю, только использую не STATE а регистр кода доступа к логическому сегменту