Jump to content

    
Sign in to follow this  
MX_Master

STM32H750 + Ethernet + веб-загрузчик

Recommended Posts

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

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

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

Share this post


Link to post
Share on other sites
5 минут назад, MX_Master сказал:

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

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

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

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

Share this post


Link to post
Share on other sites
3 минуты назад, jcxz сказал:

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

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

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

Share this post


Link to post
Share on other sites
6 минут назад, MX_Master сказал:

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

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

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

Цитата

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

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

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

Share this post


Link to post
Share on other sites
30 minutes ago, MX_Master said:

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

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by MX_Master

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
4 минуты назад, Aner сказал:

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
15 минут назад, jcxz сказал:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

2019-02-22_012430.jpg.c906219e8ca62ea4df45693e98ec5ac9.jpg2019-02-22_012650.jpg.a20238e21bfe458801d617914b53cd10.jpg2019-02-22_013220.jpg.5ac054bfaea58f1b78bfd40daabb9f68.jpg

 

 

 

 

 

 

 

В 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. Веб загрузчик такого позволить себе не может (:

Edited by MX_Master

Share this post


Link to post
Share on other sites
5 часов назад, MX_Master сказал:

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

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

Share this post


Link to post
Share on other sites
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 нервно курит в сторонке, здесь все не по детски. :ok: 

Share this post


Link to post
Share on other sites
7 часов назад, jcxz сказал:

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

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

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

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

 

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

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

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

Edited by MX_Master

Share this post


Link to post
Share on other sites
27 minutes ago, MX_Master said:

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this