Granulex, всё верно, спасибо за уточнение. В статье я сжал этот пункт, а зря - тема заслуживает развёрнуто.
Соглашусь по всем тезисам. Главная боль действительно не в перформансе, а в архитектуре доверия: shared ring между userspace и ядром стирает классическую syscall-границу, на которой раньше держалась львиная доля seccomp/SELinux-политик. Любая seccomp-фильтрация по номеру сискола после io_uring_enter теряет смысл - реальную операцию ядро уже взяло из SQE и проводит сама, минуя обычный путь.
Из конкретики, которая подкрепляет тезис: в Android начиная с 14 io_uring запрещён через seccomp по умолчанию для непривилегированных приложений; в ChromeOS он отключён в sandboxed renderer-процессах с 2023, после серии CVE; Project Zero в 2023 разбирали, как из найденных kernel exploit chains большинство пошло именно через io_uring - просто потому, что attack surface для непривилегированного процесса разом вырос на сотни новых kernel paths. В RHEL 9 он тоже отключён под дефолтной SELinux-политикой для сервисов, которым явно не разрешён.
То есть формулировка ровно та, к которой пришла индустрия: io_uring - инструмент привилегированных процессов в trusted-окружении. На мультитенантных хостах с непроверенным кодом его надо явно вырезать.
Если интересно, могу разобрать в отдельной заметке, как именно ломается seccomp-модель на io_uring - там есть несколько неочевидных моментов с регистрацией fd через IORING_OP_OPENAT2 в обход политик файловой системы.
Granulex, всё верно, спасибо за уточнение. В статье я сжал этот пункт, а зря - тема заслуживает развёрнуто.
Соглашусь по всем тезисам. Главная боль действительно не в перформансе, а в архитектуре доверия: shared ring между userspace и ядром стирает классическую syscall-границу, на которой раньше держалась львиная доля seccomp/SELinux-политик. Любая seccomp-фильтрация по номеру сискола после io_uring_enter теряет смысл - реальную операцию ядро уже взяло из SQE и проводит сама, минуя обычный путь.
Из конкретики, которая подкрепляет тезис: в Android начиная с 14 io_uring запрещён через seccomp по умолчанию для непривилегированных приложений; в ChromeOS он отключён в sandboxed renderer-процессах с 2023, после серии CVE; Project Zero в 2023 разбирали, как из найденных kernel exploit chains большинство пошло именно через io_uring - просто потому, что attack surface для непривилегированного процесса разом вырос на сотни новых kernel paths. В RHEL 9 он тоже отключён под дефолтной SELinux-политикой для сервисов, которым явно не разрешён.
То есть формулировка ровно та, к которой пришла индустрия: io_uring - инструмент привилегированных процессов в trusted-окружении. На мультитенантных хостах с непроверенным кодом его надо явно вырезать.
Если интересно, могу разобрать в отдельной заметке, как именно ломается seccomp-модель на io_uring - там есть несколько неочевидных моментов с регистрацией fd через IORING_OP_OPENAT2 в обход политик файловой системы.
жестоко )
дайте расту шанс и распробуйте его ))
спасибо, будет во второй части
пишу вторую часть