🔓 Площадь атаки, которую ты не заказывал

Когда кто-то несколько раз задаёт один и тот же вопрос, ответ начинает менять смысл. Что делает система, пока ты не смотришь? Становится тем, чем захочет. Именно это приводит к принципиально разным архитектурным решениям.

 

 

`io_uring` (Linux 5.1, 2019) — асинхронный I/O интерфейс: два кольцевых буфера в разделяемой памяти между пользователем и ядром, без единого syscall (истинного вызова). Он же — самый плодотворный вектор атаки на ядро Linux за последние годы. Практически каждый эксплойт для Android Enterprise его использует. Единственный компонент ядра с несколькими одновременно открытыми CVE. За три года — около 100 уязвимостей, ~$20M выплат по bug bounty. Samsung отключил `io_uring` полностью на всём своём железе.

 

 

`io_uring` решает реальную задачу — высокопроизводительный I/O. В комитте ядра не отвергли идею. И приняло всё сразу: несколько сотен opcodeов, новый регион разделяемой памяти, новый путь исполнения запросов — в одном релизе. Высокая плотность дефектов — не случайность. Это прямое следствие того, как строится система.

 

 

На FreeBSD та же проблема не возникает — и причина та же. `io_uring` предлагали для FreeBSD (Jonathan Lemon, FreeBSD 14.1). Но его не приняли целиком — как и macOS, и другие BSD. Для асинхронного I/O FreeBSD использует `kqueue`: один механизм, проверенный десятилетиями, без async-коридора, без новых регионов разделяемой памяти, без ~500 opcodeов. Ни одного из векторов атаки `io_uring` в продакшне.