| |
| 2.5, Аноним (5), 17:01, 20/09/2025 [^] [^^] [^^^] [ответить]
| –2 +/– |
Везде, где нужно запускать больше одного ядра параллельно. Для локалхоста, очевидно, не нужно.
| | |
| |
| |
| 4.21, Аноним (21), 17:56, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Позволить?!
Если хостеры на этом смогут *продавать* больше виртуалок т.е. больше заработать денег на том же железе, то им это нужно.
| | |
| |
| 5.41, trashwind23 (ok), 19:43, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
 По описанию в новости не похоже что тостеры смогут больше. Тут прибивание кернелей к ядрам цпу, а хостерам оверсел в основном деньги приносит.
| | |
|
| 4.22, Аноним (22), 18:12, 20/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если своей фантазии не хватает, в новости можно пройти по ссылкам и почитать и чем мотивировались авторы, и сравнение с виртуалками, и даже предполагаемые юзкейсы.
| | |
|
| 3.17, Аноним (17), 17:47, 20/09/2025 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Везде, где нужно запускать больше одного ядра параллельно. Для локалхоста, очевидно, не
> нужно.
Эээ, у меня локалхост, а мне вот нужно. Вы, батенька путаете понятие локалхост и локалхост хомяка-нормиса, которому там только фурей смотреть и арч обновлять. И нет, неочевидно!
| | |
| |
| 4.24, Аноним (22), 18:14, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Я как раз ничего не путаю, в отличие от тебя. То, что ты дома по вечерам косплеишь сисадмина не добавляет нужности твоему локалхосту.
| | |
|
|
|
| 1.4, Аноним (4), 16:55, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Надо развернуть сравнение "Attack Surface" с VM, сдаётся мне, фуфло они втирают. "Kernel Customization" тоже, в виртуалке любое ядро можно запускать
| | |
| 1.6, 08497 (?), 17:09, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Отличное изобретение для хакиров. Все уязвимости одного кернела умножаем ни количество запущенных кернелов. А если еще на каждом кернеле запустить еще по несколько виртуалок, в каждой по несколько кернелов, ну вы поняли, да?
| | |
| |
| 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.7, Аноним (7), 17:09, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Не понимаю что здесь нового. Разные ядра linux и так выполняются в разных VM.
| | |
| |
| 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 - под ядром, да
| | |
|
|
| 1.9, Аноним (7), 17:12, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Производительность при использовании Multikernel оценивается как близкая к производительности выполнения на отдельном оборудовании.
Ну так паравиртуализация тоже близка по производительности к нативной.
| | |
| 1.12, Аноним (7), 17:24, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Гипервизор не зря ел свой "хлеб". Это гибкость, функциональность, контроль, безопасность. Обработчик SMP будет "обрастать ракушками" по мере плавания и будет тем же гипервизором.
| | |
| |
| 2.20, Еще один Аноним (?), 17:52, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну дак это классическая (Н. Винера) кибернетическая система (хоть и виртуальная), состоящей из управляющего (в данном случае гипервизор) и управляемого (сама ВМ) элемента. Мне кажется, что если покопаться детально в этом Multikernel, может тоже выясниться, что там тоже есть разделение на управляющую и управляемую подсистемы.
| | |
| |
| 3.40, 1 (??), 19:42, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Сложность управляющей системы не может быть меньше управляемый.
| | |
|
|
| 1.14, Аноним (14), 17:28, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Скрестили ужа с ежом, получилось непонятно что. С процессорами еще можно отдаленно понять как они между ядрами расшариваются. А память как делить? А ввод-вывод? Без гипервизора, ага
| | |
| |
| 2.15, Аноним (14), 17:30, 20/09/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Напоминает добровольную мультизадачность под досом. Все хорошо пока хорошо
| | |
| 2.16, Аноним (16), 17:42, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
На уровне ведра этим можно рулить (если патчи сделать), это не проблема. Непонятно только, почему они утверждают будто изоляция на уровне ядер дает меньшую поверхность атаки, чем виртуализация. Ну и в целом юзкейсы неясны. Виртуализация нужна для эмуляции оборудования, а контейнеризация для простой и быстрой доставки приложений. Какие профиты дает мультикернел непонятно.
| | |
| |
| 3.31, Аноним (31), 18:42, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
При атаке на гипервизор у малвари права ring -2, а так только ring 0.
| | |
| |
| 4.34, Аноним (27), 19:16, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Минус 2 - это относительно ring 0 гостя, для хоста это - ring 0 если сам гипервизор (аппаратно-виртуализованный, если эмуляция - то вообще всё в ring 2), а эмулируемые устройства, за исключением нескольких virtio-устройств вообще в ring 2 живут. При этом атаковать сам гипервизор на порядки сложнее из-за того что у него поверхность атаки меньше (в основном это эмулируемые устройства), а код KVM-гипервизора шарится многими продуктами и весьма отлажен и оттестирован.
| | |
| |
| 5.39, Аноним (31), 19:41, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– | |
-2 это smm, гипервизор это -1
и vmware к примеру того, да и xen
| | |
|
|
|
| 2.23, пох. (?), 18:13, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ну так и делить - тебе половина, и мине одна вторая.
В принципе, для этого и в обычном ведре почти все есть.
Диски очевидно привязаны к экземпляру. Консоль достанется кому-то одному.
Про "эффективность" при таком разделении топором, понятно, можно забыть.
| | |
| 2.43, 1 (??), 19:47, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Ещё немного ещё чутьчуть и интел сделает в процах аналог ldom.
| | |
|
| 1.25, Аноним (30), 18:21, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Наконец будет нормальное 3d ускорение в гостевой системе без virgl/virtio и sriov?
| | |
| 1.26, Аноним (27), 18:27, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>Multikernel преподносится как новая архитектура изоляции, занимающая нишу между виртуализацией при помощи гипервизора и контейнерной изоляцией на базе общего ядра
Не понятно, зачем. Главная претензия к контейнерам - из них можно достать до главного ядра, ломануть его, а как его ломанули - так машина взломана по полной. Для решения этой проблемы используют гипервизоры. Ядру выделяется виртуальная машина, оно в ней полностью крутится, а из виртуальной машины до хоста - гипервизор с очень ограниченной поверхностью атаки. Тут же предлагают выполнять дочерние ядра поверх хостового без всякого гипервизора, то есть ничего не меняется с точки зрения взлома контейнеров: ломаем дочернее ядро, и сразу же ломаем хостовое, PROFIT.
| | |
| |
| 2.37, Аноним (37), 19:23, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Забыл ещё вывод подвести: предложенная система будет жрать память как полноценная виртуалка, иметь оверхед, сравнимый с виртуалкой, а безопасность предлагать на уровне контейнера. На сайте один маркетинговый буллшит, snake oil какой-то.
| | |
|
| 1.28, Аноним (27), 18:33, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Кстати, дочерние ядра прямо в юзерспейсных процессах, а под ними - своя ФС, свои контейнеры ... можно запускать было очень давно, с начала нулевых в ядре опция его собирать так, чтобы оно работало как обычная линуксовая программа. Только единственный профит - это просто упрощение разработки самого ядра линукс и дров к нему, чтобы с виртуалками не париться. Кому для изоляции - тем полноценная виртуалка. Кому не нужны такие требования к изоляции - тем и контейнеры и песочницы сойдут.
| | |
| |
| 2.45, 1 (??), 19:55, 20/09/2025 [^] [^^] [^^^] [ответить]
| +/– |
Скорее невозбранно сперли, но недоперли и отдали впопенсорс.
| | |
|
| 1.46, Аноним (46), 19:57, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Мне кажется, или что-то походжее уже было в Cooperative Linux? Там, правда, ядро запускали в винде
| | |
| 1.51, Аноним (53), 20:14, 20/09/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Multikernel IPI
А почему ipi?
Ч̶т̶о̶б̶ы̶ ̶н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ api бы не пропустили т.к. stable is a nonsense, а так прокатит.
| | |
|
