Да, шейдеры — отличный пример. Но опять же это пример вычислений. Отображение множеств геометрии и текстур в множество пикселей конечной сцены.
С другой стороны есть куча задач, где вычисления как таковые не нужны. А нужно просто в нужное время выставлять нужные биты в нужных местах. И ещё — быстро реагировать на изменения битов в других местах. Это приблизительно то, чем занимается приснопамятный UEFI.
Хотя, если подняться чуточку выше — появляются и задачи для ФП. Мне тут подумалось, что можно например реализовать USB стек на ФП языках. Да и вообще задачи современного прошивкописания всё больше тяготеют к массовой параллельной обработке данных.
А потому что для каждой задачи свой инструмент. Я вот тоже по работе занимаюсь тем, что битики флипаю. Но когда мне надо обработать мегабайт трейс-логов я достаю Питон, а не начинаю писать парсер на С. Угадайте, почему?
ФП хороши для преобразования данных. Собственно, функции в математическом смысле только и делают что отображают элементы одних множеств на элементы других множеств. Идеальная программа на ФП не содержит сайд-эффектов.
Напротив, вся работа железа на низком уровне построена именно на сайд-эффектах. Настолько, что это даже сносит крышу даже обычным С-компиляторам. Например как вам такое — вы пишете в область памяти одно число, а потом читаете оттуда другое? Или читаете два раза подряд из одной и тоже ячейки памяти и при этом получаете совершенно разные значения?
Это не глюк, так работает вся memory-mapped периферия. Приходится использовать хитрые конструкции чтобы сишные компиляторы не ломали работу с периферией своими оптимизациями. Более того, нынешние процессоры тоже шибко умные и выбрасывают лишние (по их мнениею) обращения к памяти. А что тогда говорить про языки более высокого уровня? Поэтому и нет применеия ФП в UEFI.
Зато, если мне надо будет превращать тысячи HTTP запросов в тысячи HTTP ответов — я вользу Эрланг. Потому что ключевое слово — «превращать». Отображать множество HTTP запросов на множество HTTP ответов.
Точно то же самое. Четыре здоровых ARM ядра, пара маленьких, которые управляют разной мультимедией (камера, ускорение видео), плюс DSP (который к счастью никто не использует), плюс отдельная прошивка для Audio Backend. Ну и GPU тоже со своей прошивкой, куда ж без него. И просто дичайше навороченная система power management. Хорошо, что на automotive чипах это не столь актуально.
Но всё равно мне TI как то милее квалкома. Они всё-таки повернуты лицом к комьюнити.
Тут, к сожалению, сложно.
Я сталкивался с двумя реализациями secure boot которые реально используются в продакшене — одна от TI (точнее от TrustedLogic), вторая от Qualcomm. Но и у тех и у других всё так покрыто NDA, что даже получить документацию на обычный чип нелегко. А уж на secure-версию — так вообще.
При чем, дело не только в NDA, но ещё и в экспортных ограничениях на криптографию.
Тут был вопрос от аккаунта read&comment по поводу обновления прошивки и образов tz, sbl1, sbl2.
К сожалению кнопка «отклонить» очень похожа на «ответить». И я случайно отклонил этот комментарий. Прошу прощения. Можете повторить его ещё раз, если хотите.
По сути вопроса — да, эти образы представляют собой цепочку загрузчиков. Но это не значит на 100% что активен secure boot. Загрузчики могут проверять, а могут и не проверять подпись следующего в цепочке. Всё зависит от производителя прошивки.
Прерывание сгенерировать теоретически можно. Но надо что бы secure world настроил контроллер прерываний подходящим образом. Правильный способ попасть в secure monitor — это smc.
Инструкция SMC (Secure Monitor Call) кидает в EL3 из EL1/EL2. Попытка вызвать её из EL0 приведет Undefined Instruction Exception. Гипервизор может трапнуть SMC и таким образом виртуализировать secure monitor.
С EDK2 не работал, поэтому сказать не могу. Честно говоря даже не слышал о платформах где он используется.
Вообще на гитхабе ARM'а лежит совершенно открытый код secure monitor. OP-TEE тоже открыта. Там же на армовском гитхабе лежит и EDK2. При желании наверное можно собрать всё в кучу. Вообще, было бы круто, если бы все ARM-вендоры перешли на EFI, но пока предпосылок к этому я не вижу.
Насколько я знаю — нет. В армовской TRM'ке явно сказано что L1 instruction cache дропается при смене режима процессора.
Судя по описанию атаки, они генерируют запись в те физические регионы памяти, где хранится код SMM. Интеловская архитектура просто опускает такие операции. ARM же сгенерит Data Abort и на это всё закончится.
Контроллер памяти висит на шине (так же как и контроллер DMA). Шина просто не даст ему работать с защищенными регионами.
Самые злые девайсы что я знаю — это SoCи от Texas Instruments. Но они забили на мобильные чипы и теперь ориентируются на automotive. Можно взять TI DRA7xxx. Вам нужна будет HS (High Security) версия, которую купить тяжеловато. Вообще, всё что связанно с безопасностью и криптографией очень тяжело добыть.
Можно взять тот же самый Renesas, но там всё куда проще. Насколько я знаю, secure boot там не построить.
А вообще на поиграться — хватит и RPI и даже Qemu. Ещё можно глянуть список поддерживаемых платформ в доках OP-TEE. Функциональность (в этом плане) у них всех приблизительно одинакова.
Да, можно и так. Но обычно стараются сделать проверку подписей централизовано. Так, например, проще менять ключи
К тому же, если бы загрузчик сам проверял подпись, то в него нужно было бы встроить кучу криптографии. А так он делает ровно один secure monitor call, где передает указатель на буфер и размер. А монитор сам парсит контейнер с образом, находит нужный ключ и проверяет подпись. При чем монитор может воспользоваться аппаратным ускорителем криптографии.
Кажется вы слишком хорошего мнения о проприетарных кодеках. Я бы мог много страшного рассказать, то NDA не дает вдаваться в детали.
Вот, например, был очень интересных глюк в однмом проприетарном OMX компоненте. В результате кривого взаимодействия с аппаратным модулем, код OMX компонента вызывал munmap с очень неправильным размером, в результате чего размапливалась вся память mediaserver'a. Просто потому что один разработчик прошивки кодека решил использовать поле size в шареном буфере немножно не по назначению.
А теперь представьте сколько ошибок такого рода просто не вылезло при тестировании или на них решили забить.
Два самых толстых вектора атаки — это GPU и апаратные кодеки. И у того, и у другого есть своя прошивка и есть возможность работать с любой памятью в обход ядра. При чем, аппаратные кодеки чаще всего управляются мелким ARM-ядром, соотвественно набор комманд известен.
Поэтому, то что MediaServer будет изолирован на уровня ядра линукса никак не спасет от хитрого видео-файла, который вызовет переполнение стека в коде аппаратного декодера и исполнение произвольного кода на отдельном процессорном ядре.
Мне кажется, что такие атаки непопулярны только потому что они будут таргетированны только на конкретную модель устройства.
Так я же и говорю — при проектировании что-то пошло сильно не так. На этот самый FX3 должна существовать errata которая описывает вашу ситуацию (и возможные решеиня). Если вы при этом всё равно выбрали этот чип — значит это ваше осознанное решение и значит вы готовы выжимать всё возможное из GPIO.
Но это — исключение из правил. Обычно всё-таки стараются выбрать такой чип, в котором работает вся ключавая периферия в нужных режимах.
Ну на AVRках его может и тяжело назвать контроллером. Но на всяких ARM-based микроконтроллерах (и тем более SoCах) он бывает довольно продвинутым. Правда, всё равно, подорзеваю что там большую часть логики занимает сопряжение с шиной (включая реализацию регистрового банка).
Попытки программно управлять ногами контроллера с максимальной скоростью очевидно имеют предел, значительно меньший чем позволяют заточенные под это периферийные устройства.
Собственно, мой комментарий был о том же. Незачем использовать GPIO для высокоскоростного обмена. Всегда можно найти более подходящую периферию для такой задачи.
Мне кажется что подход в корне неверен. Почему-то ни в статье, ни в комментариях я не увидел главной аббревиатуры — GPIO. Процессорное ядро не управляет напрямую пинами. Оно обращается к контроллеру GPIO, который как раз отвественнен за ногодрыжество. Из этого следует несколько интересных выводов:
1. У контроллера GPIO есть своё быстродействие, которое может быть ниже быстродействия процессора. Просто потому что переключать силовые транзисторы долго. То что процессор записал единичку в какой-то регистр — ещё не значит что эта единичка тут же появится на пине/пэде.
2. GPIO — это general purpose input/output. А значит он нужен для неспешного подергивания пинами. Если возникает задача управлять пинами с частотой даже в сотню килогерц — значит при проектировании что-то пошло сильно не так.
Поэтому проблема быстрого управления GPIO должна рассматриваться как чисто теоретическое упражнение.
Да там вообще аппноут сделать отвратительно, честно говоря. Такое ощущение, что код писал один человек, а сам документ — другой (при чем, менее понимающий).
Ну я бы именно так делал. Точность рассчетов будет выше на этих три бита.
Я так понимаю, калибровка происходит следующим образом: они охлаждают чип, очень точно замеряют температуру T0_deg и снимают показание АЦП, которое называют T0_OUT, потом подогревают чип, замеряют температуру T1_deg и замеряют показание АЦП которое станет T1_OUT.
Но у них заявленная точность 0.5 градуса, а, чувствительность — вообще 0.0016 градуса. Поэтому они не могут сохранить T0_deg и T1_deg в целых градусах. Поэтому они добавляют ещё три бита точности и таким образом хранят эти значения с точностью 1/8 градуса.
Пока ваши измерения между T0 и T1 — это в принципе не очень страшно. Но судя по примеру из даташита, у них T0 около +10, а T1 — около +20. Итого всего 10 градусов разницы. Поэтому если вы попробуете измерить температуту +40, у вас точность уже будет в два раза хуже, чем на промежутке 10-20. И с каждой десятков градусов точность будет падать ещё в два раза. Вот тут то вас и спасут три лишние бита.
С другой стороны есть куча задач, где вычисления как таковые не нужны. А нужно просто в нужное время выставлять нужные биты в нужных местах. И ещё — быстро реагировать на изменения битов в других местах. Это приблизительно то, чем занимается приснопамятный UEFI.
Хотя, если подняться чуточку выше — появляются и задачи для ФП. Мне тут подумалось, что можно например реализовать USB стек на ФП языках. Да и вообще задачи современного прошивкописания всё больше тяготеют к массовой параллельной обработке данных.
Напротив, вся работа железа на низком уровне построена именно на сайд-эффектах. Настолько, что это даже сносит крышу даже обычным С-компиляторам. Например как вам такое — вы пишете в область памяти одно число, а потом читаете оттуда другое? Или читаете два раза подряд из одной и тоже ячейки памяти и при этом получаете совершенно разные значения?
Это не глюк, так работает вся memory-mapped периферия. Приходится использовать хитрые конструкции чтобы сишные компиляторы не ломали работу с периферией своими оптимизациями. Более того, нынешние процессоры тоже шибко умные и выбрасывают лишние (по их мнениею) обращения к памяти. А что тогда говорить про языки более высокого уровня? Поэтому и нет применеия ФП в UEFI.
Зато, если мне надо будет превращать тысячи HTTP запросов в тысячи HTTP ответов — я вользу Эрланг. Потому что ключевое слово — «превращать». Отображать множество HTTP запросов на множество HTTP ответов.
Но всё равно мне TI как то милее квалкома. Они всё-таки повернуты лицом к комьюнити.
Я сталкивался с двумя реализациями secure boot которые реально используются в продакшене — одна от TI (точнее от TrustedLogic), вторая от Qualcomm. Но и у тех и у других всё так покрыто NDA, что даже получить документацию на обычный чип нелегко. А уж на secure-версию — так вообще.
При чем, дело не только в NDA, но ещё и в экспортных ограничениях на криптографию.
К сожалению кнопка «отклонить» очень похожа на «ответить». И я случайно отклонил этот комментарий. Прошу прощения. Можете повторить его ещё раз, если хотите.
По сути вопроса — да, эти образы представляют собой цепочку загрузчиков. Но это не значит на 100% что активен secure boot. Загрузчики могут проверять, а могут и не проверять подпись следующего в цепочке. Всё зависит от производителя прошивки.
Инструкция SMC (Secure Monitor Call) кидает в EL3 из EL1/EL2. Попытка вызвать её из EL0 приведет Undefined Instruction Exception. Гипервизор может трапнуть SMC и таким образом виртуализировать secure monitor.
Вообще на гитхабе ARM'а лежит совершенно открытый код secure monitor. OP-TEE тоже открыта. Там же на армовском гитхабе лежит и EDK2. При желании наверное можно собрать всё в кучу. Вообще, было бы круто, если бы все ARM-вендоры перешли на EFI, но пока предпосылок к этому я не вижу.
Судя по описанию атаки, они генерируют запись в те физические регионы памяти, где хранится код SMM. Интеловская архитектура просто опускает такие операции. ARM же сгенерит Data Abort и на это всё закончится.
Самые злые девайсы что я знаю — это SoCи от Texas Instruments. Но они забили на мобильные чипы и теперь ориентируются на automotive. Можно взять TI DRA7xxx. Вам нужна будет HS (High Security) версия, которую купить тяжеловато. Вообще, всё что связанно с безопасностью и криптографией очень тяжело добыть.
Можно взять тот же самый Renesas, но там всё куда проще. Насколько я знаю, secure boot там не построить.
А вообще на поиграться — хватит и RPI и даже Qemu. Ещё можно глянуть список поддерживаемых платформ в доках OP-TEE. Функциональность (в этом плане) у них всех приблизительно одинакова.
К тому же, если бы загрузчик сам проверял подпись, то в него нужно было бы встроить кучу криптографии. А так он делает ровно один secure monitor call, где передает указатель на буфер и размер. А монитор сам парсит контейнер с образом, находит нужный ключ и проверяет подпись. При чем монитор может воспользоваться аппаратным ускорителем криптографии.
Вот, например, был очень интересных глюк в однмом проприетарном OMX компоненте. В результате кривого взаимодействия с аппаратным модулем, код OMX компонента вызывал munmap с очень неправильным размером, в результате чего размапливалась вся память mediaserver'a. Просто потому что один разработчик прошивки кодека решил использовать поле size в шареном буфере немножно не по назначению.
А теперь представьте сколько ошибок такого рода просто не вылезло при тестировании или на них решили забить.
Поэтому, то что MediaServer будет изолирован на уровня ядра линукса никак не спасет от хитрого видео-файла, который вызовет переполнение стека в коде аппаратного декодера и исполнение произвольного кода на отдельном процессорном ядре.
Мне кажется, что такие атаки непопулярны только потому что они будут таргетированны только на конкретную модель устройства.
Но это — исключение из правил. Обычно всё-таки стараются выбрать такой чип, в котором работает вся ключавая периферия в нужных режимах.
Собственно, мой комментарий был о том же. Незачем использовать GPIO для высокоскоростного обмена. Всегда можно найти более подходящую периферию для такой задачи.
1. У контроллера GPIO есть своё быстродействие, которое может быть ниже быстродействия процессора. Просто потому что переключать силовые транзисторы долго. То что процессор записал единичку в какой-то регистр — ещё не значит что эта единичка тут же появится на пине/пэде.
2. GPIO — это general purpose input/output. А значит он нужен для неспешного подергивания пинами. Если возникает задача управлять пинами с частотой даже в сотню килогерц — значит при проектировании что-то пошло сильно не так.
Поэтому проблема быстрого управления GPIO должна рассматриваться как чисто теоретическое упражнение.
Я так понимаю, калибровка происходит следующим образом: они охлаждают чип, очень точно замеряют температуру T0_deg и снимают показание АЦП, которое называют T0_OUT, потом подогревают чип, замеряют температуру T1_deg и замеряют показание АЦП которое станет T1_OUT.
Но у них заявленная точность 0.5 градуса, а, чувствительность — вообще 0.0016 градуса. Поэтому они не могут сохранить T0_deg и T1_deg в целых градусах. Поэтому они добавляют ещё три бита точности и таким образом хранят эти значения с точностью 1/8 градуса.
Пока ваши измерения между T0 и T1 — это в принципе не очень страшно. Но судя по примеру из даташита, у них T0 около +10, а T1 — около +20. Итого всего 10 градусов разницы. Поэтому если вы попробуете измерить температуту +40, у вас точность уже будет в два раза хуже, чем на промежутке 10-20. И с каждой десятков градусов точность будет падать ещё в два раза. Вот тут то вас и спасут три лишние бита.