Наличие IOMMU в системе должно защищать от любых DMA-атак. Более реалистичен сценарий с выключением питания и считываем планок с еще "горячей" информацией. Против этого на некоторых системах есть шифрование RAM, но оно должно вносить какой-то оверхед.
Очень сложно, знаете ли, конкурировать с инструкцией процессора, работающей на частоте в несколько ГГц и имеющей по экземпляру в каждом ядре. Лично у меня aes-xts работает на скорости 2.8 гигабайт в секунду на ядро.
С разделением ключей на области чисто теоретически такое реализовать можно (никаких принципиальных проблем нет), но я таких реализаций не видел. dm-crypt берет один мастер-ключ и реализует софтварное шифрование.
Про EFI и брутфорс - да, вы правы, именно такая модель угроз там и задумывалась.
Но у True/VeraCrypt есть другой, на мой взгляд более серьёзный недостаток — принципиальный отказ от поддержки TPM, что означает хранение ключей в оперативной памяти
Абсолютно любой софт, с поддержкой TPM или без, будет хранить мастер-ключ в оперативной памяти. Вы же не ожидаете, что крохотный TPM, подключенный к шине в 33 МГц, будет способен шифровать трафик современных дисков?
TPM всегда используется только для расшифровки мастер-ключа, которым уже шифруются данные.
Так вот в какой момент все, кому достаточно второго, кинулись использовать первое, хоть это и оверкилл?
Полагаю, что примерно тогда, когда в этот "прокси" пришлось завернуть всю систему (или поднять его на роутере и завернуть всю локалку). Это куда проще делается отдельным интерфейсом и маршрутизацией всего туда. Да и на протокол SOCKS без слез не взглянешь, если честно.
Теперь я понимаю, почему создателям ЯМР пришлось переименоваться в МРТ.
ЯМР - физическое явление, МРТ - приложение этого явления к трехмерному сканированию.
Довольно странно видеть рассуждения о том, что полезный USB мы выкинем, а парсер текстового формата оставим. Хотя текстовый CLI загрузчику нужен так же, как собаке бензобак.
Это не только синтаксический разбор строчек (тоже не очень компактная вещь, если делать по уму), а еще как минимум readline-подобный обработчик ввода. Валидация и подробные сообщения об ошибках. Автодополнение не помешало бы. Всякие help команды и справка по аргументам. Для того, чтобы человеку не приходилось разбирать байты, просто пишется консольная утилита для хоста, которая сама становится этим CLI и может иметь произвольную сложность.
Еще я слабо представляю набор команд у встроенного CLI, кроме "напечатать статус", "залить прошивку" и "перезагрузиться". Но это уже малосущественные детали.
P.S. А если у меня контроллер подключен к системе по SPI, например? Делать CLI over SPI?
Можно и Type B, это не принципиально. Ориентацию он тоже не перепутает, потому что разъем физически нельзя вставить наоборот.
А вот покупать USB-UART кабель специально для вашего устройства гарантированно никто не будет, если мы говорим об устройстве для широких слоев населения. Его просто принесут вам в сервисный центр, вернут обратно в магазин или может быть даже отправят назад почтой - после чего с кирпичом вы будете разбираться сами. Можете посчитать, сколько денег стоит добавление USB, а сколько - оплата всего этого процесса. USB, конечно, не гарантирует отсутствие возврата кирпичей, но хотя бы может уменьшить их количество.
Лично умещал драйвер USB (ACM класс) в 3 килобайта флеша и 200 байт RAM (причем я не то, чтобы сильно старался - никаких оптимизаций под размер там не было).
USB в целом весьма простой протокол (когда у вас есть аппаратный интерфейс, он берет на себя огромную часть сложности), DFU - в особенности.
Критерий применимости - не простота интерфейса с точки зрения количества проводков и сигнала на этих проводках, а возможность использования такого интерфейса конечным пользователем.
Толку от UART, выведенного на потаенный разъем, не больше, чем от SWD, выведенного туда же - конечный пользователь ни тем, ни другим воспользоваться не сможет. Вроде как не в 1997 году живем, когда RS-232 разъем был на каждом компьютере. Толку от USB DFU сильно больше, например - пользователь втыкает устройство в обычный компьютер, скачивает утилиту и возвращает устройство к жизни.
Хорошо видно, что задачу даже не пытались разделять на слои абстракции.
1 - Зависит от конкретного приложения, но если речь идет об устройстве с физическим интерфейсом (например, USB) - то загрузчик. Если это что-то сложное с WiFi и интернетом - тогда отдельно надо озаботиться тем, чтобы не отстрелить себе ногу при OTA. Например, путем сохранения минимально работающей (достаточной, чтобы обновиться) прошивки в отдельный recovery-раздел внешней флешки.
4, 6, 7 - при запуске уже записанной во флеш прошивки достаточно банальной проверки контрольной суммы и флага, что эта прошивка вообще присутствует.
4, 15, 17 - я правильно понимаю, что BGA дорожки, аппаратный вотчдог и стирание маркировки предлагаются из-за того, что загрузчик не осилил банальную аутентификацию загружаемой прошивки?
13, 14 - почему именно UART? Почему именно CLI? Почему не USB DFU, например? Почему не бинарный протокол? Универсальные советы редко бывают хорошими.
9 - по Reference Manual ядро стартует со включенными прерываниями, и такой совет потребует доработки приложения. Отключать надо источники прерываний, а не сами прерывания. Аналогично 12 - по спецификации ядро ставит стек из первого слова векторной таблицы, загрузчик должен сделать так же. Даже если конкретный startup файл его и переставляет сразу же, поведение должно совпадать.
18 - перемещаемый и позиционно-независимый код - это две абсолютно разные вещи. Для перемещаемого кода вам придется хранить метаинформацию о перемещениях и применять эти перемещения. Позиционно-независимый код тоже имеет свои накладные расходы, но может запускаться из любого адреса. Сама необходимость такой фичи выглядит сомнительной, если только речь не идет про какие-то A/B boot схемы.
20 - сначала стартует загрузчик, потом приложение (по тем же причинам отстрела ноги). Если конкретный чип не позволяет конфигурировать VTOR или отображение памяти (например, новые STM позволяют) - то загрузчику особо больше негде быть, кроме как в начале флеша.
22 - наоборот, неплохо бы предпринять меры для того, чтобы даже при баге в приложении оно физически не могло испортить загрузчик. Если МК не позволяет что-то более гибкое - то просто пометить соответствующие страницы как R/O, если позволяет - то использовать эти механизмы (напр., Securable Flash на контроллерах STM32G4).
Я так тоже могу, только загрузчик не нужен - беру программатор, подключаюсь, прошиваю. Разве что с защитой флеша вопросы, но например в новых STM можно закрыть отладочный интерфейс не полностью, а с требованием аутентификации.
Вопрос в том, что устройство висит/стоит/лежит у юзеров, им тоже брать UART кабель и прошивать, если вдруг через OTA прилетела неудачная прошивка?
К вам такой же вопрос. Залили вы приложение с дефектным сетевым интерфейсом, а по вашей же логике за подготовку образа отвечает именно приложение. Дальнейшие действия?
512 кБ read-only SPI NOR, у которой техпроцесс размером со слона - это все же немного другого класса устройство, чем терабайтный TLC NAND чип, изрядно потрепанный прошлыми записями.
Потому я и уточнил, что через интернет. Если у вас есть локальный приемник - то пользы от станции точного времени даже больше - несущая там тоже тактируется от тех же атомных часов. Выделив несущую, можно получить эталонный тактовый сигнал, даже если не декодировать информационную нагрузку. По этим же причинам, кстати, у несущих "красивые" и круглые частоты.
С появлением доступных GPSDO генераторов это стало менее актуально, конечно, но заметить стоит. Та же локальная KiwiSDR прекрасно справится с задачей сама, потому что она от GPS синхронизирует свое собственное тактирование. Никакая станция точного времени ей для этого не требуется.
Да увидите вы и условия циклов, и условия ветвлений. Вы не увидите тела неисполненных веток. Условно, вы видите следующий код (допустим, на x86, а не 8051, в него я не умею):
Перерезание питания - это инвазивная операция. Пусть и небольшая.
Если МК за время работы (когда на него подавали данные и он исполнял программу) не обращался к какому-то адресу памяти - значит, этот адрес памяти для исполнения программы не очень важен. Но да, есть шанс потерять ветку, на которую не зашли (хотя условие её достижимости будет видно).
Не очень понял, какую кучу данных мы получим, если встрянем в цикл. Да, будет чтение повторяющихся ячеек, но EEPROM на то и EEPROM, что ячейку достаточно увидеть один раз. Не нужно анализировать всю трассу исполнения, достаточно просто узнать содержимое памяти по конкретному адресу. Сколько раз этот адрес будет прочитан - дело десятое.
Я не уверен, какая была схемотехника микросхем того времени (тем более советских), но с современными микросхемами даже при отрезанном питании я бы ожидал паразитной запитки процессора через ESD диоды на I/O ножках. Допускаю, что на советских микросхемах их могли не ставить.
Наличие IOMMU в системе должно защищать от любых DMA-атак. Более реалистичен сценарий с выключением питания и считываем планок с еще "горячей" информацией. Против этого на некоторых системах есть шифрование RAM, но оно должно вносить какой-то оверхед.
Очень сложно, знаете ли, конкурировать с инструкцией процессора, работающей на частоте в несколько ГГц и имеющей по экземпляру в каждом ядре. Лично у меня aes-xts работает на скорости 2.8 гигабайт в секунду на ядро.
С разделением ключей на области чисто теоретически такое реализовать можно (никаких принципиальных проблем нет), но я таких реализаций не видел. dm-crypt берет один мастер-ключ и реализует софтварное шифрование.
Про EFI и брутфорс - да, вы правы, именно такая модель угроз там и задумывалась.
Абсолютно любой софт, с поддержкой TPM или без, будет хранить мастер-ключ в оперативной памяти. Вы же не ожидаете, что крохотный TPM, подключенный к шине в 33 МГц, будет способен шифровать трафик современных дисков?
TPM всегда используется только для расшифровки мастер-ключа, которым уже шифруются данные.
Полагаю, что примерно тогда, когда в этот "прокси" пришлось завернуть всю систему (или поднять его на роутере и завернуть всю локалку). Это куда проще делается отдельным интерфейсом и маршрутизацией всего туда. Да и на протокол SOCKS без слез не взглянешь, если честно.
ЯМР - физическое явление, МРТ - приложение этого явления к трехмерному сканированию.
Правильно, сначала ампутируем себе ногу, перенося всё подряд в snap'ы, а потом задумываемся - а как бы теперь жить без ног?
Забыли упомянуть MS-DOS, OS/2, IBM POWER8 и БЭСМ-6.
Довольно странно видеть рассуждения о том, что полезный USB мы выкинем, а парсер текстового формата оставим. Хотя текстовый CLI загрузчику нужен так же, как собаке бензобак.
Это не только синтаксический разбор строчек (тоже не очень компактная вещь, если делать по уму), а еще как минимум readline-подобный обработчик ввода. Валидация и подробные сообщения об ошибках. Автодополнение не помешало бы. Всякие help команды и справка по аргументам. Для того, чтобы человеку не приходилось разбирать байты, просто пишется консольная утилита для хоста, которая сама становится этим CLI и может иметь произвольную сложность.
Еще я слабо представляю набор команд у встроенного CLI, кроме "напечатать статус", "залить прошивку" и "перезагрузиться". Но это уже малосущественные детали.
P.S. А если у меня контроллер подключен к системе по SPI, например? Делать CLI over SPI?
Можно и Type B, это не принципиально. Ориентацию он тоже не перепутает, потому что разъем физически нельзя вставить наоборот.
А вот покупать USB-UART кабель специально для вашего устройства гарантированно никто не будет, если мы говорим об устройстве для широких слоев населения. Его просто принесут вам в сервисный центр, вернут обратно в магазин или может быть даже отправят назад почтой - после чего с кирпичом вы будете разбираться сами. Можете посчитать, сколько денег стоит добавление USB, а сколько - оплата всего этого процесса. USB, конечно, не гарантирует отсутствие возврата кирпичей, но хотя бы может уменьшить их количество.
Лично умещал драйвер USB (ACM класс) в 3 килобайта флеша и 200 байт RAM (причем я не то, чтобы сильно старался - никаких оптимизаций под размер там не было).
USB в целом весьма простой протокол (когда у вас есть аппаратный интерфейс, он берет на себя огромную часть сложности), DFU - в особенности.
Критерий применимости - не простота интерфейса с точки зрения количества проводков и сигнала на этих проводках, а возможность использования такого интерфейса конечным пользователем.
Толку от UART, выведенного на потаенный разъем, не больше, чем от SWD, выведенного туда же - конечный пользователь ни тем, ни другим воспользоваться не сможет. Вроде как не в 1997 году живем, когда RS-232 разъем был на каждом компьютере. Толку от USB DFU сильно больше, например - пользователь втыкает устройство в обычный компьютер, скачивает утилиту и возвращает устройство к жизни.
Хорошо видно, что задачу даже не пытались разделять на слои абстракции.
1 - Зависит от конкретного приложения, но если речь идет об устройстве с физическим интерфейсом (например, USB) - то загрузчик. Если это что-то сложное с WiFi и интернетом - тогда отдельно надо озаботиться тем, чтобы не отстрелить себе ногу при OTA. Например, путем сохранения минимально работающей (достаточной, чтобы обновиться) прошивки в отдельный recovery-раздел внешней флешки.
4, 6, 7 - при запуске уже записанной во флеш прошивки достаточно банальной проверки контрольной суммы и флага, что эта прошивка вообще присутствует.
4, 15, 17 - я правильно понимаю, что BGA дорожки, аппаратный вотчдог и стирание маркировки предлагаются из-за того, что загрузчик не осилил банальную аутентификацию загружаемой прошивки?
13, 14 - почему именно UART? Почему именно CLI? Почему не USB DFU, например? Почему не бинарный протокол? Универсальные советы редко бывают хорошими.
9 - по Reference Manual ядро стартует со включенными прерываниями, и такой совет потребует доработки приложения. Отключать надо источники прерываний, а не сами прерывания. Аналогично 12 - по спецификации ядро ставит стек из первого слова векторной таблицы, загрузчик должен сделать так же. Даже если конкретный startup файл его и переставляет сразу же, поведение должно совпадать.
18 - перемещаемый и позиционно-независимый код - это две абсолютно разные вещи. Для перемещаемого кода вам придется хранить метаинформацию о перемещениях и применять эти перемещения. Позиционно-независимый код тоже имеет свои накладные расходы, но может запускаться из любого адреса. Сама необходимость такой фичи выглядит сомнительной, если только речь не идет про какие-то A/B boot схемы.
20 - сначала стартует загрузчик, потом приложение (по тем же причинам отстрела ноги). Если конкретный чип не позволяет конфигурировать VTOR или отображение памяти (например, новые STM позволяют) - то загрузчику особо больше негде быть, кроме как в начале флеша.
22 - наоборот, неплохо бы предпринять меры для того, чтобы даже при баге в приложении оно физически не могло испортить загрузчик. Если МК не позволяет что-то более гибкое - то просто пометить соответствующие страницы как R/O, если позволяет - то использовать эти механизмы (напр., Securable Flash на контроллерах STM32G4).
Я так тоже могу, только загрузчик не нужен - беру программатор, подключаюсь, прошиваю. Разве что с защитой флеша вопросы, но например в новых STM можно закрыть отладочный интерфейс не полностью, а с требованием аутентификации.
Вопрос в том, что устройство висит/стоит/лежит у юзеров, им тоже брать UART кабель и прошивать, если вдруг через OTA прилетела неудачная прошивка?
К вам такой же вопрос. Залили вы приложение с дефектным сетевым интерфейсом, а по вашей же логике за подготовку образа отвечает именно приложение. Дальнейшие действия?
512 кБ read-only SPI NOR, у которой техпроцесс размером со слона - это все же немного другого класса устройство, чем терабайтный TLC NAND чип, изрядно потрепанный прошлыми записями.
Потому я и уточнил, что через интернет. Если у вас есть локальный приемник - то пользы от станции точного времени даже больше - несущая там тоже тактируется от тех же атомных часов. Выделив несущую, можно получить эталонный тактовый сигнал, даже если не декодировать информационную нагрузку. По этим же причинам, кстати, у несущих "красивые" и круглые частоты.
С появлением доступных GPSDO генераторов это стало менее актуально, конечно, но заметить стоит. Та же локальная KiwiSDR прекрасно справится с задачей сама, потому что она от GPS синхронизирует свое собственное тактирование. Никакая станция точного времени ей для этого не требуется.
Таймер на микроволновке или автоматическая собачья поилка считаются?
Через интернет точное время намного удобнее принимать в формате NTP, а не через KiwiSDR или WebSDR.
А я видел, причем из Чип-и-Дипа (дело было в 2020 году). Только у меня они отставали секунд на 10 в сутки.
Да увидите вы и условия циклов, и условия ветвлений. Вы не увидите тела неисполненных веток. Условно, вы видите следующий код (допустим, на x86, а не 8051, в него я не умею):
Ветка не выполнилась и неизвестно, что внутри, но как заставить её выполниться - достаточно очевидно.
Перерезание питания - это инвазивная операция. Пусть и небольшая.
Если МК за время работы (когда на него подавали данные и он исполнял программу) не обращался к какому-то адресу памяти - значит, этот адрес памяти для исполнения программы не очень важен. Но да, есть шанс потерять ветку, на которую не зашли (хотя условие её достижимости будет видно).
Не очень понял, какую кучу данных мы получим, если встрянем в цикл. Да, будет чтение повторяющихся ячеек, но EEPROM на то и EEPROM, что ячейку достаточно увидеть один раз. Не нужно анализировать всю трассу исполнения, достаточно просто узнать содержимое памяти по конкретному адресу. Сколько раз этот адрес будет прочитан - дело десятое.
Я не уверен, какая была схемотехника микросхем того времени (тем более советских), но с современными микросхемами даже при отрезанном питании я бы ожидал паразитной запитки процессора через ESD диоды на I/O ножках. Допускаю, что на советских микросхемах их могли не ставить.