Знакомимся с новым ядром Linux 4.5

В середине марта после почти двух месяцев разработки и семи release candidate Линус Торвальдс представил новую версию ядра 4.5. Кроме исправлений, в релизе действительно много нового. Изменения затронули все подсистемы — дисковую, работу с памятью, системные и сетевые сервисы, безопасность, и, конечно же, добавлены драйверы для новых устройств. Попробуем разобраться с некоторыми наиболее интересными.

О релизе

Релиз ядра 4.4 вышел относительно недавно, в начале января 2016-го, но за это короткое время накопилось большое количество дополнений. И хотя Линус назвал новый релиз «нормальным», можно увидеть, что по сравнению с версией 4.4 размер патча вырос почти на треть — 70 Мбайт против 49 Мбайт. В разработке участвовало примерно 1528 человек, которые внесли около 13 тысяч исправлений. В более чем 11 тысяч файлов были добавлены 1 146 727, удалено 854 589 строк кода. В 4.4 было соответственно 714 106 и 471 010 строк. Почти половина (45%) всех изменений связана с драйверами устройств, 17% затрагивают код аппаратных архитектур, 14% касаются сетевого стека, 4% — файловых систем, и 3% затронули внутренние подсистемы ядра.

Наибольшее количество строк внесли Даг Ледфорд (Doug Ledford) из Red Hat, занимавшийся в основном чисткой кода (7,7%), Томи Валкейнен (Tomi Valkeinen) из Texas Instruments, работавший над поддержкой субархитектуры OMAP (5,3%), три разработчика сосредоточили внимание на драйверах графических карт AMD: Эрик Хуан (Eric Huang) — 3,3%, Алекс Дойхер (Alex Deucher) — 2,4% и yanyang1 — 1,6%. Лидеры по чейнджсетам — Линус Валлей (Linus Walleij) из Linaro, реализовавший множество низкоуровневых изменений, в том числе к поддерживаемому им GPIO (2,0%), Арнд Вергман (Arnd Bergmann), проделавший большую работу для поддержки ARM (1,9%), и Лео Ким (Leo Kim), занимавшийся драйвером wilc1000 (1,7%). Как и ранее, многие корпорации заинтересованы в развитии ядра. Работу над версией 4.5 поддержали более 200 компаний, среди которых Red Hat, Intel, AMD, Texas Instruments, Linaro, Linux Foundation, Samsung, IBM, Google. Большинство из них развивают поддержку своих устройств и связанных подсистем и инструментов, но, например, Google традиционно вносит очень много изменений в сетевую подсистему Linux.

Другие статьи в выпуске:

Xakep #208. Атака на сигналку

• Содержание выпуска
• Подписка на «Хакер»-60%

Ядро и драйверы

Продолжился перенос сложного и плохо поддерживаемого кода, написанного на ассемблере (x86/asm) на С, начатый еще в 4.0. Ядро теперь можно собирать с параметром -fsanitize=undefined. Сам параметр появился два года назад в GCC 4.9+ и активирует отладочный режим UBSan (Undefined Behavior Sanitizer), который детектирует неопределенное поведение, присущее языкам C и C++: использование нестатических переменных до инициализации, деление на ноль, целочисленное переполнение и так далее. Компилятор обычно предполагает, что такие операции никогда не произойдут, а в случае наступления результат может быть любой и зависит от самого компилятора. Теперь компилятор обнаруживает такие ситуации, выдает «runtime error:» (можно отключить -fno-sanitize-recover) и продолжает выполнение.

По умолчанию в каждой сборке ОС все библиотеки загружаются в определенные адреса, что позволяет легко реализовать атаку. Для увеличения безопасности используется ряд технологий, одна из них — случайное смещение при вызове mmap(), реализованное в виде ASLR (Address Space Layout Randomization). Впервые технология ASLR появилась в Linux в 2005 году в ядре 2.6 и выдавала для 32-битных систем 8-битное смещение (то есть 256 вариантов адресов, хотя на самом деле меньше), а для x64 — смещение уже 28-битное. Для x64 вариантов вполне достаточно, а вот для 32-битных систем, среди которых Android, этого на сегодня явно мало. Уже известны эксплоиты, умеющие подбирать адрес. В результате поиска решения проблемы написан патч, позволяющий устанавливать большую хаотичность для ASLR, через /proc/sys/vm/mmap_rnd_bits и /proc/sys/vm/mmap_rnd_compat_bits (в системах x64 для x86-процессов). Для каждой архитектуры указываются минимальные и максимальные значения с учетом доступного адресного пространства. Для x86 значение может находиться в диапазоне от 8 до 16 бит или 28–32 (для x64-версии). Параметры по умолчанию можно задавать при сборке ядра.

Расширены возможности DRM-драйвера для видеокарт NVIDIA (Nouveau) и Intel (поддержка будущего поколения чипов Kaby Lake), добавлена поддержка новых звуковых карт, USB-контроллеров, криптоускорителей. Производители графических карт Intel и NVIDIA уже давно отказались от использования режима UMS (Userspace Mode Setting) в своих open source драйверах в пользу KMS (Kernel Mode Setting), теперь пришла очередь драйвера ATI Radeon, в котором убран код режима UMS. С 3.9 было возможно его включать параметром DRM_RADEON_UMS или установкой radeon.modeset=0 в GRUB. Теперь остался только KMS (Kernel Mode Setting). Это нужно учитывать, если необходимо использовать старые драйверы или режим UMS (UMS иногда показывает большую производительность).

В драйвер AMDGPU добавлена экспериментальная поддержка технологии динамического управления питанием PowerPlay, позволяющая повысить производительность GPU для GPU Tonga и Fiji и интегрированных Carrizo и Stoney. В режиме PowerPlay GPU запускается в режиме низкого энергопотребления, но в случае возрастания нагрузки на графическую подсистему автоматически увеличивает частоту. По умолчанию PowerPlay отключен, для включения следует передать ядру параметр amdgpu.powerplay=1.

Новая версия Media controller API расширяет поддержку устройств Video4Linux и позволяет использовать функциональность мультимедиаконтроллера в других подсистемах, таких как DVB, ALSA и IIO.

В KVM (Kernel-Based Virtual Machine) много сделано для поддержки архитектуры s390 (теперь она может использовать до 248 vCPU), ARM/ARM64 и улучшения работы x86 в Hyper-V.

$ wget -с http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/linux-headers-4.5.0-040500-generic_4.5.0-040500.201603140130_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/linux-headers-4.5.0-040500_4.5.0-040500.201603140130_all.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.5-wily/linux-image-4.5.0-040500-generic_4.5.0-040500.201603140130_amd64.deb
$ sudo dpkg -i linux*.deb

Поддержка ARM

ARM-компьютеры используются как мини-серверы под определенные задачи или в качестве контроллеров автоматизации, что делает их очень популярными и востребованными. ARM-сообщество Linux за последние пять лет превратилось в одно из наиболее активных, проведя колоссальную работу по поддержке 32-разрядных ARM-платформ, занимающих серьезную долю рынка, и эта работа в общем завершилась к выходу ветки 4.5. Ранее для каждого ARM-устройства необходимо было собрать собственное ядро, обеспечивающее поддержку только определенных устройств. Но проблема в том, что устройства становились сложнее, появилась возможность изменения конфигурации, да и сами пользователи на ARM-устройствах хотели использовать без лишних телодвижений обычные дистрибутивы. Но в итоге мы имели несколько сотен вариантов сборки ядра, что очень затрудняет использование Linux.

Результатом очистки и рефакторинга большого количества кода стало возможным включение в ядро кода поддержки ARMv6 и ARMv7, то есть теперь можем собрать универсальное ядро, способное загружаться на обеих системах. Здесь, наверное, нужно вспомнить и о продвигаемой в последнее время спецификации Device Tree, возникшей как часть разработок Open Firmware. Device Tree позволяет конфигурировать оборудование во время загрузки при помощи специальных dts-файлов, хранящихся в /boot/dtbs, и менять установки без пересборки ядра. Использование Device Tree становится обязательным для всех новых разработок ARM и не только устройств. Все это вместе дает уверенность, что дистрибутивы Linux в будущем можно будет спокойно запускать на любом ARM-устройстве. Параллельно Грег Кроу-Хартман (Greg Kroah-Hartman) из Linux Foundation выпустил патч, реализующий подобную возможность для ранних версий ядра. В arch/arm64 найдем код, обеспечивающий поддержку новой 64-битной архитектуры ARM (ARMv8). Добавлены новые функции для всех популярных архитектур ARM — Allwinner, Amlogic, Samsung, Qualcomm и поддержка новых ARM-плат различных разработчиков.

Системные сервисы

Для доступа к данным прошивок UEFI (Unified Extensible Firmware Interface) в Linux используется специальная псевдофайловая система efivars (настраивается EFIVAR_FS), которая монтируется в /sys/firmware/efi/efivars. В некоторых реализациях при выполнении команды rm -rf /* удалялось содержимое и этого каталога, что приводило к разрушению прошивки. Компании — разработчики устройств не считают это серьезным недостатком, ведь ситуация, конечно, не самая распространенная, да и вряд ли какому-то пользователю придет в голову это проверить. Тем не менее проблема есть, и писатели вирусов вполне реально могут воспользоваться такой возможностью. Теперь в ядре 4.5 добавлена специальная защита каталога /sys/firmware/efi/efivars, не позволяющая удалять файлы внутри.

Механизм контрольных групп cgroups ядра Linux, появившийся в 2.6.24, позволяет изолировать и ограничивать вычислительные ресурсы. Используется при создании контейнеров в таких решениях, как Docker и LXC. Сегодня разработку cgroups курирует Теджун Хо (Tejun Heo) из Facebook. Изначальная архитектура была немного запутанной, что приводило к проблемам взаимодействия между обработчиками и повышенным затратам ресурсов ядра. В ядре 4.5 появилась кардинально переработанная версия cgroups v2, уже полностью обкатанная в работе в Facebook. В v2 используется единая унифицированная жесткая иерархия (Cgroup unified hierarchy). Иерархия cgroup теперь может монтироваться при указании типа файловой системы cgroup2. Соответствующие изменения для поддержки cgroup2 произведены и в модуле xt_cgroup в iptables, позволяющем легко управлять сетевым трафиком cgroup при помощи метки. Требует ядро, собранное с параметром CONFIG_NETFILTER_XT_MATCH_CGROUP.

$ echo 1 > /sys/fs/cgroup/net_cls/block/net_cls.classid
$ iptables -A OUTPUT -m cgroup ! --cgroup 1 -j ACCEPT

В cgroup memory controller появилась возможность контролировать потребление памяти различными структурами данных, что позволяет учитывать состояние и лимитировать потребление памяти в группе. При желании можно вывести связанную с сокетами память из-под действия общей системы лимитирования памяти cgroup.memory=nosocket. По умолчанию в некоторых дистрибутивах cgroup memory controller отключена, проверить можно по наличию /sys/fs/cgroup/memory.

Просмотреть работу также можно:

$ cat /proc/cgroups | grep memory
$ dmesg | grep cgroup

Если в выводе ничего не потребуется, включить при загрузке ОС:

$ sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet cgroup_enable=memory swapaccount=1"

Над ускорением операций копирования работают постоянно, но существенных изменений происходит не так много. Год назад в виде патчей Анны Шумахер (Anna Schumaker) был представлен новый системный вызов copy_file_range, вошедший в итоге в ядро 4.5. Его использование позволяет ускорить копирование файла за счет проведения операции через кеш ядра без переключения в пространство пользователя. Первоначально copy_file_range действовал только для файлов на одной точке монтирования, но при работе над патчем это ограничение было снято. Реализовано несколько режимов. Так, COPY_FR_COPY копирует данные в обычном режиме, ускоряя работу на уровне файловой системы (если возможно). В случае COPY_FR_REFLINK при запросе копии запрашивается файл назначения, без фактического его копирования. Например, Btrfs позволяет таким образом обмениваться ссылками на блоки файла. Вызов COPY_FR_DEDUP похож на COPY_FR_REFLINK, но применяется, когда блоки на источнике и назначении одинаковы, в результате получаем два дедуплицированных файла, которые используют одни и те же блоки данных. В ближайшее время новый вызов будет реализован для Btrfs, есть пачти для команды copy для NFS v4.2 и для XCOPY в SCSI. В остальных случаях copy_file_range не особо выигрывает у привычной cp, так как I/O-операции с накопителя занимают много времени.

Файловая система ext4 поддерживает несколько вариантов квот — пользовательские, групповые, теперь дополнительно реализована поддержка квот проектов project quota. Подобная возможность есть уже в XFS и GPFS. В ext4 использованы наработки XFS. Проект представляет собой совокупность не связанных друг с другом инодов (inode), которые могут принадлежать файлам в разных каталогах. Все иноды проекта имеют одинаковый идентификатор project ID и настройки прав/квот для пользователей групп. Квоты проекта могут отличаться от общесистемных. При создании файла в каталоге его inode автоматически получает настройки проекта каталога.

В netfilter/nftables появилась возможность перенаправления и дублирования пакетов netdev, позволяющая быстро пробрасывать пакеты между двумя интерфейсами.

# nft add table netdev filter
# nft list table netdev filter
# nft add chain netdev filter ingress { type filter hook ingress device eth0 priority 0\; }
# nft add rule netdev filter ingress dup to dummy0

Также добавлена поддержка изменения данных в пакете (mangling packet payload) с автоматической корректировкой контрольной суммы и возможность учета в правилах счетчика байтов или пакетов.

Вывод

Конечно, рассказать даже кратко обо всех новинках очень сложно. Но очевидно, что Linux сделал, может, и небольшой, но все же шаг вперед. Над улучшением ядра Linux работают постоянно, и обществу становятся доступными новые и, главное, полезные функции. Радует, что в поддержке, кроме сообщества, стабильно участвует большое количество коммерческих компаний.