LINUX.ORG.RU

Релиз ядра Linux 3.17

 


1

6

Состоялся релиз ядра Linux 3.17, среди наиболее важных улучшений и изменений:

  • Включена поддержка техники маппинга памяти memfd, суть которого заключается в идентификации области памяти через файловый дескриптор, который может передаваться между процессами. Это позволяет после выделения памяти обращаться к ней по файловому дескриптору, то есть фактически как с файлом.
  • Добавлена техника запечатывания файла (file sealing), позволяющая ограничить операции, которые могут выполняться над файлом. Например можно запретить на уровне файлового дескриптора изменение содержимого файла.
  • Теперь по умолчанию включена технология Render Nodes, предназначенная для разделения монолитных устройств /dev/dri/card{num} на две категории. Первая категория Rendering Nodes (/dev/dri/renderD{num}) отвечает за аппаратное ускорение рендеринга и обсчет вычислительных заданий GPGPU. Вторая ModeSetting Nodes (/dev/dri/modeset{num}) обеспечивает переключение видеорежимов и управление экраном. Это позволяет более гибко управлять правами доступа и предоставляет возможность выполнения вычислений на GPU или рендеринга без вывода на экран и без привязки к активному дисплею.
  • Представлена реализация API DMA-BUF, позволяющего организовать совместное использования буферов драйверами и различными подсистемами, а также синхронизировать работу устройств (cross-device synchronization). Теперь она доступна для всех модулей ядра.
  • Для утилиты perf добавлена возможность трассировки обращений к невыделенным страницам памяти (page-fault) и генерации связанной с такими обращениями статистики.
  • При использовании файловой системы XFS теперь необходима сборка ядра с 64-разрядным числом секторов.
  • Добавлена начальная поддержка Multiqueue SCSI, рассчитанного на организацию многопоточного доступа к данным на многоядерных системах и позволяющего эффективно использовать возможности современных SSD-накопителей.
  • Добавлен системный вызов kexec_file_load(), позволяющий выполнить проверку по цифровой подписи для нового ядра, перед его запуском с использованием механизма kexec. Ранее функцию загрузки нового ядра из уже запущенного ядра Linux (kexec) приходилось отключать при использовании UEFI Secure Boot, так как невозможно было гарантировать сохранение цепочки доверия.
  • Для криптографической подсистемы добавлена поддержка детерминированного генератора псевдослучайных чисел, соответствующего спецификации NIST SP800-90A.
  • В подсистему LSM (linux security module) добавлен новый hook kernel_fw_from_file(), который можно использовать для проверки целостности бинарных прошивок перед их загрузкой ядром.
  • Полностью прекращена поддержка архитектур POWER3 и rs64;
  • Также прекращена поддержка систем Samsung S5P6440, S5P6450 и S5PC100.
  • В код для архитектуры ARM64 добавлена поддержка четырёхуровневых таблиц страниц памяти, что позволило значительно расширить размер адресуемой виртуальной памяти.
  • Гипервизор KVM адаптирован для big-endian ARM-систем.
  • Для DRM-драйвера Nouveau устранены проблемы с использованием GPU Kepler, добавлена поддержка режима Zero Bandwidth Clear для GPU Fermi, Kepler и Maxwell.
  • Поддержка чипов «Hawaii» (Radeon R9 290) добавлена в DRM-драйвер Radeon.
  • Проведена подготовка к поддержке DRM-драйвером Intel Atom SoC Cherry Trail, добавлена поддержка Universal plane.

>>> Подробности (на английском языке)

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Wizard_ (всего исправлений: 2)

По поводу file sealing - обычные файлы никто «запечатывать» не собирается. Для них, скорее всего, этот функционал никогда не будет поддерживаться.

С практической стороны данная функциональность необходима для заморозки содержимого memfd, чтобы после передачи файлового дескриптора не позволить другим процессам изменять связанную с memfd область памяти. File sealing и memfd являются ключевыми компонентами, необходимыми для реализации kdbus (аналог D-Bus внутри ядра);

Так что это нужно для вполне конкретной узкоспециализированной цели. Лично мне было не понятно, чем отличаются shm_open() + mmap() и memfd_create(), пока я не прочитал для чего реализовали memfd.

x_hash
()
Ответ на: комментарий от unt1tled

Очень правильная мысль. Почему раньше не додумались сделать логи ридонли даже для рута, чтоб только сам процесс мог затереть... Кулхацкирам было бы сложнее заметать следы.

например, потому что ты не разбираешься в том о чем говоришь? если я уже имею рут на системе, я могу без проблем заставить любой процесс выполнить произвольный код, так что такая защита ничего не дала бы. более того, для этой цели уже миллион лет как существует xattr append-only, только вот понятно что рута это не остановит. целостность логов может гарантировать только ецп с шиппингом на отдельный кластер. и то, только логов _до_ взлома.

val-amart ★★★★★
()

О, ну тогда сразу до 3.17 обновлюсь по выходу нужных патчей. А то даже в дебианорепы уже 3.16.2 прилетело, а у меня 3.15.7 до сих пор. При том, что ему всего два месяца... Впрочем, в чейнджлоге ничего полезного для себя не вижу, разве что memfd, если удастся заюзать его вместо tmpfs (но memfd уже вроде давно в ядре есть, просто отключён ввиду недопиленности).

MiniRoboDancer ★☆
()

Это позволяет после выделения памяти обращаться к ней по файловому дескриптору, то есть фактически как с файлом.

ramfs?

Например можно запретить на уровне файлового дескриптора изменение содержимого файла.

Прав доступа уже не достаточно?

loz ★★★★★
()
Ответ на: комментарий от val-amart

я могу без проблем заставить любой процесс выполнить произвольный код

Прям таки любой, прям таки без проблем?

loz ★★★★★
()

В qemu-kvm сеть отвалилась. Как понял перестал работать bridge. Пишет:

Ошибка запуска сети 'default': failed to add iptables rule to enable masquerading

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 66, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/network.py", line 82, in start
    self.net.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1652, in create
    if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
libvirtError: failed to add iptables rule to enable masquerading

superuser ★★★★★
()
Ответ на: комментарий от val-amart

В винде у админа можно отобрать права на всё, включая на смену прав. Причём можно создать такую ситуацию что права уже никак не вернуть. Сделав таким образом чёрный ящик.
В Linux так нельзя разве?

EvilFox ★★
()
Ответ на: комментарий от MyTrooName

ФС устанавливается на бронетранспортеры.

splinter ★★★★★
()
Ответ на: комментарий от praseodim

То-то я смотрю Майкрософт выпустили NTFS под GPL совместимой лицензией и отправили заплатку в ядро.

anonymous
()
Ответ на: комментарий от KennyMinigun

Сам панику поднял, сам разобрался и всё всем разъяснил. Молоток!

WARNING ★★★★
()
Ответ на: комментарий от val-amart

я могу без проблем заставить любой процесс выполнить произвольный код

Даже если бинарик после запуска удалить? Я не сказал, что Ъ это остановит, но теоретически! может сделать жизнь кулхацкира сложнее, если продумать все варианты развития событий.

unt1tled ★★★★
()
Ответ на: комментарий от loz

Рут может выполнять код в пространстве ядра путём втыкания в ядро произвольных модулей. «Обычный» процесс, даже если он под рутом, выполняется в пространстве пользователя (в контексте x86 — ring3).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

То-то я смотрю Майкрософт выпустили NTFS под GPL совместимой лицензией и отправили заплатку в ядро.

твой сарказм понятен. но NTFS по сравнению с ZFS - это как FAT по сравнению с NTFS.

к тому же, велосипедить свой ZFS только ради того, чтобы сменить лицензию, никому не интересно. это тебе не coreutils, которые велосипедят на первом курсе в качестве домашки.

MyTrooName ★★★★★
()
Ответ на: комментарий от loz

Да выпилить можно вообще всё что угодно; можно вообще собрать ядро так, что там только idle loop останется. Суть не в этом. А в том, что на рута принципиально не накладывается никаких дополнительных ограничений.

intelfx ★★★★★
()
Ответ на: комментарий от EvilFox

В Linux так нельзя разве?

можно, с помощью всевозможных RBAC.

anonymous
()
Ответ на: комментарий от intelfx

На рута не накладывается, но его процессы все равно выполняются в пользовательском режиме. Как кроме модулей он может засунуть код в ядро?

loz ★★★★★
()
Ответ на: комментарий от loz

/dev/mem. Переписать vmlinuz и ребутнуть машину, в конце концов.

Нет, конечно, последовательно выпиливая из ядра разную функциональность, можно запретить руту лезть в пространство ядра. Выпилив ptrace, можно запретить руту лезть в адресное пространство других процессов. Но идея в том, что руту по определению «можно всё», поэтому выпилить придётся очень много, да и то не будет гарантии, что нигде не осталось обходного пути.

В общем, с каждым таким выпиливанием ядро будет всё больше походить на пустой бесконечный цикл.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Secure Boot поможет. Ядро вроде бы можно собрать так, чтобы оно не загружало неподписанные модули. Останется только выпилить /dev/mem etc.

Правда поменять юзерспейсный бинарик не помешает, на них подписи вроде бы ещё не ставятся, хотя можно сверять хэши при загрузке. ptrace тоже придётся выпилить.

anonymous
()
Ответ на: комментарий от anonymous

Хм, да, где-то даже на LKML обсуждали это (помнится, Линус тогда опять всех обматерил)...

intelfx ★★★★★
()
Ответ на: комментарий от loz

конечно. 5 звезд и 5 лет на лоре, пора бы уже знать.

val-amart ★★★★★
()
Ответ на: комментарий от unt1tled

да. во-первых, то что ты «удалишь бинарник» ничего не значит пока процесс запущен, ты просто удаляешь последнюю именованную жесткую ссылку, восстановить не проблема. во-вторых, мне для этого бинарник вообще не нужен. в-третьих, даже не считая возможности выполнить произвольный код _на уровне ядра_, мне как руту будет достаточно что какому-нибуть, все равно какому, uid разрешено изменять файл.

val-amart ★★★★★
()
Ответ на: комментарий от unt1tled

Очень правильная мысль. Почему раньше не додумались сделать логи ридонли даже для рута, чтоб только сам процесс мог затереть... Кулхацкирам было бы сложнее заметать следы.

man chattr

ATTRIBUTES A file with the 'a' attribute set can only be open in append mode for writing. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Только все это фигня, логи должны храниться на syslog сервере, доступ к которому для хацкеров закрыт снаружи :-)

anonymous
()
4 декабря 2014 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.