Мой дэйли дайджест

одно техническое понятие в день

Ядро Linux

19 июля 2026 · ~13 мин чтения

ос linux ядро инфраструктура открытый-код безопасность

Ядро Linux

Ядро Linux — это центральная программа операционной системы: единственный слой, который напрямую управляет процессором, памятью, дисками и сетью, а всем остальным программам выдаёт ресурсы по запросу. Всё, что ты называешь «Linux» — Ubuntu, Android, прошивка роутера, — это ядро плюс обвязка вокруг него.

История

Осень 1991 года, Хельсинки. Линус Торвальдс, 21-летний студент университета, купил себе компьютер на процессоре Intel 386 и был недоволен учебной операционной системой Minix, которую тогда использовали на курсах. 25 августа 1991 года он написал в новостную группу comp.os.minix сообщение, ставшее легендой: «Я делаю (бесплатную) операционную систему — просто хобби, ничего большого и профессионального вроде GNU не будет». Это одно из самых знаменитых ошибочных предсказаний в истории IT.

Ключевые вехи:

Проект никому не принадлежит как продукт: код под GPLv2, торговая марка Linux — у Торвальдса, а сам он и ключевые мейнтейнеры (например, Грег Кроа-Хартман, отвечающий за stable-ветки) работают в некоммерческом фонде Linux Foundation, основанном в 2007 году. Талисман — пингвин Tux, нарисованный Ларри Юингом в 1996 году.

Что это такое

Слово «ядро» (kernel) — это не метафора красоты, а точное описание места в архитектуре. Операционная система устроена слоями, и ядро — самый нижний программный слой, единственный, которому разрешено напрямую командовать железом.

Всё остальное — браузер, терминал, nginx, твой Python-скрипт — живёт в «пользовательском пространстве» (user space) и физически не может само записать байты на диск или отправить пакет в сеть. Вместо этого программа вежливо просит ядро через системный вызов (syscall — формализованный запрос «открой файл», «дай памяти», «отправь данные»). Ядро проверяет права, выполняет работу с железом и возвращает результат. Это разделение — фундамент стабильности и безопасности: упавший браузер не роняет систему, потому что он никогда и не трогал железо сам.

Важно развести три понятия, которые в быту сливаются в одно слово «линукс»:

Архитектурно Linux — монолитное ядро с загружаемыми модулями: драйверы и подсистемы работают внутри одного большого ядра (это быстро), но многие куски можно подгружать и выгружать на лету как модули (это гибко). Противоположный подход — микроядро (QNX, seL4, Minix), где драйверы вынесены в отдельные процессы: надёжнее в теории, медленнее и сложнее на практике. Windows (ядро NT) и macOS (ядро XNU) — гибриды между этими крайностями.

Аналогии из жизни

Двигатель автомобиля. Ты «пользуешься машиной», но с двигателем напрямую не взаимодействуешь никогда: есть педали, руль и коробка — интерфейсы. Ядро — двигатель и трансмиссия, приложения — водитель, системные вызовы — педали. Обновить ядро без перезагрузки — как перебрать двигатель на ходу.
Где ломается: у машины один водитель, а ядро обслуживает сотни программ одновременно и постоянно делит между ними ресурсы. Ядро не «тянет» одну задачу, а жонглирует тысячами — двигатель так не умеет.

Кухня ресторана. Гости (программы) не заходят на кухню и не жарят сами — они делают заказ через официанта (системный вызов), кухня (ядро) распределяет плиты и поваров (процессор, память) и выдаёт блюда. Санитарная зона «только для персонала» — это kernel space: гостям туда нельзя, и это защищает всех.
Где ломается: в ресторане официант может отказать хаму, но кухня не рухнет, если гость всё же прорвётся. В ОС прорыв программы в kernel space — это полная компрометация: злоумышленник на кухне становится шеф-поваром. Именно поэтому уязвимости ядра — самые страшные.

Диспетчерская аэропорта. Самолёты (процессы) не решают сами, кто садится на полосу: диспетчер (планировщик ядра) выдаёт слоты, разруливает очереди и приоритеты — санитарный борт (высокоприоритетный процесс) сядет раньше чартера. Полос мало, желающих много — это и есть разделение времени процессора.
Где ломается: диспетчер только командует, а физическую работу делают пилоты. Ядро же само и «диспетчер», и «пилот»: оно не просто разрешает доступ к диску, а само двигает данные через драйвер. Аналогия занижает объём работы ядра.

Как это работает

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

Сюжет 1: от кнопки питания до приглашения в терминале.

[кнопка питания]
      |
BIOS/UEFI            — прошивка материнской платы находит диск
      |
GRUB (загрузчик)     — меню в /boot: какую версию ядра грузить
      |
Ядро + initramfs     — ядро распаковывается в память; initramfs
      |                (мини-файловая система) даёт драйверы,
      |                чтобы смонтировать настоящий диск
      |
systemd (PID 1)      — первый пользовательский процесс; поднимает
      |                сеть, логи, nginx, базы — все сервисы
      |
login / SSH          — система готова

Отсюда понятны две вещи, которые постоянно всплывают в админской практике. Первая: на диске может лежать несколько ядер одновременно (в /boot), а работает одно — то, что выбрал загрузчик. Вторая: обновление ядра не действует до перезагрузки. Пакетный менеджер кладёт новое ядро рядом со старым, ставит флаг «требуется reboot», но подменить работающее ядро на лету штатно нельзя — оно держит на себе вообще всё. Поэтому «установили патч, нужен ребут» — это не лень админов, а архитектура.

Сюжет 2: программа читает файл.

  1. Python-скрипт вызывает open("data.txt") — библиотечная функция превращает это в системный вызов.
  2. Процессор переключается из пользовательского режима в режим ядра (это аппаратный механизм, не соглашение).
  3. Ядро проверяет права доступа: можно ли этому пользователю читать этот файл.
  4. Подсистема VFS (виртуальная файловая система — единый интерфейс поверх ext4, XFS, NTFS и прочих) находит нужный драйвер.
  5. Драйвер диска читает блоки, ядро кладёт данные в память процесса и возвращает управление.
  6. Скрипт продолжает работу, даже не узнав, сколько слоёв отработало под ним.

Внутри ядра за это отвечают крупные подсистемы: планировщик (кому из процессов дать процессор и на сколько миллисекунд), менеджер памяти (виртуальная память, своп, кэши), VFS, сетевой стек (TCP/IP живёт именно в ядре), подсистема безопасности (права, namespaces, SELinux/AppArmor) и драйверы. Драйверы — это, по разным оценкам, большая часть из примерно 30 миллионов строк кода ядра: поддержка тысяч моделей железа.

Почему уязвимости ядра — отдельная лига

Обычная дырявая программа отдаёт злоумышленнику свои права. Дыра в ядре отдаёт всё: ядро стоит выше любых проверок, потому что сами проверки — это оно. Типовой сценарий атаки: взломали сайт → получили слабого пользователя → через уязвимость ядра поднялись до root. Поэтому kernel-CVE патчат срочно, а хостеры рассылают тревожные письма.

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Номер версии ядра не гарантирует наличие патча

Дистрибутивы бэкпортируют (переносят в свои старые версии) фиксы безопасности, не меняя основную цифру: ядро 6.8.0-136 в Ubuntu может содержать заплатки из гораздо более новых ядер, а может ещё не содержать самую свежую. Проверять надо не «какая у меня версия», а бюллетени безопасности дистрибутива (у Ubuntu — USN, Ubuntu Security Notices) и статус конкретного CVE в трекере.

Кто пользуется

Ядро при этом разрабатывают не энтузиасты по вечерам: основные контрибьюторы последних лет — инженеры Intel, Google, Red Hat, AMD, Meta, Oracle, Huawei и других компаний, которым нужна поддержка их железа и их нагрузок.

Альтернативы и конкуренты

Отдельной строкой — Fuchsia от Google с микроядром Zircon: многолетний эксперимент по замене Linux в устройствах Google, пока живёт в умных дисплеях Nest, о захвате мира речи не идёт.

Когда НЕ стоит использовать

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера хостер прислал тревожное письмо о критических уязвимостях ядра Linux с громкими именами — пришлось сначала проверять, не фишинг ли это (CVE оказались настоящими, письмо легитимным), а затем готовить VPS к перезагрузке: чистить забитый диск, убеждаться, что патченное ядро установлено и загрузчик его подхватит, ребутать и проверять, что все сервисы поднялись уже на новом ядре. Один день — и практически весь жизненный цикл ядра на сервере: уязвимость, патч, ребут, верификация.

Краткое резюме