LINUX.ORG.RU

Из ядра Linux удалена поддержка UDP Fragmentation Offload

 , , ,


4

3

Андрей Коновалов (Andrey Konovalov) нашел с помощью фаззера syzkaller последовательность системных вызовов, которая портит память ядра, если в системе есть хотя бы один сетевой интерфейс с MTU < 65535 и включенной опцией UDP Fragmentation Offload. На самом деле требуется еще право менять опции интерфейса, но его легко получить через непривилегированные пользовательские пространства имен. Они же позволяют создать такой интерфейс, если его не было в системе изначально. Итог: на некоторых ядрах, поставляемых Ubuntu, продемонстрировано повышение привилегий от обычного пользователя до root (CVE-2017-1000112). Проблема существует также в ядрах не от Ubuntu.

David S. Miller в качестве решения проблемы предложил удалить поддержку UDP Fragmentation Offload и выслал соответствующий набор патчей в рассылку netdev. Мотивация: «эту операцию поддерживает очень небольшое число устройств, польза от нее в лучшем случае сомнительна, и эта операция добавляет немало сложности в пути обработки данных». На данный момент патчи приняты в ветку net-next.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

Ответ на: комментарий от valman___

Сетевой интерфейс раньше мог «аппаратно» распиливать большие UDP-пакеты на фрагменты, влезающие в PMTU. Сейчас эта операция всегда делается программно.

AEP ★★★★★
() автор топика

А как поступят в LTS-релизах систем? Непонятно... Роллинг-релизы понятно, а эти? Даже если удалят из дистрибутивов Linux с 1 годом поддержки, то это будет понятно: на этих дистрах же «обкатываются» будущие LTS-ы.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

В бубунте например, ядра обновляются. И в 16.04.5 уже этого точно не будет.

anonymous
()
Ответ на: комментарий от ZenitharChampion

А как поступят в LTS-релизах систем?

Удалят. Это всего лишь (опасная, как оказалось) оптимизация.

AEP ★★★★★
() автор топика

удалена поддержка UDP Fragmentation Offload

Зачем фиксить баги? У нас нет времени долбаться с ними.
Лучше ещё раз запилить $YET_ANOTHER_IPC. А потом пропатчить CFS.
А потом опять IPC.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

С одной стороны да, печально. А с другой стороны, кому нафиг нужно делать оффлоад фрагментации UDP на сетевую карту?

sergej ★★★★★
()

Добавляют новые возможности - ядро раздувается, плохо. Выкидывают ненужное, что случайно нашли по багу, - тоже плохо.

anonymous
()

в качестве решения проблемы предложил удалить поддержку

А если в программе rm найдут возможность повреждения памяти — её удалят?

h578b1bde ★☆
()

Ты гляди, что мой полный тёзка-растоман вытворяет, из-за него теперь в ядре нет мега-полезной фичи, которая повышала мне FPS'ы в Quake! Теперь колёсики в glxgears будут крутиться медленнее и винда под VB тяжело грузится начнёт. А всё потому что увлечение Rust'ом вот до такого доводит! :(

DRVTiny ★★★★★
()
Ответ на: комментарий от AEP

Сетевой интерфейс раньше мог «аппаратно» распиливать большие UDP-пакеты на фрагменты, влезающие в PMTU. Сейчас эта операция всегда делается программно.

Какого *** контролем соединений занимается ядро ОС, а не драйвер сетевых соединений?

И вообще, какого *** драйвера то встраивают, то удаляют из ядра ОС? Отделите уже наконец-то мух от коклеты, товарищи из Kernel Team!

atsym ★★★★★
()
Последнее исправление: atsym (всего исправлений: 1)
Ответ на: комментарий от atsym

Какого *** контролем соединений занимается ядро ОС, а не драйвер сетевых соединений?

Что еще за драйвер сетевых соединений? Сетевая карта обычно должна ловить трафик и передавать его ОС, а уже ОС будет из этого строить соединения.

Deleted
()
Ответ на: комментарий от atsym

Какого *** контролем соединений занимается ядро ОС, а не драйвер сетевых соединений?

Школьник чтоль? Ну ничего, на первом курсе ИТ проходят сетевые технологии и операционные системы. Все впереди. :)

anonymous
()

Если ошибка в дизайне, и функционал в конечном итоге не теряется, то можно удалить.

Plushev
()

в качестве решения проблемы предложил удалить поддержку

Впрочем, ничего нового.

IPR ★★★★★
()
Ответ на: комментарий от DRVTiny

Вот прям команда

ethtool -k eth0 | grep udp-fragmentation-offload
выдает on? У меня везде оно оказывается выключено. Сдается мне, для большинства - новость ниочем.

A-234 ★★★★★
()

в качестве решения проблемы предложил удалить поддержку

Популярное, смотрю, решение. Пусть ядро удалят вообще, там по любому багов полно, чё, их же отлавливать и исправлять еще надо, а это сложно.

normann ★★
()
Ответ на: комментарий от ozz_is_here

Линукс - что ни баг, то получение прав рута.

Ну а как еще? В домашней венде ж из-под рута все и так работают

upcFrost ★★★★★
()
Ответ на: комментарий от normann

Популярное, смотрю, решение. Пусть ядро удалят вообще, там по любому багов полно, чё, их же отлавливать и исправлять еще надо, а это сложно.

Если эта фича никому не нужна, но добавляет сложный путь обработки, на который нужно тратить время — да, её проще удалить.

kirk_johnson ★☆
()
Ответ на: комментарий от anonymous

Э, чувак... Обновись, win98 немножко устарела

счастливый человек, который не знает фразу «симерка моксемальная»?

upcFrost ★★★★★
()
Ответ на: комментарий от h578b1bde

А если в программе rm найдут возможность повреждения памяти — её удалят?

Сначала ее встроят в ядро. А потом — да, удалят.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Популярное, смотрю, решение. Пусть ядро удалят вообще, там по любому багов полно, чё, их же отлавливать и исправлять еще надо, а это сложно.

Если эта фича никому не нужна, но добавляет сложный путь обработки, на который нужно тратить время — да, её проще удалить.

Фича предлогаемая Торвальдсом на kernel.org тоже нужна от силы 2% пользователей ЭВМ.

normann ★★
()

Чем биткойны майнить, лучше бы фаззеры массово гоняли.

(Из побочных эффектов - ядро и прочий софт похудеют вдвое)

anonymous
()
Ответ на: комментарий от normann

2% пользователей ЭВМ.

каждому линуксоиду?

anonymous
()
Ответ на: комментарий от Deleted

У редхата ещё 2.6.32 на регулярной поддержке, а для некрокастомеров с 5кой на расширенной поддердке, думаю, и 2.6.18 пропатчат.

redgremlin ★★★★★
()
Последнее исправление: redgremlin (всего исправлений: 1)
Ответ на: комментарий от normann

Фича предлогаемая Торвальдсом на kernel.org тоже нужна от силы 2% пользователей ЭВМ.

Если ты зашлешь в рассылку «привет чуваки, кому нужен Linux?» ты увидишь много откликов «мне». Если ты зашлешь туда же «кому нужен UDP offload» ты увидишь молчание в ответ. Так понятнее?

kirk_johnson ★☆
()

А каким образом вообще Linux ядро выполняет фрагментацию UDP datagram? То есть, на основе какого RFC был реализован данный механизм? И какие приложения используют данный механизм?

RFC 768: User Datagram Protocol, не содержит для этого необходимых сведений, RFC 8085: UDP Usage Guidelines содержит следующие строки:

RFC 8085: UDP Usage Guidelines

«3.2. Message Size Guidelines

IP fragmentation lowers the efficiency and reliability of Internet communication. The loss of a single fragment results in the loss of an entire fragmented packet, because even if all other fragments are received correctly, the original packet cannot be reassembled and delivered. This fundamental issue with fragmentation exists for both IPv4 and IPv6.

In addition, some network address translators (NATs) and firewalls drop IP fragments. The network address translation performed by a NAT only operates on complete IP packets, and some firewall policies also require inspection of complete IP packets. Even with these being the case, some NATs and firewalls simply do not implement the necessary reassembly functionality; instead, they choose to drop all fragments. Finally, [RFC4963] documents other issues specific to IPv4 fragmentation.

Due to these issues, an application SHOULD NOT send UDP datagrams that result in IP packets that exceed the Maximum Transmission Unit (MTU) along the path to the destination. Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191][RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation.

...

Applications that fragment an application-layer message into multiple UDP datagrams SHOULD perform this fragmentation so that each datagram can be received independently, and be independently retransmitted in the case where an application implements its own reliability mechanisms.»

Собственно говоря это и логично, ведь есть TCP, который и призван осуществлять сегментацию на транспортном уровне или SCTP, если TCP не подходит из каких-то соображений.

А в случае, когда ядро выполняет фрагментацию UDP datagram, то ситуация выглядит даже хуже чем IP фрагментация. Поскольку UDP заголовок не имеет вообще не каких полей, для определения номера фрагмента, а каждый datagram согласно RFC является законченным сообщением с точки зрения транспортного уровня.

Я предполагаю, что возможно мне не удалось правильно сформировать запрос, чтобы найти больше информации, как получилось и почему самое главное, что была реализована фрагментация UDP datagram.

ZANSWER
()
Ответ на: комментарий от ZANSWER

RFC 8085 - Это BCP а не нормативный документ, т.е. рассуждения на тему что «вот хорошо бы было если бы так». К тому-же этот документ весьма свеж (чуть больше полугода)

duger
()
Ответ на: комментарий от dv76

rm на всяких самсунгобуках вроде как умело удалять efivars

Срочно удалить!

h578b1bde ★☆
()
Ответ на: комментарий от upcFrost

Ну а как еще? В домашней венде ж из-под рута все и так работают

Обновляться с Win 9x пробовал?

h578b1bde ★☆
()
Ответ на: комментарий от A-234

Спасибо, я теперь хотя бы знаю, как это смотреть :)

DRVTiny ★★★★★
()
Ответ на: комментарий от duger

Верно, это указано в заголовке документа, что это Best Current Practice и он заменил более старую версию, под другим номером от 2008 года. Но, как это отвечает на заданные мною вначале моего сообщения вопросы?

Я к тому, что RFC 768 имеет статус INTERNET STANDARD и гласит следующие:

«This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP)[2].»

Это не означает, что за реализацию UDP datagram fragmentation, должны отлучать от сети, но тем не менее, какова была мотивация реализации UDP datagram fragmentation в ядре Linux? И каким образом соблюдается факт транзакционной ориентированности протокола в таком случае?

ZANSWER
()

Вот, что мне удалось найти в документации ядра:

«UDP Fragmentation Offload =========================

UDP fragmentation offload allows a device to fragment an oversized UDP datagram into multiple IPv4 fragments. Many of the requirements for UDP fragmentation offload are the same as TSO. However the IPv4 ID for fragments should not increment as a single IPv4 datagram is fragmented.»

Иными словами речь идёт о IP fragmentation, а значит мои вопросы можно считать исчерпанными.

ZANSWER
()
Ответ на: комментарий от ZANSWER

А каким образом вообще Linux ядро выполняет фрагментацию UDP datagram? То есть, на основе какого RFC был реализован данный механизм?

На основе RFC 791. Т.е. это просто фрагментация IP-пакетов без флага «DF», примененная к UDP.

AEP ★★★★★
() автор топика
Ответ на: комментарий от AEP

Да, я нашёл всё таки документацию, но в любом случае спасибо за ответ. :)

ZANSWER
()
Ответ на: комментарий от spec_po_kiskam

диванным экспертам

которые спецы по диванным котикам?

anonymous
()

приятно что местная идея о нинужна побеждает!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.