В списке рассылки ядра Linux представлена шестая версия патчей с реализацией механизма Kexec HandOver (KHO), развиваемого инженерами из компаний Amazon, Microsoft и Google. Патчи уже приняты в ветку mm-everything, в которой осуществляется накопление изменений для будущей ветки ядра 6.16, связанных с управлением памятью. На базе Kexec HandOver компания Google разрабатывает подсистему Live Update Orchestrator (LUO), позволяющую перезагружать ядро без остановки работы устройств...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63075
В промежутках между рестартами эту область памяти можно править как хочешь и занести троян.
> В промежутках между рестартами эту область памяти можно править как хочешь и
> занести троян.а чё сразу троян не записать в ядро? Или не записать троян в /dev/mem? А, точно, права же нужны
> а чё сразу троян не записать в ядро? Или не записать троян
> в /dev/mem? А, точно, права же нужныБолее того. Если кто-то смог втиснуться куда-то в район kexec() - он и так уже все полномочия давно имел. А /dev/mem можно и зарубить, в режиме lockdown вы фиг пропатчите им память ядра. Даже от рута.
>> В промежутках между рестартами эту область памяти можно править как хочешь и
>> занести троян.
> а чё сразу троян не записать в ядро? Или не записать троян
> в /dev/mem? А, точно, права же нужныЧто бы была возможность понять ответ на "риторический" вопрос, необходимы основополагающие знания, что есть алгоритм.
Алгоритм такой:
1. Получаем права.
2. Пишем троян.И не надо засыпать риторическими вопросами "как ты получишь права?" и "где мне скачать зеродей?"
Если lockdown, то еще подписать этот троян валидным ключом придется. Или это тоже риторический вопрос?
> Если lockdown, то еще подписать этот троян валидным ключом придется. Или это
> тоже риторический вопрос?Да, это вопрос цены.
> можно править как хочешь и занести троян.Но зачем?
Надежнее заносить трояны и бекдоры прямо в ядро.
Чтобы потом всякие Bvp47 жили по 10 лет.
> Надежнее заносить трояны и бекдоры прямо в ядро.
> Чтобы потом всякие Bvp47 жили по 10 лет.Опять этот чудак тут с этим Bvp47, который вообще - совершенно отдельная приблуда и Linux "виноват" только тем что эта штука и его решила поддерживать. Но оно и не только на линухе работает, и это же можно пре.
Видимо этот горе-анон надеялся что никто не дойдет даже до вики, почитать что такое Bvp47. Но этот хитрый план потерпел неудачу.
> В промежутках между рестартами эту область памяти можно править как хочешь и
> занести троян.Чувак, если у тебя кто-то правит память прямо когда старый кернел отдает управление новому - у тебя в системах и так уже был жирнейший троян, со всеми полномочиями. Более того - этот троян уже имел абсолютный контроль над системой и всяко мог делать все что пожелает.
Некоторые вещи из всё "что пожелает" делать не так просто. Например, реализовать stop_machine() без вызова stop_machine().
> Некоторые вещи из всё "что пожелает" делать не так просто. Например,
> реализовать stop_machine() без вызова stop_machine().Как говорится, бойтесь своих желаний...
Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний. Может это потому, что они юзают си, где нет ооп в явном виде. При наличии ооп задача сохранения состояния объекта обычно становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. Хоть в файл, хоть в другую область памяти, хоть куда.
> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением
> состояний. Может это потому, что они юзают си, где нет ооп
> в явном виде. При наличии ооп задача сохранения состояния объекта обычно
> становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо,
> ты без всякой сериализации просто сохраняешь память объекта куда тебе надо.
> Хоть в файл, хоть в другую область памяти, хоть куда.ну, и где хоть в одной оси написаной на модном ооп-язычке есть что-то типа kexec хотяб в старом виде? Может не в опенсорсной макоси или вынде?
> Может не в опенсорсной макоси или вынде?так они на немодных.
Надо попробовать на брейнфаке!
При обновлении соснёшь. При переносе на другое железо соснёшь.
> При обновлении соснёшь. При переносе на другое железо соснёшь.такое ощющение что ты пишешь не приходя в сознание, какой kexec при смене железа? Ты вообще в букавы умеешь?
Он утверждает, что сериализация -- оверинжиниринг. Это не так. При чём тут kexec, у тебя всё хорошо?
> Он утверждает, что сериализация -- оверинжиниринг. Это не так. При чём тут
> kexec, у тебя всё хорошо?ты знаешь что такое контекст обчуждения? Топик от kexec. Сериализовывать оперативную память -- это прям эпик вин
Совершенно очевидно, он говорил это вне контекста. А чё ты ещё с памятью сделаешь? Ты же не возьмёшь и сохранишь как оно есть в памяти, нужно разбираться, что сохранять и откуда. А потом ты заменишь какой-нибудь код или обновишь версии компонентов тулчейна и без процесса десериализации всё развалится.
> Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо.Для этого не нужно ооп. Думаешь структуры нельзя сохранить хоть куда? Звучит по меньшей мере странно.
Для этого надо знать структуру данных закрытых систем.
Концепция инкапсулярности позволяет не вникать во внутреннюю структуру, а выполнять действия только через интерфейсы.
Зачем их куда-то сохранять, если они и так в памяти лежат?
Вы наверно плохо знакомы с механизмами освобождения и предоставления памяти.
> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний. Может это потому, что они юзают си, где нет ооп в явном виде. При наличии ооп задача сохранения состояния объекта обычно становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. Хоть в файл, хоть в другую область памяти, хоть куда.А кто тебе сказал что проблема в сохранении состояния? Его если нужно - сохранить не трудно, даже на уровне прикладного ПО.
Проблема в пересчитывании состояний. Вот возьми любой свой язык (ну желательно конечно из более менее популярных), где есть понятие инклудов.
Напиши на нем какую-нибудь либу, ну там lib.php, lib.py, lib.c, lib.pas - неважно. В этой либе напиши какую-нибудь функцию. Например function hello_world, которая просто выводит print("Hello World\n") - на любом из твоих ЯП, неважно.
И напиши программу, которая инклудит эту либу, и скажем так, вызывает в периодическом цикле функцию hello_world() из твоей либы. Запусти ее. У тебя выводится Hello World.
Потом в своей либе поменяй print("Hello World\n") на print("Привет Мир\n"). Ну то есть мы типа обновили либу.
И вот тут начинаются проблемы. Ведь твоя программа не стала выводить Привет Мир, она по прежнему выводит Hello World. А ведь здесь по сути даже состояний нет - здесь просто вывод одной строчки.
Все проще- она иноагент не шпрехающий по русски...
Не совсем понятно. Если есть процесс, который динамически подцепил библиотеку с печатью Hello World, а вы как-то поменяли образ библиотеки (которая отображена в память процесса), то ясно, что система просто сделает Copy-on-Write и оставит старую версию, пока сам процесс не перезагрузит новую версию библиотеки или что более вероятно система Вас пошлет.
> просто сохраняешь память объекта куда тебе надоКак сохранить указатель? Вот то-то же и оно. Да и зачем ООП, когда просто структа достаточно? По твоей же логике, просто берем и делаем memcpy всего структа куда надо.
да да, ни разу не видел класс без указателей в реальном проекте, а потом появляются разные пергурзки операторов, чтобы его в/из стрима доставать...
>> просто сохраняешь память объекта куда тебе надо
> Как сохранить указатель? Вот то-то же и оно.В смысле? Берешь и сохраняешь. Ессно не трогая регион на который он указывает. Если регион никто не телепал (это кто-то должен делать явно) - если указатель показывал на адрес 42 ДО операции, и после восстановления показывает на адрес 42, и по адресу 42 никто ничего не менял - окей, и в чем проблема? RAM так то сам по себе не теряет данные, если что.
Прикинь, допустим нажатие кнопки RESET само по себе вообще RAM не очищает?! Это кто-то должен явно пройтись по всем адресам и протереть это. Иначе там останется то что было на момент ресета, ВНЕЗАПНО.
> Да и зачем ООП, когда просто структа достаточно? По твоей же логике, просто берем и
> делаем memcpy всего структа куда надо.А что если этот {объект, структ} в новой версии немного изменился например? :)
Вероятно у Вас ограниченная практика, если Вы сводите всё к просто копированию памяти.
> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний.А проприетарщики типа дружат? Это кто? Винда чтоли, которая "я луше знаю - вам пора в ребут, вот вам!" - и пользователь такой "ах ты блин, я файлы не засэйвил, куда?!"
> Может это потому, что они юзают си, где нет ооп в явном виде.
Покажи свое ядро на чем угодно которое вообще сможет вон то, как это, сишное.
> При наличии ооп задача сохранения состояния объекта обычно становится тривиальной.
Теперь повтори это же для более 9000 оных, а также девайсов живущих своей жизнью, особенно развеселых вещей типа DMA, работающих вообще side by side с процом независимо от него. Чтоб какой DMA не уронил бы все в процессе. Апликущники вообще не в курсе как все это работает.
> Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой
> сериализации просто сохраняешь память объекта куда тебе надо.И конечно в новом ядре - оно вот прямо всенепременно обязано на 100% совпадать, ды? Что делать если в новом ядре это немного изменилось и старая версия напрямую не котируется - мы подумаем потом, видимо.
Более того - по дефолту ядро видите ли дейтвовало так что его запустили из бутлоадера, оно считало себя первым кто раскочегаривает систиему. Так что вот вся инициализация памяти, девайсов и чего там. С ноля. В этот момент ваши виртуалки, конечно, перестанут существовать. Вообще совсем. О том что ядро надо явно информировать что это НЕ запуск из бутлоадера и надо именно не рушить состояние и сделать трансфер оного - мы тоже подумаем потом видимо. А задним то умом все крепкие. Когда фичу за вас уже запилили - тогда просто.
> Хоть в файл, хоть в другую область памяти, хоть куда.
Как говорится, было просто на бумаге, да забыли про овраги.
> Винда что-ли, которая "я лучше знаю - вам пора в ребут, вот вам!"Читайте новости про Windows Server 2015 Ж-)
> Винда что ли, которая "я лучше знаю - вам пора в ребут, вот вам!"Ай-я-яй: Фрейд... Конечно -- 2025
Читайте новости про Windows Server 2025 Ж-)
> Может это потому, что они юзают си, где нет ооп в явном виде.Каждый раз думаю, все, хорош читать коменты на опеннете, но блин, ради таких генальных комментов можно и подсесть :)))
Троллите, или вам просто лень посмотреть на реализацию сохранения и загрузки объекта? Нихрена там не тривиально, особенно с методами. По сути нужно чуть ли не ELF-файл дампить, чтобы потом обратно ваш "объект" загрузить.
А можно написать команду как меняется переход то?
Такое уже было и даже в нескольких видах. И умирало потому что особо никому не нужно было. На самом деле "когда остановка недопустима и необходимо обеспечить непрерывный цикл работы отдельных устройств." _очень_ узкая прослойка, сходу даже и не скажешь, где нельзя остановиться, но, где прям кровь из носу, нужно зачем-то обновиться.
При чём тут "нельзя"? Просто зачем делать перебой, если его можно не делать?
Решается покупкой второго компьютера и использованием системы с передачей управления в него от выключаемого. Другой вопрос, почему перезагрузка вдруг стала "дорогой", медленной операцией.
Давно реализовано понятие Кластер. Топик решает проблему, когда миграция клиентов проблематична.
Когда у тебя в условиях предоставления услуги написано 24/7, то повертишься.
Очередной эээ назовём его мягко "несведущий человек" вещающий про 24/7, но не понимающий, что за этим 24/7 стоит на деле. И да даже это "мифическое 24/7" можно обеспечить разными способами и без всякой муры типа "обновление ядра без перезагрузки".
Как по мне это все костыли для монолитного монстра. Нужно сохранять состояния системы, для того что бы обновиться в рилтайм? Используйте QNX или другие системы с модульным микроядром. А если уж приспичело обновлять монолитное ядро то реализацию нужно возлагать на разработчиков модулей и софта, а не патчи придумывать ...
Взгляд с другой стороны
> Как по мне это все костыли для монолитного монстра. Нужно сохранять состояния
> системы, для того что бы обновиться в рилтайм? Используйте QNX или
> другие системы с модульным микроядром. А если уж приспичело обновлять монолитное
> ядро то реализацию нужно возлагать на разработчиков модулей и софта, а
> не патчи придумывать ...
> Взгляд с другой стороныQNX научился обновлять ядро без остановки приложений?
> для того что бы обновиться в рилтайм? Используйте QNX или другие системы с
> модульным микроядром.И конечно вы нам насыпете сейчас пруфлинк что оно так вообще умеет, прозрачно для юзермода?
И кстати вот что-что а реалтайм при таком - несколько идет нахрен. Ибо пока ядро реинициализируется, весь юзермод, таки - подождет. Однако реальное время штука относительная. Вот смотрите. Вы видите этот браузер. И меня в нем. У меня это даже виртуалка. Если оно на пару секунд притормозит - и растормозится - это будет не особо заметно. А ядро - вот - обновилось. Это как оно в идеале выглядит. Т.е. для софта это небольшая пауза, типа как при лив миграции VM и процессов. Только теперь это не миграция - а замена кернела прям на лету.
> А если уж приспичело обновлять монолитное ядро то реализацию нужно
> возлагать на разработчиков модулей и софта, а не патчи придумывать ...Как говорится, кто лучше всех знает как надо - тот это и показывает. Делом. А так то давать мастерклассы гуглу, амазону и майкрософту как софт девелопать для нонсофт инфры? Аноны опеннета бьют просто рекорды наглости.
И за, где там всякие сингулярити от майкрософт? А, что, они пришли к идее что проще из линуха сделать сообща с другими то что им на самом деле хотелось в инфре? :))
>> для того что бы обновиться в рилтайм? Используйте QNX или другие системы с
>> модульным микроядром.
> И конечно вы нам насыпете сейчас пруфлинк что оно так вообще умеет,
> прозрачно для юзермода?Он не будет это делать, пока нет _доказательства_, что так умеет linux. Прохождение тестов (подтверждение в частных случаях) не является доказательством корректности в общем случае. Прюфлинк называется "чистая функция".
P.S. да, я знаю, кому отвечаю, потому советую не трудиться с очередной порцией "риторики".
> Он не будет это делать, пока нет _доказательства_, что так умеет linux.
> Прохождение тестов (подтверждение в частных случаях) не является доказательством корректности
> в общем случае. Прюфлинк называется "чистая функция".Лично мой интерес во всем этом - не поупражняться в остроумии с каким-то ненужным унылкой с опеннета, а отхватить себе прикольную фичу. Которой я точно найду применение. И кстати я еще автор этой новости. Этим мы в конечном итоге и отличаемся. На мой вкус вы унылы и бесполезны, неуважаемый.
> а отхватить себе прикольную фичу.Ну и как, халявщик, отхватил?
"вы нам насыпете сейчас пруфлинк"
Унести сможешь всей той толпой, что из себя навоображал?
Когда корпы начинают лезть во что то хорошее, то это хорошее становится злом.Предлоги не важны.
> Когда корпы начинают лезть во что то хорошее, то это хорошее становится злом.Предлоги не важны.Корпы хотят инфру с минимальными дайнтаймами. Это является мотиватором к вджобу над вон тем. А вы нас за столько лет ничем на эту тему не осчастливили. Поэтому вы ни хорошее, ни плохое. Вы - никакое. Void вообще не подлежит сравнению.
> Когда корпы начинают лезть во что то хорошееЕсли бы корпы не влезали в это хорошее, то оно так бы осталось студенческим баловством одного финского студента, вовремя подсуетившегося, пока других студентов нагнула банда "законников"
Кстати, до сих пор весь мой прикладной софт написан студентами и/или дилетантами. Ядро большого значения тут не имеет. Ну и толку от корп? Корпы решают только свои задачи.
> Кстати, до сих пор весь мой прикладной софт написан студентами и/или дилетантами.
> Ядро большого значения тут не имеет. Ну и толку от корп?"Один в поле - не воин" (Народная мудрость)
> Корпы решают только свои задачи.
Т.е. толку от Бубунты, Дебиана, Апача, Нгинкса, Кэди, ЗФС, Опен/ЛибреОфисе - нет никаго толку ?
Интресно... на чем же тогда ваша Ось и что это за чудо приложения (от студентов) которых вам на всё хватает...
У меня ощущение, что в либре концентрация студентов и дилетантов как раз запредельная. Ещё толпа засланных казачков из аналогов северной кореи, судя по добавляемым васянским зависимостям с уязвимостями.Опензфс абсолютно сборище дилетантов.
Что касается убунт, всё, что их разработчики делали, всегда было максимальным разочарованием с кучей багов. Лучше всего у них получается перепаковывать иконки и перебивать копирайты, пока они занимаются исключительно этим, всё довольно не плохо.
> У меня ощущение, что в либре концентрация студентов и дилетантов как раз
> запредельная.Вы историю Опен/Либре офиса знаете, кто ее изначально создал? Сейчас, да, новшества в основном на мазне
> Что касается убунт, всё, что их разработчики делали, всегда было максимальным разочарованием с кучей багов.А про бубунту вы можете что угодно говорить, оно против статистики как капля в море
народ, особенно девопсовский - лайк ит. Может про родителя ака дебиан поговорить? Ну так посмотрите на длинный список партнеров дебиана, далеко не из подвалов одиночные красноглазики
Напомнить, как её хомякам продвигали? Чего только кейс педивикии стоит.
> Напомнить, как её хомякам продвигали?Мы все еще про тех (ака корпы) кто создал продукты или уже сьехали на что-то другое?
Продукт и его популярность никак не связаны. Рекламные бюджеты и популярность же соотносятся прямым образом, получается, у корпораций тут преимущество. Это к вопросу о статистике и девопсинах.
Не надо просто идеализировать корпорации. У них острые зубы и здоровый аппетит.
В добавок: вспоминая по памяти из сериала Элементарно: "Вы ищите социопата в менеджменте корпорации? Мы все здесь социопаты"
> Не надо просто идеализировать корпорации. У них острые зубы и здоровый аппетит.С чего это вы взяли, что я их идиализировал? Просто константирую факты...
Просто:
(Много людей + много время + платно) > (Любители + в свободное от работы время + безплатно)
А почему нельзя было просто сделать то же самое, корректно написав выгрузку драйвера гипервизора с сохранением состояния? Нафига всё ядро обновлять?
потому что цель- в обновлении ядра а не в этом драйвере...
Как изнутри системы/виртуальной машины определить, что ты потерял время и была "заморозка" или пауза при работе?
навернео по расхождению часов с внешним истоником. Кстати это можно делать и не в ВМ. Если обнаружить что цикл цефеид вдруг стал нестабильным - то наверное мы всетаки живем в матрице
Для нас цикл цефеид по идее останется стабильным - он ведь часть матрицы (если считать, что мы в матрице).
Нет оснований считать, что если уж мы в матрице, то цефеиды почему-то вне неё.
любое отклонение от цикла который согласно расчетам должен быть стабильным - вызовет подозрение. если отклонений нет - ну чтож, надо искать дальше...
И лайвпатч сразу стал не нужен.