К сожалению, такие красивые окошки Кейл умеет рисовать для очень ограниченного количества процов; вероятно, их люди делали "вручную". А регистры рисуются по sfr-файлу, который производитель МК поставляет.
У меня есть старая статья (которая, правда, не совсем про это), сейчас я пользуюсь другим фреймворком; тоже самодельным, но уже на С++, регистрировать тесты гораздо удобнее и boost не нужен.
Если коротко, то все сводится к запуску в симуляторе, с перенаправлением вывода printf в отладочное окно.
Как-то сходу ничего больше на нашел. Но если хотите, могу статью написать :)
Но тогда их надо запускать или в симуляторе родной архитектуры МК, либо на тестовой плате и получать результаты тестов на комп каким-то образом.
Вообще, я может невнимательно читал, но в статье я не нашел, под какую платформу происходит компиляция и как происходит запуск.
Мне показалось, что тесты компилируются под х86 и запускаются там же...
В качестве IDE – Visual Studio, потому что нам нравится ее внешний вид, удобство отладки и рефакторинга кода. Данная IDE также подходит для написания кода на «чистом» C.
Ну, "совсем" никак — это все-таки слишком сильно. Имхо если есть физический доступ к устройству, то взлом возможен — вопрос только в цене и количестве усилий.
В конце концов, можно кислотой стравливать чип слой за слоем. Но можно и тротила в корпус насовать. Но можно корпус вскрывать в жидком азоте. Но можно… ну вы поняли, это бесконечная битва :)
Через манипуляции с питанием, можно попытаться смотри сделать, но только если неправильно детектор питания в софте наполнен
По-моему глитчингом можно добиться неверного выполнения команд процессором, так что софтом тут не прикроешься.
Разумеется, за 3$ нельзя достичь секьюрности уровня ключей за 200+ долларов. Однако, собранный девайс можно рассматривать как ключ начального уровня. <..> В любом случае, использование такого устройства поднимет безопасность как минимум на уровень выше. Так что это отличный способ начать использовать аппаратные ключи.
С этим не спорю.
Теперь поговорим немного о том, что будет еслы Вы потеряете этот ключ. Сам ключ защищен пин-кодом. После нескольких неудачных попыток ключ блокируется. Память самого устройства защищена от чтения, так что считать записанные в него ключи напрямую не получится.
Существуют некоторые виды атак на сам чип(например препарирование и подключение к нему микроэлектородов, что позволит измерять напряжение в любом месте чипа, в том числе и памяти), но они довольно затратные.
Для снижения времени обращения к переменным настроек устройства во время работы требуется держать актуальные значения в RAM (обычно объем таких данных варьируется от десятка переменных до 3 килобайт в зависимости от устройства).
Скажите, пожалуйста, а вот этот пункт был обоснован какими-то реальными замерами?
Вы привели типичный пример неправильного использования венгерской нотации.
Именно! Вроде бы, товарищ Спольски это называет "Наивная венгерская нотация" — когда к переменной приписывается формальный тип, который никого не интересует.
Ну и я хотел привести пример кода, с которым людям все еще приходится работать сейчас; причем freeRTOS обещает сохранять обратную совместимость вечно.
Пояснение: u — unsinged, v — void, x — хз что. Да, ux — это unsigned хз что.
И вот какая мне, блин, разница, что возвращают эти функции? Почему они все не начинаются со слова task, они ведь все относятся к блоку манипуляции тасками?! А вот. И, разумеется, большинство IDE начинают поиск только если первую букву угадаешь.
Меня лично всегда удивляло, что xml комментарии в C# даже Visual Studio не отображает "красиво", когда смотришь на сам код метода:
///<summary>Adds two integers and return the result</summary>
///<returns>the difference between the two operands</returns>
static int Add(int operand1, int operand2)
{
return operand1 + operand2;
}
При этом по ховеру всплывает красивая подсказка. Почему нельзя по-умолчанию все эти теги рендерить красиво и при обычном просмотре функции? А по клику на комментарий переходить в режим редактирования.
Ну, банально владение любым динамически выделенным объектом. В С++ это решается либо вручную (т.е. вручную delete звать, порождая висячие указатели и т.д.), либо умным указателем с подсчетом ссылок. Ну или сборщиком мусора.
А в Rust, если владелец у ресурса в каждый момент времени один, вообще ничего делать не нужно; компилятор сам понимает, что время жизни ресурса закончилось и вставит вызов деструктора.
Плюс эта же концепция владения хорошо натягивается на многопоточные программы — к каждому разделяемому между потоками ресурсу должен обращаться только один поток в каждый момент времени, чтобы гонок не было; опять же, компилятор это гарантирует.
Ну, это все на словах так радужно, конечно, в реале это приводит к дополнительным прыжкам через обручи, когда компилятор сам не может понять, что все норм, но насколько часто это происходит в реальных больших проектах — судить не берусь, продакшен на расте не писал .
И еще вопрос — в каких языках кроме С++ есть move-семантика? В чем отличия и особенности?
В Rust есть. Там по-умолчанию move, но это подается под соусом "передачи владения"; владение можно либо отдать на совсем (move), тогда объектом больше пользоваться нельзя и деструктор для него не вызовется, либо объект можно одолжить (borrow), тогда заимствующий не может его удалить. И скопировать можно.
Ну так, на пальцах. Это очень логично ложится на обычную логику владения ресурсами (памятью, доступом к i/o и т.п.), которая в других языках выражается неявно.
Идея интересная, буду ждать продолжения!
Пара ремарок:
Если вы пользуетесь HAL'ом, то вы автоматически пользуетесь и библиотекой CMSIS, которая дает следующие возможности:
CoreDebug->DEMCR, напримерК сожалению, такие красивые окошки Кейл умеет рисовать для очень ограниченного количества процов; вероятно, их люди делали "вручную". А регистры рисуются по sfr-файлу, который производитель МК поставляет.
У меня есть старая статья (которая, правда, не совсем про это), сейчас я пользуюсь другим фреймворком; тоже самодельным, но уже на С++, регистрировать тесты гораздо удобнее и boost не нужен.
Если коротко, то все сводится к запуску в симуляторе, с перенаправлением вывода printf в отладочное окно.
Как-то сходу ничего больше на нашел. Но если хотите, могу статью написать :)
Мой опыт тестов в симуляторе Keil говорит примерно то же самое; единственное что тесты иногда довольно долго выполняются.
Но тогда их надо запускать или в симуляторе родной архитектуры МК, либо на тестовой плате и получать результаты тестов на комп каким-то образом.
Вообще, я может невнимательно читал, но в статье я не нашел, под какую платформу происходит компиляция и как происходит запуск.
Мне показалось, что тесты компилируются под х86 и запускаются там же...
А как у нее с С99? Неужели добавили поддержку?
Ну, "совсем" никак — это все-таки слишком сильно. Имхо если есть физический доступ к устройству, то взлом возможен — вопрос только в цене и количестве усилий.
В конце концов, можно кислотой стравливать чип слой за слоем. Но можно и тротила в корпус насовать. Но можно корпус вскрывать в жидком азоте. Но можно… ну вы поняли, это бесконечная битва :)
По-моему глитчингом можно добиться неверного выполнения команд процессором, так что софтом тут не прикроешься.
Признаю, выразился тоже не слишком удачно; спасибо.
С этим не спорю.
А вот это, к сожалению, не верно; конкретно для этого чипа обойти защиту довольно легко: https://medium.com/@LargeCardinal/how-to-bypass-debug-disabling-and-crp-on-stm32f103-7116e7abb546
Спасибо за развернутый ответ! Судя по всему, мне просто везло с задачами :)
Я, в целом-то, чисто теоретически все это знаю, но с задачами, где бы что-то из этого как-то влияло на работу пока не сталкивался.
Интересно, спасибо.
Скажите, пожалуйста, а вот этот пункт был обоснован какими-то реальными замерами?
Именно! Вроде бы, товарищ Спольски это называет "Наивная венгерская нотация" — когда к переменной приписывается формальный тип, который никого не интересует.
Ну и я хотел привести пример кода, с которым людям все еще приходится работать сейчас; причем freeRTOS обещает сохранять обратную совместимость вечно.
Имхо венгерская плоха в первую очередь тем, что мешает автокомплиту в IDE — никогда не помнишь, с какой буквы надо начинать набор.
Скажем, во freeRTOS все API — с венгеркой. И это просто адище:
Пояснение: u — unsinged, v — void, x — хз что. Да, ux — это unsigned хз что.
И вот какая мне, блин, разница, что возвращают эти функции? Почему они все не начинаются со слова task, они ведь все относятся к блоку манипуляции тасками?! А вот. И, разумеется, большинство IDE начинают поиск только если первую букву угадаешь.
Интересно, почему не
count_set_bitsвместоpopcount?Меня лично всегда удивляло, что xml комментарии в C# даже Visual Studio не отображает "красиво", когда смотришь на сам код метода:
При этом по ховеру всплывает красивая подсказка. Почему нельзя по-умолчанию все эти теги рендерить красиво и при обычном просмотре функции? А по клику на комментарий переходить в режим редактирования.
Это отрадно слышать.
Ну, банально владение любым динамически выделенным объектом. В С++ это решается либо вручную (т.е. вручную delete звать, порождая висячие указатели и т.д.), либо умным указателем с подсчетом ссылок. Ну или сборщиком мусора.
А в Rust, если владелец у ресурса в каждый момент времени один, вообще ничего делать не нужно; компилятор сам понимает, что время жизни ресурса закончилось и вставит вызов деструктора.
Плюс эта же концепция владения хорошо натягивается на многопоточные программы — к каждому разделяемому между потоками ресурсу должен обращаться только один поток в каждый момент времени, чтобы гонок не было; опять же, компилятор это гарантирует.
Ну, это все на словах так радужно, конечно, в реале это приводит к дополнительным прыжкам через обручи, когда компилятор сам не может понять, что все норм, но насколько часто это происходит в реальных больших проектах — судить не берусь, продакшен на расте не писал .
В Rust есть. Там по-умолчанию move, но это подается под соусом "передачи владения"; владение можно либо отдать на совсем (move), тогда объектом больше пользоваться нельзя и деструктор для него не вызовется, либо объект можно одолжить (borrow), тогда заимствующий не может его удалить. И скопировать можно.
Ну так, на пальцах. Это очень логично ложится на обычную логику владения ресурсами (памятью, доступом к i/o и т.п.), которая в других языках выражается неявно.