Готов HTML и EPUB книги об учебной операционной системе xv6.
Яндекс.Диск:
Google.Drive: https://drive.google.com/drive/folders/1Rt7hcHysWAilDn64uf-RpLACuJ39YKaR
В стандартной C-библиотеке Glibc выявлена уязвимость (CVE-2024-2961), приводящая к переполнению буфера при преобразовании специально оформленных строк в кодировке ISO-2022-CN-EXT функцией iconv().
Выявивший проблему исследователь 10 мая выступит на конференции OffensiveCon с докладом, в анонсе которого упоминается возможность эксплуатации уязвимости через приложения на языке PHP. Проблема затрагивает всю экосистему PHP и некоторые приложения.
При преобразовании строк в кодировке UCS4, в соответствии с требованиями RFC 1922, библиотека Glibc добавляет некоторые escape-символы, выделяющие части строки, в которых кодировка была изменена.
Уязвимость в вызвана некорректной проверкой границ внутренних буферов функцией iconv(), что может привести к переполнению буфера максимум на 4 байта. При переполнении за границу буфера могут быть записаны определённые фиксированные значения, такие как '$+I', '$+J', '$+K', '$+L', '$+M' и '$*H'. Несмотря на то, что эксплуатация подобной уязвимости для выполнения кода кажется маловероятной, этого оказалось достаточно для подготовки нескольких прототипов эксплоитов для удалённой атаки на PHP-приложения, приводящей к выполнению кода.
Уязвимость проявляется с 2000 года и устранена в находящейся в разработке ветке Glibc 2.40. Исправление также доступно в виде патчей для выпусков Glibc с 2.32 по 2.39. В дистрибутивах проследить за исправлением уязвимости можно на страницах: Debian, Ubuntu, Gentoo, RHEL, SUSE, Fedora, Arch.
Источник: OpenNET.
Утечки памяти преследовали программы на языке С с тех пор, как существует этот язык. Было предложено множество решений, вплоть до идеи переписать программы на языке C на других языках. Но есть лучший способ.
Здесь представлено простое решение, которое устранит утечки памяти в каждой программе на языке C. Используйте этот модуль с вашей программой, и утечки памяти останутся в прошлом.
#include <dlfcn.h>
#include <stdio.h>
struct leaksaver {
struct leaksaver *next;
void *pointer;
} *bigbucket;
void *
malloc(size_t len)
{
static void *(*nextmalloc)(size_t);
nextmalloc = dlsym(RTLD_NEXT, "malloc");
void *ptr = nextmalloc(len);
if (ptr) {
struct leaksaver *saver = nextmalloc(sizeof(*saver));
saver->pointer = ptr;
saver->next = bigbucket;
bigbucket = saver;
}
return ptr;
Пояснение автора кода в оригинале:
Every allocated pointer is saved in the big bucket, where it remains accessible. Even if no other references to the pointer exist in the program, the pointer has not leaked.
It is now entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.
Problem sovled!
В списке рассылки разработчиков ядра Linux возобновилось начатое шесть лет назад обсуждение перспектив использования современного кода на C++ в ядре Linux, помимо нынешнего применения языка С, ассемблерных вставок и продвижения языка Rust.
Изначально тема разработки ядра на C++ была поднята в 2018 году инженером из Red Hat, который первого апреля в качестве шутки опубликовал набор из 45 патчей для использования шаблонов, наследуемых классов и перегрузки функций C++ в коде ядра.
С инициативой продолжения обсуждения выступил Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков ядра в компании Intel и создатель таких проектов, как syslinux, klibc и LANANA, разработавший для ядра Linux систему автомонтирования, реализацию RAID 6, драйвер CPUID и x32 ABI. По мнению Анвина, который является автором многочисленных макросов и ассемблерных вставок в ядре, с 1999 года языки С и С++ значительно продвинулись вперёд в своём развитии, а язык С++ стал лучше подходить для разработки ядра операционных систем, чем С.
Анвин считает, что C++ более предпочтителен, чем Rust, так как последний существенно отличается от языка С по синтаксису, непривычен для текущих разработчиков ядра и не позволяет постепенно переписывать код (в случае языка С++ можно по частям переводить код с языка C, так как С-код можно компилировать как C++). В поддержку использования С++ в ядре также выступили Иржи Слаби (Jiri Slaby) из компании SUSE и Дэвид Хауэллс (David Howells) из Red Hat.
Источник: OpenNET.
Вышла вторая редакция проекта PLB (Programming Language Benchmark) по тестированию производительности решения типовых задач на различных языках программирования. В ней измеряется производительность кода для умножения матриц и решения задачи расстановки 15-ферзей, а также дополнительно оценивает поиск решений в игре Судоку и определение пересечений двух массивов.
Код для тестирования PLB написан на 20 языках программирования. Наиболее высокую производительность показала реализация тестовых приложений на языке C (при компиляции в clang). На втором месте оказался язык Zig, на третьем Nim, на четвёртом Mojo. Далее примерно на одном уровне следуют D, Java, JavaScript-платформа Bun и Rust, а после них Go, Crystal и V.
Высокие результаты показали Node.js, Dart, Lua и C#. Хорошие показатели у Java и C# объясняются использованием отдельной стадии JIT-компиляции, в то время как в Dart, Bun, Node.js, Julia, LuaJIT, PHP, PyPy и Ruby3 (YJIT) JIT-компиляция выполняется на лету и затрагивает только часто выполняемый код. JavaScript-платформа Bun заметно обогнала Node.js. Относительно медленными оказались результаты у Julia и Swift.
Наихудшие показатели производительности выявлены у PHP, Ruby, Perl и CPython, при этом производительность PHP оказалась примерно в 4 раза выше, чем CPython.
Дополнение: В реализации на языках Rust, D и Julia внесены оптимизации, которые позволили Rust занять второе место, D - третье, Julia - 7, а V показал лучший результат в nqueen+matmul.
Источник: OpenNET.