как вам трассировка?

У моего коллеги Саши Батина (техлида проекта Станции Стрит) — первая статья на Хабре.

https://habr.com/ru/companies/yandex/articles/925610/

признайтесь захотелось?

​​Volatile
#опытным

Ключевое слово, которое не embedded С++ разработчик вряд ли когда-нибудь встречал в код. Сегодня мы поговорим, для чего оно используется.

Предположим, что у нас есть переменная keyboard_press, память под которую замаплена на память устройства ввода-вывода. Когда нажимается кнопка клавиатуры, изменяется переменная keyboard_press. Оставим сам маппинг за скобками и попробуем написать какую-то детсадовскую логику с переменной keyboard_press:

int keyboard_press = 0;
size_t count_test = 0;

void some_function() {
  while(keyboard_press == 0) {
    count_test++;
  }
  // doing stuff
}

Что в ассемблере?

some_function():
  mov eax, DWORD PTR keyboard_press[rip]
  test eax, eax
  jne .L1
.L3: // это кстати пустой бесконечный цикл, куда нельзя попасть и откуда нельзя выбраться
  jmp .L3
.L1:
  ret
count_test:
  .zero 8
keyboard_press:
  .zero 4

А где цикл? А где инкремент count_test?

На самом деле код собран с -О3 и компилятор просто выкинул цикл. Он не видит, что в данном коде где-то еще изменяется keyboard_press, поэтому разумно полагает, что мы написали бесконечный цикл без сайдэффектов, который вообще-то ub.

Но keyboard_press может изменяться, просто это никак не понятно по коду программы.

Теоретически компилятор мог бы увидеть, что мы замапили устройство ввода-вывода на эту переменную. А может и не увидеть. Если маппинг происходит в другой единице трансляции, то точно не увидит. Компилятор технически не может знать всего, что творится в коде. Он оптимизирует какой-то локальный участок кода на основе своих эвристик, которые просто не могут учитывать весь код программы.

Однако компилятор точно видит тип переменной. И на него мы можем повлиять. Вот чтобы отучить компилятор от таких фокусов, нужно пометить keyboard_press ключевым словом volatile.

volatile int keyboard_press = 0;
size_t count_test = 0;

// same

Теперь ассемблер выглядит так:

some_function():
  mov eax, DWORD PTR keyboard_press[rip]
  test eax, eax
  jne .L1
  mov rax, QWORD PTR count_test[rip]
  add rax, 1
.L3:
  mov edx, DWORD PTR keyboard_press[rip]
  mov rcx, rax
  add rax, 1
  test edx, edx
  je .L3
  mov QWORD PTR count_test[rip], rcx
.L1:
  ret

Все, что делает volatile - все операции над переменной становятся видимыми спецэффектами и не могут быть оптимизированы компилятором. Ну и еще операции над volitile переменными не могут переупорядочиваться с другими видимыми спецэффектами в порядке кода программы.

Говорится ли здесь что-нибудь о потоках? Нет! Здесь говорится только об оптимизациях компилятора.

Поэтому использовать volatile можно только для обработки сигналов(хэндлер которых вызывается в том же прерванном потоке), либо в тех местах, где вы работаете с переменной строго в одном потоке.

Доступ к volatile переменным не атомарный + с их помощью нельзя делать синхронизацию неатомарных переменных между потоками, так как volitile не подразумевает барьеров памяти.

Именно из-за этих ограничений volatile используется в очень узком спектре задач работы с I/O. Во всех остальных случаях в С++ используются атомики.

Don't be optimized out. Stay cool.

#cppcore #multitasking #memory

Это я, сижу жду когда ИИ меня наконец заменит на работе

RP2350 Hacking Challenge
Raspberry Pi неожиданно показали отличный пример системного подхода к безопасности: как грамотно организовать bug bounty и превратить это в удачный пиар.

Для начала их контроллер использовался в бейдже на прошлогоднем DEF CON 2024 — крупнейшей в мире конференции по информационной безопасности. Нужно отметить, что DEF CON ежегодно собирает около 30 000 человек — профессионалов и энтузиастов в сфере безопасности. Это сильно гиковская тусовка, собирающая лучших хакеров со всего мира.

Одним из традиционных развлечений конференции является конкурс с бейджем — стилизованной печатной платой. Для одних это способ социализации через взаимодействие бейджей, для других — возможность пореверсить и взломать устройство, что и является сутью конкурса. Для третьих — шанс попрограммировать на новой архитектуре. Взломать бейдж — всегда азартная и престижная часть DEF CON.

Во-вторых, Raspberry не просто предоставили свой контроллер для создания бейджа — они объявили отдельный приз за успешое извлечение ключа из OTP. За время конференции никто с задачей не справился, что вполне логично: большинство приехало пить пиво Club-Mate и развлекаться. Хардкорный хакинг обычно начинается уже после конференции, на воодушевленном подъеме. Поэтому Raspberry продлили конкурс до конца года и увеличили призовой фонд с $10 000 до $20 000. И это очень правильный шаг: если вас не взламывают (за предложенные деньги) — это не значит, что вас невозможно взломать, а скорее, что за эти деньги вы просто никому не нужны.

В итоге их поломали аж пять команд — и довольно разными способами. Все подробно описано в их блоге:
1️⃣ “Hazardous threes” – Aedan Cullen
2️⃣ USB bootloader single-instruction fault with supply-voltage injection – Marius Muench
3️⃣ Signature check single-instruction fault with laser injection – Kévin Courdesses
4️⃣ Extracting antifuse secrets from RP2350 by FIB/PVC – IOActive
5️⃣ Glitch detector evaluation, and OTP read double-instruction fault with EM injection – Hextree

По итогу:
- Raspberry, по цене полугодовой зарплаты одного сильного инженера, получили пять уникальных методов взлома своего чипа — и понимание, как защищаться в следующих ревизиях.
- Отлично прорекламировали конкурс и завлекли исследователей, по сути сунув чипы каждому посетителю прямо в карман
- Назначили достойные призы, не пожадничали и расширили фонд, не обидев ни одну команду — все участники реально проделали крутую работу
- По результатам открыто рассказали о взломах, дав отличный пиар и себе, и исследователям
- Для общественности это хороший набор примеров того, что следует учитывать при проектировании безопасных чипов

До этого момента я не воспринимал RP2350 как сколько-нибудь серьёзную платформу в плане безопасности. Сейчас смотрю кардинально иначе. Может быть, потому что не было никаких ожиданий — а в итоге увидел честный, правильный подход от команды, которая действительно старается.

Возможно, такой качественный результат конкурса получился потому, что подход Raspberry одновременно и привлёк сильных ресерчеров, и за счёт необходимости хоть немного вложиться (купить железо) — отсеял тех, кто обычно приходит на багбаунти ради копейки, заваливая платформы потоком низкосортных отчётов. Чаще всего — это выводы сканеров или, теперь уже, голый выхлоп ChatGPT без малейшей проверки.

Оставлю как напоминание, как грамотно организовать bug bounty.

Как поломали RP2350 ⬇️

1️⃣ “Hazardous threes” – Aedan Cullen
OTP хранит не только ключи, но и критические настройки (debug enable), а также модуль имеет логику-интерфейс (и стейт-машину), которая должна запоминать значение в условиях нестабильного питания. Вариация power-glitch, при которой при reset из OTP считывается неверное значение, и остаётся включённый JTAG. [github] [video]

2️⃣ USB bootloader single-instruction fault with supply-voltage injection – Marius Muench
Недостаток API в BootROM. Команда которая называется REBOOT_TYPE_PC_SP и позволяет сделать soft-reset с нужным PC и SP, конечно же, только из доверенного загрузчика. С помощью fault injection во время команды к USB bootloader можно было изменить команду reboot API и вызвать soft-reset с PC в RAM, где уже был наш невирицированный код.

3️⃣ Signature check single-instruction fault with laser injection – Kévin Courdesses
Классика, fault injection на функции проверки подписи. RP2350 имеет voltage-glitch detector, поэтому гличили лазером.

4️⃣ Extracting antifuse secrets from RP2350 by FIB/PVC – IOActive
Ликнули OTP значения под SEM-микроскопом. Писал об этом выше.

5️⃣ Glitch detector evaluation, and OTP read double-instruction fault with EM injection – Hextree
Атакуем сам glitch detector. С помощью electromagnetic fault injection (EMFI) можно найти место на чипе, где гличинг не будет ловиться детектором.

картинка для квартального отчета @wtfcontrolsengineer

Microchip анонсировали огромное количество 32-разрядных МК в низкоценовом сегменте. Даже не читая новостей, можно понять, что дела у компании идут не очень хорошо, и этим шагом компания пытается бороться за существование, взяв одну из долей рынка.

Я как разработчик продукцию Microchip для тех же ГБК не рассматривал, так как у их контроллеров, по крайней мере, раньше, был важнейший косяк — для прошивки нужен был специализированный программатор, который стоит очень дорого. Так, PICKIT-5 стоит на алиэкспрессе немилосердные 11кР, и это в то время, когда STM'овский "свисток" "нисколько не стоит", аналогичная ситуация для WCH, а для ESP32 программатор вовсе не нужен. Благо в последних контроллерах серии PIC32 я увидел JTAG, а значит, есть смутная надежда прошиваться через него.

Если бы "земля звездой" была компонентом

Обзор схемотехники и микроэлектронного исполнения разных типов балансиров

Интересная сборка АКБ LiFePO4 12V 30Ah

В ЮТ, оказывается, много скама по типу сборок на сотни ампер никелевой лентой 0.15мм, так что качественными мы делимся. Судя по части с тестированием, использовать для варки риса и чая...

Справочник инженера-технолога "Трафареты для SMT-монтажа" | Трафарез