После шести месяцев разработки состоялся (https://sourceware.org/ml/libc-alpha/2018-02/msg00054.html) релиз системной библиотеки GNU C Library (http://ftp.gnu.org/gnu/glibc/) (glibc) 2.27 (http://sourceware.org/glibc/wiki/Release/2.27), которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2008. В состав нового выпуска включены исправления от 73 разработчиков. Примечательно, что мэйнтейнером выпуска 2.27 (https://sourceware.org/glibc/wiki/Release/2.27) стал (https://sourceware.org/glibc/wiki/Release) Дмитрий Левин, генеральный конструктор ALT Linux.
Из добавленных в Glibc 2.27 улучшений (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h... можно отметить:- Реализованы новые функции memfd_create и mlock2, специфичные для платформы Linux. Функция memfd_create позволяет создавать области маппинга памяти при помощи механизма memfd, при котором область памяти идентифицируется через файловый дескриптор, который может передаваться между процессами (можно выделить память как по malloc, но обращаться к ней как с файлом, по файловому дескриптору). Функция mlock2 расширяет возможности вызова mlock() поддержкой дополнительного аргумента, позволяющего задействовать новый режим блокировки VM_LOCKONFAULT, при котором страницы памяти в указанном диапазоне будут закреплены в ОЗУ не сразу, а только после возникновения page fault (обращение к невыделенным страницам памяти);
- Добавлена поддержка механизма PKU (Memory Protection Keys (https://en.wikipedia.org/wiki/Memory_protection#Protection_k... реализованного в серверных моделях процессоров Intel на базе микроархитектуры Skylake для защиты доступа к страницам памяти из пространства пользователя, без изменения таблиц страниц памяти при изменении домена защиты. Для использования данного режима в sys/mman.h добавлены функции pkey_alloc, pkey_free, pkey_mprotect, pkey_set и pkey_get, которые можно использовать для дополнительной защиты размещения в памяти ключей шифрования, предоставив возможность чтения только для одного потока в многопоточной программе шифрования;
- Добавлена функция copy_file_range, позволяющая ускорить выполнение операций копирования данных из одного файла в другой файл с выполнением операции только на стороне ядра, без предварительного чтения данных в память процесса, что избавляет от частого переключения контекста между ядром и пространством пользователя. Тем не менее, в обычных условиях использование copy_file_range лишь немного быстрее обычной команды "cp", так как основное время уходит на ввод/вывод с накопителя;- Добавлена возможность компиляции Glibc (опция "--enable-static-pie") с поддержкой сборки статически связанных исполняемых файлов в формате PIE. По сравнению с обычными статическими исполняемыми файлами подобные файлы в формате PIE могут быть загружены по любому адресу и предоставляют дополнительные средства защиты, ценой определённого повышения потребления памяти и снижения производительности. При сборки Glibc с опцией "--enable-static-pie" формируется файл libc.a, который можно использовать с компилятором GCC 8, для создания статических файлов PIE при указании опции '-static-pie'. Возможность реализована для архитектур i386, x86_64 и x32 (требуется binutils 2.29), а также aarch64 (требуется binutils 2.30);
- Добавлена поддержка архитектуры RISC-V, которая предоставляет открытую и гибкую систему машинных инструкций, позволяющую создавать микропроцессоры для произвольных областей применения, не требуя при этом отчислений и не налагая условий на использование. RISC-V позволяет создавать полностью открытые SoC и процессоры. Для использования RISC-V также требуется binutils 2.30, gcc 7.3.0 и ядро Linux 4.15;
- Проведена оптимизация кода функций asin, atan2, exp, expf, log, pow, atan, sin, cosf, sinf, sincosf и tan с задействованием набора инструкций FMA (https://en.wikipedia.org/wiki/FMA_instruction_set) (Fused Multiply–Add) на платформе x86-64;- Проведена оптимизация кода функций trunc и truncf с задействованием инструкций SSE4.1 на платформе x86-64;
- Проведены общие платформонезависимые оптимизации кода функций expf, exp2f, logf, log2f, powf, sinf, cosf и sincosf;
- Проведена оптимизация функций memcpy, mempcpy, memmove и memset для процессоров sparc M7;- С целью обеспечения более быстрого и безопасного завершения процессов в наборе функций malloc прекращён вывод информации о адресе сбоя и обратной трассировке стека. Целью изменения является минимизация действий, выполняемых после обнаружения выхода за границы диапазонов памяти, чтобы избежать потенциальных уязвимостей в коде обработки данных ситуаций и сократить время завершения работы процесса;
- В функции abort обеспечено мгновенное завершение процессов, без сброса буферов ввода/вывода в stdio, что снижает вероятность повреждения данных после краха и возникновения ситуаций взаимной блокировки;- В библиотеку математических функций добавлены интерфейсы _Float32, _Float64 и _Float32x в соответствии с требованиями стандарта ISO/IEC TS 18661-3:2015. Для платформ с поддержкой формата IEEE binary128 для типа "long double" (aarch64, alpha, mips64, riscv, s390 и sparc) в библиотеке математических функций также реализованы интерфейсы _Float128 для данного типа;
- В утилите ldconfig при обработке директивы include обеспечена сортировка в соответствии с локалью C/POSIX (ранее использовались правила из текущей локали, что приводило к проблемам);
- Добавлена поддержка двух грамматических форм имён месяцев (например, января и январь). В strftime спецификаторы "%B" и "%b" теперь выводят имена месяца с учётом их грамматической формы в контексте общей даты, а новые спецификаторы %OB" и "%Ob" могут применяться для вывода грамматической формы названия месяца как такового. В функции strptime считаются корректными любые формы имени месяца, обрабатываемые через специфкаторы %B", "%b", "%h", "%OB", "%Ob" и "%Oh". Вызов nl_langinfo выводит форму со склонением при указании флагов MON_1..12 и ABMON_1..12, и нормальную форму при указании флагов ALTMON_1..12 и _NL_ABALTMON_1..12;
- Устаревшая функциональность и изменения, приводящие к нарушению обратной совместимости:
- Изменения в бинарном формате локали не позволяют использовать файлы локали, собранные для Glibc 2.27, в статически скомпилированных приложениях. В этом случае вместо запрошенной локали будет включена локаль C/POSIX, а для корректной загрузки локали требуется перекомпиляция приложения;- Объявлена устаревшей возможность использования в статически скомпилированных приложениях вызова dlopen. Поддержка таких приложений будет прекращена в следующем выпуске. Для подобных программ следует применять динамическое связывание;
- Объявлена устаревшей и будет прекращена в следующем выпуске поддержка старых программ, в которых используются внутренние структуры данных и функции stdio (_IO_*), в том числе программы C++ использующие класс streams из libstdc++ (GCC 2.95);
- Из заголовочного файла sys/ptrace.h убрано определение константы PTRACE_SEIZE_DEVEL на системах GNU/Linux;
- В libm прекращена поддержка обработчиков ошибок SVID (вызов пользовательской функции matherr при ошибке) и применение переменной _LIB_VERSION для управления обработкой ошибок. Прекращена поставка библиотеки libieee.a. Из заголовочного файла math.h убраны определения макросов X_TLOSS, DOMAIN, SING, OVERFLOW, UNDERFLOW,
TLOSS, PLOSS и HUGE;- В новых программах прекращена поддержка функций pow10, pow10f и pow10l вместо которых следует использовать exp10, exp10f и
exp10l;- Прекращена поддержка механизма сборки дополнительных пакетов во время сборки Glibc. Опция "--enable-add-ons" теперь игнорируется;
- Во время сборки теперь не учитывается опция "--without-fp", а задействование аппаратных средств вычислений с плавающей запятой производится на уровне опций компилятора;
- В функции res_hnok, res_dnok, res_mailok и res_ownok добавлена проверка соответствия переданной стоки тре...URL: https://sourceware.org/ml/libc-alpha/2018-02/msg00054.html
Новость: http://www.opennet.me/opennews/art.shtml?num=48009
pacman -Q binutils
binutils 2.29.1-2
pacman -Ss glibc
core/glibc 2.26-11 (base) [установлен]
GNU C Library
core/lib32-glibc 2.26-11 [установлен]
GNU C Library (32-bit)
пока еще не обновился, Господи сколько CVE'х то.
> core/glibc 2.26-11
> 2.26-11
> 11Уверены, что они не пофикшены уже?
>> core/glibc 2.26-11
>> 2.26-11
>> 11
> Уверены, что они не пофикшены уже?Он уверен, что https://security.archlinux.org/package/lib32-glibc мы вот так вот прям сразу --- и побежали проверять.
Ой, скудо--ный толстячок нынче пошёл.
> Примечательно, что мэйнтейнером выпуска 2.27 стал Дмитрий Левин, генеральный конструктор ALT Linux."Зато в Альт Линуксе есть!" (c)
>> Примечательно, что мэйнтейнером выпуска 2.27 стал Дмитрий Левин,
>> генеральный конструктор ALT Linux.
> "Зато в Альт Линуксе есть!" (c)Таки да: https://packages.altlinux.org/ru/Sisyphus/srpms/glibc/changelog
Лучше б свой сайт починили [https://i.imgur.com/33hKp0d.png] 🤦
Передал разработчику сайта, но может зависеть от локальных настроек, сами понимаете.PS: #47 тоже переслал; нет, точно не php. :)
А может зависеть от пары строк CSS а то и (не дай бог) PHP
> Передал разработчику сайта, но может зависеть от локальных настроек, сами понимаете.передайте ещё что шрифт нужно использовать не как все(arial, helvetica, sans-serif) а просто sans-serif, это плохая практика
Вам оффтоп: https://geektimes.ru/post/297819/
> Вам оффтоп:Да все в курсе, просто в РБТ не лучшие времена по части комплекта разработчиков астры, увы.
Надеюсь, всё-таки справятся. Ну а управделами остаётся пожелать начинать с пилотных проектов.
А что, альт таки портируют на RISC-V? Или таки оправдают самые смелые ожидания в области майнтенанса?// русский вариант Дреппера у альтов получился на славу :)
> Добавлена поддержка двух грамматических форм имён месяцевДжвадцать лет ждал!
> Объявлена устаревшей возможность использования в статически скомпилированных приложениях вызова dlopen. Поддержка таких приложений будет прекращена в следующем выпуске. Для подобных программ следует применять динамическое связывание;Разве статически скомпилированная программа не может хотеть динамически подгрузить какой-либо плагин? Странноватое решение как по мне
Странно, я был уверен, что это и раньше не работало.
Согласен, напуркуа было выпиливает, непонятно
> Согласен, напуркуа было выпиливает, непонятноНаверное потому что для динамической загрузки надо вызывать динамический линковщик, и наверное еще и (динамически!) линковаться к libdl, так что статика получается не совсем статичная. Более того, очень интересно не хотят ли парни их глибсы починить остое..вшие уже вещи когда всякие сетевые функции статически линковаться не хотят. Так что статика для сетевых программ опять же получается не совсем статичной, портя малину.
> Наверное потому что для динамической загрузки надо вызывать динамический линковщик, и наверное
> еще и (динамически!) линковаться к libdl, так что статика получается нединамически-то зачем? ну да, последние лет десять немодно собирать статически libdl.a, но там нет никакого волшебного кода, который ей бы мешал так собираться.
(разумеется, если ты собираешься подключать dlopen'ом не какой-то специальный плагин, тоже статически слинкованный со всеми абсолютно зависимостями, тебе понадобится полный набор .so и именно тех версий, с которыми оно было собрано, когда-то даже gcc об этом предупреждал при такой сборке)
> совсем статичная. Более того, очень интересно не хотят ли парни их
> глибсы починить остое..вшие уже вещи когда всякие сетевые функции статически линковатьсяа вот это точно не хотят. Это sun'овский nss, это освящено (прошло)вековыми традициями и POSIX'ом, даром что мертвеньким родилось и нахрен никогда и никому не пригодилось.
Когда-то очень давно у glibc был специальный параметр для сборки без всей этой херни (полагаю, давным-давно сломанный) - но это получалась такая причудливая версия, которую только для статической линковки и можно было использовать (потому что вся nss-музыка заменялась неработающими stub'ами)
>> Объявлена устаревшей возможность использования в статически скомпилированных приложениях вызова dlopen. Поддержка таких приложений будет прекращена в следующем выпуске. Для подобных программ следует применять динамическое связывание;
> Разве статически скомпилированная программа не может хотеть динамически подгрузить какой-либоУ тебя русская языка на родная что ли?
Написано "glibc не хочет поддерживать", ты читаешь "программа не может".
Странный ты.
> плагин? Странноватое решение как по мне
>>> Объявлена устаревшей возможность использования в статически скомпилированных приложениях вызова dlopen. Поддержка таких приложений будет прекращена в следующем выпуске. Для подобных программ следует применять динамическое связывание;
>> Разве статически скомпилированная программа не может хотеть динамически подгрузить какой-либо
> У тебя русская языка на родная что ли?
> Написано "glibc не хочет поддерживать", ты читаешь "программа не может".Поясни, как программа сможет использовать. Сомневаюсь, что и ты за musl топишь.
>> Написано "glibc не хочет поддерживать", ты читаешь "программа не может".
> Поясни, как программа сможет использовать.open(), read() и далее по месту.
Захочет, чего в этой библиотеке нет, -- своё напишет...
>Сомневаюсь, что и ты за musl топишь.
..., другую библиотеку возьмёт.
Нет препятствий для програмизздов, да?
> Нет препятствий для програмизздов, да?угу, ничто не мешает "програмиззду" без конца чинить то, что сломано без всякой необходимости.
у него ж других занятий в этой жизни нет.
>> Нет препятствий для програмизздов, да?
> у него ж других занятий в этой жизни нет.Ну-да, "прогресс не остановить"TM и "маргиналы, некорфилы, динозавры и все^^3 пр.менньшинства будут страдать"SM.
"memfd_create и mlock2" - странно, раньше это было shm*(), которое в линуксе по факту было просто файлом на tmpfs, в остальном вроде всё так же.copy_file_range - так это sendfile() или splice().
> "memfd_create и mlock2" - странно, раньше это было shm*(), которое в линуксе
> по факту было просто файлом на tmpfs, в остальном вроде всё
> так же.Не также. У shm_* есть имя "файла", у нового -- нет. Те можно закрыть, открыть потом по имени, а к этих fd - главная ссылка, закрыли его и нет "файла"... Семантика, чтоб ей было хорошо.
int memfd_create(const char *name, unsigned int flags);
так и тут имя файла.
> int memfd_create(const char *name, unsigned int flags);
> так и тут имя файла.От меня-то чего надо? Ну есть, но не используется и вообще не один и тот файл.
Ссылки на man7.org/linux/man-pages/ доступны всем, кому нужно найти различия. Вам не надо -- проходите.
" Names do not affect the behavior of the file descriptor, and as such multiple files can have the same name without any side effects. "
" shm_open() creates and opens a new, or opens an existing, POSIX shared memory object. "
__
А, да, вот же ещё одно: не POSIX. Это тоже "очень важно" для многих. Совместимость, пром.стандарты и настоящие UNIX^tm-like-и.
Интересно, даст ли новая глибц той же скорости, что есть у Clear Linux?
> Интересно, даст ли новая глибц той же скорости, что есть у Clear
> Linux?У твоего возлюбленного скорость не от glibc, а от icc.
Конечно даст. Но в другие дистры это счастье году в 2019 попадёт, а в Clear уже куча других улучшений будет.
> Конечно даст. Но в другие дистры это счастье году в 2019 попадёт,
> а в Clear уже куча других улучшений будет.Я Вас умоляю, в http://altlinux.org/regular завезут на следующей неделе. Можно и прямщас, просто зачем торопиться, если в среду оно само?
PS: это если конкретно про glibc-2.27, а не см. #21.
> а в Clear уже куча других улучшений будет.Что и лучшие не закрытые дыры тоже?
Не думал, что в чисто софтверной компании есть должность (генеральный) конструктор.
> Не думал, что в чисто софтверной компании есть должность (генеральный) конструктор.Расейская специфика.
Дмитрий Левин -- это случайно не он про компьютеры в нач. 00-ых книги писал? Забыл название читал одну такую. Вроде автор Лёвин был или это другой?
Книга была А. Левин - Самоучитель работы на компьютере.
> Книга была А. Левин - Самоучитель работы на компьютере.Александр Левин мне чем-то напоминает Федорчука. Оба писатели. Вот только Федорчук пишет о никсах Левин о Windows. Давно-давно, я с его книги начинал знакомился с компьютерами.
> CVE-2018-6485 - вызов функций posix_memalignА вот не работает, даже на 2.19
10 уязвимостей закрыли, 20 сделали
> 10 уязвимостей закрыли, 20 сделалиПовод сделать следующую версию
Объясните в двух словах, чем risc-v лучше существующего уже давно operisc?
OpenRISC устарело на стадии разработки. RISC-V имеет поддержку 64-bit и много других вкусностей :)
Кстати, уже скоро (19:00 MSK) должен быть интересный доклад про RISC-V на FOSDEM: https://live.fosdem.org/watch/k1105
> OpenRISC устарело на стадии разработки. RISC-V имеет поддержку 64-bit и много других
> вкусностей :)Вообще-то у OpenRISC тоже 64-битная версия есть. А так оба пока существуют в виде мелких SoC, в основном 32-битных. С RISC-V однако несколько фирмочек возятся с выпуском SoC под линь прямо сейчас.
> Объясните в двух словах, чем risc-v лучше существующего уже давно operisc?Так вот же написали:
> Для использования RISC-V также требуется binutils 2.30, gcc 7.3.0 и ядро Linux 4.15
Привязка к ядру Linux и его системному ПО - враг не подойдёт.
>> Для использования RISC-V также требуется binutils 2.30, gcc 7.3.0 и ядро Linux 4.15
> Привязка к ядру Linux и его системному ПО - враг не подойдёт.Что тебе не понятно? Что OpenRISC, что RISC-V в твоей бзде если и будут то весьма маргинально, на уровне еще хуже чем (более попсовые!) ARM и MIPS, которые в фряхе перманентно в ауте. Ну то-есть процессорные то ядра там конечно поддерживаются, но что с ними делать то без периферии?
>>> Для использования RISC-V также требуется binutils 2.30, gcc 7.3.0 и ядро Linux 4.15
>> Привязка к ядру Linux и его системному ПО - враг не подойдёт.
> Что тебе не понятно? Что OpenRISC, что RISC-V в твоей бзде если
> и будут то весьма маргинально, на уровне еще хуже чем (более
> попсовые!) ARM и MIPS, которые в фряхе перманентно в ауте. Ну
> то-есть процессорные то ядра там конечно поддерживаются, но что с ними
> делать то без периферии?Как вы не поймёте, что драйвер под железку пишет производитель железки, а не разработчик операционной системы? Разработчик ОС обеспечивает лишь протокол взаимодействия драйверов с ядром ОС. Во FreeBSD всё для этого готово, так как из /usr/src/, сидя на [i386] или [amd64], можно собрать кросс-компиляцией системы: [arm], [arm64], [powerpc], [mips], [riscv], [sparc64].
А Linux - только ядро.
> Как вы не поймётеЭто Вы никак не поймёте. Попробуйте не трындеть, а собрать _и_ запустить. Узнаете много нового.
> Объясните в двух словах, чем risc-v лучше существующего уже давно operisc?Не лучше.
Да не, нормально. :-)В принципе, glibc-2.27 может быть/готова (нужное подчеркнуть :-) ) к использованию на платформе hurd/i386 с микроядром mach. В этом плане тоже была проделана большая работа, но в новости почему-то об этом ни слова. :-\
P.S. В комментах intl/plural.y по-прежнему написано что ему нужен bison >= 2.0. :-)
А так, - молодцы конечно. :-)
Я что-то совсем не понял, как в libc могут быть уязвимости повышения привилегий? Это ведь уязвимости ядра, а не libc, ничто не мешает злоумышленнику, если в libc нет нужных ему уязвимостей, использовать системные вызовы напрямую.
> Я что-то совсем не понял, как в libc могут быть уязвимости повышения
> привилегий? Это ведь уязвимости ядра, а не libc, ничто не мешает
> злоумышленнику, если в libc нет нужных ему уязвимостей, использовать системные вызовы
> напрямую.Смирись, тебе не понять.
Ты ж не прочитал, что написано строчкой ниже слов "повышение привилегий" (2из3 -- буквально в следующей строке, 3ий - через 4 строки...). Или две строчки не поместились в твоей голове? Хорошо, что ты научился спрашивать вопросы -- тебе ж на них ответят ответы. #успехесливспомнишьвчёмбылвопрос
атакующий должен иметь возможность создания жесткой ссылки на исполняемый SUID-файл
Как, как? Вы сказали musl?