В чем различия между ядром RHEL и другими дистрибутивами?

В настоящее время я работаю в месте, которое использует RHEL с версии 4. Насколько мне известно, никогда не было конкретной технической причины для выбора этого дистрибутива. Это было «корпоративное» распределение, и вокруг него существует некий имидж, что вы сможете обратиться к кому-то в случае возникновения проблем.

Тем не менее, за все годы использования RHEL и лицензии «самоподдержки», помощь никогда не приходила. Кроме того, способ использования операционной системы на объектах клиентов действительно очень прост. Более того, некоторые клиенты даже извлекли старые диски RHEL6 и 7, потому что им ужасно не нравится быть связанными с Gnome, и все программное обеспечение KDE, которым они наслаждались, внезапно исчезло. С учетом всех этих вещей, RHEL начинает приносить гораздо больше проблем, чем стоит. Аргументы вроде «стабильности» и другие подобные термины сложно количественно оценить, в основном потому, что у меня нет проблем со стабильностью и на других основных дистрибутивах.

С этим, однако, мой вопрос. Я осведомлён, что ядро, используемое для RHEL, не такое же, как широко доступное, и что RHEL официально поддерживает только ядра, скомпилированные ими. Однако какие реальные изменения в него вносятся, чтобы оправдать наличие своей версии? Есть ли драйверы или какие-то другие функции, доступные здесь, которых нет в общедоступных версиях ядер, или в том, что вы компилируете сами?

Это не полный ответ на ваш вопрос,
особенно поскольку я не знаю много о RHEL,
но я считаю, что это дает хороший контекст для “других”,
к которым относится ваш вопрос.
Этот ответ не ограничивается ядром;
это то, как ответить на вопрос о “Upstream” против “Debian” для любого пакета.
Надеюсь, это будет полезно.

Что касается упаковки Debian (или Ubuntu, или производных),
будь то ядро или что-то другое,
вы можете использовать apt source <package>
для изучения источников того, что именно установлено на вашем компьютере.

$ apt source linux-5.10.226
$ ls
linux_5.10.226.orig.tar.xz      <-- Upstream, чистые источники
linux_5.10.225-1.debian.tar.xz  <-- Изменения, специфичные для Debian
linux_5.10.226-1.dsc            <-- Индекс того, что в исходном пакете
linux-5.10.226/                 <-- Извлеченные и скомпилированные все компоненты

Первое, что мы можем сделать, это изучить формат:

$ cat debian/source/format
3.0 (quilt)

3.0 (quilt) (в отличие от native) означает, что
этот пакет использует исходный tarball, и Debian накладывает патчи сверху.
Это соответствует найденным нами файлам.

Мы также можем увидеть, откуда пришел исходный файл.
debian/watch может быть полезен для этого.
Он определяет схему для uscan, чтобы скачать и проверить оригинальный tarball,
или проверить наличие более новых версий и загрузить их.

$ cat debian/watch
# Найдите первый не-rc tarball, связанный с kernel.org.
version=3
opts="pgpmode=mangle, pgpsigurlmangle=s|\.xz$|.sign|, decompress" \
https://www.kernel.org/ .*/linux-([0-9.]+).tar.xz debian uupdate

Далее мы можем собрать это с помощью dpkg-buildpackage.
Один из первых шагов, предпринятых этим инструментом, – это выполнение dpkg-source -b,
который выполняет хэш (MD5?) всего, что находится вне каталога debian/,
и затем сравнивает это с тем, что ожидает от чистого извлечения *.orig.tar.xz.
Если он обнаруживает любые изменения, то прерывает процесс.
Это гарантирует, что мы не загрязнили исходный код Upstream.

Следующее, что делает dpkg-source -b, это использование quilt для применения всех патчей, найденных в debian/patches/series:

$ cat debian/patches/series
debian/gitignore.patch

# Отключение функций, испорченных исключением файлов Upstream
debian/dfsg/arch-powerpc-platforms-8xx-ucode-disable.patch
debian/dfsg/drivers-media-dvb-dvb-usb-af9005-disable.patch
debian/dfsg/vs6624-disable.patch
debian/dfsg/drivers-net-appletalk-cops.patch
debian/dfsg/video-remove-nvidiafb-and-rivafb.patch
debian/dfsg/documentation-fix-broken-link-to-cipso-draft.patch

# Изменения для поддержки системы сборки пакетов
debian/version.patch
debian/uname-version-timestamp.patch
debian/kernelvariables.patch
debian/ia64-hardcode-arch-script-output.patch
...

В этом конкретном пакете файл series содержит 146 строк с 107 патчами. Эти патчи описывают различия между выпуском Debian и пакетом Upstream.

Если мы изучим один из патчей (выбранный произвольно),
мы увидим, что это формат unified-diff с заголовком dep3.
На самом деле это git-commit, выбранный из дерева ядра Upstream,
он был написан сотрудником Red Hat,
и был интегрирован в это выпуск ядра для решения проблемы CVE.

From: Miklos Szeredi <m>
Date: Mon, 14 Dec 2020 15:26:13 +0100
Subject: vfs: переместить вызов cap_convert_nscap() в vfs_setxattr()
Origin: https://git.kernel.org/linus/7c03e2cda4a584cadc398e8f6641ca9988a39d52
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-3493

cap_convert_nscap() выполняет проверку разрешений, а также преобразование
значения xattr условно в зависимости от user-ns файловой системы.

Это необходимо для overlayfs и, вероятно, для других слоистых файловых систем (ecryptfs) и это
то, что vfs_foo() и должно делать.

Signed-off-by: Miklos Szeredi <>
Acked-by: James Morris <>
---
 fs/xattr.c                 | 17 +++++++++++------
 include/linux/capability.h |  2 +-
 security/commoncap.c       |  3 +--
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index cd7a563e8bcd..fd57153b1f61 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -276,8 +276,16 @@ vfs_setxattr(struct dentry *dentry, const char *name, const void *value,
 {
    struct inode *inode = dentry->d_inode;
    struct inode *delegated_inode = NULL;
+   const void  *orig_value = value;
    int error;

+   if (size && strcmp(name, XATTR_NAME_CAPS) == 0) {
+       error = cap_convert_nscap(dentry, &value, size);
+       if (error < 0)
+           return error;
+       size = error;
+   }
+
 retry_deleg:
    inode_lock(inode);
    error = __vfs_setxattr_locked(dentry, name, value, size, flags,
@@ -289,6 +297,9 @@ vfs_setxattr(struct dentry *dentry, const char *name, const void *value,
        if (!error)
            goto retry_deleg;
    }
+   if (value != orig_value)
+       kfree(value);
+
    return error;
 }
 EXPORT_SYMBOL_GPL(vfs_setxattr);
...

Если я посмотрю на другой, этот предназначен для решения проблемы, которая была поднята в Kali Linux.

$ cat -p debian/patches/features/x86/intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch 
From: Ben Hutchings <>
Date: Wed, 21 Aug 2019 00:32:16 +0100
Subject: intel-iommu: Добавить опцию Kconfig для исключения iGPU по умолчанию
Bug-Debian: https://bugs.debian.org/935270
Bug-Kali: https://bugs.kali.org/view.php?id=5644

Существует еще прошивка для ноутбуков, которая влияет на встроенный GPU за спиной
операционной системы и не упоминает об этом в таблице RMRR.
Включение IOMMU для всех устройств вызывает сбой.

Замените CONFIG_INTEL_IOMMU_DEFAULT_ON на выбор из трех вариантов,
соответствующий "включено", "выключено" и "включено, intgpu_off".

Signed-off-by: Ben Hutchings <>
---
--- a/drivers/iommu/intel/Kconfig
+++ b/drivers/iommu/intel/Kconfig
@@ -45,14 +45,28 @@ config INTEL_IOMMU_SVM
      для доступа к ресурсам DMA через адресное пространство процесса
      с помощью идентификатора адресного пространства процесса (PASID).

-config INTEL_IOMMU_DEFAULT_ON
-   def_bool y
-   prompt "Включить устройства Intel DMA Remapping по умолчанию"
-   зависит от INTEL_IOMMU
+if INTEL_IOMMU
+
+choice
+   prompt "Статус по умолчанию для устройств Intel DMA Remapping"
+   default INTEL_IOMMU_DEFAULT_ON
...

Еще одной важной частью является файл debian/rules,
который определяет любые определения конфигурации.
Часто это включает определения стиля autoconf или -DCMAKE_....
Это может включать компоненты,
или определять другие поведения, указанные проектом Upstream.

Так что если вы хотите знать разницу
между любым пакетом Upstream (ядро или другой)
и выпуском Debian,
вы можете просто изучить исходный пакет таким образом.

• Официальное ядро Linux не имеет стабильного API/ABI, и RedHat на самом деле предоставляет его. Это позволяет предприятиям/людям использовать RHEL с их собственными сторонними (как открытыми, так и закрытыми) драйверами более десяти лет, не опасаясь, что что-то может сломаться. RedHat делает это, придерживаясь одной версии ядра на протяжении всего времени выпуска одной RHEL. То есть RHEL 9 поставляется с ядром 5.14.0, и это будет единственная версия ядра на протяжении всех 10 или около того лет этого выпуска RHEL.
• Официальное ядро Linux имеет очень неполное покрытие QA/QC, если вообще есть. RedHat тратит кучу денег на то, чтобы убедиться, что все работает и нет регрессий.
• С официальным ядром очень трудно получить какую-либо поддержку. Кучи регрессий решаются годами или вообще не решаются. Для поддерживаемого/квалифицированного оборудования RedHat на самом деле предлагает поддержку и может выпускать исправления.

Ядро RedHat не без своих недостатков:

• Это корпоративное ядро и в основном подходит для серверов. Его не рекомендуется использовать на совершенно новых ноутбуках и настольных компьютерах, которым требуется последний код ядра.
• RedHat не всегда исправляет уязвимости безопасности так быстро, как это делает upstream.

Теперь давайте обратим внимание на комментарии и голосования вниз:

• Существует ядро 4.19.322, которое почти полностью состоит из исправлений ошибок, их несколько тысяч.
• В то время как у Microsoft есть обширная программа (WHQL) для тестирования драйверов, их функций, производительности и стабильности, ничего подобного не существует для всего ядра Linux. Коммиты объединяются, если они компилируются и не ломают критические вещи сразу.
• Некоторые компании и люди действительно компилируют ядро, убеждаясь, что оно работает, но физически невозможно протестировать, например, все драйверы, когда у вас есть соответствующее оборудование. Например, Intel автоматизирует тестирование i915, iwlwifi и других их драйверов. Google также это делает, но объем охвата не известен, во-вторых, Google, как и RedHat, придерживается одной версии ядра достаточно долго.
• Некоторые люди регулярно тестируют ядро на регрессии производительности, но это не согласованный единый регулярный подход, а нечто очень фрагментарное и эпизодическое, например, Phoronix.
• Теперь перейдем к более современным примерам: драйвер amdgpu для Linux 6.11 имеет 53 поданных ошибок/регрессий: https://gitlab.freedesktop.org/drm/amd/-/issues/?sort=created_date&state=all&search=6.11
• Ядро Linux имеет нулевую (подразумеваемую) внутреннюю совместимость API и ABI. https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://news.ycombinator.com/item?id=21243406 Модули, скомпилированные, например, для ядра 6.11.3, не будут работать с ядром 6.11.4. Существуют хаки для обхода этой проблемы, но это неподдерживаемые хаки. Не путайте это с системными вызовами, то есть пользовательскими API, которые предоставляет ядро.