После шести месяцев разработки состоялся (https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html) релиз системной библиотеки GNU C Library (http://ftp.gnu.org/gnu/glibc/) (glibc) 2.26 (http://sourceware.org/glibc/wiki/Release/2.26), которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2008. В состав нового выпуска включены исправления от 66 разработчика.
Из добавленных в Glibc 2.26 улучшений (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h...) можно отметить:- В функции malloc реализована поддержка кэша, индивидуального для каждого потока, что позволило избавиться от блокировок, возникающих при использовании общего для всех потоков кэша, и существенно поднять производительность выделения и освобождения небольших блоков памяти;
- Расширены возможности встроенного DNS-резолвера: реализовано определения изменения файла /etc/resolv.conf для оперативной загрузки изменённой конфигурации (для запрета автообновления предусмотрена опция "no-reload"); обеспечена возможность указания произвольного числа элементов в списке "domain search" в /etc/resolv.conf (ранее можно было указать не больше шести доменов); при указании опции "rotate" в glibc теперь случайным образом выбирается сервер имён, который будет использован первым (ранее первым всегда использовался сервер, указанным вторым в списке);- По умолчанию включены средства тонкой настройки runtime-компонентов, которые позволяют изменять поведение Glibc при помощи переменной окружения GLIBC_TUNABLES;
- Добавлена функция reallocarray, позволяющего выделить память для нескольких отличающихся по размеру объектов без дополнительных затрат на очистку памяти, но с сохранением средств борьбы с целочисленными переполнениями;
- Добавлены функции-обвязки для новых системных вызовов Linux - preadv2() и pwritev2() (https://lwn.net/Articles/670231/), которые отличаются от preadv() и pwritev() наличием ещё одного аргумента для передачи ядру дополнительных флагов. В настоящее время при наличии ядра Linux 4.7+ поддерживаются флаги RWF_SYNC (сброс данных и метаданных из кэша на носитель после выполнения операции) и RWF_DSYNC (принудительный сброс на носитель только данных);
- В posix_spawnattr_setflags добавлена поддержка флага POSIX_SPAWN_SETSID, используемого для создания нового идентификатора сеанса session ID для порождённого процесса. Данный флаг намечен для включения в следующей версии стандарта POSIX, поэтому пока поставляется в составе расширений "_GNU_SOURCE";- Заголовочный файл errno.h теперь безопасно использовать из блоков на языке ассемблера, прошедших обработку в Си-препроцессоре;
- На архитектурах ia64, powerpc64le, x86-32 и x86-64 в библиотеку math добавлена поддержка 128-разрядных операций с плавающей запятой, определённых в стандартах ISO/IEC/IEEE 60559:2011 (IEEE
754-2008) и ISO/IEC TS 18661-3:2015. Для задействования данной возможности в программах компилятор должен поддерживать тип _Float12 или __float128. Функциональность доступна при включении набора _GNU_SOURCE или __STDC_WANT_IEC_60559_TYPES_EXT__;
- Возможности, связанные с кодировками, информацией о типах символов и таблицами транслитерации, приведены в соответствие со спецификацией Unicode 10.0.0;- Удалён порт для Native Client с архитектурой ARMv7-A;
- Объявлены устаревшими и отключены по умолчанию (для включения требуется сборка с "--enable-obsolete-rpc") компоненты Sun RPC, включая rpcgen, librpcsvc и заголовочные файлы Sun RPC. Также объявлены устаревшими модули NIS/NIS+, а также библиотеки libnss_nis, libnss_nisplus, libnss_compat и libnsl. В качестве замены рекомендуется использовать TIRPC (https://github.com/thkukuk/), в котором имеется поддержка IPv6;
- Из заголовочного файла string.h исключены inline-версии строковых функций, а макросы __USE_STRING_INLINES и __NO_STRING_INLINES большие ни на что не влияют;
- Удалён нестандартный заголовочный файл xlocale.h, вместо которого следует использовать locale.h. Также удалён устаревший файл sys/ultrasound.h;
- Удалена поддержка устаревшей функции cfree() вместо которой следует использовать free();- Для работы теперь требуется ядро Linux 3.2 или более новый выпуск. Для сборки Glibc необходимо наличие GNU Binutils 2.25+ и GCC 4.9+ (ограничение не распространяется на сборку приложений, использующих Glibc, только на сборку самого Glibc);
- Устранены уязвимости:
- CVE-2017-1000366 (https://security-tracker.debian.org/tracker/CVE-2017-1000366) - локальное повышение привилегий через манипуляцию с содержимым переменной окружения LD_LIBRARY_PATH при вызове suid-приложений. На базе данной уязвимости была построена (https://www.opennet.ru/opennews/art.shtml?num=46724) серия эксплоитов для локального получения прав root в рамках атаки Stack Сlash;- CVE-2017-12132 (https://security-tracker.debian.org/tracker/CVE-2017-12132) - DNS-резолвер подвержен спуффинг-атакам, манипулирующим фрагментацией пакетов большого размера;
- CVE-2010-3192 (https://security-tracker.debian.org/tracker/CVE-2010-3192) - утечка информации через повреждение стека при вызове функции __stack_chk_fail;
- CVE-2017-12133 (https://security-tracker.debian.org/tracker/CVE-2017-12133) - обращение к буферу после его освобождения (use-after-free) в коде clntudp_call из состава Sun RPC.
URL: https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=46959
И он стал ещё тяжелее и медленее.
Почему сразу тяжелее? Список изменений начинается как раз с изменения, которое ускоряет и избавляет от блокировок.
это щас мода такая, пихать dns-резолвер везде, где только можно?
боюсь спросить, как ты себе представляешь libc без резолвера? gethostbyname(3) как будет работать?
Тсс, спугнёте специалистов. Интересно разве что -- двоих или одного...
зависит от того, сколько у вас сегодня ипостасей Михаил. очевидно две или три.
> Тсс, спугнёте специалистов. Интересно разве что -- двоих или одного...Миш, ничего, что я еще помню времена, когда libresolv/libresolv_r были отдельными как минимум в паре опенсорсных систем?
(в линуксе вот не помню, хотя как раз линукс-то в embed-варианте вполне может оказаться собран вообще без ip протоколов)
Сейчас - практически не может - это, сичтай, всегда самый осмысленный способ взаимодействовать с окружающим миром - от мониторинга состояния до апдейтов. Если кому сильно надо - пусть сам извращается.
> Сейчас - практически не может - это, сичтай, всегда самый осмысленный способ
> взаимодействовать с окружающим миромобычно людям не очень нравится, когда их BMW взаимодействует с окружающим миром - ремонт дороговат. А если еще и окружающий мир норовит через какую-нибудь дырку с ней повзаимодействовать без спросу, то просто караул.
То есть решение включать-не включать подобные элементы непосредственно в общий бинарник - оно ситуационное. Но раньше эти библиотеки происходили из окрестностей ISC, что как бе говорит нам о качестве их кода, а по мере переписывания - содержимое во всех известных мне проектах безальтернативно засосало в libc, включая ее кастрированные варианты.При этом какая-нибудь libpthread - по сей день отдельная сущность, хотя вот зачем ей быть отдельной - совершенно неясно (использование name resolving - это вопрос области применения программы, она предсказуема, использование позикс-тредов - исключительно вопрос дизайна, ты никогда не будешь уверен, что очередная программа их не использует или в следующей версии вдруг не начнет)
"Людям" может сколько угодно не нравиться - но шансы, что устройства внутри будут со временем обмениваться инофрмацией по IP и с каким-то ресолвингом близки к 100% - как только число этих устройств за сотню перевалит. И то, что хорошая доля будет (как минимум, опосредованно) общаться ещё и со вненим миром - дорогой, другими машинами и т.д. - тоже понятно. И то, что весь этот зоопарк должен уметь отдавать диагностику (вероятно - удалённо) и обновлять фирмварь. В общем, куда б те "люди" делись, разве что обратно в пещеры.Впрочем, насчёт того, что libpthread совершенно напрасно отдельная сущность - согласен.
> При этом какая-нибудь libpthread - по сей день отдельная сущность,как часть проекта glibc
> ... хотя вот зачем ей быть отдельной - совершенно неясно
наверное, чтобы можно было строить non-MT приложения (убирая overhead), если автор так видит.
> При этом какая-нибудь libpthread - по сей день отдельная сущность, хотя вот зачем ей быть отдельной - совершенно неясно (использование name resolving - это вопрос области применения программы, она предсказуема, использование позикс-тредов - исключительно вопрос дизайна, ты никогда не будешь уверен, что очередная программа их не использует или в следующей версии вдруг не начнет)libc имеет несколько реализаций posix-threads. На линуксе стандартом используется NPTL, но есть и более кроссплатформенная реализация, которая позволяет glibc существовать и на системах где нет ядра linux. Вероятно при этом, включение posix-threads в configure влияет не только на то, что создаётся ещё один бинарь -- libpthreads.so, -- но и на другие части, делая тот или иной код совместимым с libpthreads (впрочем это лишь предположение, я не могу указать ни одного куска такого кода).
А вот код резолвера нет смысла держать в нескольких вариантах. При этом приложение может просто игнорить этот код: он совершенно определённо ни на что не влияет. Пока ни одно приложение его не использует, этот код лежит на диске внутри файлика libc.so, никак не влияя на работу приложения или других частей libc. Я практически уверен в том, что ядро даже не читает в память ненужные куски бинарей -- я сомневаюсь слегка, потому что читал ядро и ldd, выясняя как это работает, лет десять назад, и у меня могло в голове всё перепутаться с тех пор. Но насколько я помню, там просто выполняется mmap на файл, но физическая память не выделяется -- затем уже, по мере того как вылетают исключения связанные с обращениями к несуществующим страницам, маппинг реализует себя и копирует страницы с жёсткого диска в память. Так вот, если ни одно приложение не использует gethostbyname и прочие функции резолвера, весь этот код мирно лежит на диске и никому не мешает. Это, тем не менее, может быть существенно для каких-нибудь embedded устройств с сильно ограниченной в размере флешкой вместо нескольких терабайт жёстких дисков и SSD, но glibc был создан не для этих устройств.
Это было бы логично
Через систему инициализации systemd! )
Школотрон, либц это единственное место, где резолверу место
Агащазблин. А как дела с асинхронным резолвером в глибцах?
Асинхронность делай сам, для этого тебе дадены gethostbyname_r и gethostbyname2_r.
Вапсчето"The gethostbyname*() and gethostbyaddr*() functions are obsolete. Applications should use getaddrinfo(3) and getnameinfo(3) instead."
> "The gethostbyname*() and gethostbyaddr*() functions are obsolete. Applications should
> use getaddrinfo(3) and getnameinfo(3) instead."да-да, а то иначе ipv6 дыры могут ненароком их не зацепить.
(ага, эти интерфейсы принесены нам теми же людьми)
>Асинхронность делай сам, для этого тебе дадены gethostbyname_r и gethostbyname2_r.Вот такие идиоты работают в профессии. Вон из профессии!
Все резолверы _уже_ написаны, например, adns, c-ares и т.д. Те, кто жалуется на glibc либо не знают, что до них все написали, либо троли. Что касается самого glibc, то мне лично побарабану, что они там изобретают, т.к. это по факту шлак. И этот шлак годится только для лаб и курсовых, а в производстве это фуфло меняется на что-то действительно полезное.
> они там изобретают, т.к. это по факту шлак. И этот шлак
> годится только для лаб и курсовых, а в производстве это фуфло
> меняется на что-то действительно полезное.Праильнаящитаю! KERNEL.EXE фарева.
А производстве чего, стесняюсь спросить?
> (ранее первым всегда использовался сервер, указанным вторым в списке)Не только лишь всегда, но и когда в списке один? :)
единственную важную (и, увы, нерадостную) часть новости, как обычно, пыонэры даже не замечают. :-(Ну ладно, я может сдохнуть успею еще, пока оно не доберется до неновых-немодных дистрибутивов...
(да, я про rpc)
++ много
Хм, единственное реальное их использование я видел для NFS, которая сама по себе - то ещё подарок (и как по мне - концептуально неверная идея). Опять же - не удалили, а заменили.
> (да, я про rpc)И в чём проблема, комсомолец? Тебе же дали альтернативу да ещё и с поддержкой IPv6. Или тебе шашеч^W слово SUN так нравится?
мне совершенно не нужна "альтернатива" в виде дыры-v6. Разработанная комсомольцами с горящими сердцами и пустыми головами (кто, какие идиоты используют rpc over v6? Это ж девственные джунгли граблей от моря до моря), никому неинтересная, и поэтому гарантированно гнилая.если бы вместо этого выбросили nss_плагины, целиком, вместе с бредовой идеей, украденной у sun (когда-то очень давно было модно не "как в виндовс", а "как у больших" - и тоже без малейшей попытки остановиться и подумать, зачем нам еще одно как-у-больших глюкало, если оно и так есть, для желающих, "и в общем, недорого") - еще можно было бы принять такой trade-off.
А отсутствие rpc в libc - это, по сути, еще больший уход от нормальной юникс-системы в сторону yблюдства "как в виндовс, только НАХАЛЯВУ", причем без каких либо положительных моментов.
ну так пока дойдёт до "неновых-немодных" - разгребут грабли. Учитывая, что IPv6 уже неизбежен (чему лично я только рад) - ворчать тут не на что. Опять же - кто Sun RPC вообще использует?
> ну так пока дойдёт до "неновых-немодных" - разгребут грабли. Учитывая, что IPv6
> уже неизбежен (чему лично я только рад) - ворчать тут не
> на что. Опять же - кто Sun RPC вообще использует?program version netid address service owner
100000 4 tcp 0.0.0.0.0.111 rpcbind superuser
100000 3 tcp 0.0.0.0.0.111 rpcbind superuser
100000 2 tcp 0.0.0.0.0.111 rpcbind superuser
100000 4 udp 0.0.0.0.0.111 rpcbind superuser
100000 3 udp 0.0.0.0.0.111 rpcbind superuser
100000 2 udp 0.0.0.0.0.111 rpcbind superuser
100000 4 local /var/run/rpcbind.sock rpcbind superuser
100000 3 local /var/run/rpcbind.sock rpcbind superuser
100000 2 local /var/run/rpcbind.sock rpcbind superuser
660035415 6 tcp 0.0.0.0.39.168 - unknownкто опознал - респект ;-)
нет, это не линукс, конечно, там уже и не заведется, наверное. Mar 25 2002 бинарничек, ага.
Все еще работает.
Ну так из того, что у вас там крутится, его никто и не забирает. А я вот в дебиане не вижу ни одного пакета, зависящего этой ерунды, когторый я бы в здравом уме стал использовать.
и нет, не разгребут уже - некому.
Скорее уж nfs доломают окончательно и бесповоротно.
Ну и к лучшему. Она нынешним реалиям напрочь не адекватна, как и любые другие попытки сымитировать локальное взаимодействие поверх сетевого без оглядки на специфические реалии конкретного проекта. А с оглядкой - как правило, проще и надёжнее по HTTP какую-то более вменяемую логику организовать.
> Ну и к лучшему. Она нынешним реалиям напрочь не адекватнаситуации, когда fs экспортируют системе а не юзеру - вполне адекватна и поныне. Хотя и распространена гораздо меньше.
> на специфические реалии конкретного проекта. А с оглядкой - как правило,
> проще и надёжнее по HTTP какую-то более вменяемую логику организовать.ну и если вам http проще и надежнее - то флаг, конечно, в руки.
А я лучше уж с сасамбой останусь, раз вариантов нет - хотя она и не проще, и не надежнее nfs, и даже быстрее далеко не всегда.
Экспорт удалённых данных в виде FS плох тем, что клиент не знает, что он работает с сетью и, как правило, ни черта не готов к отказам (а часто - и к задержкам). При работе HTTP всё это остаётся явным и обычно более-менее обрабатывается, а при желании - может быть обработано очень хорошо. Больше того - с FS куча информации просто теряется - там банально нет средств отдать достаточно детальную диагностику, сравнимую хотя бы с теми же кодами HTTP.То же касается и nfs - она, может, и нормально жила бы там, где понимают, что это сеть, и с надёжностью у неё... скажем так, по всякому. В этом смысле как раз для системы её тянуть - так себе идея, благо минимальныое локальное хранилище стоит копейки, а удалённо апдейты накатывать его наличие не мешает. А вот самба, которая при всём своём безумии, обычно используется просто как удалённое харнилище пользовательских документов, в итоге выходит чуть поспокойнее - потому что паттерн использования другой.
Вообще все эти архитектурные решения - они процентов на 70 не о железках, а о людях.
v6 сдох давно, никогда его не внедрят, уже мплс внедрили, уже 3х факторный нат для п2п внедрили, и всеравно v4 еще есть, и смысл. скорее фсбэшный идентификатор гражданина внедряд туда, где не светит солнце.
вы же понимаете, при наличии большой дубины, "внедрить" вам могут и дохлого крота, даже давно уже дохлого.А дубина в лице icann/ripe/прочих у нас есть. И гугль поддержит.
Регулятор, на то и регулятор, что напрямую не вмешивается, ни запретить, ни заставить не могут, рекомендовать и только, всем сра-ть.Гугл давно уже сдулся,есть альтернативы че они решают, апи в андоиде, дальше что, дальше все.
https://www.google.com/intl/en/ipv6/statistics.htmlВот примерно так и "сдыхает", по 50% в год.
То есть для вас стакан уже на 22% заполнен, а для меня он на 78% пуст
Для меня стабильно ускоряющийся рост распространённости (по есть положительная производная) никак не означает "умирает".
> мне совершенно не нужна "альтернатива" в виде дыры-v6.Печально... Даже не знаю, что тебе предложить, кроме как "сделать вдоль" :(
этой "новости" сто лет в обед. и глибцы с --enable-obsolete-rpc приходится собирать уже хрен знает какой релиз
как я понимаю, смысл новости противоположный - "а мы это enable наконец-то доломали".
> этой "новости" сто лет в обед. и глибцы с --enable-obsolete-rpc приходится собирать
> уже хрен знает какой релиз"Тише-тише, профкссионала спугнёшь."
>> этой "новости" сто лет в обед. и глибцы с --enable-obsolete-rpc приходится собирать
>> уже хрен знает какой релиз
> "Тише-тише, профкссионала спугнёшь.""Тише-тише", он не просто "профкссионал", он "мишин учитель"!
Самое существенное новшестство данного выпуска - 128-битная вещественная арифметика.
теперь случайным образом выбирается сервер имён, который будет использован первымЖуть.. скоро и math будет флоат вычислять случайным образом.
А когда и тип возвращаемого значения будет случайным, то получим PHP:)