Hacker News Digest

XDP (eXpress Data Path) — самый быстрый фреймворк для обработки пакетов в Linux, но изначально работал только для входящего трафика. Компания Loophole Labs обнаружила лазейку, позволяющую использовать XDP для исходящего трафика, exploiting уязвимость в том, как ядро Linux определяет направление пакета. Их решение обеспечивает в 10 раз лучшую производительность, чем текущие альтернативы, работает с существующими Docker/Kubernetes контейнерами и не требует модификаций ядра.

При обработке трафика со скоростью сотни гигабит в секунду во время миграции контейнеров и ВМ, XDP достигает скорости линии связи (line-rate), в то время как Traffic Control (TC) ограничен всего 21Gbps на исходящем трафике. Это критически важно для их инфраструктуры, где каждая CPU-единица имеет значение. Решение позволяет обрабатывать пакеты на максимальной скорости сетевого интерфейса, будь то 20Gbps или 200Gbps, без каких-либо изменений в существующей инфраструктуре.

• XDP для egress – авторы используют виртуальные интерфейсы veth, чтобы заставить XDP обрабатывать исходящий трафик, что позволяет достичь 10-кратного прироста пропускной способности по сравнению с iptables/TC, при этом оставаясь совместимым с контейнерами и Kubernetes.
• производительность и совместимость – тесты показывают, что при использовании XDP для обработки исходящих пакетов достигается 20-ти кратное увеличение пропускной способности по сравнению с iptables/TC, при этом не требуется никаких изменений в контейнере или оркестраторе.
• почему не DPDK? – авторы отмечают, что DPDK требует специального драйвера и не может быть использован в контейнерах без привилегий, в то время как XDP работает в любом месте, где работает Linux kernel, и не требует специального оборудования.
• будущее: TC и eBPF – вместо того, чтобы продолжать использовать устаревший TC, сообщество может перейти на eBPF, что позволит в будущем использовать более продвинутые функции, такие как socket фильтры, которые могут быть реализованы в пространстве имен.

Конфиденциальные ВМ требуют переработки стека Linux в облаке.
Публичное облако не гарантирует приватности: хост-провайдер может получить доступ к памяти гостя. Confidential computing решает это, шифруя память даже от гипервизора, но приходится балансировать между безопасностью и производительностью.

Изоляция и производительность
Аппаратные уровни привилегий, IOMMU, KVM, cgroups и namespaces обеспечивают изоляцию ВМ. Однако для скорости всё чаще используют прямой доступ к устройствам (DPDK, vDPA), что снижает контроль ОС и усиливает зависимость от железа и прошивок.

Решение: доверенные устройства
AMD SEV-TIO и стандарт TDISP позволяют гостю криптографически убедиться в подлинности устройства и разрешить ему прямой доступ к зашифрованной памяти, избегая медленных bounce-буферов. Реализуется через SR-IOV: физическое устройство создаёт множество виртуальных функций, каждая из которых может быть «доверенной» для конкретной конфиденциальной ВМ.

• Критики считают, что Confidential Computing (CC) — это скорее маркетинговый трюк облачных провайдеров, чем реальная защита: аппаратная основа часто уязвима и не может быть исправлена.
• Даже при шифровании памяти вы всё равно работаете на чужом железе, которое теоретически могут модифицировать для сниффинга или извлечения данных.
• Для многих CC — способ «галочки» под GDPR, особенно в медицинских исследованиях, но реальная польза пока минимальна.
• Apple реализовала собственную версию CC качественно, но она закрыта и только для экосистемы Apple.
• Участники соглашаются: если ваша модель угроз не позволяет доверять провайдеру, используйте физические серверы; «доверие» в облаке всегда остаётся условным.

• История: от pre-fork до epoll — каждый шаг уменьшал сисколлы, но они всё ещё оставались узким местом.
• io_uring — кольцевые очереди в памяти: сервер пишет команды, ядро асинхронно их выполняет и кладёт результат обратно. При высокой нагрузке strace не покажет ни одного сисколла.
• 1 поток = 1 ядро без разделяемых структур; память берётся только из локального NUMA-узла.
• Память: заранее выделяем фиксированный буфер на соединение — без brk/mmap, без фрагментации.
• kTLS — после рукопожатия шифрование переходит в ядро. Плюсы:
  1. Работает sendfile, данные не копируются в userspace.
  2. Возможно аппаратное ускорение NIC.

• io_uring даёт «zero-syscall» при высокой нагрузке, но требует ручного управления памятью: безопасность не обеспечивается ни borrow checker, ни runtime.
• На большинстве облачных платформ io_uring выключен по умолчанию, поэтому остаётся нишевым.
• Автор статьи сначала чистит код, а потом будет мерить производительность — что вызвало одобрение читателей.
• Обсуждаются альтернативы: epoll, kTLS, DPDK, eBPF, а также споры «один поток на ядро» vs oversubscription.
• Некоторые считают, что сложность io_uring и async Rust — цена за неспособность ОС ускорить syscalls без нарушения обратной совместимости.