Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Первый выпуск mklinux для одновременного выполнения нескольких экземпляров ядра Linux

26.08.2026 10:55 (MSK)

Представлен первый публичный выпуск проекта Multikernel Linux (mklinux-v7.0-mk2), развивающего вариант ядра Linux, дополненный возможностью выполнения нескольких независимых экземпляров ядра на одном физическом компьютере без использования гипервизора и виртуализации. Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам и может использоваться для запуска отдельных изолированных системных окружений. Первый выпуск основан на ядре Linux 7.0 и содержит сборочную настройку "CONFIG_MULTIKERNEL", при отключении которой ядро становится полностью аналогично штатному ядру 7.0. Из архитектур CPU пока поддерживается только x86_64.

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

Хостовое ядро обеспечивает распределение имеющихся CPU, памяти и PCI-устройств между параллельно работающими дополнительными экземплярами ядра. Каждый экземпляр выполняется на отдельном выделенном ядре CPU, работает с закреплёнными за ним устройствами и имеет доступ к выделенной области физической памяти. Одновременное выполнение нескольких ядер осуществляется без виртуализации, используя SMP-обработчик, распределяющий доступные CPU. Поддерживается динамическое выделение ресурсов запускаемым окружениям и обеспечение предсказуемой производительности.

Благодаря исключению свойственных виртуализации накладных расходов, производительность при использовании Multikernel оценивается как близкая к производительности выполнения на отдельном оборудовании. При использовании Multikernel отсутствует стадия передачи управления между виртуальными машинами (VM exit), не используются страницы памяти второго уровня, отдельная модель устройств и трансляция IOMMU. При сравнении с гипервизором KVM при использовании Multikernel отмечается повышение производительности различных системных вызовов и функций от 1.07 до 2.5 раз (fork + exit - 1.07x, write() - 1.39x, AF_UNIX - 1.55x, Pipe - 2.18x, переключение контекста - 2.50x), пропускная способность и задержки при работе с памятью находятся на одном уровне.



  1. Главная ссылка к новости (https://lore.kernel.org/lkml/a...)
  2. OpenNews: Представлен Multikernel, механизм для одновременного выполнения нескольких ядер Linux
  3. OpenNews: Для ядра Linux развивается система распределённого выполнения потоков Popcorn
  4. OpenNews: Механизм Kexec HandOver для перезагрузки ядра Linux без потери состояния
  5. OpenNews: Google открыл код защищённой операционной системы KataOS
  6. OpenNews: Выпуск Kata Containers 4.0 с изоляцией контейнеров при помощи виртуализации
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/66142-mklinux
Ключевые слова: mklinux, multikernel, linux
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (19) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:26, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то вроде Xen намечается.
     
     
  • 2.4, Аноним (4), 11:53, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Скорее LPAR
     

  • 1.2, Аноним (2), 11:26, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > высокий уровень изоляции

    Насколько, что насчёт Spectre-like уязвимостей?

     
  • 1.3, Xasd7 (?), 11:42, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    чёт не ясно..

    будто бы это и хужЕе чем контэйнэрная архитектура... так как содеожит лишнии элементы которое ОДНО ядро молгло бы разруливать...

    и одновремено хужЕе чем гипервизор.. так как суть гипервизора как раз в унификации -- а если гипервизора нет -- то как бы херня какая-то чисто архитектурно

     
  • 1.6, Мемоним (?), 11:59, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Каждый экземпляр выполняется на отдельном выделенном ядре CPU

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

     
  • 1.7, localhostadmin (ok), 12:00, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам

    А как тогда достигается изоляция? Что мне мешает на одном экземпляре прочитать данные с другого, просто через /dev/sda?

     
     
  • 2.8, Мемоним (?), 12:08, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.
     
     
  • 3.11, Sm0ke85 (ok), 12:19, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.

    Так у тебя файловая система вмонтирована в оба ядра, я так понимаю, как другое ядро тебе запретит ее читать...?

    Или это просто "куча линуксов" со своей ФС запущенные одновременно? Ну так все равно, если я ломанул один, то я, как бы, могу примонтировать "чужую" ФС в /mnt например и "гулять дальше"...

     
     
  • 4.19, Мемоним (?), 13:28, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да, это компания "дружественных" ядер, где каждое ядро забирает себе часть устройств по согласию. Если ломануть одно, то изоляция ломается. Поэтому безопасность тут слабее, чем с гипервизором.

     
  • 3.13, Аноним (13), 12:23, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.
     
     
  • 4.20, Мемоним (?), 13:34, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.

    Ядра с разными настройками (тюнинг под нагрузку), ядра разных версий, живая замена ядра (но нужны отдельные инструменты чтобы перенести приложения с ядра на ядро). И изоляция все-таки более строгая, здесь ты не можешь "выйти из контейнера". Еще юзкейс: повышенная надежность, если одно ядро ушло в кернел паник, другие продолжают работать.

     
  • 2.15, похнапоха (?), 12:28, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +/
    наверное будет нужен некий VIOS, как в IBM Power, либо нужен некая преднастройка кому какое блочное устройство смапить, как в том же IBM Power.
     

  • 1.9, тожемимокрокодил (?), 12:11, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не очень понятно, это аналог NetBSD-шного RUMP или развитие Siemens-овского Xenomai?
     
  • 1.10, Sm0ke85 (ok), 12:14, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мне не очевидна область применения... Какую задачу данная технология решает лучше других... Оно как будто бы во всех задачах имеет существенные минусы... Ну может под какое нить оборудование нужно постарее/новее ядро и я вдруг пременил данного ежа-носорога и далее получил что...? Или использовал вместо виртуалки и что улучшилось, кроме производительности, или хотя бы не ухудшилось...?

    Кто-нибудь в курсе: зачем Это...?

     
     
  • 2.12, Аноним (2), 12:20, 26/08/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > зачем

    Реклама компании
    https://multikernel.io/products/cloud.html
    Цитирую - "A per-node annual subscription"

     

  • 1.16, Аноним (16), 12:34, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пахнет как вагон проблем с гонкой за ресурсами инстансами ядра, без гипервизора то
     
  • 1.17, Аноним (17), 13:10, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не очень понятно, зачем такое может понадобится. Память на каждое ядро придётся выделить заранее (нет возможности балансировать при нагрузке), устройства - тоже (каждому ядру по своей сетевой карте и жесткому диску. Ну или загрузка по сети).

    Т.е. можно запустить на мощном сервере пару десятков "независимых" машинок, но виртуалки дадут почти тот же эффект.

     
  • 1.18, Аноним (-), 13:11, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эксплуатация одного из ядер даёт почти наверняка доступ ко всем остальным...

    В гипервизоре получение права исполнения кода от имени ядра открывает путь к эксплуатации гипервизора. Защита многослойная. А тут... Для контейнеров уж лучше gVisor использовать, если виртуализация совсем не подходит.

     
  • 1.21, Жыжа (?), 13:36, 26/08/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам
    > отдельное ядро в каждом изолированном окружении (...) эксплуатация уязвимости в котором не затрагивает другие окружения

    Звучит как взаимосиключающие параграфы, не?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру