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

[Liseev]

А как вы будете защищать "механизм защиты от несанкционированного выполнения"?
А механизм защиты механизма защиты?
А от прямого попадания молнии?

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

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

Используйте WDT от "случайных" зависаний

ИМХО, "случайные зависания" в граммотно разработанной программе невозможны так что и необходимость применения WDT практически равна нулю

проверяйте CRC программного кода

Проверяю

Здесь эта тема броде бы обсуждалась

Обсуждалась...А отслеживаю темы подобной тематики

[SasaVitebsk]

ИМХО, "случайные зависания" в граммотно разработанной программе невозможны так что и необходимость применения WDT практически равна нулю

Liseev писал вам правильно, а вы наводите тень на плетень. Естественно, ни о каких программных зависаниях речь не может идти. Но "зависание", как таковое, это не бездействие процессора. Если процессор "завис" после помехи или сбоя - это значит он попал в какой то цикл. Причём цикл обычный, "правильный", только в "неправильное" время. Из этого состояния его и вытягивает WDT.

Предложу вам свой метод вставки WDT.

1) Программа отлаживается полностью без WDT.
2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).
3) Определяется минимальное время, достаточное для работы без "вылета".
4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)
5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.
6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

Тестируется.

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

Liseev писал вам правильно, а вы наводите тень на плетень.

Странный у вас метод ведения дисскусии

Но "зависание", как таковое, это не бездействие процессора.

Да что Вы говорите...Прям открытие для меня сделали..А я прям не знал

Если процессор "завис" после помехи или сбоя - это значит он попал в какой то цикл. Причём цикл обычный, "правильный"

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):
В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

Предложу вам свой метод вставки WDT.

1) Программа отлаживается полностью без WDT.
2) Анализируется текст программы. Выявляются минимальное число мест, где нельзя обойтись без сброса WDT. Надо чётко понимать, чем больше вы ввалите WDR, тем ниже вероятность выведения проца из ступора после сбоя (выше вероятность, что он зациклится там, где предусмотрен WDR).
3) Определяется минимальное время, достаточное для работы без "вылета".
4) Анализируются прерывания. (Здесь кто-то предлагал ставить WDR в регулярных прерываниях. На мой взгляд это возможный, но не самый лучший вариант)
5) В местах установки вами WDR желательно программно анализировать остальные параметры работы программы. Например известные признаки разрешения прерываний, максимальная длительность нахождения программы в том или ином цикле и так далее.
6) Программа инициализации должна анализировать состояние и причину сброса. Должна обеспечивать полную инициализацию всего используемого оборудования, включая умолчания. Сама инициализация должна проводится максимально быстро либо обеспечивать "теневую" работу. Иными словами, в оптимале, чтобы пользователь не замечал пересброса системы.

И как всё это можно применить в многозадачной среде RTOS?
http://electronix.ru/forum/index.php?showtopic=43223

[SasaVitebsk]

Ещё раз повторяю (Вы что не читатель? Почему я должен повторять?):
В правильно разработанной (грамотной) программе таких циклов (а значит и зависаний) быть не может!!!

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

Ладно попытаюсь вам объяснить.

Представьте себе правильно написанную программу, которая отработана и не содержит не единой ошибки. В ней находится следующий текст например:

Код

...
ReadLptEPP:
    sbic    pinc,LptSTB    ; Строб пришёл?
    rjmp    ReadLptEPP    ; иначе повторить
    sbic    pine,WRITE    ; Если запись HOST, то продолжить
    rjmp    errLptEPP    ; иначе ошибка
    in        wl,ILPT        ; ввод данных в wl
    sbi        portc,WAIT    ; подтвердить
rwaitNoLptSTB:
    sbis    pinc,LptSTB    ; Строб сняли?
    rjmp    rwaitNoLptSTB; иначе повторить
    cbi        portc,WAIT    ; подтвердить
    ret
...

Теперь представьте себе что произошёл сбой в работе процессора и программа попала в ReadLptEPP либо rwaitNoLptSTB. Не по логике работы программы, а по сбою. Если для вас это непонятно, то представьте, что произошла ошибка во время перехода процессора, либо во время сбоя исказился PC, либо исказился стек и произошёл возврат не туда. Ну что доступно объясняю? Более того чтобы не исказилось и кудабы проц не пошёл, то он заткнётся в каком-нибудь цикле!!!! Это то понятно? В любой программе правильно написаной десятки либо тысячи циклов. Что тут непонятно? Но если ваша программа, например, сидит в цикле ожидания символа из UARTа, а он туда не должен придти, по той банальной причине, что вы не делали запроса и не потому что программа неправильно написана, а потому, что произошёл сбой и программа попала туда, куда не должна была попасть.

Что тут не ясно?

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

Что тут не ясно?

Мне всё ясно... Вы привели продемонстрировали сейчас КАК НЕ НАДО ПИСАТЬ ПРОГРАММЫ на примере неправильной организации программы..Я Вам еще раз повторяю: в граммотно спроектированной программе вечных циклов быть не должно не при каких искажениях данных и регистров!!!!

во время сбоя исказился PC, либо исказился стек и произошёл возврат не туда

Вот в этом, собственно, и вопрос темы. Как спроектировать программу, чтобы она детектировала приведённые Вами явления. Надеюсь из моих объянений и примеров Вы поняли, что Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны


Хочу заметить, Господа что я прекрасно себе представляю, что [u]абсолютно все случаи несанкционированного использования кода программно обнаружить невозможно[/u] (а может есть MCU с аппаратной реализацией деления и защиты кода во FLASH?).

Такой команды у AVR нет.

Согласен.. описАлся

Если это в основном цикле

Какой ещё основной цикл в многозадачной многопоточной среде RTOS? И там стеков не один, а несколько...Причём как стеки PC, так и стеки данных

[SasaVitebsk]

Мне всё ясно... Вы привели продемонстрировали сейчас КАК НЕ НАДО ПИСАТЬ ПРОГРАММЫ на примере неправильной организации программы....

Надеюсь из моих объянений и примеров Вы поняли, что Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны
Хочу заметить, Господа что я прекрасно себе представляю, что [u]абсолютно все случаи несанкционированного использования кода программно обнаружить невозможно[/u] (а может есть MCU с аппаратной реализацией деления и защиты кода во FLASH?).

Простите пожалуйста О ВЕЛИКИЙ.
Мне надо ещё долго учиться правильности написания программ. А также правильности её организации.
Да вот ещё незадача - разработчики компилятора C IAR (а я по своей дурости его использую как и тысячи других ещё вами не просвещённых) в своих библиотеках тоже совершенно безграмотно пишут. Например при обращении к EEPROM. Безусловно надо всё переписать. Завтра же возьмусь. Правда придётся заказывать новые чипы, так как новый правильный код в старые увы не влезет.

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

С уважением,
ваш почитатель.

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

Простите пожалуйста О ВЕЛИКИЙ.
Мне надо ещё долго учиться правильности написания программ. А также правильности её организации.
Да вот ещё незадача - разработчики компилятора C IAR (а я по своей дурости его использую как и тысячи других ещё вами не просвещённых) в своих библиотеках тоже совершенно безграмотно пишут. Например при обращении к EEPROM. Безусловно надо всё переписать. Завтра же возьмусь. Правда придётся заказывать новые чипы, так как новый правильный код в старые увы не влезет.

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

С уважением,
ваш почитатель.

А Вы ещё ИАРу напишите, что у них неправильный ИАР...

А вообще "нЕчего на зеркало пенять коли рожа кривая"(с) Если Вы не хотите чуть-чуть больше подумать на стадии проектирования программы, то тут уже Вам не ИАР, не Atmel ни кто-либо ещё уже не поможет

Кстати, Господа!! Хочу заметить вот что:

1) Вы мне хорошо расписали необходимость применения WDT в простейшей программе типа СуперЛуп и даже объяснили, где лучше вставлять команду сброса WDT для этого случая... Но при этом ничего не сказали о специфике применения WDT для случая многопоточных приложений в вытесняющей RTOS
2) Что можно применить кроме WDT высказлся только Непомнящий Евгений, а что же остальные?

Да и завтра же отпишусь на Atmel, Intel, Dallas, Philips, TI и прочие конторы, что для правильно написанной программы "Watchdog тут поможет также как козе пятая нога, ибо в граммотно спроетированной программе вечные циклы невозможны".

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