STM32H573: Secure Manager не даёт приложению перевести чип в CLOSED
В карте производственных операций остаётся одна строка: прошить готовую плату, прогнать функциональный тест, снять её с фикстуры и отправить последнюю защищённую команду. Код уже работает, образ подписан, а SWD/JTAG физически больше не выведен наружу. Именно такую последовательность попытались применить к STM32H573 с установленным Secure Manager, чтобы после теста перевести PRODUCT_STATE из TZ-CLOSED в CLOSED.
Привилегия живёт в provisioning-конфигурации
Ответ ST для этой конфигурации оказался жёстким: Non-Secure application не обладает правом менять product state. Аутентификация команды не расширяет привилегии её инициатора. Производитель предлагает заложить CLOSED в производственный артефакт заранее: изменить PRODUCT_STATE в Option_Bytes.csv с 0xC6 для TZ-CLOSED на 0x72 для CLOSED и поднять minimum product state в конфигурации Secure Manager до 0x72.
PRODUCT_STATE здесь управляет не только доступом к отладчику. Это option byte, допустимость которого контролирует boot stage; конфигурация OEM Secure Manager задаёт минимальное состояние, из которого разрешён запуск приложения. Поэтому прошивка может исправно исполняться и всё равно не иметь власти над следующим жизненным состоянием кристалла. Финальная защёлка оказывается частью доверенной конфигурации, которую устанавливают при provisioning.
Производственная операция, а не вызов API
Производственная операция, а не вызов API
CLOSED не равен безвозвратной блокировке
Из этого вырастает неприятная развилка для технолога. TZ-Closed оставляет нативную отладку Non-Secure домена, что удобно для ICT, функционального теста и поиска брака. Но готовая плата, оставленная в TZ-CLOSED с расчётом «позже закроемся собственной командой», может так и остаться в этом состоянии. Если же прошивать сразу CLOSED, обычный SWD уже закрыт до финальных проверок.
Значит, порядок операций надо рисовать до разводки платы и закупки оснастки: где шьётся SFI-образ, где программируются option bytes, на каком шаге тестируется конечная прошивка, нужен ли сервисный debug после сборки, каким образом обрабатывается плата с отказом на последнем тесте. В такой схеме подпись образа, доступность тест-падов и содержимое Option_Bytes.csv связаны одной производственной политикой.
CLOSED не равен безвозвратной блокировке
Слово «закрыть» легко уводит к неверному выводу, будто CLOSED навсегда отрезает любую диагностику. UM3254 разделяет состояния TZ-Closed, Closed и Locked. В Closed отладка закрыта по умолчанию, однако OEM может заранее предусмотреть Debug Authentication: она способна открыть Non-Secure debug и разрешить regression в оговорённых режимах. Полностью исключает reopening и regression состояние Locked. Эти режимы нельзя смешивать в документации на производство и в threat model изделия.
Есть и важная граница утверждения. Для другой последовательности ST описывала firmware provisioning из Open через PROVISIONING в CLOSED. Этот контрпример не отменяет ответ для уже установленного Secure Manager в TZ-CLOSED, но запрещает превращать его в универсальный закон для любого пользовательского кода STM32H573. В обсуждаемом потоке финальное состояние должно приехать на плату вместе с provisioning-конфигурацией, а не родиться из Non-Secure приложения после того, как оснастка потеряла доступ к чипу.