Пусть отправляют поток на 30 секунд раньше реального времени, буферизуют уже на месте и отправляют его в эфир, синхронизируя с локальными часами. Так что в любом случае не на зеркало надо пенять, а на кривые руки.
Спасибо за ответ! Примерно так и сделано, только вместо прошивки бинарник с одним тестом, слинкованный для загрузки в RAM, а вместо UART CLI - SWD интерфейс, через который бинарник сначала копируется в память, потом туда же копируются тестовые данные, потом PC ставится на адрес функции и контроллер запускается. И волки, как говорится, сыты, и прошивка девственна.
Хорошо, конкретизирую. У меня есть оптимизированная версия curve25519, вещи чисто математической. Рядом есть богомерзкий питон, в котором есть референсная версия из стандарта. Кроме того, сам curve25519 легко влезает в два килобайта, это разных тестовых данных у меня два мегабайта. В готовом устройстве никаких SD-карт и SPI не будет, там будет контроллер с 128 кб флеша. FatFs ему для своих прямых обязанностей тоже не нужен, в силу отсутствия разъема для SD карт.
Богомерзкий питон генерирует файлы в стиле скриншота, где просто перечисляется куча случаев и корректные ответы для них
А у меня, кстати, еще один вопрос представителям питерской школы. Вот есть у меня в прошивке алгоритм. Рядом лежит версия этого алгоритма на высокоуровневом языке, служащая образцом. Мне надо протестировать то, что я корректно реализовал оптимизированную версию алгоритма на C и она совпадает с образцовой.
В случае с тестированием на хосте это тривиально - берем, генерим пару мегабайт тестовых данных и эталонных ответов, компилим, запускаем, проверяем. Как сие тестировать из прошивки и UART-CLI?
У Flipper Zero используется нативный USB микроконтроллера, никаких переходников там нет. И это как раз логично, раз USB разъем в устройстве есть - берешь два провода и соединяешь его с МК, ноль затрат. Однако факт остается фактом - Flipper Zero - это устройство от гиков и для гиков.
Устройство, к которому приложил руку я - это прибор, стоящий на заводе. У прибора есть основной SoC (nVidia Orin), который присоединяется к внешнему миру эзернетом. От основного SoC внутри корпуса идут кабели к частям с МК (которые крутят моторами и делают некоторые другие вещи). Юзер даже не знает о том, что там есть какой-то UART вообще. Он заходит браузером на основной модуль и тыкает там кнопочки. Кроме того, юзер - это рабочий на заводе, он вообще не знает, что такое UART. Он занимается своими прямыми обязанностями, а не изучает внутренности прошивки через CLI.
Однако если Вы добавите сокращенный Shell в релизную сборку для какого-н прибора то, пользователи будут Вам очень благодарны за такой extra функционал.
Подскажите, пожалуйста, для какой целевой аудитории вы делаете приборы. Мои пользователи будут благодарны, если прибор будет работать по назначению. Ближайший USB UART адаптер от них находится на расстоянии компьютерного магазина, причем скорее всего не ближайшего магазина.
Примером устройств, где CLI оставлен в релизе являются векторный антенный анализатор NanoVNA V2, трансивер Flipper Zero, отладочная плата U-Blox ODIN, Bluetooth модуль BC127, домофоны и прочее.
Все, кроме домофонов - весьма специфичные продукты.
Разработчики московской школы программирования MCU привыкли прекрасно обходиться без CLI. Это нормально.
Прекрасно обходиться без CLI на микроконтроллерах. Еще немного удивляет, как вы разбили людей на две бинарные категории и упорно пытаетесь эти категории натянуть.
Это, конечно, плохо, что у вас на работе урезали локального админа и не хотят оплачивать лицензии (а в нынешних реалиях скорее всего и не могут), но обсуждение вроде идет о разработке embedded софта, а не о работе на должности XXX в фирме YYY.
Я принадлежу к той школе, которая говорит, что если инструмент экономит твоё время - его надо использовать, поскольку время - это самый ценный ресурс. А нормальный отладчик экономит просто вагон времени, и никакой UART-CLI по эффективности поиска багов с ним даже рядом не стоял. Настолько рядом не стоял, что я и говорю о его ненужности для меня - у него просто нет решаемых задач. Единичные высокоуровневые отладочные команды (например, выбрать устройство на шине, послать ему запрос, дождаться ответа, проверить CRC) - это просто команды основного протокола коммуникации с хостом. И в одном проекте они одни, в другом другие, в третьем отсутствуют - ибо это разные устройства и предметная область там разная. А часть вещей типа записи истории исполнения вообще дополнительных физических проводов требует, и никаким софтом на МК вы её не сделаете. Самая полезная фича, кстати - позволяет видеть, как накладывались друг на друга прерывания/задачи/etc.
Смотрим, как накладываются прерывания
Смотрим, что измеряет драйвер шагового двигателя
Тем более, если начинает не хватать памяти, то из релиза CLI всегда можно выпилить одной строчкой в make/CMake.
Если начинает не хватать памяти - то значит, что отладка на этом месте прекращается, поскольку вы больше не можете залить прошивку на устройство. Толку-то от того, что в релизе этого не будет - для того, чтобы состоялся релиз, сначала нужно доделать проект до конца.
Иными словами - средства отладки действительно не исключают друг друга, и отлаживать схему можно светодиодами - но согласитесь, что логическим анализатором это делать намного приятнее.
Используемый отладчик специально спроектирован, как отдельный самостоятельный инструмент. Работает исключительно на метаданных ELF файла, а чем, как и где ELF файл был собран - его абсолютно не интересует.
Спасибо за заботу, но у меня работает колесико на мышке, и я успешно доскроллил до этого комментария самостоятельно. И специально для этого я указал, что сборка идет через CMake, и что IDE может быть любая. У меня, например, используется CLion, который просто C++ IDE общего назначения. Отвечает за подсветку синтаксиса, автодополнение и линтинг. Даже не подозревает, что результат будет исполняться на МК.
Потому я ожидал все же более предметных комментариев.
А я вот через GUI спокойно просматриваю регистры GPIO, UART, I2C и вообще любой периферии, вижу разбивку регистров по битовым полям с осмысленными именами. И адреса запоминать не нужно. А еще вижу список RTOS задач, могу переключаться по ним, смотреть их состояния, текущий стек и точку, в которой они сейчас находятся. Могу посмотреть историю исполнения программы (запись примерно последней секунды её жизни), включая время исполнения каждой функции (с точностью до такта) и их вложенность. Могу увидеть, из какого места МК свалился в хардфолт и что этому предшествовало. Могу ткнуть отладчик носом в переменную и он мне построит её график в реальном времени. Могу без графиков, просто смотреть значения избранных переменных в реальном времени с автообновлением. Могу подключить отладчик к эзернету и унести на этаж ниже, где стоит устройство. О всяком пошаговом исполнениии, брейкпоинтах и вотчпоинтах молчу.
И это всё занимает в прошивке 0 байт и требует 0 секунд, чтобы оно появилось в новом проекте. Именно потому я на вашу UART-CLI смотрю с ощущением того, что людям реально делать нечего, кроме как рисовать таблички в прошивке МК и раскрашивать вывод последовательного порта. Я обычно то же самое время трачу на написание осмысленного кода, решающего непосредственную задачу.
И, к слову, это абсолютно никак не мешает собирать проект из CMake, обмазывать его тестами и настраивать CI/CD. Потому что отладчик - полностью отдельная штука, которая подключается к абсолютно любой IDE, хоть к блокноту.
Вам нужно работоспособность SysTick таймера протестировать (вдруг чип бракованный подсунули?) или корректность сборки платы?
Если вдруг вам часто подсовывают чипы, где сломан SysTick таймер - можете залить тестовый код в RAM и оттуда выполнить. Но это мягко говоря нецелевое применение обсуждаемой технологии.
Выглядит так, как будто исчерпывающий ответ на это был дан в моих прошлых комментариях. Код написан на Python из-за того, что на таргете его запускать априори не планируется по самой постановке задачи.
Ваша основная проблема состоит в том, что вы делаете какую-то вещь под себя, после чего приходите на хабр и начинаете убеждать народ, что это правильный и универсальный подход, и весь мир завтра так должен делать. И на критику реагируете фразой "Это что мне надо ...". Нет, вам ничего не надо. Разговор вообще не идет о том, как оптимизировать ваши процессы. Разговор идет о том, как оптимальнее решить задачу целиком, причем для случайного мимокрокодила.
У меня, например, нет готового UART CLI (и никогда не появится, потому что он мне нафиг не нужен, это пустой расход как человеческих ресурсов, так и машинных). Думаю, что у большинства читателей тоже.
Специально для вас прикладываю скриптик в 40 строк, который читает и пишет любые регистры на реальном МК. Даже светодиодик загорается, лично проверил. Никаких проблем добавить туда хоть CLI, хоть HTML вообще нет - и для этого не надо писать никаких драйверов UART-а, достаточно простого println.
Ну, приведенное вам по ссылке коммерческое ПО именно так и работает.
Учитывая, что в приведенном вами фрагменте "прошивки" 10% логики и 90% простыни из копипаста - уверен, на каком-нибудь python это получилось бы куда проще как минимум из-за замены C высокоуровневым языком, а так же доступности полноценной ОС. Для того, чтобы через SWD дергать ножками GPIO, усилий вообще не требуется (помимо поиска библиотеки для используемого отладчика).
JTAG/SWD дают прямой доступ к памяти МК, и, как следствие, ко всем его регистрам. Не очень быстрый, но доступ. Не только к GPIO, а вообще ко всей периферии. Хоть GPIO ставьте, хоть АЦП считывайте, хоть через I2C с остальной платой разговаривайте. Сам boundary scan (в своем изначальном смысле) - это исключительно JTAG, но тут он и не нужен.
Всё то же самое можно реализовать на хостовой стороне, получив в добавок кучу бонусов - например, (теоретическую) возможность использовать одну и ту же софтину для кучи плат, задавая конкретную конфигурацию хоть мышкой. Да и сама софтина может быть хоть десять гигабайт, уметь тестировать не только сам МК, но еще, например, периферийные микросхемы.
Юзер указал опцию, что нужно пробросить сокет ssh-agent, который используется для аутентификации с ключами в памяти. Однако внезапно SSH пробросил сокет ssh-agent, и, что дважды внезапно, им можно воспользоваться для аутентификации.
В законе используется термин "доминирующее положение", а не "монополия", Он не подразумевает, что обязан остаться только один. Он подразумевает, что игрок должен быть достаточно крупным.
Наличие IOMMU в системе должно защищать от любых DMA-атак. Более реалистичен сценарий с выключением питания и считываем планок с еще "горячей" информацией. Против этого на некоторых системах есть шифрование RAM, но оно должно вносить какой-то оверхед.
Очень сложно, знаете ли, конкурировать с инструкцией процессора, работающей на частоте в несколько ГГц и имеющей по экземпляру в каждом ядре. Лично у меня aes-xts работает на скорости 2.8 гигабайт в секунду на ядро.
С разделением ключей на области чисто теоретически такое реализовать можно (никаких принципиальных проблем нет), но я таких реализаций не видел. dm-crypt берет один мастер-ключ и реализует софтварное шифрование.
Про EFI и брутфорс - да, вы правы, именно такая модель угроз там и задумывалась.
Но у True/VeraCrypt есть другой, на мой взгляд более серьёзный недостаток — принципиальный отказ от поддержки TPM, что означает хранение ключей в оперативной памяти
Абсолютно любой софт, с поддержкой TPM или без, будет хранить мастер-ключ в оперативной памяти. Вы же не ожидаете, что крохотный TPM, подключенный к шине в 33 МГц, будет способен шифровать трафик современных дисков?
TPM всегда используется только для расшифровки мастер-ключа, которым уже шифруются данные.
Пусть отправляют поток на 30 секунд раньше реального времени, буферизуют уже на месте и отправляют его в эфир, синхронизируя с локальными часами. Так что в любом случае не на зеркало надо пенять, а на кривые руки.
Спасибо за ответ! Примерно так и сделано, только вместо прошивки бинарник с одним тестом, слинкованный для загрузки в RAM, а вместо UART CLI - SWD интерфейс, через который бинарник сначала копируется в память, потом туда же копируются тестовые данные, потом PC ставится на адрес функции и контроллер запускается. И волки, как говорится, сыты, и прошивка девственна.
Хорошо, конкретизирую. У меня есть оптимизированная версия curve25519, вещи чисто математической. Рядом есть богомерзкий питон, в котором есть референсная версия из стандарта. Кроме того, сам curve25519 легко влезает в два килобайта, это разных тестовых данных у меня два мегабайта. В готовом устройстве никаких SD-карт и SPI не будет, там будет контроллер с 128 кб флеша. FatFs ему для своих прямых обязанностей тоже не нужен, в силу отсутствия разъема для SD карт.
Богомерзкий питон генерирует файлы в стиле скриншота, где просто перечисляется куча случаев и корректные ответы для них
А у меня, кстати, еще один вопрос представителям питерской школы. Вот есть у меня в прошивке алгоритм. Рядом лежит версия этого алгоритма на высокоуровневом языке, служащая образцом. Мне надо протестировать то, что я корректно реализовал оптимизированную версию алгоритма на C и она совпадает с образцовой.
В случае с тестированием на хосте это тривиально - берем, генерим пару мегабайт тестовых данных и эталонных ответов, компилим, запускаем, проверяем. Как сие тестировать из прошивки и UART-CLI?
У Flipper Zero используется нативный USB микроконтроллера, никаких переходников там нет. И это как раз логично, раз USB разъем в устройстве есть - берешь два провода и соединяешь его с МК, ноль затрат. Однако факт остается фактом - Flipper Zero - это устройство от гиков и для гиков.
Устройство, к которому приложил руку я - это прибор, стоящий на заводе. У прибора есть основной SoC (nVidia Orin), который присоединяется к внешнему миру эзернетом. От основного SoC внутри корпуса идут кабели к частям с МК (которые крутят моторами и делают некоторые другие вещи). Юзер даже не знает о том, что там есть какой-то UART вообще. Он заходит браузером на основной модуль и тыкает там кнопочки. Кроме того, юзер - это рабочий на заводе, он вообще не знает, что такое UART. Он занимается своими прямыми обязанностями, а не изучает внутренности прошивки через CLI.
Подскажите, пожалуйста, для какой целевой аудитории вы делаете приборы. Мои пользователи будут благодарны, если прибор будет работать по назначению. Ближайший USB UART адаптер от них находится на расстоянии компьютерного магазина, причем скорее всего не ближайшего магазина.
Все, кроме домофонов - весьма специфичные продукты.
Прекрасно обходиться без CLI на микроконтроллерах. Еще немного удивляет, как вы разбили людей на две бинарные категории и упорно пытаетесь эти категории натянуть.
Это, конечно, плохо, что у вас на работе урезали локального админа и не хотят оплачивать лицензии (а в нынешних реалиях скорее всего и не могут), но обсуждение вроде идет о разработке embedded софта, а не о работе на должности XXX в фирме YYY.
Я принадлежу к той школе, которая говорит, что если инструмент экономит твоё время - его надо использовать, поскольку время - это самый ценный ресурс. А нормальный отладчик экономит просто вагон времени, и никакой UART-CLI по эффективности поиска багов с ним даже рядом не стоял. Настолько рядом не стоял, что я и говорю о его ненужности для меня - у него просто нет решаемых задач. Единичные высокоуровневые отладочные команды (например, выбрать устройство на шине, послать ему запрос, дождаться ответа, проверить CRC) - это просто команды основного протокола коммуникации с хостом. И в одном проекте они одни, в другом другие, в третьем отсутствуют - ибо это разные устройства и предметная область там разная. А часть вещей типа записи истории исполнения вообще дополнительных физических проводов требует, и никаким софтом на МК вы её не сделаете. Самая полезная фича, кстати - позволяет видеть, как накладывались друг на друга прерывания/задачи/etc.
Если начинает не хватать памяти - то значит, что отладка на этом месте прекращается, поскольку вы больше не можете залить прошивку на устройство. Толку-то от того, что в релизе этого не будет - для того, чтобы состоялся релиз, сначала нужно доделать проект до конца.
Иными словами - средства отладки действительно не исключают друг друга, и отлаживать схему можно светодиодами - но согласитесь, что логическим анализатором это делать намного приятнее.
Используемый отладчик специально спроектирован, как отдельный самостоятельный инструмент. Работает исключительно на метаданных ELF файла, а чем, как и где ELF файл был собран - его абсолютно не интересует.
Спасибо за заботу, но у меня работает колесико на мышке, и я успешно доскроллил до этого комментария самостоятельно. И специально для этого я указал, что сборка идет через CMake, и что IDE может быть любая. У меня, например, используется CLion, который просто C++ IDE общего назначения. Отвечает за подсветку синтаксиса, автодополнение и линтинг. Даже не подозревает, что результат будет исполняться на МК.
Потому я ожидал все же более предметных комментариев.
А я вот через GUI спокойно просматриваю регистры GPIO, UART, I2C и вообще любой периферии, вижу разбивку регистров по битовым полям с осмысленными именами. И адреса запоминать не нужно. А еще вижу список RTOS задач, могу переключаться по ним, смотреть их состояния, текущий стек и точку, в которой они сейчас находятся. Могу посмотреть историю исполнения программы (запись примерно последней секунды её жизни), включая время исполнения каждой функции (с точностью до такта) и их вложенность. Могу увидеть, из какого места МК свалился в хардфолт и что этому предшествовало. Могу ткнуть отладчик носом в переменную и он мне построит её график в реальном времени. Могу без графиков, просто смотреть значения избранных переменных в реальном времени с автообновлением. Могу подключить отладчик к эзернету и унести на этаж ниже, где стоит устройство. О всяком пошаговом исполнениии, брейкпоинтах и вотчпоинтах молчу.
И это всё занимает в прошивке 0 байт и требует 0 секунд, чтобы оно появилось в новом проекте. Именно потому я на вашу UART-CLI смотрю с ощущением того, что людям реально делать нечего, кроме как рисовать таблички в прошивке МК и раскрашивать вывод последовательного порта. Я обычно то же самое время трачу на написание осмысленного кода, решающего непосредственную задачу.
И, к слову, это абсолютно никак не мешает собирать проект из CMake, обмазывать его тестами и настраивать CI/CD. Потому что отладчик - полностью отдельная штука, которая подключается к абсолютно любой IDE, хоть к блокноту.
Вам нужно работоспособность SysTick таймера протестировать (вдруг чип бракованный подсунули?) или корректность сборки платы?
Если вдруг вам часто подсовывают чипы, где сломан SysTick таймер - можете залить тестовый код в RAM и оттуда выполнить. Но это мягко говоря нецелевое применение обсуждаемой технологии.
Выглядит так, как будто исчерпывающий ответ на это был дан в моих прошлых комментариях. Код написан на Python из-за того, что на таргете его запускать априори не планируется по самой постановке задачи.
Ваша основная проблема состоит в том, что вы делаете какую-то вещь под себя, после чего приходите на хабр и начинаете убеждать народ, что это правильный и универсальный подход, и весь мир завтра так должен делать. И на критику реагируете фразой "Это что мне надо ...". Нет, вам ничего не надо. Разговор вообще не идет о том, как оптимизировать ваши процессы. Разговор идет о том, как оптимальнее решить задачу целиком, причем для случайного мимокрокодила.
У меня, например, нет готового UART CLI (и никогда не появится, потому что он мне нафиг не нужен, это пустой расход как человеческих ресурсов, так и машинных). Думаю, что у большинства читателей тоже.
Специально для вас прикладываю скриптик в 40 строк, который читает и пишет любые регистры на реальном МК. Даже светодиодик загорается, лично проверил. Никаких проблем добавить туда хоть CLI, хоть HTML вообще нет - и для этого не надо писать никаких драйверов UART-а, достаточно простого
println.Душат змею без регистрации и SMS
Ну, приведенное вам по ссылке коммерческое ПО именно так и работает.
Учитывая, что в приведенном вами фрагменте "прошивки" 10% логики и 90% простыни из копипаста - уверен, на каком-нибудь python это получилось бы куда проще как минимум из-за замены C высокоуровневым языком, а так же доступности полноценной ОС. Для того, чтобы через SWD дергать ножками GPIO, усилий вообще не требуется (помимо поиска библиотеки для используемого отладчика).
JTAG/SWD дают прямой доступ к памяти МК, и, как следствие, ко всем его регистрам. Не очень быстрый, но доступ. Не только к GPIO, а вообще ко всей периферии. Хоть GPIO ставьте, хоть АЦП считывайте, хоть через I2C с остальной платой разговаривайте. Сам boundary scan (в своем изначальном смысле) - это исключительно JTAG, но тут он и не нужен.
Всё то же самое можно реализовать на хостовой стороне, получив в добавок кучу бонусов - например, (теоретическую) возможность использовать одну и ту же софтину для кучи плат, задавая конкретную конфигурацию хоть мышкой. Да и сама софтина может быть хоть десять гигабайт, уметь тестировать не только сам МК, но еще, например, периферийные микросхемы.
А где компрометация приватных ключей?
Юзер указал опцию, что нужно пробросить сокет ssh-agent, который используется для аутентификации с ключами в памяти. Однако внезапно SSH пробросил сокет ssh-agent, и, что дважды внезапно, им можно воспользоваться для аутентификации.
В законе используется термин "доминирующее положение", а не "монополия", Он не подразумевает, что обязан остаться только один. Он подразумевает, что игрок должен быть достаточно крупным.
Наличие IOMMU в системе должно защищать от любых DMA-атак. Более реалистичен сценарий с выключением питания и считываем планок с еще "горячей" информацией. Против этого на некоторых системах есть шифрование RAM, но оно должно вносить какой-то оверхед.
Очень сложно, знаете ли, конкурировать с инструкцией процессора, работающей на частоте в несколько ГГц и имеющей по экземпляру в каждом ядре. Лично у меня aes-xts работает на скорости 2.8 гигабайт в секунду на ядро.
С разделением ключей на области чисто теоретически такое реализовать можно (никаких принципиальных проблем нет), но я таких реализаций не видел. dm-crypt берет один мастер-ключ и реализует софтварное шифрование.
Про EFI и брутфорс - да, вы правы, именно такая модель угроз там и задумывалась.
Абсолютно любой софт, с поддержкой TPM или без, будет хранить мастер-ключ в оперативной памяти. Вы же не ожидаете, что крохотный TPM, подключенный к шине в 33 МГц, будет способен шифровать трафик современных дисков?
TPM всегда используется только для расшифровки мастер-ключа, которым уже шифруются данные.