В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57131
Никогда не было, и вот опять
Опять детский сад и школа виноваты? 👀 )
Programs written on C be like:
Да-да, Rust бы здесь помог ;)
Был бы uClibc написан на расте, тут было бы 300+ постов экспертных мнений. А так под комменты даже не пообедать.
Debian with Glibc ннада?
Надо переписать на Hare
Hare внезапно бы сам догадался, что вот здесь надо рандомизировать ID.
Не, ну с printf было забавнее, я так понимаю у них у всех качество кода примерно одинаковое.
OpenWRT же на musl переезжал, нет?
Деды-пердуны на 19.07 могут иметь uClibc
Там тоже musl.
> muslТам же тоже какие-то застаревшие проблемы с сетью, с тем же DNS, нет?
>> musl
> Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS,
> нет?Нет.
А пишут, что musl = based but still immature with a lot of network issues, glibc = cringe but rock solid.Уже нет? :) Ура!
Ты накидывай лучше сразу ссылки на уязвимости в DNS, а не языком по широкому холсту.
Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1
> Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1Это тулчейн. Как оно компиляется по большому счёту никому нет дела. А libc в самом OpenWRT от musl.
ага, например, musl не умеет в DNS через TCP
То есть DoT/DoH в Alpine Linux не будет работать?
DoT/DoH не через libc работают
UDP маздай.
Однако, NAT он пробивает лучше, чем TCP.
NAT не нужен, но UDP ещё и канал лучше утилизирует.
Он использует те же алгоритмы управления потоком, что и TCP. Просто напулять пакетов без проверки доставки можно больше, но кому такое нужно? Даже realtime видео нафиг не упало, если оно рассыпается на кашу из квадратов.
QUIC может использовать свои алгоритмы для проверки доставки.
> QUIC может использовать свои алгоритмы для проверки доставки.Проверка доставки или всё же управление потоком? Так-то в подавляющем большинстве реализаций обычный CUBIC стоит в дефолте. Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Вам не кажется, что где-то в одном из двух случаев логика даёт сбой и создатели протокола просто "залечивают" без должного обоснования.
QUIC - синдром NIH Гугли.
> Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей?Потому что это разные задачи. Разным задачам, разные решения. Ты не знал об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.
> Потому что это разные задачи. Разным задачам, разные решения. Ты не знал
> об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.Господин, вы бредите. Когда-нибудь на досуге попробуй джиттер померять в userspace реализациях и в kernel. Гарантирую, ты прозреешь. Как ресэмплинг звука в userspace вынесли, так все начали ныть про кривой pulseaudio, хотя он просто старые алгоритмы вынес в пользовательское пространство. В сетевых протоколах есть абсолютно идентичный негативный эффект от подобного переноса и не важно, это VPN или CUBIC/Reno, реализованные поверх UDP.
Нет ты.Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если ты говоришь, что они принципиально не отличаются по своим требованиям к реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай.
Во-вторых, разработка чего-либо в ядре гораздо дороже. Строчка кода ядра обходится дороже, чем строчка кода юзерспейса. Поддержка этой строчки кода обходится резко дороже. Это ещё помножается на то, что ядерная разработка будет работать только с одним ядром, и если ты хочешь кроссплатформенности, то тебе придётся вести несколько разработок под разные ядра. OpenVPN тоже исходно разрабатывался в юзерспейсе, несмотря на весь этот твой бла-бла-бла про джиттер. Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее. Они знали, что разработка в ядре дорого, и поэтому нащупывать правильную архитектуру для реализации VPN, правильные структуры данных, правильные алгоритмы, структуру конфига, и всё остальное лучше в юзерспейсе. В юзерспейсе дешевле разрабатывать код, дешевле его мейнтейнить, дешевле дебажить, дешевле профайлить, ошибки (как архитектурные так и вида use-after-free) обходятся и исправляются дешевле, и поэтому в юзерспейсе было возможно разработать OpenVPN, в ядре практически невозможно. Вот теперь, когда накоплен опыт разработки VPN, опыт использования VPN, когда можно профайлить работу VPN со всех сторон, выясняя где и какие бутылочные горлышки возникают, вот теперь можно запилить и ядерную реализацию, причём сразу отливая её в граните так, чтобы потом не перелопачивать каждый год, когда очередная гениальная идея в голову пришла, или когда какое-нибудь важное наблюдение о строчке кода-источнике джиттера было сделано.
Ты, как заурядный опеннетовец, вслепую ощупываешь слона и говоришь, что слон похож на столб. Глаза разуй и посмотри на проблему во всей её неповторимой сложности. Тогда ты, возможно, прекратишь бредить своими деревьями джиттеров, и начнёшь говорить дельные вещи о лесе в целом.
QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать результат, но теория на то и теория, чтобы проверяться практикой. Только опеннетовец может ратовать за то, чтобы вбухивать сотни нефти в разработку этого QUIC прям сразу в ядре. Любой разумный человек будет разрабатывать его в юзерспейсе поверх стандартного для многих платформ API сокетов, внедрять на все платформы в юзерспейс, собирать данные с практического применения, и вот только после этого ставить вопрос: а не занести ли QUIC в ядро?
> Нет ты.
> Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если
> ты говоришь, что они принципиально не отличаются по своим требованиям к
> реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай.Читай внимательно, что я написал. Мне до твоего HTTPS дела нет, я писал про управление потоком в QUIC как пример корявости, т.к. данное действие является задачей близкой к realtime'у. А ведь именно уменьшение накладных расходов на операции подобного приоритета стали обоснованием для выноса протокола Wireguard в ядро. Будто до этого VPN'ов на уровне ядра не было...
Вирегад в ядро вытащен только по одной причине, по той же, по которой опенжпн свой ядерный модуль пилит.
Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста на каждый долбаный пакет.В случае клюка совершенно не актуально, потому что тот, кто его танцует, его и ужинает.
> Вирегад в ядро вытащен только по одной причине, по той же, по
> которой опенжпн свой ядерный модуль пилит.
> Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста
> на каждый долбаный пакет.Т.е. QUIC в таком случае не должен существовать. Спасибо, что хоть на таком уровне со мной согласились.
Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - пакеты приходят всё тому же адресату, который занимается и управлением потоком.В случае вирегада и прочих впн - пакеты идут через декодер, и снова уходят в ядро - следующему получателю. Разница ощутима?
> Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе -
> пакеты приходят всё тому же адресату, который занимается и управлением потоком.А чё он тогда на 30% жручее до CPU? В чём профит тогда? В обновляемости congestion control'а? Так фуфло это. Гуглу одинаково легко обновить что bbr.ko, что код веб-сервера. А сторона клиента значения не имеет от слова вообще (если ты только не загружаешь что-то). Я уже не говорю про конкретные реализации QUIC с их конкретными глюками и затупами. Чего только в 2-5 раз более медленная загрузка на Firefox/QUIC стоит.
Жручее по сравнению с чем?
> Жручее по сравнению с чем?В сравнении с TCP.
Э, а ничего, что там SSL сверху?
Тогда уж с HTTPS сравнивай.
> Э, а ничего, что там SSL сверху?
> Тогда уж с HTTPS сравнивай.Сравнивали и не один раз:
https://www.fastly.com/cimages/6pk8mg3yh2ee/495gZP7ZprKQUsEj...Если сравнивать BBR vs CUBIC, то первый сливает везде, кроме линий с большим дропом и большой задержкой.
Опять какое-то тёплое с мягким.
Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?
Впрочем я уверен, у QUIC он будет больше - разбирать подобие DTLS (мелкими блоками) - так себе затея.
Другое дело, что он не для передачи гигабит в секунду, он больше для контроля latency на куче смузи-опилок, из которых современные говносайты построены.
> Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...
Советую почитать выводы. Протокол, который обещал при создании обновления алгоритма без вмешательства в систему, требует сетевое оборудование с GSO и нужно патчить реализацию UDP sendmsg для обеспечения более-менее сравнимой скорости. Я нахожу это ироничным.
> Другое дело, что он не для передачи гигабит в секунду, он больше
> для контроля latency на куче смузи-опилок, из которых современные говносайты построены.Посмотри обоснование для его создания.
> Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...Опять какие-то сферические гуглы в вакууме.
Но даже если попытаться из этой ахинеи какие-то выводы сделать - то оно реально колышется где-то на уровне HTTPS ныне, плюс минус вечность в зависимости от имплементации.
Но кстати вот эта смузи-презенташка моё предположение подтвердила неожиданно, разбирать и слать DTLS - очень накладно.Но я вангую что с клюком нас ждёт огромная масса смешного секса, и в итоге оно будет о полутора землекопах. Не потому, что там с производительностью плохо. Я тут погуглил на тему интеропа имплементаций этого счастья, и мне поплохело.
К слову, в том, что кряк - говно, я не сомневаюсь ни разу.
Но там дело не в том, что он не в ядре.
Дело в попытке соплями и скотчем примотать L4 к L7.
И да, всё правильно. В обновляемости алкоритмов, написанных с бодуна под смузи.
> Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее.
> QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и
> выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать
> результат, но теория на то и теория, чтобы проверяться практикой.Разрабы Google, выходит, у тебя лохи печальные, а в Wireguard ну просто гении. Дружище, научись писать внутренне непротиворечивые тексты для начала. А там, может, и до деталей реализации RTP дойдём.
Скажи это провайдерам.
Говорю каждый раз, пора бы уже ipv6 внедрять. Внедрение ipv6 во всём постсовсовке на уровне стран африки.
Открою тебе секрет - и не только в постсовке.
У нас есть полтора пользователя IPv6, Европа, причём западная.
Они даже им вроде как пользуются.
Но абсолютное и подавляющее большинство им не интересуется вообще.
Не взлетело.
(нет, мы можем всем выдать по /64 автоматом, и даже пробовали на все серверы его развесить (не зашло, поубирали) - и после бодро отрапортоваться о 100% пенетрации, но клиентам от этого будет только хуже - жалобы на откровенно хреновую работу при попытке подобное делать были, есть, и будут есть)
А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA при резолве DNS сделать приоритетным.
В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика иметь 80-120, а то и вообще ничего не иметь, и начинают жаловаться.
> А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA
> при резолве DNS сделать приоритетным.
> В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика
> иметь 80-120, а то и вообще ничего не иметь, и начинают
> жаловаться.Кулстори какие-то. Сижу через туннель, ибо провайдер дебил, пинг из-за европейского сервера выше на 80мс до яндекса. И знаешь что? Различий вообще почти не вижу, может у вас такая реализация была классная? А чтобы колическо пользователей выросло, то надо свои роутеры через TR-69 настраивать и пользователям говорить, чтобы ipv6 включали, либо (что менее вероятно из-за кривых приложений с захардкоженным ipv4 адресом) сразу отрубать ipv4, выпускать только с ipv6 и NAT64. Так кстати некоторые новые провайдеры делают и мобильные операторы, ибо ipv4 уже на вес золота.
> отрубать ipv4, выпускать только с ipv6 и NAT64Эдак у вас число пользователей уменьшаться начнёт, а не вырастет.
Ну а чего кулстори. Есть провайдеры в местных (ну, не местных, соседние страны) залупищенсках, трасса по IPv6 от которых идёт через такие дрындыня, что закачаешься. И вот когда на сервере вывешиваешь IPv6, из этой страны начинают ходить по болотам вприпрыжку, потому что академичные дятлы заприорили AAAA, всем по IPv6 и нивалнуед, что там потери, и лейтенси двукратный. А между странами всего 150 км расстояния, и они друг к другу в магазины ходят :D
Это сейчас ещё хецнеровские туннели убились - стало полегче, раньше можно было легко на них нарваться, там вообще благодать была.
Теперь народ начнёт понимать, почему glibc такая "жирная" 🙂
Думаешь в glibc нет бэкдоров? Поверь мне, их там еще больше.
Системы с glibc обычно не проблема обновить.
А вот то, где uclibc - многое из этого уже (древнющее и не очень) легаси, в т.ч. разряда хоаксного iot, для которого вендор прошивку выпускать уже не будет, да и есть ли он.
Обновишь и получишь еще больше бэкдоров, руткитов, вирусов, телеметрии, малвари и фингерпринтинга.
Сомнительное преимущество.
Всё ещё сидишь на ядре 2.0?
Все кто любят юникс, первым делом выпиливают юниксовые "убства" в первую очередь. Либси должна содержать наборчик макросов 90% скопипащеных с ядра и неболее ящитаю.
Гордый суффикс "-ng" прикрутили, а на прикрутить рандом "не в состоянии исправить"? :D
