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

[Rst7]

Если 2-й параметр MCU и имеет такой же примерно порядок величины как , например, резистор. То первый хуже в 100 000 раз и более.

Откуда такая цифра? Пожалуйста, опишите методику ее получения.

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

А по поводу стороны проблемы затронутой Rst7 вот есть полезная статейка

А вот Вам полезная статейка http://www.referatik.com.ua/subject/67/30320/?page=2

Цитата оттуда:"Предварительные исследования показали, что для элементной базы
среднего качества (надежность 0.999 - “три девятки после запятой”) при
оптимальном сочетании скорости получения результата на его надежность в
вычислительной среде теоретически достижима достоверность получения
правильных результатов машинного счета в “двести девяток после запятой” при
замедлении темпа их получения в 300-400 раз [1], что эквивалентно
увеличению надежности до 200 порядков величины при введении сравнительно
небольшой вычислительной избыточности, приводящей к потере
производительности не более чем на 2-3 порядка, что уже на современном
уровне может компенсироваться подбором компьютеров требуемой
производительности."

Откуда такая цифра? Пожалуйста, опишите методику ее получения.

Моя программа инсталлирована более чем на 11000 девайсах. За 2,5 года эксплуатации сетей с моими девайсами было программами, зашитыми в них, было обнаружено порядка 170 000 сбоев, которые были программой же устранены (эту цифру взял из логов, которые регулярно раз в неделю смотрит обслуживающий персонал и заносит эту инфу в спец.журнал). За это же время вышло из строя 5 девайсов. Но в них вышел из строя не процессор. Из чего и следует эта цифра "более 100 000"

Моя программа инсталлирована более чем на 11000 девайсах. За 2,5 года эксплуатации сетей с моими девайсами было программами, зашитыми в них, было обнаружено порядка 170 000 сбоев, которые были программой же устранены (эту цифру взял из логов, которые регулярно раз в неделю смотрит обслуживающий персонал и заносит эту инфу в спец.журнал). За это же время вышло из строя 5 девайсов. Но в них вышел из строя не процессор. Из чего и следует эта цифра "более 100 000"

Причём это сбои именно из-за ЭМС. Потому что у нас в лаборатории постоянно гоняется уже 2,5 года таже сеть из 87-ми девайсов, но только "на столе" без воздействия ЭМС. За 2,5 года было только 13 сбоев, обнаруженных системой... Так что программная защита от незамечания сбоев реально работает

было обнаружено порядка 170 000 сбоев, которые были программой же устранены (эту цифру взял из логов, которые регулярно раз в неделю смотрит обслуживающий персонал и заносит эту инфу в спец.журнал).

Разумеетцо велось и взаимо тестирование девайсов, когда девайс не отвечал другому девайсу (например кварцевый генератор в девайсе от мороза не запустился) или отвечал не правильно. Для этого случая тоже велись свои логи и они в цифру "170 000" не вошли

[galjoen]

Опять же, дело в цене вопроса. И если не трогать CALL / JMP, то остается проблема избавления от LDS/STS. Тоже, имхо, решаемая за счет использования LDD/STD. Но,блин, асм...

Итак от LDS/STS избавились!!! (исправил - спасибо '_Pasha')
CALL / JMP - тоже исправимо!!!
Заменой на rjmp. Не реже, чем через каждые 4 кслова (чтоб rjmp дотягивался) ставим ещё один rjmp. И переходим через последовательность rjmp. Например так:
rcall m2proc ;(proc-PC)>4096, а вот (m2proc-PC)<4096
....;
m2proc: rjmp m1proc ; (m1proc-m2proc)<4096
....;
m1proc: rjmp proc ; (proc-m1proc)<4096
....;
proc:
...
ret
На асме это можно сделать с помощью макрокоманд с условной трансляцией. А компилятор C - переделать так, чтоб он про CALL / JMP "забывал". В смысле опцию компилятора такую создать.
Всё это шутка конечно, но в каждой шутке...

А вообще тут уместно будет басню Крылова вспомнить. Лиса и виноград называется. ИМХО многие на методы защиты, здесь поднятые потому ополчились - что сами этого не делают. И базу подводят - мол это я не делаю не потому, что не могу (не додумался, лень, руки кривые). А из идейных соображений!!! И намёками понять дают, что тем кто что-то такое использует - стыдно за это должно быть.

[_Pasha]

[b]Итак от LDD/STD избавились!!!

* LDS/STS. Исправьтесь, пока не поздно, а то запинают.
Короче, кривое выпрямляется, становится подобно пикам. Но получше, получше...
З.Ы. А с длинными джампами - проблема. На больших программах - сплошной изврат.
Я вот думаю, если все крутится под многопотоком, проще переделать выход из потока, чем совать rjmp куда ни попадя

Сообщение отредактировал _Pasha - Feb 18 2008, 11:15

[Guest_Serg79_*]

Да, есть такая проблема и называется она безопасность программного обеспечения. Способы ее решения зависят от работы девайса.

На данный момент, мы вчастности работаем над этой проблемой. Но сразу оговарюсь, доказательство безопасности мы еще не прошли, но предварительные слушанья показывают, что данные принципы имеют право на жизнь :-) .

Чтобы было понятно, опишу немного пинцип работы девайса. Девайс висит на линии связи и ждет команды. По приходу команды он ее выполняет и отсылает ответ со своим состоянием. Вроде бы, что может быть проще. А нет, у заказчика возникает вопрос, а если ваша система сойдет с ума и начнет немного шалить, т.е. ей приходит команда сделай шаг вперед а она, собака такая, берет и делает два шага назад или наоборот ничего неделает, а в линию связи, эта скотина, отсылает ответ что выполнила команду правильно. Вы можете утверждать с пеной у рта, что этого не может происходить потому что это из области фантастики, НО ВЫ НИКОГДА НЕ ДОКАЖЕТЕ ЭТО СО 100 ПРОЦЕНТНОЙ ВЕРОЯТНОСТЬЮ (случаи перерубания топором проводников питания не расматриваются :-) ). Кстати, заказчик тоже технически грамотный и знает, что со 100 процентной вероятностью этого никто не докажет, поэтому он требует, чтобы вероятность того что система сойдет с ума а со стороны будет казаться что она вполне даже разумна была не выше 10 в -8 степени.

И так, теперь как это технически реализовывается. Система двух процессорная, каждый процессор висит на своей линии связи (физически получается две линии связи), между процессорами организована линия обмена данными.

Теперь, как работает эта система:
1 - по линии связи приходит команда.
2 - процессор проводит тестирование внутрених узлов микропроцессора (из первого набора функций).
3 - производится межпроцессорный обмен.
4 - выполняется команда.
5 - процессор проводит тестирование внутрених узлов микропроцессора (из второго набора функций).
6 - отсылается ответ в линию связи.

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

Теперь постораюсь каждый пункт описать более подробно:
1) По приходу команды происходит проверка адреса в заголовке пакета (на одной линии висит несколько девайсов). Происходит проверка команды на пренадлежность ее ко множеству всех допустимых команд. Проверяется контрольная сумма пакета. Если все условия выполняются, то команда передается дальше по цепочке.
2) Происходит тестирование внутренних узлов микроконтроллера. К тестам внутренних узлов микроконтроллера относятся (в порядке выполнения): тест безусловных переходов (команды 'jmp', 'call' и т.д.), тест условных переходов и регистра 'SREG' ('brcs' и все ему подобные, также включает в себя проверку всех команд оперирующих с битами регистра 'SREG', 'clz' и все ему подобные), тест первой половины регистров общего назначения (РОН) (к ним относятся те регистры, которые компилятор GCC позволяет изменять при вызове функций без востанавления их первоначального состояния "r18-r27", "r30-r31"), тест второй половины регистров общего назначения ("r0-r17", "r28-r29"), тест оперативной памяти, проверка 'CRC' flash-памяти содержашей код программы, тест группы команд логических операций, тест группы команд арифметических операций, тест групы команд пересылки данных, тест АЦП (на двух точках контрольного напряжения), тест таймеров (удостоверямся что они шелкают в соответствии с установлеными делителями).
3) При межпроцессорном обмене происходит обмен поступившей командой, а также флагами прохождения тестов узлов микроконтроллера.
4) Выполняем команду.
5) Все тоже самое что в пункте 2, только вторым набором функций тестирования. Это сделано для того что бы, если по какой то причине тест из первого набора даст ложное 'OK' на ошибку, то тест из второго набора сможет зафиксировать данную ошибку (звучит глупо, но иногда это срабатывает :-) ).
6) Вот сдесь мы можем утверждать, что у нас все хорошо с заданной вероятностью. О чем и попытаемся сказать в линию связи. :-)

Сделаю несколько замечаний:
1 - Не прохождение тестов из пункта 2 и 5 приводит к переводу устройства в защитный отказ (это такой отказ из которого система недолжна выходить даже при сбросе и востановлении питания).
2 - Не следует сразу же входить в защитный отказ при непрохождении какого то одного из тестов (например: тест оперативной памяти), мы используем счетики непрохождения тестов и если они переполняются то уже переводим устройство в защитный отказ. Это обусловленно тем что микропроцессору свойственно изредка подглючивать, особенно в сложной электромагнитной обстановке. И еще, удачное прохождение теста не должно сразу сбрасывать данный счетчик в нуль, мы обычно делаем так: при ошибки счетчик увеличивается на два, при прохождении теста счетчик уменьшается на один. До скольки расти счетчику, решать Вам.
3 - Если представленная выше цепочка пунктов не выполняется в течении 'n-го' времени то система переводится в безопасное состояние. Выход из безопасного состояния в рабочее происходит по выполнению всех пунктов данной цепочки. Обычно это происходит если одна из линий связи обрывается и соответственно один из процессоров не получает команды, это обнаруживается на межпроцессорном обмене.
4 - По возможности все данные программы которые сохраняют свои значения между вызовами функций должны формироваться динамически. Например, флаги прохождения тестов формируются динамически и если какой то из тестов не прошел, то это будет отловленно на межпроцессорном обмене. Так же в пакет команды и ответа по линии связи надо вводить постоянно изменяемое поле для того, что бы это приводило к изменению контрольной суммы. Да и вообще статические данные склонны к накоплению ошибок.

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

P.S. Все что описано выше нельзя расматривать как руководство к построению безопасного программного обеспечения, т.к. ПО построеное на данных принципах еще не получило заключение экспертизы, потверждающее его безопасность.

И еще, прежде чем что либо доказывать, проводиться привязка программного продукта к классу который напрямую связан с тяжестью состояния оказа. Вот например какое разделение по классам производится стандартом для сертификации бортового авиационного ПО согласно RTCA DO-178B (или его европейского аналога EUROCAE ED-12B):
A ) Катастрофическое - состояние, не совместимое с безопасным полетом и посадкой.
B ) Опасное - состояние, при котором функциональные способности летательного аппарата (ЛА) или способности экипажа справляться с неблагоприятными условиями управления достигают нижних пределов безопасности. Экипаж не может выполнять свои задачи аккуратно и полностью.
C ) Существенное - состояние, при котором функциональные способности ЛА или способности экипажа справляться с неблагоприятными условиями управления снижены до существенных пределов. Имеет место существенное увеличение нагрузки на экипаж или ухудшение эффективности работы экипажа.
D ) Несущественное - состояние, не приводящее к значительным потерям безопасности управления ЛА.
E ) Не влияющее - состояние, никак не влияющие на способности управления ЛА.

Уже начинаете чувствовать, что не все так просто :-) . Так что на этом фоне все высказывания типа: "'watchdog' панацея от всех твоих проблем", в самом общем случае вызывает улыбку.

[Rst7]

Моя программа инсталлирована более чем на 11000 девайсах. За 2,5 года эксплуатации сетей с моими девайсами было программами, зашитыми в них, было обнаружено порядка 170 000 сбоев, которые были программой же устранены (эту цифру взял из логов, которые регулярно раз в неделю смотрит обслуживающий персонал и заносит эту инфу в спец.журнал). За это же время вышло из строя 5 девайсов. Но в них вышел из строя не процессор. Из чего и следует эта цифра "более 100 000"

Причём это сбои именно из-за ЭМС.

Проведите испытания на ЭМС согласно стандарту. Будете приятно удивлены. Судя по цифрам какие-либо меры противодействия помехам отсутствуют начисто.

А вообще, если не секрет, где Вы работаете и что это за устройства?

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

Что я понимаю под надёжностью программы.
Надёжность программы - это свойство программы выполнять свои функции в условиях "помех" (некорректные данные и сигналы, поступающие извне, случайные изменения ячеек ОЗУ, FLASH, случайные JMP и CALL, вызванные воздействием помехонесущих полей на внутренние микроконтроллера и т.д.)
Аксиома №1. 100% -ая надёжность программы не достижима
Аксиома №2. Надёжность программы влияет на надёжность всего устройства в целом


Все причины низкой надёжности программы можно разделить на 3 класса:
1. Ошибки и недочёты при разработке алгоритма (например, не учли в алгоритме возможность случайного джампа на процедуру записи во FLASH). Эти ошибки вызваны недостаточным пониманием архитектуры MCU, для которого пишется программа и не понимание как ведёт себя этот MCU в условиях внешних воздействий
2. Ошибки и недочёты на этапе кодирования алгоритма на том или ином языке (например вместо команды CBR написали SBR в случае написания программы на ассемблере
3. Ошибки в программных инструментах, использованных при разработке Вашей программы (например глюк компилятора) или неправильное использование программных инструментов, вызванное не пониманием того, для чего они предназначены и как они работают

Сообщение отредактировал Дон Амброзио - Feb 18 2008, 11:35

[_Pasha]

Сделаю несколько замечаний:
1 - Не прохождение тестов из пункта 2 и 5 приводит к переводу устройства в защитный отказ (это такой отказ из которого система недолжна выходить даже при сбросе и востановлении питания).

Непонятно... И что - в линию связи не говорит, мол "чувак, не могу, болею" ?

Теперь про менее ответственные применения.
Есть еще общий таймаут связи, радикально помогает во многих случаях. Т.е. команды долбятся постоянно. Перерубили провод - все, извини...

[zltigo]

Девайс висит на линии связи и ждет команды. По приходу команды он ее выполняет и отсылает ответ со своим состоянием.

На К ВЫХОДАМ девайса подключен контролирующий девайс отсылающий в дополнение к рапорту управляющего девайса в линию связи свое видение выданного управляющим девайсом выходного воздействия. Все. Максимальная степень достоверности. Возможно легкое дальнейшее повышение степени достоверности наращиванием числа контролирующих девайсов. Возможно упрощение системы, когда контролирующего девайса нет, но есть контролирующий процесс, который перехватывает ображения уже непостедственно к исполнительном железу, и уже он отправляет рапорт о состоянии.
То, что изложено автором напоминает ответ на вопрос "кто шил костюм" - "к пуговицам претензии есть?"
"Вы исполнили команду?" - "Перед тем, как мы попытались выполнить присланную команду претензий к исполнению команд JUMP контроллером не было".

[galjoen]

З.Ы. А с длинными джампами - проблема. На больших программах - сплошной изврат.
Я вот думаю, если все крутится под многопотоком, проще переделать выход из потока, чем совать rjmp куда ни попадя

Ну люблю-люблю я извращения!
Как вам мой 2й вариант замены call на следующую последовательность команд:
ldi R16,low(mRet) ; только в случае call - для jmp не ставим
push R16 ; только в случае call - для jmp не ставим
ldi R16,high(mRet) ; только в случае call - для jmp не ставим
push R16 ; только в случае call - для jmp не ставим
ldi R16,low(mCall)
push R16
ldi R16,high(mCall)
push R16
ret ; Это вместо call - тапереча так будет. jmp заменить проще - 4 первых команды выкидываются.
mRet:
....
mCall:
...
ret
Это вообще и в асм(.macro) и в С(#define) запросто включается!
А где тут патенты-то выдают, вы говорите?

[_Pasha]

На К ВЫХОДАМ девайса подключен контролирующий девайс отсылающий в дополнение к рапорту управляющего девайса в линию связи свое видение выданного управляющим девайсом выходного воздействия. Все. Максимальная степень достоверности.

Что особенно полезно, когда оба девайса находятся рядом или питаются от одного питальника. Концепция - железная. А в исполнении - нет предела маразму. Ну и тема, однако...

2galjoen: да, пользуем все это.

Сообщение отредактировал _Pasha - Feb 18 2008, 11:51

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

А где тут патенты-то выдают, вы говорите?

[Guest_Serg79_*]

На К ВЫХОДАМ девайса подключен контролирующий девайс отсылающий в дополнение к рапорту управляющего девайса в линию связи свое видение выданного управляющим девайсом выходного воздействия. Все. Максимальная степень достоверности. Возможно легкое дальнейшее повышение степени достоверности наращиванием числа контролирующих девайсов. Возможно упрощение системы, когда контролирующего девайса нет, но есть контролирующий процесс, который перехватывает ображения уже непостедственно к исполнительном железу, и уже он отправляет рапорт о состоянии.
То, что изложено автором напоминает ответ на вопрос "кто шил костюм" - "к пуговицам претензии есть?"
"Вы исполнили команду?" - "Перед тем, как мы попытались выполнить присланную команду претензий к исполнению команд JUMP контроллером не было".

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

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

Что особенно полезно, когда оба девайса находятся рядом или питаются от одного питальника. Концепция - железная. А в исполнении - нет предела маразму. Ну и тема, однако...

2galjoen: да, пользуем все это.

А Вы думаете что раз они находяться на одной плате и питаються от одного источника, то они непременно ОБА сглюканут ОДНОВРЕМЕННО и причём у обоих будет ОДИН И ТОТ ЖЕ глюк?

[zltigo]

Вы знаете, нас уже не волнует что происходит вне нашей железяки...

Вот я и говорю - "к пуговицам претензии есть?" А на вопрос "кто шил костюм" или кто проектировал СИСТЕМУ ответов не будет.