The OpenNET Project / Index page

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

Представлен Multikernel, механизм для одновременного выполнения нескольких ядер Linux

20.09.2025 15:17

Для обсуждения разработчиками ядра Linux предложена серия патчей, разработанных проектом Multikernel, который на днях был переведён в категорию открытого ПО и теперь будет развиваться совместно с сообществом. Multikernel позволяет на одном физическом компьютере выполнять несколько независимых экземпляров ядра Linux, которые имеют прямой доступ к аппаратным ресурсам и могут использоваться для запуска нескольких изолированных системных окружений. Проект создан компанией Multikernel Technologies, основанной и возглавляемой Конгом Вангом (Cong Wang), сопровождающим в ядре Linux подсистему управления трафиком (TC, Traffic Control).

Для запуска и управления ядрами предложен усовершенствованный вызов kexec, который в отличие от классического kexec не ограничивается заменой работающего ядра и позволяет запускать дополнительные экземпляры ядра, выполняемые параллельно. Для мониторинга и отладки запущенных экземпляров ядра реализован интерфейс "/proc/multikernel", а для обмена сообщениями между ядрами и координации работы предложен коммуникационный фреймворк Multikernel IPI.

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

Производительность при использовании Multikernel оценивается как близкая к производительности выполнения на отдельном оборудовании. Подобного удалось добиться за счёт исключения свойственных виртуализации накладных расходов, возникающих из-за обработчиков передачи управления между виртуальными машинами (VM exit), трансляции IOMMU и вмешательства гипервизора в выполнение привилегированных операций. Поддерживается динамическое выделение ресурсов запускаемым окружениям и обеспечение предсказуемой производительности.

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

Основные достоинства Multikernel:

  • Улучшенная изоляция от сбоев в работе выполняемых окружений.
  • Повышенная безопасность за счёт разделения на уровне ядра.
  • Более эффективное использование ресурсов по сравнению с традиционными виртуальными машинами на базе гипервизоров, таких как KVM и Xen.
  • Потенциальная возможность обновления ядра без остановки работы при использовании механизма KHO (Kernel Hand Over).
  • Поддержка интеграции со стандартными облачными инфраструктурами и возможность прозрачного перехода с традиционных систем виртуализации и контейнерной изоляции.
  • Полная совместимость с существующими приложениями и системными интерфейсами Linux. Multikernel лишь точечно изменяет ядро, сохраняя полную совместимость на уровне API.


  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: VMScape - атака на CPU AMD и Intel, обходящая изоляцию между гипервизором и гостевой системой
  3. OpenNews: Выпуск Kata Containers 3.4 с изоляцией на основе виртуализации
  4. OpenNews: Компания Intel прекратила разработку дистрибутива Clear Linux
  5. OpenNews: Для ядра Linux развивается система распределённого выполнения потоков Popcorn
  6. OpenNews: Механизм Kexec HandOver для перезагрузки ядра Linux без потери состояния
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/63913-multikernel
Ключевые слова: multikernel, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (107) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 16:44, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Не описано где может быть полезен такой комбайн.
     
     
  • 2.5, Аноним (5), 17:01, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Везде, где нужно запускать больше одного ядра параллельно. Для локалхоста, очевидно, не нужно.
     
     
  • 3.11, Аноним (11), 17:21, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Эм, хостеры которые не могут себе позволить виртуалки ?
     
     
  • 4.21, Аноним (21), 17:56, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Позволить?!

    Если хостеры на этом смогут *продавать* больше виртуалок т.е. больше заработать денег на том же железе, то им это нужно.

     
     
  • 5.41, trashwind23 (ok), 19:43, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По описанию в новости не похоже что тостеры смогут больше. Тут прибивание кернелей к ядрам цпу, а хостерам оверсел в основном деньги приносит.
     
     
  • 6.82, Аноним (-), 10:09, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > По описанию в новости не похоже что тостеры смогут больше. Тут прибивание
    > кернелей к ядрам цпу, а хостерам оверсел в основном деньги приносит.

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

    Т.е. если 1 мультикернел профачится - может это отлиться другому мультикернелу или основному кернелу из той схемы? В виртуалке то - как максимум процесс виртуалки будет прибит и на этом факап и закончится. А там?

     
  • 4.22, Аноним (22), 18:12, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Если своей фантазии не хватает, в новости можно пройти по ссылкам и почитать и чем мотивировались авторы, и сравнение с виртуалками, и даже предполагаемые юзкейсы.
     
     
  • 5.108, Аноним9444935593 (?), 21:56, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется и в новости довольно доходчиво объяснено, чукча писатель.
     
  • 3.17, Аноним (17), 17:47, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Везде, где нужно запускать больше одного ядра параллельно. Для локалхоста, очевидно, не
    > нужно.

    Эээ, у меня локалхост, а мне вот нужно. Вы, батенька путаете понятие локалхост и локалхост хомяка-нормиса, которому там только фурей смотреть и арч обновлять. И нет, неочевидно!

     
     
  • 4.24, Аноним (22), 18:14, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Я как раз ничего не путаю, в отличие от тебя. То, что ты дома по вечерам косплеишь сисадмина не добавляет нужности твоему локалхосту.
     
     
  • 5.42, native (??), 19:45, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    огласите признаки нужности, пожалуйста
     
     
  • 6.96, Аноним (22), 16:43, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Приносит деньги — значит нужен.
     
     
  • 7.121, Аноним (121), 09:53, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Тестирование - денег не приносит. Удаляем.

                                  Э. Мэнеджер.

     
     
  • 8.123, Потомок изобретателя колеса (?), 11:10, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Приносит Потом ... текст свёрнут, показать
     
  • 2.33, Аноним (33), 18:46, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.kernel.org
     
  • 2.56, двухядерный (?), 21:29, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Core One Duo & Core Two Duo.
    На первом ядре запущено ядро с опеннетом в lynx. На втором вторые герои.
    И получилась какая-то линукс-тавтология, ля.
     
  • 2.87, shardddin (?), 12:09, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    По идее, при параллельном выполнении другим ядро с маленькой задержкой - можно дойти до точки паники первого ядра и обойти ошибку - с продолжением работы... Во втором случае - запустить деятельность обновленного ядра после обновления - бесшовно и без перезагрузок... Видится хорошим делом!
     
     
  • 3.93, sage (??), 15:36, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Паника скорее от драйверов прилетит, значит или там баг или железо отвалилось.
    Судя по диаграммам, драйверы железа останутся в общем Kernel. И когда оно запаникует, умрёт вся система.
     

  • 1.4, Аноним (4), 16:55, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    Надо развернуть сравнение "Attack Surface" с VM, сдаётся мне, фуфло они втирают. "Kernel Customization" тоже, в виртуалке любое ядро можно запускать
     
     
  • 2.62, penetrator (?), 22:08, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    100% фуфло

    Одновременное выполнение нескольких ядер осуществляется без виртуализации - так за счет чего тогда изоляция? если аппаратные ресурсы для этого не используются? чем это лучше крэп-контейнеров?

    VM - performance overhead - High
    бред сивой кабылы, я тестил VMWare на AMD CPU, производительность под VM была ниже всего на 1-2%, когда тот же кубер сжирает до 30% и никого это не волнует

    есть конечно проблемы с оверсейлингом и с ущербной дисковой подсистемой у VPS, обычно IO даже у гиперскелейров на уровня дешманских провайдеров, но это проблема самих продаванов, да и в принципе авторы явно не про IO пишут, а про CPU

     
     
  • 3.84, Анонисссм (?), 11:22, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >когда тот же кубер сжирает до 30% и никого это не волнует

    меня волнует ) поэтому его у меня нет

     
  • 3.94, Аноним (94), 15:40, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Одновременное выполнение нескольких ядер осуществляется без виртуализации - так за счет чего тогда изоляция?

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

     
     
  • 4.109, penetrator (?), 22:27, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    не станет также сложно, у тебя сугубо программное разделение, это же все равно что сбежать их сандбокса

    все фишки CPU для виртуализации ты не используешь, в том числе например новомодный SEV в Epyc

     
  • 3.97, Аноним (22), 16:47, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > тот же кубер сжирает до 30%

    До 30% чего именно? А то у меня этих кубов пара десятков в проде и я почему-то 30% оверхед не наблюдаю нигде. Не поделишься настройками? Хочу попугать коллег на хэллоуин.

    > проблемы с оверсейлингом

    Что такое «оверсейлинг»? Это что-то морское? Чрезмерное хождение под парусами?

     
     
  • 4.99, QrKot (?), 17:28, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да он курьер в docker-for-windows крутит. Оно и логично: кубер на линухе, запущенной в виртуалке, которая крутится в hyperV, запущенном из Windows For Home Users. Ну да, там пипец оверхед...
     
     
  • 5.104, Аноним (22), 21:44, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я раньше так и делал, только с той разницей, что на Windows 11 Pro. Я оверхед не замерял, но он там достаточно небольшой, чтобы его игнорировать, и уж точно не 30%. Вот уж что-что, а в виртуалке Линукс весьма эффективно работает, а тут ещё Майкрософт постарался чтобы под HyperV нативные интерфейсы можно было использовать. Даже в случае Docker for Windows и KinD или minikube, не видел тридцатипроцентного оверхеда, но видел уже достаточный чтобы его заметить. Теряюсь в догадках.
     
  • 5.111, penetrator (?), 22:44, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    откуда ты знаешь что там где крути? ванга куева?

    обсуждения в нете хватает

    https://www.reddit.com/r/kubernetes/comments/1eqtzqm/k8s_performance_degradati

    вот тут он сливает даже VM

    https://www.youtube.com/watch?v=Y4pOmi0j_90

    можешь свои тесты выложить, посмотрим, пообсуждаем

     
  • 4.110, penetrator (?), 22:39, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    погугли. сеть + CPU, там количество веб запросов тестировалось

    > Что такое «оверсейлинг»? Это что-то морское? Чрезмерное хождение под парусами?

    это overselling, чего докулопался, ты ж понял какой термин на английском имелся ввиду

     
  • 3.98, QrKot (?), 17:23, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Курьер съедает 30% чего? Словарного запаса? Свободного времени?
    Что такого cgroup'ы с namespace'ами съедают?
     
  • 2.68, Аноним (68), 00:21, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Attack Surface

    Они на ровных щах утверждают, что если убрать гипервизор и вкрутить ядро гостя сразу, то поверхность атаки уменьшится?

     
     
  • 3.100, Аноним (-), 18:05, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> Attack Surface
    > Они на ровных щах утверждают, что если убрать гипервизор и вкрутить ядро
    > гостя сразу, то поверхность атаки уменьшится?

    По логике вещей - да, из поверхности атаки выпадает как минимум гипервизор :)

     
     
  • 4.120, pofigist (?), 09:21, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это из серии "для лучшей безопасности уберем из сети фаервол, чтоб уменьшить поверхность отаки"🤣
     
  • 2.73, SKZ (?), 06:03, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    "Золяция идеть" там, разве что, за счёт разных таблиц трансляции на разных процессорах.
     

  • 1.6, 08497 (?), 17:09, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Отличное изобретение для хакиров. Все уязвимости одного кернела умножаем ни количество запущенных кернелов. А если еще на каждом кернеле запустить еще по несколько виртуалок, в каждой по несколько кернелов, ну вы поняли, да?
     
     
  • 2.19, мамины какиры самые забавные (?), 17:51, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Отличное изобретение для хакиров. Все уязвимости одного кернела умножаем ни количество
    > запущенных кернелов. А если еще на каждом кернеле запустить еще по
    > несколько виртуалок, в каждой по несколько кернелов, ну вы поняли, да?

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

    Но по факту чем оно отличается от необходимости щупать подсеть с несколькими машинами на предмет наличия уязвимостей в каждой, например?

    Сдаётся мне, вы на очень толстый глобус пытаетесь натянуть очень тощую и ни разу не эластичную сову.


     
     
  • 3.36, 08497 (?), 19:22, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Чисто гипотетически, в вакууме, но к этим всем ядрам ваш вакуумный какир должен ещё пробраться и как-то понять, что соседнее ядро это соседнее ядро в пачке мультиядер, как-то сдетектить каким уязвимостям оно подвержено и т.п.

    ls /proc/multikernel

    > Но по факту чем оно отличается от необходимости щупать подсеть с несколькими машинами на предмет наличия уязвимостей в каждой, например?

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

    > Сдаётся мне, вы на очень толстый глобус пытаетесь натянуть очень тощую и ни разу не эластичную сову.

    И получается, что сова не такая и тощая, да и глобус не толст.

     
  • 3.47, Хорошо смеёцца TOT (?), 19:59, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хз, как оно в вакууме, а в зэ Ядре вон - интерфейс мультиядра. "Для мониторинга и отладки". Ага.

    Доступ к железу прямой. И у ядер-сыновей и Ядра-Отца. А у нас тут миллион "спекулятивных" уязвимостей в процессорах и чипах памяти. Удобно.

    Сеть изолировать легко. У сети - периметр. Сторожа на концах протоколов.
    А тут, понимаю, дЫрект-аксэс-саксэсс к железу, на котором стоит сторожка.

    А потом, когда доступ наспекулировали, на нескольких ядрах можно ещё долго прятаться: переживая сканирования, обновления и перезагрузки. Ведь, не будут же "экономисты" из-за нас все ядра останавливать и допрашивать..

    Ну хз, конечно. Но если из виртуалок убегают и гипервизоры ломают, тот тут.. Ну зато сэкономия. А ещё сэкономнее - в розетку не включать. Люди, берегите планету!

     

  • 1.7, Аноним (7), 17:09, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Не понимаю что здесь нового. Разные ядра linux и так выполняются в разных VM.
     
  • 1.8, Мемоним (?), 17:10, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А на средней схеме Hypervisor не должен быть под Kernel?
     
     
  • 2.10, Аноним (7), 17:14, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Они его интегрировали и сделали прозрачным.
     
  • 2.38, 1 (??), 19:34, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эта схема для kvm.
    В случае с xen или vmware hypervisor будет над hardware.
     
     
  • 3.52, morphe (?), 20:15, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > vmware

    Если речь о vmware workstation и прочем консьюмерском - то над kernel, если о чём-то другом - хотел бы услышать о чём

    HyperV вот как и Xen - под ядром, да

     
     
  • 4.61, Аноним (61), 21:53, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> если о чём-то другом - хотел бы услышать о чём

    Вы про ESXi не слышали?.. Оо

     
     
  • 5.63, morphe (?), 22:37, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы про ESXi не слышали?.. Оо

    Я почему-то думал что под него только штуки для менеджмента от vmware есть (VSphere), я думал сам ESXi не от них, спасибо

     
     
  • 6.126, пох. (?), 12:09, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    экспертиза... ну вы поняли, да.
     
  • 3.66, Мемоним (?), 23:05, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Эта схема для kvm.
    > В случае с xen или vmware hypervisor будет над hardware.

    Тут по-моему неважно что код KVM реализуется как часть ядра. Важно что он предоставляет низкоуровневый сервис верхнему слою (остальному ядру).

     

  • 1.9, Аноним (7), 17:12, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Производительность при использовании Multikernel оценивается как близкая к производительности выполнения на отдельном оборудовании.

    Ну так паравиртуализация тоже близка по производительности к нативной.

     
     
  • 2.95, sage (??), 15:43, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это пока процесс работает. Когда переключение контекста происходит - всё замирает на большее время.
     

  • 1.12, Аноним (7), 17:24, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Гипервизор не зря ел свой "хлеб". Это гибкость, функциональность, контроль, безопасность. Обработчик SMP будет "обрастать ракушками" по мере плавания и будет тем же гипервизором.
     
     
  • 2.20, Еще один Аноним (?), 17:52, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну дак это классическая (Н. Винера) кибернетическая система (хоть и виртуальная), состоящей из управляющего (в данном случае гипервизор) и управляемого (сама ВМ) элемента. Мне кажется, что если покопаться детально в этом Multikernel, может тоже выясниться, что там тоже есть разделение на управляющую и управляемую подсистемы.
     
     
  • 3.40, 1 (??), 19:42, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сложность управляющей системы не может быть меньше управляемый.
     
     
  • 4.48, Аноним (48), 20:03, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сомнительно. Какова ваша аргументация?
     
  • 4.67, r1 (?), 23:46, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Наоборот! Она должна быть меньше- иначе не случится собственно управления. Получится просто еще одна надстройка над управляемым объектом.
     
  • 2.80, Аноним (-), 10:05, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Гипервизор не зря ел свой "хлеб". Это гибкость, функциональность,
    > контроль, безопасность. Обработчик SMP будет "обрастать ракушками"
    > по мере плавания и будет тем же гипервизором.

    Или не будет - не настолько крутая и полная абстракция - может заскипать некоторые вещи.

     

  • 1.14, Аноним (14), 17:28, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Скрестили ужа с ежом, получилось непонятно что. С процессорами еще можно отдаленно понять как они между ядрами расшариваются. А память как делить? А ввод-вывод? Без гипервизора, ага
     
     
  • 2.15, Аноним (14), 17:30, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Напоминает добровольную мультизадачность под досом. Все хорошо пока хорошо
     
  • 2.16, Аноним (16), 17:42, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    На уровне ведра этим можно рулить (если патчи сделать), это не проблема. Непонятно только, почему они утверждают будто изоляция на уровне ядер дает меньшую поверхность атаки, чем виртуализация.  Ну и в целом юзкейсы неясны. Виртуализация нужна для эмуляции оборудования, а контейнеризация для простой и быстрой доставки приложений. Какие профиты дает мультикернел непонятно.
     
     
  • 3.31, Аноним (31), 18:42, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    При атаке на гипервизор у малвари права ring -2, а так только ring 0.
     
     
  • 4.34, Аноним (34), 19:16, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Минус 2 - это относительно ring 0 гостя, для хоста это - ring 0 если сам гипервизор (аппаратно-виртуализованный, если эмуляция - то вообще всё в ring 2), а эмулируемые устройства, за исключением нескольких virtio-устройств вообще в ring 2 живут. При этом атаковать сам гипервизор на порядки сложнее из-за того что у него поверхность атаки меньше (в основном это эмулируемые устройства), а код KVM-гипервизора шарится многими продуктами и весьма отлажен и оттестирован.
     
     
  • 5.35, Аноним (34), 19:16, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    тьфу, в ring 3
     
  • 5.39, Аноним (31), 19:41, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    -2 это smm, гипервизор это -1

    и vmware к примеру того, да и xen

     
     
  • 6.74, Аноним (74), 07:56, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Скажем прямо, что минусовые уровни вообще чистые фантазии.
     
     
  • 7.81, Аноним (31), 10:07, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это возможности системы по ограничению прав кода. Фантазиями это было, пока не пошло массово на практике.
     
     
  • 8.83, Аноним (83), 10:51, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ни в одной официальной документации эти режимы не перечисленны как минусовые кол... текст свёрнут, показать
     
     
  • 9.86, Аноним (31), 11:49, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Там вообще какие-то подробности есть Это всё под NDA, пользователь таких детале... текст свёрнут, показать
     
     
  • 10.88, SKZ (?), 13:39, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Такое NDA, что аж в SW Developer Manual расписано ... текст свёрнут, показать
     
     
  • 11.89, Аноним (31), 14:09, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Там не то расписано ... текст свёрнут, показать
     
     
  • 12.127, SKZ (?), 12:52, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Обычно эти сказки рассказывают те, кто ни одного NDA не видел в жизни, не говоря... текст свёрнут, показать
     
     
  • 13.128, Аноним (31), 13:04, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё чаще в них не верят те, кто свой опыт проецируют туда, где ему не место Кон... текст свёрнут, показать
     
  • 7.101, Аноним (-), 18:08, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Скажем прямо, что минусовые уровни вообще чистые фантазии.

    А SMM mode тогда - какой ring получается? Учитывая что он более привилегированный чем ring0 вплоть до того что может в любой момент выставить код ring0, тот никак не может это предотвратить и может как максимум постфактум узнать - что SMM handler его оказывается выпер с проца на эн наносекунд. Что делает x86 не очень подходящими для реалтайм применений системами. Потому что worst case обработчика SMM в проприетарном бинарном фирмваре - неизвестная величина.

     
     
  • 8.119, Аноним (119), 09:13, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Никакой, это просто SMM mode ... текст свёрнут, показать
     
  • 2.23, пох. (?), 18:13, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так и делить - тебе половина, и мине одна вторая.
    В принципе, для этого и в обычном ведре почти все есть.
    Диски очевидно привязаны к экземпляру. Консоль достанется кому-то одному.

    Про "эффективность" при таком разделении топором, понятно, можно забыть.

     
  • 2.43, 1 (??), 19:47, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё немного ещё чутьчуть и интел сделает в процах аналог ldom.
     
  • 2.118, Аноним (-), 09:07, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    DragonFlyBSD так с самого начала и работает На каждом ядре CPU можно запускать ... большой текст свёрнут, показать
     

  • 1.25, Аноним (25), 18:21, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Наконец будет нормальное 3d ускорение в гостевой системе без virgl/virtio и sriov?
     
     
  • 2.44, 1 (??), 19:50, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Без ... не будет.
     

  • 1.26, Аноним (34), 18:27, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Multikernel преподносится как новая архитектура изоляции, занимающая нишу между виртуализацией при помощи гипервизора и контейнерной изоляцией на базе общего ядра

    Не понятно, зачем. Главная претензия к контейнерам - из них можно достать до главного ядра, ломануть его, а как его ломанули - так машина взломана по полной. Для решения этой проблемы используют гипервизоры. Ядру выделяется виртуальная машина, оно в ней полностью крутится, а из виртуальной машины до хоста - гипервизор с очень ограниченной поверхностью атаки. Тут же предлагают выполнять дочерние ядра поверх хостового без всякого гипервизора, то есть ничего не меняется с точки зрения взлома контейнеров: ломаем дочернее ядро, и сразу же ломаем хостовое, PROFIT.

     
     
  • 2.37, Аноним (37), 19:23, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Забыл ещё вывод подвести: предложенная система будет жрать память как полноценная виртуалка, иметь оверхед, сравнимый с виртуалкой, а безопасность предлагать на уровне контейнера. На сайте один маркетинговый буллшит, snake oil какой-то.
     

  • 1.28, Аноним (34), 18:33, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Кстати, дочерние ядра прямо в юзерспейсных процессах, а под ними - своя ФС, свои контейнеры ... можно запускать было очень давно, с начала нулевых в ядре опция его собирать так, чтобы оно работало как обычная линуксовая программа. Только единственный профит - это просто упрощение разработки самого ядра линукс и дров к нему, чтобы с виртуалками не париться. Кому для изоляции - тем полноценная виртуалка. Кому не нужны такие требования к изоляции - тем и контейнеры и песочницы сойдут.
     
     
  • 2.65, Аноним (65), 23:00, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как опция в конфиге выглядит?
     
     
  • 3.75, Аноним (74), 08:04, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ARCH=um
     
  • 3.102, Аноним (-), 18:10, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Как опция в конфиге выглядит?

    man "user mode linux" грубо говоря. Идея проста как топор: ядро пашет в юзермоде и реализует свои сисколы - сбагриванием сисколов себе подобному уровнем ниже. Но вот по оверхеду это все же не совсем бесплатно.

     

  • 1.32, Аноним (32), 18:43, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    О, начали rump NetBSDшный переизобретать...
     
     
  • 2.45, 1 (??), 19:55, 20/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее невозбранно сперли, но недоперли и отдали впопенсорс.
     

  • 1.46, Аноним (46), 19:57, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне кажется, или что-то походжее уже было в Cooperative Linux? Там, правда, ядро запускали в винде
     
     
  • 2.70, Аноним (-), 02:53, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    CoLinux - это модифицированный User-Mode Linux т.е. запуск ядра как приложения пользователем в его окружении от сюда и название. Сабж вроде как модифицирует процесс загрузки ядра и вместо одного ядра, запускает несколько ядер. Пользователь никаких приложений не запускает, он дает команду утилите которая взаимодействует с ядром.
     
  • 2.92, maximnik0 (?), 15:29, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Мне кажется, или что-то походжее уже было в Cooperative Linux?

    Да, был похожий проект.Специально падченное ядро - ещё без полноценной аппаратной виртулизации В ALT linux  стоит поискать -  там была какая то метка у той серии ядер.Если нужно поищу в рассылке - народ для серверов использовал- но глюки иногда были страшные, как выяснилось изоляция оказалось слабая из за особенности сегментной памяти.Спустя 2 года вышел xen а потом и остальные подтянулись проект загнулся: кое что в виде подачей потом ушло на контейнеры и KVM.

     

  • 1.51, Аноним (51), 20:14, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Multikernel IPI

    А почему ipi?
    Ч̶т̶о̶б̶ы̶ ̶н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ api бы не пропустили т.к. stable is a nonsense, а так прокатит.

     
     
  • 2.72, solardiz (ok), 04:54, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://en.wikipedia.org/wiki/Inter-processor_interrupt
     

  • 1.55, Аноним (55), 20:53, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Продаваны виртуалок негодуют,придется переучиваться.
     
  • 1.64, Аноним (64), 22:52, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вот так ядро Линукс получит микроядерную архитектуру! Размножат обкусанный монолит и посадят по ядру на каждую подсистему.
     
     
  • 2.69, Аноним (69), 01:35, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    микроядерной она от этого не станет
     
     
  • 3.78, Песнь скрипучих дроздов (?), 09:19, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    но к тому всё идёт, но а сейчас это больше напоминает ядерный ну или ядрёный флатпак.
    а так со временем выделят по ядру на каждую подсистему(конечно же для повышения безопасности) а чтобы всем этим управлять напишут "небольшой набор низкоуровневых примитивов/механизмов/сервисов", ну и чем это будет не микроядро, правда через Ж, но всё же
     
  • 2.105, Аноним (105), 21:47, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да просто Линус боится потерять контроль над разработкай ядра, иначе своё ЧСВ несможет больше реализовывать.
    Микроядерная архитектура это прогресс для свободного ПО.
     

  • 1.71, Аноним (-), 03:07, 21/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На данном этапе не пригодно к использованию: бэкэнд есть (патчи ядра), а самой утилиты-менеджера и документации нет, даже в репозитории разработчика. Разработчик на хайпе, пиарится: звезды зарабатывает, последователей, донаты, контракты. Какое-то время придется подождать пока он не настытит свое ЧСВ и не откроет утилиту-менеджер или пока другие не разработают.
     
  • 1.90, Аноним (90), 14:36, 21/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они придумали subhurd второй раз, но сделали его монструозным.
     
  • 1.91, Roman Dyaba (ok), 15:02, 21/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Это фигне больше 25-и лет ! Старо как мир.
    Заводим микроядро и vm к нему, контролируем его через сеть, заводим любую целевую систему.

    https://vk.com/qnx_rtos

    Почитайте так же документацию netbsd и freebsd, и даже opennet, всё подробно описано.

     
     
  • 2.103, Аноним (-), 18:13, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Почитайте так же документацию netbsd и freebsd, и даже opennet, всё подробно описано.

    Зачем тратить время на Linux - я понимаю. А зачем на вон тех - не особо. С этого никаких денег не получишь. Особенно на нормальных условиях и без ужасного головняка, как в этом QNX.

    Linux так то нынче - тоже уже RTOS, патчи RT Linux все ж дожали в майнлайн.

     
     
  • 3.107, Аноним (22), 21:51, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Linux так то нынче - тоже уже RTOS, патчи RT Linux все ж дожали в майнлайн.

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

     
     
  • 4.112, Аноним (112), 23:15, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > там неправильный RTOS

    можно начать с того, что x86 - не RT

     
  • 3.115, bOOster (ok), 07:27, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Разумный системный администратор применяет все что есть под рукой если решение подходит лучше.
    Ну а оголтелые с отсутствием/недостатком компетенций застревают в чем-то одном - "не понимают".
    Непониматоры/неосиляторы такие.
     

  • 1.106, Аноним (22), 21:48, 21/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну что, кто там без солярисовых зон страдал?

    Прежде чем строчить «это не то, в солярисе было…» — да, это не то. Да, в солярисе было. Именно что было. А это есть (или возможно будет — как угодно) на Линуксе, который тоже есть сейчас.

     
     
  • 2.113, нах. (?), 23:37, 21/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В солярисе было нормально сделано. А тут - очередной монстр д-ра Франкенштейна.

     

  • 1.114, bOOster (ok), 07:19, 22/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эта возможность опоздала лет на 20. Когда компьютерное железо стоило дорого. На текущий момент абсолютно ненужная и потенциально проблемная возможность.
     
     
  • 2.124, пох. (?), 11:43, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты из своего подвала не видел - компьютерное железо сейчас стоит ОЧЕНЬ дорого. Гораздо дороже твоего пнятри.
    И его мощность избыточна для твоего хомяка (ему и пня три хватило бы, если бы конденсаторы не взорвались).

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

     

  • 1.116, Аноним (116), 07:41, 22/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне одному кажется, что это уже лет 20 есть в XEN (паравиртуализация)?
     
     
  • 2.125, пох. (?), 11:44, 22/09/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ксен редбиэм запритила.
    Поэтому нате на лопате.

     

  • 1.117, Аноним12345 (?), 08:36, 22/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    дак а железо-то - я имею ввиду периферию в виде памяти, видеокарт - все равно одно, и будет к ним очередь, как ни крути
     
  • 1.122, Соль земли2 (?), 10:18, 22/09/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все ядра одинаково владеют железом? Значит безопасность не прибавляется.
     

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



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

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