Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Первый выпуск mklinux для одновременного выполнения нескольких экземпляров ядра Linux"	+/–
Сообщение от opennews (??), 26-Авг-26, 11:26
Представлен первый публичный выпуск проекта Multikernel Linux (mklinux-v7.0-mk2), развивающего вариант ядра Linux, дополненный возможностью выполнения нескольких независимых экземпляров ядра на одном физическом компьютере  без использования гипервизора  и виртуализации. Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам и может использоваться для запуска отдельных изолированных системных окружений. Первый выпуск основан на ядре Linux 7.0 и содержит сборочную настройку "CONFIG_MULTIKERNEL", при отключении которой ядро становится полностью аналогично штатному ядру 7.0. Из архитектур CPU пока поддерживается только x86_64... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66142
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 26-Авг-26, 11:26	–2 +/–
Что-то вроде Xen намечается.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

2. Сообщение от Аноним (2), 26-Авг-26, 11:26	–1 +/–
> высокий уровень изоляции Насколько, что насчёт Spectre-like уязвимостей?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23

3. Сообщение от Xasd7 (?), 26-Авг-26, 11:42	+2 +/–
чёт не ясно.. будто бы это и хужЕе чем контэйнэрная архитектура... так как содеожит лишнии элементы которое ОДНО ядро молгло бы разруливать... и одновремено хужЕе чем гипервизор.. так как суть гипервизора как раз в унификации -- а если гипервизора нет -- то как бы херня какая-то чисто архитектурно
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от Аноним (4), 26-Авг-26, 11:53	+6 +/–
Скорее LPAR
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

6. Сообщение от Мемоним (?), 26-Авг-26, 11:59	+/–
> Каждый экземпляр выполняется на отдельном выделенном ядре CPU Получается изолированных ядер Linux не больше чем ядер процессора? Довольно жесткое ограничение по сравнение с гипервизором.
Ответить | Правка | Наверх | Cообщить модератору

7. Сообщение от localhostadmin (ok), 26-Авг-26, 12:00	+1 +/–
> Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам А как тогда достигается изоляция? Что мне мешает на одном экземпляре прочитать данные с другого, просто через /dev/sda?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #15

8. Сообщение от Мемоним (?), 26-Авг-26, 12:08	+/–
Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #11, #13

9. Сообщение от тожемимокрокодил (?), 26-Авг-26, 12:11	+/–
Не очень понятно, это аналог NetBSD-шного RUMP или развитие Siemens-овского Xenomai?
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от Sm0ke85 (ok), 26-Авг-26, 12:14	+1 +/–
Мне не очевидна область применения... Какую задачу данная технология решает лучше других... Оно как будто бы во всех задачах имеет существенные минусы... Ну может под какое нить оборудование нужно постарее/новее ядро и я вдруг пременил данного ежа-носорога и далее получил что...? Или использовал вместо виртуалки и что улучшилось, кроме производительности, или хотя бы не ухудшилось...? Кто-нибудь в курсе: зачем Это...?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #22

11. Сообщение от Sm0ke85 (ok), 26-Авг-26, 12:19	+1 +/–
>Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра. Так у тебя файловая система вмонтирована в оба ядра, я так понимаю, как другое ядро тебе запретит ее читать...? Или это просто "куча линуксов" со своей ФС запущенные одновременно? Ну так все равно, если я ломанул один, то я, как бы, могу примонтировать "чужую" ФС в /mnt например и "гулять дальше"...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #19

12. Сообщение от Аноним (2), 26-Авг-26, 12:20	+/–
> зачем Реклама компании https://multikernel.io/products/cloud.html Цитирую - "A per-node annual subscription"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

13. Сообщение от Аноним (23), 26-Авг-26, 12:23	+/–
Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #20

15. Сообщение от похнапоха (?), 26-Авг-26, 12:28	+/–
наверное будет нужен некий VIOS, как в IBM Power, либо нужен некая преднастройка кому какое блочное устройство смапить, как в том же IBM Power.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

16. Сообщение от Аноним (16), 26-Авг-26, 12:34	+/–
Пахнет как вагон проблем с гонкой за ресурсами инстансами ядра, без гипервизора то
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (17), 26-Авг-26, 13:10	+/–
Не очень понятно, зачем такое может понадобится. Память на каждое ядро придётся выделить заранее (нет возможности балансировать при нагрузке), устройства - тоже (каждому ядру по своей сетевой карте и жесткому диску. Ну или загрузка по сети). Т.е. можно запустить на мощном сервере пару десятков "независимых" машинок, но виртуалки дадут почти тот же эффект.
Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Аноним (-), 26-Авг-26, 13:11	+/–
Эксплуатация одного из ядер даёт почти наверняка доступ ко всем остальным... В гипервизоре получение права исполнения кода от имени ядра открывает путь к эксплуатации гипервизора. Защита многослойная. А тут... Для контейнеров уж лучше gVisor использовать, если виртуализация совсем не подходит.
Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Мемоним (?), 26-Авг-26, 13:28	+/–
Да, это компания "дружественных" ядер, где каждое ядро забирает себе часть устройств по согласию. Если ломануть одно, то изоляция ломается. Поэтому безопасность тут слабее, чем с гипервизором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

20. Сообщение от Мемоним (?), 26-Авг-26, 13:34	+/–
> Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами. Ядра с разными настройками (тюнинг под нагрузку), ядра разных версий, живая замена ядра (но нужны отдельные инструменты чтобы перенести приложения с ядра на ядро). И изоляция все-таки более строгая, здесь ты не можешь "выйти из контейнера". Еще юзкейс: повышенная надежность, если одно ядро ушло в кернел паник, другие продолжают работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

21. Сообщение от Жыжа (?), 26-Авг-26, 13:36	+/–
> Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам > отдельное ядро в каждом изолированном окружении (...) эксплуатация уязвимости в котором не затрагивает другие окружения Звучит как взаимосиключающие параграфы, не?
Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от Аноним (22), 26-Авг-26, 14:07	+/–
Для лайв апдейтов ядра целиком по А/Б схеме. в современном мире где приложения изначально готовятся к постоянной потере аптайма неизвестно зачем это нужно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

23. Сообщение от Аноним (23), 26-Авг-26, 14:14	+/–
От Spectre даже полноценная виртуалка не защищает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема