Компания SUSE объявила (https://www.suse.com/company/press/2014/3/suse-releases-kgra...) о доступного исходных текстов ранее анонсированной системы kGraft (https://www.suse.com/promo/kgraft.html), обеспечивающей возможность обновления ядра Linux на лету, без перезагрузки и без остановки работы приложений. Возможности kGraft ограничены внесением на лету исправлений, не затрагивающих динамически изменяемые структуры данных ядра, чего достаточно для устранения уязвимостей в ядре и исправления многих видов логических ошибок. Компоненты kGraft, работающие на уровне ядра открыты (https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraf.../) под лицензией GPLv2, а выполняемые в пространстве пользователя утилиты, позволяющие создавать live-патчи к ядру, - под лицензией GPLv3.Обновление ядра Linux на лету является востребованной возможностью для промышленных дистрибутивов и систем, критичных ко времени простоя. При этом, несмотря на доступность на рынке решений, предоставляющих подобную функциональность, свободная и общедоступная реализация до сих пор не предоставляется штатным ядром Linux. Конкурирующими с kGraft системами являются технологии Ksplice (http://www.ksplice.com/) от Oracle и kpatch (http://www.opennet.ru/opennews/art.shtml?num=39235) от Red Hat. Ksplice не претендует на включение в ядро в силу прекращения публикации исходных текстов, поэтому основным конкурентом в борьбе за включение в состав основного ядра Linux является kpatch, который очень близок по архитектуре к kGraft и также является полностью открытой разработкой. Основное отличие kGraft от kpatch сводится к методу генерации модуля-патча, который в kGraft может формируется непосредственно на основе исходных текстов, без манипуляций объектным кодом (kpatch формирует патч на основе сравнения двух бинарных сборок ядра).
Средства наложения патчей на базе kGraft ограничены заменой целиком функций и связанных с ними констант. Патч формируется при помощи специального инструментария, выявляющего подлежащие замене функции на основе анализа исправлений исходных текстов, после чего формирующего исходный код модуля ядра с реализацией патча. Cгенерированный модуль загружается в ядро штатными средствами, как и любой другой модуль ядра, после чего выполняет все необходимые действия по внесению изменений в ядро без прерывания работы системы. В своей работе kGraft базируется на технологиях и идеях уже доступных в ядре: ftrace, зарезервированное через mcount место в заголовках функций, уже применяемая в jumplabels техника исправления INT3/IPI-NMI, RCU-подобное обновление кода, не требующее остановки ядра.
<center><iframe width="640" height="360" src="//www.youtube.com/embed/d8Y89obtNI8?rel=0" frameborder="0" allowfullscreen></iframe></center>
URL: https://www.suse.com/company/press/2014/3/suse-releases-kgra...
Новость: http://www.opennet.ru/opennews/art.shtml?num=39424
Годно. Теперь вообще нет нужды перезагружать сервер
Ну, насколько ясно из новости, этот вариант не покрывает все возможные варианты.
Да и, честно говоря, уж очень специфическая это вещь.
И нужна (именно нужна) она очень немногим. Я даже и не знаю кому...
График maintenance shutdowns, не зависящий от критических дыр в ведре, нужен практически всем тырпрайзным админам.
> График maintenance shutdowns, не зависящий от критических дыр в ведре, нужен практически
> всем тырпрайзным админам.Вот только одно дело запланированный шатдаун, и другое - если экстренно клюнул петух т.к. в ядре нашли дыру.
> Я даже и не знаю кому...Хацкерам, теперь не нужно искать куда спрятать спамбота, логерра/кейлогерра, ремотеаксесса,...
Не нужно писанины для масскировки, ... просто переписываешь стандартные функции со своими плюшками.
Заготавливаешь дома, обзываешь модуль intel_pс.ko, или заменяешь не используемый в системе, напр. sch_teql.ko,
суёшь и спишь спокойно. Одмин запариться искать.Я так думаю, что даже модуль необязательно делать, теоретически должен сработать вызов
основной функции замены с указанием адреса новых данных.
> Хацкерам, теперь не нужно искать куда спрятать спамбота, логерра/кейлогерра,
> ремотеаксесса,...Если развить твою идею чуть дальше: снеси ядро ОС. Прикинь как хакеры обломаются, они трояна приволокли а тут сисколы обслуживать некому! Троян в пролете - он такой подлости не ожидал! :)
> Одмин запариться искать.А обычные руткиты типа сразу находят, вычищают, и работают дальше без раскатывания системы из бэкапа?
>> Одмин запариться искать.
> А обычные руткиты типа сразу находят, вычищают, и работают дальше без раскатывания
> системы из бэкапа?Молодец, слово руткит знаешь!
Ну хз хз... как это ещё будет работать посмотреть надо.
> Ну хз хз... как это ещё будет работать посмотреть надо.Помнится, два-три года назад Марк анонсировал убунту как "первый и единственный серверный дистрибутив, которому не нужны перезагрузки". Это когда оракель выкатил поддержку ksplice для всяких убунт и федор. Так что время попробовать было.
А по ограничениям и возможностям все три варианта практически равны - оно диктуется одними и теми же законами.
Поздно kernelcare.com уже вышел и уже делают апдейты к ядрам.
> Поздно kernelcare.com уже вышел и уже делают апдейты к ядрам.Это какая-то платная проприетарщина, не дающая никаких гарантий - "KernelCare is free until May 2014. We will announce pricing for KernelCare by March 30, 2014". Какой смысл использовать обновления к ядру RHEL (KernelCare поддерживает только RHEL, CentOS и OL) от непроверенного левого производителя, когда Red Hat свою свободную систему kpatch для тех же целей продвигает для RHEL и CentOS, а Oracle пилит Ksplice для OL.
> Поздно kernelcare.com уже вышел и уже делают апдейты к ядрам.Зачем доверять подготовку апдетов сомнительной конторе, когда в kpatch и
kGraft их можно самостоятельно через запуск одной команды подготовить на основе оригинальных апдейтов дистрибутива ?
Если все это делается только из за того чтобы не было простоя, то есть для этого кластера. Тем кому ну очень важно чтобы не было ни минуты простоя, могут себе позволить кластера.
Админы кластеры хоть и не рвут волосы на заднице, когда падает один сервак, но летать на резерве без одного крыла тоже не люябт.
> Если все это делается только из за того чтобы не было простоя,
> то есть для этого кластера. Тем кому ну очень важно чтобы
> не было ни минуты простоя, могут себе позволить кластера.Вероятно важен бывает не столько простой сколько разрыв всех клиентских сессий и состояния сеансов... Скажем игровой сервер... С одной стороны можно и перезагрузить, но... Можно и без этого... (потом конечно упадёт) >:-)
Отлично, установлю на десктоп, буду с соседом аптаймами мериться.
Вот бы технологию замены ядер с новой мажорной версией на лету. Ну хотя бы между двумя соседними мажорными.
рисковано для "боеваых" серверов. и по концепции и в текущем виде.
а вот для серверов разработчиков и других "на острие бритвы" перцев с сцупер-свежим софтом и прочего бульона - вполне нужная вещЬ.