[MX_Master 1]

Замаячила на горизонте задача менять прошивку в STM32H750 с помощью веб морды. При этом хотелось бы сохранить содержимое прошивки в тайне (RDP Level 1 или PCROP).

С веб мордами проблем, вроде, нет. LWIP + HTTPD работают на ура. Зашифрованный файл (AES) заливается методом POST в SRAM и ждёт там своего часа на расшифровку и заливку. Аппаратный AES дешифратор в чипе есть. Но вот незадача. В STM32H750 всего 1 сектор флэша на все 128 Кб. Загрузчик некуда впихнуть  А код сам себя не перезапишет.

Буду рад любому пинку в правильном направлении.

[jcxz 184]

5 минут назад, MX_Master сказал:

Но вот незадача. В STM32H750 всего 1 сектор флэша на все 128 Кб. Загрузчик некуда впихнуть  А код сам себя не перезапишет.

Буду рад любому пинку в правильном направлении.

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

Если угроза есть - чем же Вы думали, когда камень выбирали? Менять.

[MX_Master 1]

3 минуты назад, jcxz сказал:

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

Угроза всегда есть, даже если её нет. Но, в данном случае, юзер будет об этом предупреждён.

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

[jcxz 184]

6 минут назад, MX_Master сказал:

Угроза всегда есть, даже если её нет. Но, в данном случае, юзер будет об этом предупреждён.

В нормально спроектированном устройстве угрозы нет и нет необходимости напрягать юзверя по пустякам.

Но если уже поздно метаться и поезд ушёл, то остаётся только грозно предупредить пользователя: "Обеспечь гарантированную электроэнергию, не то твоё устройство превратится в тыкву!!!"  

Цитата

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

Видимо не всё что нужно поместили в ОЗУ. Из ОЗУ должно нормально стираться/писаться на любом МК. Ищите какие хвосты остались во флешь.

По уму такое делается отдельной программой (скомпилённой отдельно), которая перед запуском вручную копируется в ОЗУ.

[AlexandrY 3]

30 minutes ago, MX_Master said:

Угроза всегда есть, даже если её нет. Но, в данном случае, юзер будет об этом предупреждён.

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

Похоже вы крупно промахнулись с выбором метода. 
У STM32H750 как явствует из мануала принята перепрошивка через их специальный secure bootloader.
Для этого там есть специальная область Flash в другом банке доступная только в  Secure access mode.
Шифровать вы должны были не своим самопалом, а их утилитой. Зашифрованную прошивку хранить во внешней SPI Flash. 
Перепрошивать должен был их secure bootloader из  SPI Flash после рестарта. 

[MX_Master 1]

Дык, ещё ничего не потеряно, проект в процессе начальных экспериментов. Про secure bootloader сегодня читал в доках. Как видно, невнимательно. Надо перечитать. Спасибо за наводку.

ЗЫ да, в проекте будет SPI флэшка

Изменено 21 февраля, 2019 пользователем MX_Master

[Aner 3]

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

[jcxz 184]

4 минуты назад, Aner сказал:

и в случае проблемы, откат назад без проблем.    

Если (как пишет автор) сектор флеша только один, то откатываться будет уже некуда. Или как Вы это себе представляете "без проблем"? Поясните.

Другое дело конечно если хранить прошивку в формате встроенного нестираемого загрузчика и он может до неё дотянуться - тогда и с одним сектором флешь авария питания не страшна.

10 минут назад, MX_Master сказал:

ЗЫ да, в проекте будет SPI флэшка

Почему тогда пишете "файл (AES) заливается методом POST в SRAM" если для прошивки есть флешка? Вводите в заблуждение....

[MX_Master 1]

15 минут назад, jcxz сказал:

Почему тогда пишете "файл (AES) заливается методом POST в SRAM" если для прошивки есть флешка? Вводите в заблуждение....

Нет, это не заблуждение. Сейчас файл пишется именно в SRAM. А SPI флэшка планировалась под хранение дополнительных HTML/CSS/JS файлов.

[Сергей Борщ 119]

Если в ОЗУ достаточно свободного места для хранения зашифрованной прошивки - его хватит и для расшифрованной.Что мешает зашифрованную держать во внешней флешке, а в ОЗУ - расшифрованную и работать из ОЗУ. Во встроенной флеши хранить основной и аварийный загрузчик, основной при старте проверяет и распаковывает зашифрованный образ в ОЗУ, если распаковка дает рабочий образ - передает управление ему, если распаковка не удалась - передает управление аварийному загрузчику, который кричит "все пропало, шеф!" и предоставляет веб-морду для заливки рабочего образа во внешнюю флешку. Конечно, работа из ОЗУ будет медленнее, чем из встроенной флеши, но "на безрыбье и рыбку раком".

[MX_Master 1]

Да, в H750 достаточно ОЗУ (1 Мб), чтобы временно хранить даже несколько прошивок. Однако, новую расшифрованную лучше в ОЗУ (и внешней флэхе) не держать. Есть вероятность, что более опытный мастер найдёт способ включить дебаг и глянуть, что там есть в видимой части ОЗУ.

Вроде бы, нашёл причину сбоя при работе с флэхой из SRAM. Скорее всего, виновен кэш (I/D). Где-то там может оставаться хвост на внутреннюю флэху. Надо перепроверить.

 

По поводу secure bootloader, есть вот такие слайды

 

 

 

 

 

 

 

В Root secure services (RSS) входят три функции, не связанные с обновлением прошивки

void RSS_resetAndInitializeSecureAreas(RSS_SecureArea_t area)
void RSS_exitSecureArea(unsigned int vectors)
RSS_resetAndDestroyPCROPArea(RSS_FlashBank_et bank)

Что именно входит в Secure Bootloader пока толком не нашёл. Надо покопать в смежных доках. Нашёл инфу, что для общения с Secure Bootloader надо юзать UART interface / Ymodem protocol. Веб загрузчик такого позволить себе не может (:

Изменено 21 февраля, 2019 пользователем MX_Master

[jcxz 184]

5 часов назад, MX_Master сказал:

Однако, новую расшифрованную лучше в ОЗУ (и внешней флэхе) не держать. Есть вероятность, что более опытный мастер найдёт способ включить дебаг и глянуть, что там есть в видимой части ОЗУ.

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

[AlexandrY 3]

11 hours ago, MX_Master said:

Что именно входит в Secure Bootloader пока толком не нашёл. Надо покопать в смежных доках. Нашёл инфу, что для общения с Secure Bootloader надо юзать UART interface / Ymodem protocol. Веб загрузчик такого позволить себе не может (:

Еще бы, потому он и Secure. С ним общается утилита от ST.
Этот бут валидирует все что запускается на чипе. Вам его не нужно непосредственно вызывать. 
Вы должны написать только код (вторичный загрузчик)загружающий из SPI, этот код подписывается тулсами, все ключи сохраняются в базе на PC.  
Secure boot всегда проверяет ваш вторичный загрузчик на валидность.
Ваш вторичный загрузчик загружает код приложения  в основную Flash. 
И опять  Secure boot его валидирует без вас после сброса. Он также должен быть подписан по ключам из базы.
Каждый дивайс и каждый его апдейт должен иметь уникальные ключи и сертификаты. 
Применяются SHA256 + HMAC,  элиптические кривые   и прочие ништяки. 

Короче AES нервно курит в сторонке, здесь все не по детски.  

[MX_Master 1]

7 часов назад, jcxz сказал:

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

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

Для большей наглядности, предположим, что мы (или кто-то из команды) в какой-то момент забыли в коде отключить дебаг. Ну вот так получилось. Залили прошивку, выставили RDP Level 1 и отдали "хитрому" клиенту. И где-то на официальном сайте выкладываем зашифрованные прошивки. При RDP Level 1 "хитрый" клиент не видит код, но видит открытую часть ОЗУ. В коде зашиты AES ключи и сам загрузчик, поэтому сбрасывать защиту на RDP Level 0 нельзя. Но при обновлении можно из открытой ОЗУ что-то расшифрованное вытянуть.

Как в этом случае уменьшить вероятность утечки расшифрованной прошивки? Ну, во-первых, не стоит весь файл расшифровывать сразу. AES дешифратор может кушать и по 16 байт. Во-вторых, этот буфер из 16 байт можно сделать там, где его будет не видно при дебаге. Где-нибудь в RTC регистрах или Backup SRAM. Да, это внутренняя память. Да, до неё можно изнутри добраться. Но вероятность утечки будет уже меньше, чем при расшифровке всего файла в открытой ОЗУ.

 

1 час назад, AlexandrY сказал:

Еще бы, потому он и Secure. С ним общается утилита от ST.

Вот как раз этот момент меня и не устраивает 

Изменено 22 февраля, 2019 пользователем MX_Master

[AlexandrY 3]

27 minutes ago, MX_Master said:

Вот как раз этот момент меня и не устраивает 

Если вы не подружитесь с Secure бутом, то с ним подружатся взломщики. 
Без использования этого бута у вас просто нет серьезных аргументов в защиту надежности  метода прошивки.   

Если ST вам не дает необходимых тулсов, значит ваш бизнес не дорос до такого чипа.
Выбирайте что нибудь подоступней, например Renesas Synergy.