STM32 Как прошивке проверить целостность самой себя?

[Солнцеворот]

Есть некоторые типы устройств, к которым ГОСТы предъявляют высокие требования безопасности. Одно из требований - чтобы при запуске устройство проверяло целостность своей прошивки, и если кто-то или что-то внесло в нее несанкционированные изменения, программа не запускалась бы.

Возникают вопросы:
1. При включении устройства, первым делом программа принимается вычислять CRC самой себя - берет значение по адресу 0x8000000, потом следующее и т.д. до конца прошивки.
1а. Как надежно определить, где конец прошивки?
2. Вычислив CRC самой себя программа должна сравнить полученное значение с эталонным, и если контрольная сумма совпадает, то продолжить выполнение программы.
2а. Где хранить эталонное значение CRC, с которым нужно сравнивать вычисленное? При условии, что если это значение поместить в тело прошивки, это изменит и само значение - змея ест свой хвост.

Наверняка кто-нибудь с форума уже решал такую задачу, поделитесь опытом, как вы это делали?

[Eddy_Em]

Определить конец прошивки поможет переменная из линкер-скрипта. Где-нибудь в секции text сохраняй контрольную сумму: на этапе сборки она будет равна нулю, а потом скриптом посчитаешь и впишешь (можно переводить опять). Прошивка при вычислении контрольной суммы пусть само значение суммы пропускает.

[Муркиз]

А что мешает "левой" пришивке иметь скорректированную CRC ?

[Солнцеворот]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=3982453#p3982453"]Определить конец прошивки поможет переменная из линкер-скрипта. Где-нибудь в секции text сохраняй контрольную сумму: на этапе сборки она будет равна нулю, а потом скриптом посчитаешь и впишешь (можно переводить опять). Прошивка при вычислении контрольной суммы пусть само значение суммы пропускает.[/uquote]
Спасибо. Ничего не понял.

[Eddy_Em]

Солнцеворот, если ты ничего не понял из сказанного, то встает вопрос: а как ты вообще эти прошивки собираешь?

[VladislavS]

[uquote="Солнцеворот",url="/forum/viewtopic.php?p=3982449#p3982449"]Где хранить эталонное значение CRC[/uquote]В таблице векторов прерываний есть "пропуски". Вот там и хранить длину прошивки. CRC можно в конце, а можно там же - по вкусу.

[Andrey_B]

[uquote="Солнцеворот",url="/forum/viewtopic.php?p=3982449#p3982449"]2а. Где хранить эталонное значение CRC, с которым нужно сравнивать вычисленное? При условии, что если это значение поместить в тело прошивки, это изменит и само значение - змея ест свой хвост.[/uquote]
Храните CRC не в теле прошивки, а рядом. От самопроизвольного искажения данных во флеш это спасет (не важно, что будет искажено, прошивка или сама эталонная CRC). Если же беспокоитесь о злоумышленниках, то штатная защита от считывания не даст им модифицировать прошивку, только переписать полностью. Ну а в этом случае никакая защита не поможет.

[Муркиз]

Что-то не доводилось видеть для них инкрементных обновлений....

[afz]

1. Конец прошивки проще всего определить по глобальному символу. Или поместить последней секцией специальную секцию из одного слова, или сочинить скрипт для линкера, возможны варианты...
2а. Где угодно. Подобрать КС прошивки так, чтобы с учетом этой КС общая КС вышла какой-нибудь константой, например, 0xFFFF. Для многих алгоритмов CRC, если первоначально занести в ячейку для CRC ноль, дополнение этой CRC до 1, положенное в ячейку для CRC, вместо нуля, даст в итоге CRC == 0xFFFF. То есть, пускаем программу под отладчиком, вот она стала по плохой CRC, смотрим в регистре, какая получилась CRC, делаем ей NEG и полученное число заносим в ячейку для CRC. Пробуем еще раз, если что-то не сходится, разбираемся...

[uquote="Муркиз",url="/forum/viewtopic.php?p=3982524#p3982524"]А что мешает "левой" пришивке иметь скорректированную CRC ?[/uquote] Для этого нужно, как минимум, глубоко вникнуть в программу. Тут, конечно, возникают разные сложности. Что можно порекомендовать? Маскировка, нестандартный алгоритм CRC. Да и вообще, не допускать попадания программы в открытом виде в руки злоумышленников. Запретить считывание кода из МК, передача программы в шифрованном виде, ключ дешифровки должен лежать в нечитаемой извне флеш-памяти программы...

[Солнцеворот]

Спасибо большое всем, кто ответил по-существу. Я когда найду достойное решение этой задачи, расскажу здесь, как в итоге сделал.
[uquote="afz",url="/forum/viewtopic.php?p=3986609#p3986609"]или сочинить скрипт для линкера[/uquote]
Можете дать ссылку, где почитать, как это делается?

[BOB51]

Не обязательно от злоумышленника - но в любом случае контроль случайных дефектов ПЗУ в ответственной аппаратуре.

[Муркиз]

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

Я длч этого периодически запускал контрольный расчет с известным результатом.

[Andrey_B]

[uquote="Муркиз",url="/forum/viewtopic.php?p=3991002#p3991002"]Я длч этого периодически запускал контрольный расчет с известным результатом.[/uquote]

И как, встречались прецеденты искажения прошивки ? Какие внешние условия, что за процы ?

[BOB51]

Лучше заранее перестрахериться...
У Микрощипа достаточно полная документация по возможным отказам и противодействию оным.
В частности - отказы главного генератора МК (позднее даже был введен специальный аппаратный модуль для контроля).
Чем более "нежные" технологии(малое энергопотребление, уменьшение размера кристалла при повышении плотности упаковки элементов), тем выше вероятность воздействия "грубой внешней силы" - температуры, мощные внешние электростатические/электромагнитные поля, направленные потоки ВЧ излучений, ИК излучение (ИК-прозрачные корпуса)...

[tonyk]

И как, встречались прецеденты искажения прошивки ? Какие внешние условия, что за процы ?

На практике сталкивался с ситуацией, когда расшивался один бит во всей микросхеме. Случаи были единичными, но крови мне попортили много. Программеры божились, что считают КС прошивки непрерывно, но оказалось, что забыли посчитать таблицу с векторами переходов из-за чего формировались или не формировались команды управления. Расшивка происходила не сразу, а через несколько дней работы контроллера. Использовались внешние УФ и флэш микросхемы памяти. Так что для ответственных применений нужно непрерывно считать КС, а не тупо при старте контроллера. В идеале перед каждым циклом сканирования программы (терминология ПЛК) нужно проверить КС, и только потом начать выполнение программы.

[jcxz]

[uquote="BOB51",url="/forum/viewtopic.php?p=3991391#p3991391"]В частности - отказы главного генератора МК (позднее даже был введен специальный аппаратный модуль для контроля).[/uquote]Это сейчас почти у каждого первого МК имеется.

[DX168B]

[uquote="Andrey_B",url="/forum/viewtopic.php?p=3991377#p3991377"]И как, встречались прецеденты искажения прошивки ? Какие внешние условия, что за процы ?[/uquote]
Были случаи, когда из-за искрящих рядом с МК контактов реле, прошивка улетала в атсрал после пары переключений.
Реле располагалось рядом с МК на расстоянии 3см. В нагрузке реле был довольно мощноватый контактор.
Обмотка реле и её питание были гальванически отвязаны от питания и сигналов МК. Ну а сам МК - Atmega 16.
Дуга на контактах реле порождает хороший электромагнитный импульс,
который своей наводкой корячит заряды на плавающих затворах Flash памяти МК, портя таким образом данные.