После шести месяцев разработки состоялся (https://sourceware.org/ml/libc-alpha/2016-02/msg00502.html) релиз системной библиотеки GNU C Library (http://ftp.gnu.org/gnu/glibc/) (glibc) 2.23 (http://sourceware.org/glibc/wiki/Release/2.23), которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2008. В подготовке нового выпуска использованы патчи от 74 разработчиков.
Из добавленных в Glibc 2.23 улучшений (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h...) можно отметить:
- Поддержка Unicode 8.0.0: обновлены все кодировки, информация о типах символов и таблицы транслитерации, для которых также задействованы новые или обновлённые скрипты генерации, позволившие закрыть несколько давно висевших отчётов об ошибках;- Вызовы sched_setaffinity и pthread_setaffinity_np теперь не пытаются угадать внутренние параметры активных CPU в ядре, что позволило исключить сбои при попытке изменения привязки процессов к определённым CPU (CPU affinity). В случае необходимости определения эффективных привязок CPU в приложениях следует вызывать функцию sched_getaffinity или pthread_getaffinity_np, так как ранее заданные установки могут быть откорректированы ядром;
- При сборке с опцией "-D_FILE_OFFSET_BITS=64" теперь можно использовать заголовочный файл fts.h, в котором для больших файлов предлагаются новые вызовы fts64_children, fts64_close,
fts64_open, fts64_read и fts64_set;- В функцию getaddrinfo добавлена проверка на наличие некоторых некорректных ответов через внутренний сокет netlink. В случае поступления подобных ответов, подверженный проблеме процесс будет завершён с сообщением о непредвиденной ошибке ("Unexpected error NUM on netlink descriptor NUM" или " "Unexpected netlink response of size NUM on descriptor NUM"), так как наиболее вероятной причиной повреждения ответа является ошибочное повторное использование закрытого файлового дескриптора netlink в многопоточных приложениях;
- Устранён дефект в реализации вызова malloc, связанных с выполнением лишних запросов на сериализацию памяти в многопоточных приложениях, с большой частотой создающих и завершающих потоки. Проблема проявлялась начиная с glibc 2.15 (2012 гол) или начиная с glibc 2.10 при сборке с опцией "--enable-experimental-malloc" (2009 год). После устранения ошибки наблюдается значительное увеличение пропускной способности одновременных запросов на распределение памяти
- Добавлена новая сборочная опция "--disable-timezone-tools", дающая возможность отключить сборку и установку утилит, связанных с обработкой баз часовых поясов (zic, zdump и tzselect);- Удалён устаревший заголовочный файл "regexp.h", вместо которого следует использовать "regex.h";
- Удалён заголовочный файл "sys/kdaemon.h", а устаревшие функции bdflush, create_module, get_kernel_syms,
query_module и uselib теперь недоступны для вновь скомпонованных бинарных файлов. Данный заголовочный файл и функции специфичны для систем на базе ядра Linux и потеряли смысл на системах с ядром Linux новее 2.6;
- Проведена оптимизация строковых операций, функций работы с памятью и вызовов wcsmbs для систем IBM z13;- Вновь скомпонованные программы, в которых определена переменная signgam, теперь не смогут установить её через функции lgamma, lgammaf и lgammal, так как данная переменная теперь определена в заголовочном файле math.h;
- Для сборки Glibc 2.23 теперь требуется как минимум GCC 4.7, для сборки связанных с Glibc программ по-прежнему могут применяться старые версии GCC и иные компиляторы;
Устранены уязвимости:
- CVE-2015-7547 - несколько дней назад анонсированная (https://www.opennet.dev/opennews/art.shtml?num=43886) критическая уязвимость в libresolv, позволяющая удалённо выполнить код в системе, при резолвинге подконтрольного атакующему доменного имени в любом приложении, использующем вызов getaddrinfo(). Проблема является одной из самых опасных уязвимостей за последнее время и может проявиться в широком спектре клиентских и серверных программ, от почтовых серверов до web-приложений на PHP и Ruby on Rails;
- CVE-2015-8776 - крах, вызванный обращением за границы буфера для структуры tm при вызове функции strftime;- CVE-2015-8777 - возможность использования переменной окружения LD_POINTER_GUARD для отключения механизмов защиты указателей в исполняемых файлах, запущенных в режиме AT_SECURE;
- CVE-2015-8778 - целочисленное переполнение в функциях hcreate и hcreate_r, которое может привести к обращению к областям памяти вне границ буфера;
- CVE-2015-8779 - выход за границы стека в функции catopen ** CVE-2014-9761 - выход за границы стека при обработке слишком больших строк в функциях nan, nanf и nanl;- Закрыто 264 отчёта об ошибках.
URL: https://sourceware.org/ml/libc-alpha/2016-02/msg00502.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=43910
>В функцию getaddrinfo добавлена проверка на наличие некоторых некорректных ответов через внутренний сокет netlink, так как наиболее вероятной причиной повреждения ответа является ошибочное повторное использование закрытого файлового дескриптора netlink в многопоточных приложенияхТ. е. убивают процесс на основании того, что кому-то что-то показалось. Ооок.
Нет, на основании повреждения ответа. Точно так же как сейчас при повреждении например кучи.
Если говорить конкретно getaddrinfo - то клиент отправляет запрос и получает ответ, тут всё просто. Поэтому у Mr. Cake всё правильно. Я также сначала подумал, перечитал, и понял, в предложении ведь не уточняется какого именно ответа. А значит надо брать самый очевидный ответ - клиент падает при получении кривого ответа.
подскажите пожалуйста, а после обновления glibc, нужно ли следом пересобрать весь "мир"? или достаточно перезагрузиться? т.е. необходимо перезапустить все программы, в которых используется getaddrinfo(), чтобы они подхватили новую исправленную версию библиотеки glibc?
> подскажите пожалуйста, а после обновления glibc, нужно ли следом пересобрать весь "мир"?
> или достаточно перезагрузиться? т.е. необходимо перезапустить все программы, в которых
> используется getaddrinfo(), чтобы они подхватили новую исправленную версию библиотеки
> glibc?В обычной генту, скомпилированной без особых изысков, достаточно будет перезагрузиться, т.к. всё слинковано динамически. Возможно, часть системных вещей типа busybox может быть слинкована статически - их надо будет пересобрать, но это смотрите свой профайл.
в генте бизибокс с глибц?
> в генте бизибокс с глибц?Судя по FAQ bb: https://busybox.net/FAQ.html#libc
поддерживаются uClibc и glibc, по дефолту в большинстве x86 profile'ов используется glibc. Соответствено, я предполагаю, что оно будет линковаться с glibc.
Насколько я понимаю,1. бинарная совместимость, которую glibc жестко поддерживает, позволяет использовать старые программы с новой glibc, и
2. перезагружаться не надо, заново запущенные процесс начнут использовать новую glibc, т.е. сервисы нужно перезагрузить, а init раньше нужно было сказать telinit q и он использовал новую glibc, как с systemd не знаю, но он, наверняка тоже умеет без перезагрузки.
Это если у тебя Linux, как на винде не в курсе.
> Насколько я понимаю,
> 1. бинарная совместимость, которую glibc жестко поддерживает, позволяет использовать
> старые программы с новой glibc, и
> 2. перезагружаться не надо, заново запущенные процесс начнут использовать новую glibc,
> т.е. сервисы нужно перезагрузить, а init раньше нужно было сказать telinit
> q и он использовал новую glibc, как с systemd не знаю,
> но он, наверняка тоже умеет без перезагрузки.
> Это если у тебя Linux, как на винде не в курсе."перезагрузиться" используется в смысле "легкий способ перезапустить все процессы".
> как с systemd не знаюsystemctl daemon-reexec
Уже отправлена в сизиф коллегой, принявшим участие в разработке. :)
А можно узнать процент вклада от общего обёма строк?
Как вы используете этот процент?
> Как вы используете этот процент?Целому одному мы все тут устроим стоячую овацию.
Остальные уже использовали? ;-)
Разве отвечать вопросами на вопрос для джентельменов это приемлемо?
Вполне. У некоторых национальностей это даже традиция.
>> Как вы используете этот процент?
> Целому одному мы все тут устроим стоячую овацию.У вас что-то не так с приведением типов. Один целый (int i = 1) не может содержать процент (float).
>>> Как вы используете этот процент?
>> Целому одному мы все тут устроим стоячую овацию.
> У вас что-то не так с приведением типов. Один целый (int i
> = 1) не может содержать процент (float).Ты меня с _чем_-то путаешь. То ли с конпелятором,то ли с калькулятором.
>>>> Как вы используете этот процент?
>>> Целому одному мы все тут устроим стоячую овацию.
>> У вас что-то не так с приведением типов. Один целый (int i
>> = 1) не может содержать процент (float).
> Ты меня с _чем_-то путаешь. То ли с конпелятором,то ли с
> калькулятором.Ну если ты что-то, то так тебе и надо. Самоопределение красноречивое.
несмотря на читаемый сарказм, все контрибуторы - Важны.
на самом деле сдедующаыя либа - еще интереснее будет, там список измнений и улучшений - более впечатляющий, но она будет хотеть уже не то 5.2 не то 5.3 GCC, что в общем-то - скорее плюс, чем минус, тоже.
Шигорин никогда не упустит шанс пропиарить Альт.Нет, за качество Альта ничего не говорю, но сам PR выглядит немного комично.