Компания Red Hat открыла (http://rhelblog.redhat.com/2014/02/26/kpatch/) под лицензией GPLv2 наработки проекта kpatch (https://github.com/dynup/kpatch), в рамках которого подготовлена система динамического применения патчей к работающему ядру Linux, без перезагрузки и остановки работы системы. По своему назначению kpatch напоминает развиваемую компанией Oracle систему KSplice (http://www.ksplice.com/) и анонсированный компанией SUSE проект kGraft (http://www.opennet.me/opennews/art.shtml?num=38994), и также позволяет администраторам на лету устранять уязвимости и некоторые типы ошибок в ядре.По организации обновления ядра kpatch напоминает kGraft и также выполняет замену целиком функций в ядре, используя для перенаправления на новую функцию штатные средства подсистемы ftrace. Методы формирования и загрузки патча более близки к ksplice и также основаны на сравнении бинарных сборок и использовании отдельного базового модуля для координации наложения изменений. Отмечается, что реализация kpatch ещё до конца не стабилизирована, поэтому систему динамического обновления ядра пока не стоит использовать для промышленного применения. Инструкция по сборке и экспериментах с kpatch подготовлена (https://github.com/dynup/kpatch) для Fedora 20. После открытия кода kGraft, которое запланировано на март, между системами динамического обновления ядра от Red Hat и SUSE разразится конкурентная борьба по продвижению в состав основного ядра Linux.
В состав kpatch входят следующие компоненты:
- kpatch-build - набор утилит для преобразования патча к исходным текстам ядра, созданного утилитой diff, в специализированный модуль ядра, осуществляющий наложение изменений на работающее ядро. Для оценки подлежащих замене компонентов, осуществляется сборка двух бинарных образов ядра, один для состояния до наложения патча на код ядра, а второй - после наложения патча. Далее выявляются отличия между бинарными патчами и генерируется модуль горячего обновления ядра.
- Модуль горячего обновления ядра представляет собой обычный модуль ядра (файл с разрешением.ko), содержащий бинарные варианты изменённых функций ядра и метаданные об размещении оригинальных функций, подлежащих замене.
- Базовый модуль kpatch - модуль ядра, предоставляющий интерфейс для регистрации новых функций, определённых в модуле горячего обновления ядра. Для перенаправления вызова на новую функцию используется подсистема ftrace, при помощи которой ставится хук на инструкцию вызова старой функции для перенаправления обращения на новую функцию.
- Утилита kpatch с интерфейсом командной строки для управления коллекцией модулей горячего обновления ядра. Один или более подобных модулей могут быть настроены для применения в процессе загрузки, что позволяет системе сохранить работоспособность применённых в процессе работы горячих патчей, даже в случае перезагрузки сервера.URL: http://rhelblog.redhat.com/2014/02/26/kpatch/
Новость: http://www.opennet.me/opennews/art.shtml?num=39235
Опердили SuSE :)---
Пара патчейhttps://github.com/pavlinux/kpatch/commit/041c7ccae68e36b771...
https://github.com/pavlinux/kpatch/commit/db9c6e989b7c1a5005...
---
Патчи гениальны. Они изменят судьбу мира Linux.
Ты как большой специалист знаешь же, где найти руткит на неправильные спецификаторы printf/scanf
руткит — это немного не о том, наверное эксплойт
руткит - это цель, эксплойт - это инструмент, как черепно-мозговая травма тупым предметом и молоток.
Нафиг нужны твои патчи?
> Нафиг нужны твои патчи?лохов раздражать
Так вот ты какой, северный pavlinux https://identicons.github.com/35a2ad62b28e3c7cf02bdc9d1c2932...
>Type coeection*facepalm*
>>Type coeection
> *facepalm*Да, вот так,... не хватило сил дотянуть палец до соседней кнопки. :-P
Новые фичи - новые дыры.
Вопрос к специалистам: не повлияет-ли это на совместимость ядер?
> Новые фичи - новые дыры.
> Вопрос к специалистам: не повлияет-ли это на совместимость ядер?Кроме как CONFIG_FTRACE и CONFIG_FUNCTION_TRACER вроде ничего волшебного не просит,
и само в код ядра не просится.
Теперь бэкдоры можно пихать прямо в работающее ядро?
И никаких следов, разве что оперативку сканировать.
> Теперь бэкдоры можно пихать прямо в работающее ядро?Да, от рута всё можно.
> CONFIG_FUNCTION_TRACERА с этой фичей, оверхед проца-то вырос, прим. на 10°C
В общем, поюзал... глюкалово страшное. Если патч на модуль, то раз в 500 проще
перекомпилить модуль, остановить сервис, rmmod/insmod и снова в путь.
Если на ROOTFS, в принципе, через mount --bind на ramfs, перегрузить модуль и обратно.
Но это, по сути, тот же reboot. :)И во-вторых kpatch - это временное средство, ядро всё равно обновлять придётся.
Не, можно и так работать, но есть вероятность, что модуль прибьёт OOM_killer,
или при крэшдампе отвалится.> ... не могут применяться к функциям, вызываемым только на стадии инициализации ядра;
Хе.. эти функции есть большой и толстый конфиг ядра, они в работе не используются.
Смысла их патчить вообще нет.
Лучше бы за пилили работу с двумя ядрами - master/slave ©
В каждом ядре список символов с версиями, менеджер версий.
Например та же schedule() была бы ссылкой на более старшую
версию из таблицы: schedule()_3121155 и schedule()_3121157
При появлении символа schedule()_3140000, все новые вызовы
schedule(), вызывали бы schedule()_3140000.
>в 500 проще перекомпилить модуль, остановить сервисЧто _проще_ - никто и не спорил.
Только дороговато некоторые сервисы останавливать.
тщательнее надо проектировать, остановка сервера не должна приводить к остановке сервиса
То есть вы предлагаете перепроектировать этот мир вместо того чтобы использовать kpatch, я так понимаю.
Ну что ж, предложение интересное, практичное.
Господа, а как на счет безопасности для параноикрв?
Безопасности, в смысле, security или безопасности процесса применения патча?Ради 1-го и развиваются эти технологии. По поводу 2-го - в новости сказано, что не готово для production.
Для параноиков ее нет.
для параноиков ничего не изменилось - всё как было опасно, так и остаётся
>>> Не вызовет удивления, если компания Oracle откроет свежий исходный код KSplice и также подключится к борьбе за upstreamПоздновато. У редхата большой опыт по пропихиванию разработок в апстрим. В отличие от.
Блин, в который раз редхату эпическое шпасибо за следование GPL. У меня даже есть место для применения этой штуки, весьма специфичное, но реальное.
# This script currently only works on Fedora and will need to be adapted to
# work on other distros.
Да там три с половиной строки поправить. Кто не сможет - тому рано пока это использовать.
секретничает, какое?
> секретничает, какое?Есть определенная операторская сетевая платформа, которой возможность проапдейтить ядро (особенно собственные модули, например, для добавления мелкофич или затыкания мелкобагов) на ходу очень даже пригодится. Цена останова - обрыв всех абонентских сеансов в случае PPPoE/PPTP. Даже если есть резерв. Но это применение скорее типовое.
И при разработке оной иметь такую штуку тоже очень даже неплохо, ибо можно не перегружая тестовую площадку и не выгружая/перезагружая модулей (т.е. с сохранением состояния) проапдейтить кусок ядра (если не меняются структуры данных и API/ABI), и сразу на живую посмотреть, как оно работает. Это как раз "специфичное" применение.
<delirium>Ага, значит наклепали за 5 минут, дабы пропихнуть побыстрее своё, чтоб не дай рандом клиенты не ушли к зелёным из-за фичи, которой у них нет, а потом будут это чинить годами в манере одного своего известного сотрудника.</delirium>
5 лет не уходили (см. ksplice) а тут вдруг подорвались.
неужто великим умищам нечем боле заняться чем костыли клепать?
> неужто великим умищам нечем боле заняться чем костыли клепать?Это очень нужные и важные костыли, которые могут в отдельных случаях сократить даунтайм критичных систем до минимума. В кровавом энтерпрайзе вряд ли нужно - там и часовой простой может быть нормой, бизнес от одной системы не встанет. В облаках и им подобных (фейсбуки, вконтакты и прочие гуглы) - тоже вряд ли пригодятся. А вот в телекоме, допустим, выведение из строя любой системы даже при наличии дублирующих - все равно нештатная ситуация. В биржевых системах, думается, тоже.
> В любой системе есть время на техническое обслуживание, в течении которого проводится в т.ч. обновление ПО.И что делать если даунтайм запланирован на следующей неделе, а проблему надо исправить уже сейчас ?
> - там и часовой простой может быть нормой, бизнес от одной
> системы не встанет.Ну да, помнится вот у Сбербанка "не встал".
IBM K24 же
K42 (: