Разработчики из компаний Red Hat и SUSE объединили (https://lkml.org/lkml/2015/2/9/534) свои усилия по продвижению в ядро Linux технологии динамического применения к работающему ядру патчей, которая позволяет на лету устранять уязвимости и некоторые типы ошибок без перезагрузки и без остановки работы приложений. Изначально обстоятельства сложились так, что Red Hat и SUSE практически одновременно предложили сообществу конкурирующие между собой технологии обновления ядра без перезагрузки - kPatch (http://www.opennet.me/opennews/art.shtml?num=39235) и kGraft (http://www.opennet.me/opennews/art.shtml?num=39424), которые очень близки по своим возможностям и характеристикам, и отличаются лишь в деталях реализации.
Подобная ситуация поставила разработчиков ядра в замешательство из-за невозможности отдать предпочтение одной из этих технологий. К счастью, восторжествовал здравый смысл и разработчики kPatch и kGraft встали на путь сотрудничества. Для включения в ядро 3.20 подготовлена (https://lkml.org/lkml/2015/2/9/534) базовая инфраструктура, предоставляющая универсальный API для горячего наложения патчей на ядро, который не привязан к конкретным реализациям. После включения патча в состав ядра разработчики SUSE и Red Hat согласились задействовать данный API в своих продуктах вместо специфичного для kPatch и kGraft кода на уровне ядра.
Ключевые отличия kPatch и kGraft заключаются в способах подготовки патчей и средствах обеспечения целостности системы при их применении к ядру. В kGraft патч может формироваться непосредственно на основе исходных текстов, без манипуляций c объектным кодом. В kPatch патч генерируется на основе сравнения двух бинарных сборок ядра. В обоих системах патчи оформляются в форме модуля ядра, осуществляющего необходимую подстановку кода функций. Для замены функций в ядре и перенаправления на новую функцию применяется штатная подсистема ядра ftrace.
При этом в kPatch и kGraft используются разные механизмы для защиты от вызова подменяемого кода в пограничные моменты (задача может быть переключена на исправленную функцию только в момент, когда она не использует данную функцию). В kPatch для обеспечения непротиворечивости обращения к заменяемой функции из разных потоков применяется вызов stop_machine() с последующим анализом стека на предмет влияния подмены функции на выполняемые в текущий момент процессы. В kGraft применяется модель оценки непротиворечивости каждой отдельной нити, путём перебора всех процессов ядра и переноса нитей от старого варианта функции к исправленному варианту в безопасные для подмены моменты.
Предлагаемый для ядра 3.20 базовый API не касается методов обеспечения непротиворечивости, но для ядра 3.21 уже предложена (https://lkml.org/lkml/2015/2/9/475) реализация гибридной модели, комбинирующей метод отслеживания непротиворечивости через анализ стека (kPatch) с механизмом оценки отдельных задач (kGraft). По сравнению с kPatch гибридная модель позволяет избежать задержек во время наложения патча, может применяться в ситуациях выполнения подменяемой функции и предоставляет более предсказуемый прогноз успешности выполнения операции. По сравнению с kGraft гибридный метод более прост в реализации и оказывает меньшее влияние на процессы (не требует отправки сигнала спящим задачам). Из недостатков гибридной модели по сравнению с kPatch отмечаются более высокие требования к оформлению модуля ядра с патчем.URL: https://lkml.org/lkml/2015/2/9/534
Новость: http://www.opennet.me/opennews/art.shtml?num=41651
Ну наконец-то они договорились, почти год прошёл.
Ну собственно у них мало выбора. Canonical очень много у них отхапала доли и отхапывает дальше. Вот и объединяют усилия и это хорошо.
Вот такая толстая правда.
Они договорились и выработали по сути стандарт, теперь эта технология появится и в убунте. С чем нас всех и поздравляю ;)
В Ынтерпрайз сегменте?!
А кроме вас кто-нибудь в курсе этого?
> Ну собственно у них мало выбора. Canonical очень много у них отхапала доли и отхапывает дальше.Вы еще скажите, что она перестала быть убыточной xD
[толстота]Canonical? А что это?[/толстота]
>комбинирующей метод отслеживания непротиворечивости через анализ стека (kPatch) с механизмом оценки отдельных задач (kGraft). По сравнению с kPatch гибридная модель позволяет избежать задержек во время наложения патча, может применяться в ситуациях выполнения подменяемой функции и предоставляет более предсказуемый прогноз успешности выполнения операции.Когда читаю про такие хаки мне дико хочется шотганом поотстреливать программистиков которые пытаются весь юзерспейс подменить браузером и javascript. Как ни крути, но толпа рабов работающих за зарплату/еду все же опасна..
Не надо их отстреливать. На фоне г-на нормальные программисты лучше видны...
> Не надо их отстреливать. На фоне г-на нормальные программисты лучше видны...Они в нем теряются. Иногда даже тонут.
>ядро 3.20Обещали же после 3.19 перейти к разработке 4.0. В чем дело?
Обещать - не значит жениться
Уже не первый и не второй раз и возможно не третий раз пытаются подобное светлое будущее изобрести.
Пусть конечно пилят, главное чтобы опцию оставили собирать без этих костылей. В 99.9% случаев оно того не стоит.
> Уже не первый и не второй раз и возможно не третий раз
> пытаются подобное светлое будущее изобрести.
> Пусть конечно пилят, главное чтобы опцию оставили собирать без этих костылей. В
> 99.9% случаев оно того не стоит.Ну что-то путное выйдет, на десктопе не проблема, а вот когда у вас ферма серверов и нужно срочно пропатчить ядро, а ребутать нельзя - может стать полезно.
Не пойму. Что за ситуация такая, что ребутать нельзя? Либо вы спокойно переживёте downtime либо у вас есть резервные машины.А технология интересная, да
> Что за ситуация такая, что ребутать нельзя?Почему нельзя ? Можно. В ночь со первого января на второе.
С перепою, что ли?Кроме шуток - крики "у меня критичный сервис, я не могу перезагрузиться" очень смешат. Потому что действительно критичных сервисов без резервного железа в принципе не бывает.
> Кроме шуток - крики "у меня критичный сервис, я не могу перезагрузиться"
> очень смешат. Потому что действительно критичных сервисов без резервного железа в
> принципе не бывает.Очень много "а вдруг", даже с боевым тестированием. Любой вывод системы из штатного режима рискован сваливанием в штопор. Даже если у вас мега-отказоустойчивый и 50 раз проверенный кластер, 51 раз может оказаться "как у фейсбука недавно". Поэтому никто не любит лишних ребутов и рестартов.
>> Кроме шуток - крики "у меня критичный сервис, я не могу перезагрузиться"
>> очень смешат. Потому что действительно критичных сервисов без резервного железа в
>> принципе не бывает.
> Очень много "а вдруг", даже с боевым тестированием. Любой вывод системы из
> штатного режима рискован сваливанием в штопор. Даже если у вас мега-отказоустойчивый
> и 50 раз проверенный кластер, 51 раз может оказаться "как у
> фейсбука недавно". Поэтому никто не любит лишних ребутов и рестартов.Думаешь неведомая фигня, применяющая патчи налету, ковыряющаяся в стеке и подменяющая функции, добавит системе надежности и предсказуемости?
> Думаешь неведомая фигня, применяющая патчи налету, ковыряющаяся в стеке и подменяющая функции, добавит системе надежности и предсказуемости?Почему неведомая? Она вполне себе логично работает. Другое дело, что ковыряние в стеке не нужно, достаточно создавать копию функции с подменой всех точек вызова - и те, кто зашёл в старую, выйдут также в старую.
>> Думаешь неведомая фигня, применяющая патчи налету, ковыряющаяся в стеке и подменяющая функции, добавит системе надежности и предсказуемости?
> Почему неведомая? Она вполне себе логично работает. Другое дело, что ковыряние в
> стеке не нужно, достаточно создавать копию функции с подменой всех точек
> вызова - и те, кто зашёл в старую, выйдут также в
> старую.Если ты боишься перезагрузки в режиме обслуживания, пока все сервисы продолжают работать на соседнем железе, но не боишься молодежных костылей на боевых машинах, тогда на здоровье.
Саксес стори "фейсбука недавно" ждет своего героя.
Можно будет внедрить в ядро бэкдор без перезагрузки!
+1Ага. Повышение автоматизации напрямую помогает
автоматизировать "неблаговидное" при слабой защите.Надеюсь ребята это учтут. Тут понадобится какая-то
хорошая "проверка".
очевидно что в ядро нужно встроить антивирус.
>очевидно что в ядро нужно встроить антивирус.Анон не тупи, антивирус - эта софт для вытягивания бабла домохозяек которая эффективна только после масштабного распространения вируса.
Тссс...
Сейчас же Лёня это услышит и займётся этим.
>в ядро нужно встроить антивирус
А ещё нужно отключаемость такой фишки при компиляции ядра
В ядре отключаемость будет, но системд будет обязательно требовать ядра с kpatch, так что все дистрибутивы будут поставляться со включенным. Ну так, чтобы АНБ всегда могло незаметно подсунуть что надо.
> А ещё нужно отключаемость такой фишки при компиляции ядраОна уже есть. Disable LKM, если я правильно помню название.
> Можно будет внедрить в ядро бэкдор без перезагрузки!Эта возможность существует уже четверть века. google://rootkit
> Эта возможность существует уже четверть века. google://rootkitС ядром есть маленькая проблема - руткит должен быть собран под конкретную версию и с конкретными опциями, и еще кто-то его под рутом должен запустить.
определенно нужна функция перезагрузки без перезагрузки ядра
> определенно нужна функция перезагрузки без перезагрузки ядраРекурсивная? :))))))))
JIT
> определенно нужна функция перезагрузки без перезагрузки ядраsystemctl isolate emergency && systemctl isolate default, не?
>> определенно нужна функция перезагрузки без перезагрузки ядра
> systemctl isolate emergency && systemctl isolate default, не?Pid(1) перезапускает? А то ж динамически линкованные glibc, openssl, xorg и апач, да.
> Pid(1) перезапускает? А то ж динамически линкованные glibc, openssl, xorg и апач,
> да.kexec - перезапускает всё :) И очень даже быстро, поскольку бут ядра и запуск сервисов systemd обычно копеечный, в итоге в ребуте сервака львиную долю времени занимает инициализация железа BIOS.
>> Pid(1) перезапускает? А то ж динамически линкованные glibc, openssl, xorg и апач, да.
> kexec - перезапускает всё :) И очень даже быстро, поскольку бут ядраА без перезапуска сервисов[I]!1?[I] http:/opennews/art.shtml?num=41592
> А без перезапуска сервисов!1?Скомбинируйте с criu :)
kexec?
Вот только не понимаю, зачем федоры запихнули "обновление при перезагрузке в дистр"
Реквестирую отключение по-умолчанию данной "фичи" для не-серверных ядер. Ибо локалхост заведомо слабее защищен, чем "критический сервис", и это может привести к появлению нового ботнета.