После шести месяцев разработки состоялся (https://sourceware.org/ml/libc-alpha/2017-02/msg00079.html) релиз системной библиотеки GNU C Library (http://ftp.gnu.org/gnu/glibc/) (glibc) 2.25 (http://sourceware.org/glibc/wiki/Release/2.25), которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2008. В состав нового выпуска включены исправления от 51 разработчика.
Из добавленных в Glibc 2.25 улучшений (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h...) можно отметить:- Обеспечена возможность сборки большей части glibc в режиме защиты стека от переполнения. Сборка с опцией "--enable-stack-
protector=strong" переведена в разряд рекомендованных;- В состав включены функции getentropy и getrandom, а также связанный с ними заголовочный файл sys/random.h. Getentropy и getrandom предложены проектом OpenBSD и предоставляют возможность получения значений от системного генератора псевдослучайных чисел через обращение к системному вызову, что обеспечивает надёжную защиту от атак, основанных на исчерпании доступных файловых дескрипторов (при отсутствии свободных дескрипторов невозможно задействовать /dev/urandom);
- Из OpenBSD перенесена функция explicit_bzero, предлагаемая как аналог memset() для очистки буферов, содержащих важные данные. Смысл использования explicit_bzero в исключении ситуаций, когда оптимизатор компилятора может посчитать вызов memset излишним и удалить его, что приведёт к оставлению в памяти важных данных, подлежащих очистке;
- В libc добавлены функции преобразования в строковое представление чисел с плавающей запятой (strfromd, strfromf и strfroml), определённые в стандарте ISO/IEC TS 18661-1:2014;
- В заголовочный файл math.h добавлена большая порция новых возможностей, определённых в стандарте TS 18661-1:2014:- Макросы, указывающие о присвоении значения NaN: SNANF, SNAN, SNANL;
- Функции для округления целых чисел: roundeven, roundevenf, roundevenl,
fromfp, fromfpf, fromfpl, ufromfp, ufromfpf, ufromfpl, fromfpx,
fromfpxf, fromfpxl, ufromfpx, ufromfpxf, ufromfpxl;- Функции вычисления логарифмов llogb, llogbf и llogbl, и связанные с ними макросы FP_LLOGB0 и FP_LLOGBNAN;
- Функции определения максимальных и минимальных значений: fmaxmag, fmaxmagf, fmaxmagl, fminmag,
fminmagf, fminmagl;
- Макрос для сравнения: iseqsig;
- Макросы проверки значений: iscanonical, issubnormal, iszero;
- Функции для работы с упорядоченными множествами: totalorder, totalorderf, totalorderl,
totalordermag, totalordermagf, totalordermagl;
- Функции приведения к канонической форме: canonicalize, canonicalizef, canonicalizel;
- Функции для обработки значений NaN: getpayload, getpayloadf, getpayloadl, setpayload,
setpayloadf, setpayloadl, setpayloadsig, setpayloadsigf,
setpayloadsigl.- Добавлена поддержка тестовых макросов __STDC_WANT_LIB_EXT2__,
__STDC_WANT_IEC_60559_BFP_EXT__ и __STDC_WANT_IEC_60559_FUNCS_EXT__, позволяющих включить определения c наборами функций, предложенных в спецификациях ISO/IEC TR 24731-2:2010, ISO/IEC
TS 18661-1:2014 и ISO/IEC TS 18661-4:2015. Тестовый характер макросов обусловлен тем, что не все функции из указанных спецификаций пока реализованы;- Нестандартные макросы выбора режимов работы _REENTRANT и _THREAD_SAFE для обеспечения совместимости теперь обрабатываются как синонимы вызова "_POSIX_C_SOURCE=199506L". Изменение поведения отразится только на программах, собранных в режимах совместимости со старыми стандартами. Например, видимые объявления изменятся при сборке с опциями "-std=c89 -D_REENTRANT", но останутся прежними при сборке с опциями "-D_REENTRANT" или "-std=c99
-D_POSIX_C_SOURCE=200809L -D_REENTRANT";- Объявлено устаревшим включение заголовочного файла sys/sysmacros.h из sys/types.h, который в свою очередь вызывается из stdlib.h при работе в режиме _GNU_SOURCE. В будущих выпусках макросы
"major", "minor" и "makedev" будут доступны только при явном подключении sys/sysmacros.h. Данные макросы не определены в спецификациях POSIX и XSI, поэтому бывает, что их имена конфликтуют с кодом приложений;- Добавлен новый заголовочный файл fenv.h, определённый в спецификации TS 18661-1:2014. Через fenv.h импортируются присутствующие в libm функции fesetexcept, fetestexceptflag, fegetmode и fesetmode, тип femode_t, а также макросы FE_DFL_MODE и FE_SNANS_ALWAYS_SIGNAL;
- В заголовочный файл limits.h добавлен набор макросов, определённых в стандарте TS 18661-1:2014:
CHAR_WIDTH, SCHAR_WIDTH, UCHAR_WIDTH, SHRT_WIDTH, USHRT_WIDTH,
INT_WIDTH, UINT_WIDTH, LONG_WIDTH, ULONG_WIDTH, LLONG_WIDTH,
ULLONG_WIDTH;
- В заголовочный файл stdint.h добавлен набор макросов, определённых в стандарте TS 18661-1:2014: INT8_WIDTH, UINT8_WIDTH,
INT16_WIDTH, UINT16_WIDTH, INT32_WIDTH, UINT32_WIDTH, INT64_WIDTH,
UINT64_WIDTH, INT_LEAST8_WIDTH, UINT_LEAST8_WIDTH, INT_LEAST16_WIDTH,
UINT_LEAST16_WIDTH, INT_LEAST32_WIDTH, UINT_LEAST32_WIDTH,
INT_LEAST64_WIDTH, UINT_LEAST64_WIDTH, INT_FAST8_WIDTH,
UINT_FAST8_WIDTH, INT_FAST16_WIDTH, UINT_FAST16_WIDTH,
INT_FAST32_WIDTH, UINT_FAST32_WIDTH, INT_FAST64_WIDTH,
UINT_FAST64_WIDTH, INTPTR_WIDTH, UINTPTR_WIDTH, INTMAX_WIDTH,
UINTMAX_WIDTH, PTRDIFF_WIDTH, SIG_ATOMIC_WIDTH, SIZE_WIDTH,
WCHAR_WIDTH, WINT_WIDTH;
- На платформах ColdFire, MicroBlaze, Nios II и SH3 тип float_t теперь определяется как float вместо double;- На платформе x86_64 при сборке в режиме "-mfpmath=387" или "-mfpmath=sse+387" (не применяются по умолчанию) типы float_t и double_t теперь определяются как "long double" вместо float и double. Данное изменение не влияет на ABI библиотек из состава Glibc, но влияет на ABI других библиотек, собранных с отмеченными опциями;
- Размер буфера байтовых потоков stdio теперь по умолчанию ограничен 8192 байтами (ранее в применялось значение в 4096 байт);
- В заголовочном файле sys/quota.h обеспечено включение файла linux/quota.h. Поддержка устаревшего интерфейса квот Linux, которая использовалась в ядрах до 2.4.22, удалена;
- Удалены функции malloc_get_state и malloc_set_state, но для уже динамически связанных исполняемых файлов оставлены скрытые заглушки. Из существующих проектов данные функции используются только в GNU Emacs, работоспособность сборок которого, благодаря реализованным заглушкам, не нарушится;
- Из resolv.h удалены опции "ip6-dotint", "no-ip6-dotint" и "ip6-bytestring", завязанные на неиспользуемые в сети расширения. Объявлены устаревшими флаги RES_USE_INET6, RES_AAONLY, RES_PRIMARY, RES_NOCHECKNAME, RES_KEEPTSIG и RES_BLAST, а также опция "inet6" в /etc/resolv.conf;
- Из arpa/nameser.h удалены все объявления, связанные с DNSSEC. Библиотека libresol больше не пытается самостоятельно декодировать записи DNSSEC. Из arpa/nameser.h также удалены макросы ns_t_qt_p, ns_t_mrr_p, ns_t_rr_p, ns_t_udp_p и ns_t_xfr_p;
- Для поддержки multi-arch для сборки Glibc рекомендовано использовать GCC с поддержкой режима косвенного вызова функций ('--enable-gnu-indirect-function');
- В POSIX Threads для мьютексов и условных переменных структур добавлены обработчики наглядного вывода для GDB через команды 'print' и 'display';
- Добавлена возможность тонкой настройки runtime-компонентов для определённых приложений ('--enable-tunables');- Реализован новый вариант функции pthread_rwlock, основанный на более масштабируемом алгоритме, не использущем критические секции для изменения состояния;
- Устранены две уязвимости:- CVE-2016-6323 (https://security-tracker.debian.org/tracker/CVE-2016-6323) - функция makecontext генерировала обратную трассировку (backtrace), приводящую к краху на 32-разрядных системах с ARM EABI. Например, проблема могла использоваться для вызова отказа в обслуживании программ на языке Go, собранных компилятором gccgo;
- CVE-2015-5180 (https://security-tracker.debian.org/tracker/CVE-2015-5180) - разыменование нулевого указателя в резолвере при обработке специально оформленной DNS-записи с типом RR.
URL: https://sourceware.org/ml/libc-alpha/2017-02/msg00079.html
Новость: http://www.opennet.me/opennews/art.shtml?num=45985
>Из OpenBSD перенесена функция explicit_bzero, предлагаемая как аналог memset() >для очистки буферовКакое-то кривое решение
Хм, нужно было назвать: volatile_memset()
> Какое-то кривое решениеЕсть предложения получше?
конечно
сказать компилятору, что бы не "оптимизировал" участок кода.более того, gcc уже умеет в volatile / push_options
зачем плодить сущности?
> конечно
> сказать компилятору, что бы не "оптимизировал" участок кода.
> более того, gcc уже умеет в volatile / push_options
> зачем плодить сущности?Поясните, пожалуйста.
И, да, explicit_bzero() не завязана на фичи конкретного компилятора, что как бы тоже плюс.
> в исключении ситуаций, когда оптимизатор компилятора
> может посчитать вызов memset излишним и удалить егоБорьба писателей компилятора с писателями системной либы? Маразматичненько так...
садись, два
>Размер буфера байтовых потоков stdio теперь по умолчанию ограничен 8192 байтамиэпохальненько. релиз вообще тянет на 2.5, а не на минорщину.
"Однако... Два двадцать пять..." (с)
Был уже такой релиз - в 2006 году
> - Обеспечена возможность сборки большей части glibc в режиме защиты стека
> от переполнения. Сборка с опцией "--enable-stack-
> protector=strong" переведена в разряд рекомендованных;Поясните простому DebSid-юзеру, ни разу не программисту... А что, библиотеку можно кусками собрать?
>> - Обеспечена возможность сборки большей части glibc в режиме защиты стека
>> от переполнения. Сборка с опцией "--enable-stack-
>> protector=strong" переведена в разряд рекомендованных;
> Поясните простому DebSid-юзеру, ни разу не программисту... А что, библиотеку можно кусками
> собрать?Можно, один C-модуль за другим. ;)
Но формулировка в новости, действительно, звучит странно.
поясняю: нет, тебе нельзя. Речь о том, что даже c --enable-stack-protector=strong некоторые куски все равно собираются без -fstack-protector, потому что он их ломает.(вообще-то фича скорее вредная, чем полезная)
> потому что он их ломаетЭто потому, что надо писать код аккуратно и без грязных хаков. Тогда ничего ломать не будет.
Восхитительная наивность. Это всё-таки libc, а не библиотечка, вызываемая раз в полгода тремя приложениями. Здесь эффективность важнее красоты.
Ну-ну. Напиши что-нибудь типа longjmp или setcontext под стек-протектором, а потом рассказывай о том, как надо писать libc без грязных хаков.
Подозреваю, что если собрать все эти модные фичи дя безопасности, которые "практически не сказываются на производительности", то в сумме они эту производительность просаживают раза в два.
Это все запоздалая реакция на то, что в пользовательском коде сишники ленятся проверить выход за границы буфера, считая, наверно, это уделом холопов и гнокодеров из MS. А еще "производительность просаживается". Вот и пришлось городить на уровне libc, что бы ЧСВ сишников не страдало, и ошибки отлавливались, а не превращались в CVE.А нужно всего лишь элементарную гигиену в пользовательском коде применять и тесты писать. Тогда и костыли в libc не понадобятся
То-то, я смотрю, у разных пыхеров и прочих рубистов CVE ну ни одного не видать
А проблемы с prelink уже пофиксили?
https://bugs.gentoo.org/show_bug.cgi?id=579374
Живём только с патчем из 8-го коммента
> А проблемы с prelink уже пофиксили?
> https://bugs.gentoo.org/show_bug.cgi?id=579374
> Живём только с патчем из 8-го комментаhttp://patchwork.sourceware.org/patch/11998/
Патчь-ревю процесс с веб-два-нуль-фейсом -- работает же, смотрите! //отдельные бонусы [нет, не призы-] тому, кто найдёт glibc-devel ML archive. и спасибо редхатту!
>//отдельные бонусы [нет, не призы-] тому, кто найдёт glibc-devel ML archive.От,я старый ----к, sourceware.org/ml/libc-alpha/ же вроде. Вверу написано. Всем спасибо.
> и спасибо редхатту!
Собираю с Glibc 2.12 и запускаю в 2.22. Многое теряю? Софт на GTK.
> Собираю с Glibc 2.12 и запускаю в 2.22. Многое теряю? Софт напока собирается (и запускается) - ничего не теряешь.
Когда перестанет - ну ты понял, да?P.S. ну, надеюсь, майнтейнеры твоей 2.22 уже заткнули вручную CVE-2015-5180 - два года уже, как-никак (вроде бы в некоторых случаях может и remote root выйти)
Объясните почему в стандартной библиотеке столько не нужного. Почему нельзя разделить стандартную библиотеку от другого функционала, который не в стандарте. Почему со стандартными библиотеками (glibc,musl) идут системные вызовы linux, динамичемкий линковщик (загрузчик). Все программы линкуются с ним, даже C++. Разве он не должен идти в состав линковщика ld?
> не нужного.Уроки учи, читай букварь.
Не нужное - то что не входит в стандартную библиотеку. Стандартная библиотека - asset.h, complex.h, ctype.h, string.h, stdio.h и т.д. Помимо много других заголовочных файлов. Они не входят в стандартную библиотеку СИ.
> Не нужноеУроки учи. В первую очередь - грамматику.
А ты с людьми научись нормально общатся. А если не умееш - лучше молчи, не отвечай ничего.
Вам ответили несколько грубовато, но в целом по делу.
Тяжелое наследие. Еще спроси почему модулей нет и компиллятор однопроходный.
Понятно. Спасибо.