The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Разработчики Red Hat и SUSE занялись унификацией механизмов ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от opennews (??) on 10-Фев-15, 23:26 
Разработчики из компаний Red Hat и SUSE объединили (https://lkml.org/lkml/2015/2/9/534) свои усилия по продвижению в ядро Linux технологии динамического применения к работающему ядру патчей, которая позволяет на лету устранять уязвимости и некоторые типы ошибок без перезагрузки и без остановки работы приложений. Изначально обстоятельства сложились так, что Red Hat и SUSE практически одновременно предложили сообществу конкурирующие между собой технологии обновления ядра без перезагрузки - kPatch (http://www.opennet.dev/opennews/art.shtml?num=39235) и kGraft (http://www.opennet.dev/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.dev/opennews/art.shtml?num=41651

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +13 +/
Сообщение от Аноним (??) on 10-Фев-15, 23:26 
Ну наконец-то они договорились, почти год прошёл.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от soarin on 11-Фев-15, 09:37 
Ну собственно у них мало выбора. Canonical очень много у них отхапала доли и отхапывает дальше. Вот и объединяют усилия и это хорошо.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

14. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +3 +/
Сообщение от EHLO on 11-Фев-15, 09:58 
Вот такая толстая правда.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

26. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +2 +/
Сообщение от SU on 11-Фев-15, 21:08 
Они договорились и выработали по сути стандарт, теперь эта технология появится и в убунте. С чем нас всех и поздравляю ;)
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

30. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Анжелика on 12-Фев-15, 22:50 
В Ынтерпрайз сегменте?!
А кроме вас кто-нибудь в курсе этого?
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

34. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Аноним (??) on 13-Фев-15, 20:46 
> Ну собственно у них мало выбора. Canonical очень много у них отхапала доли и отхапывает дальше.

Вы еще скажите, что она перестала быть убыточной xD

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

40. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от AlexAT (ok) on 15-Фев-15, 20:53 
[толстота]Canonical? А что это?[/толстота]
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

2. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –2 +/
Сообщение от Аноним (??) on 10-Фев-15, 23:30 
>комбинирующей метод отслеживания непротиворечивости через анализ стека (kPatch) с механизмом оценки отдельных задач (kGraft). По сравнению с kPatch гибридная модель позволяет избежать задержек во время наложения патча, может применяться в ситуациях выполнения подменяемой функции и предоставляет более предсказуемый прогноз успешности выполнения операции.

Когда читаю про такие хаки мне дико хочется шотганом поотстреливать программистиков которые пытаются весь юзерспейс подменить браузером и javascript. Как ни крути, но толпа рабов работающих за зарплату/еду все же опасна..

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +2 +/
Сообщение от Аноним (??) on 11-Фев-15, 00:10 
Не надо их отстреливать. На фоне г-на нормальные программисты лучше видны...
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

38. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Аноним (??) on 13-Фев-15, 20:51 
> Не надо их отстреливать. На фоне г-на нормальные программисты лучше видны...

Они в нем теряются. Иногда даже тонут.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

3. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –1 +/
Сообщение от Аноним (??) on 10-Фев-15, 23:32 
>ядро 3.20

Обещали же после 3.19 перейти к разработке 4.0. В чем дело?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +3 +/
Сообщение от кверти (ok) on 11-Фев-15, 08:49 
Обещать - не значит жениться
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

13. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –1 +/
Сообщение от EHLO on 11-Фев-15, 09:57 
Уже не первый и не второй раз и возможно не третий раз пытаются подобное светлое будущее изобрести.
Пусть конечно пилят, главное чтобы опцию оставили собирать без этих костылей. В 99.9% случаев оно того не стоит.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от SkyRanger email(ok) on 11-Фев-15, 10:40 
> Уже не первый и не второй раз и возможно не третий раз
> пытаются подобное светлое будущее изобрести.
> Пусть конечно пилят, главное чтобы опцию оставили собирать без этих костылей. В
> 99.9% случаев оно того не стоит.

Ну что-то путное выйдет, на десктопе не проблема, а вот когда у вас ферма серверов и нужно срочно пропатчить ядро, а ребутать нельзя - может стать полезно.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Crazy Alex (ok) on 11-Фев-15, 14:42 
Не пойму. Что за ситуация такая, что ребутать нельзя? Либо вы спокойно переживёте downtime либо у вас есть резервные машины.

А технология интересная, да

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

27. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +1 +/
Сообщение от Аноним (??) on 11-Фев-15, 23:57 
> Что за ситуация такая, что ребутать нельзя?

Почему нельзя ? Можно. В ночь со первого января на второе.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

32. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Crazy Alex (ok) on 13-Фев-15, 00:49 
С перепою, что ли?

Кроме шуток - крики "у меня критичный сервис, я не могу перезагрузиться" очень смешат. Потому что действительно критичных сервисов без резервного железа в принципе не бывает.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

41. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от AlexAT (ok) on 15-Фев-15, 20:56 
> Кроме шуток - крики "у меня критичный сервис, я не могу перезагрузиться"
> очень смешат. Потому что действительно критичных сервисов без резервного железа в
> принципе не бывает.

Очень много "а вдруг", даже с боевым тестированием. Любой вывод системы из штатного режима рискован сваливанием в штопор. Даже если у вас мега-отказоустойчивый и 50 раз проверенный кластер, 51 раз может оказаться "как у фейсбука недавно". Поэтому никто не любит лишних ребутов и рестартов.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

43. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от EHLO on 15-Фев-15, 21:52 
>> Кроме шуток - крики "у меня критичный сервис, я не могу перезагрузиться"
>> очень смешат. Потому что действительно критичных сервисов без резервного железа в
>> принципе не бывает.
> Очень много "а вдруг", даже с боевым тестированием. Любой вывод системы из
> штатного режима рискован сваливанием в штопор. Даже если у вас мега-отказоустойчивый
> и 50 раз проверенный кластер, 51 раз может оказаться "как у
> фейсбука недавно". Поэтому никто не любит лишних ребутов и рестартов.

Думаешь неведомая фигня, применяющая патчи налету, ковыряющаяся в стеке и подменяющая функции, добавит системе надежности и предсказуемости?

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

44. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от AlexAT (ok) on 15-Фев-15, 21:54 
> Думаешь неведомая фигня, применяющая патчи налету, ковыряющаяся в стеке и подменяющая функции, добавит системе надежности и предсказуемости?

Почему неведомая? Она вполне себе логично работает. Другое дело, что ковыряние в стеке не нужно, достаточно создавать копию функции с подменой всех точек вызова - и те, кто зашёл в старую, выйдут также в старую.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

51. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от EHLO on 17-Фев-15, 10:29 
>> Думаешь неведомая фигня, применяющая патчи налету, ковыряющаяся в стеке и подменяющая функции, добавит системе надежности и предсказуемости?
> Почему неведомая? Она вполне себе логично работает. Другое дело, что ковыряние в
> стеке не нужно, достаточно создавать копию функции с подменой всех точек
> вызова - и те, кто зашёл в старую, выйдут также в
> старую.

Если ты боишься перезагрузки в режиме обслуживания, пока все сервисы продолжают работать на соседнем железе, но не боишься молодежных костылей на боевых машинах, тогда на здоровье.
Саксес стори "фейсбука недавно" ждет своего героя.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

15. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +1 +/
Сообщение от Аноним (??) on 11-Фев-15, 10:05 
Можно будет внедрить в ядро бэкдор без перезагрузки!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от kuku (ok) on 11-Фев-15, 11:58 
+1

Ага. Повышение автоматизации напрямую помогает
автоматизировать "неблаговидное" при слабой защите.

Надеюсь ребята это учтут. Тут понадобится какая-то
хорошая "проверка".

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +1 +/
Сообщение от Аноним (??) on 11-Фев-15, 16:36 
очевидно что в ядро нужно встроить антивирус.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

23. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –1 +/
Сообщение от Аноним (??) on 11-Фев-15, 19:45 
>очевидно что в ядро нужно встроить антивирус.

Анон не тупи, антивирус - эта софт для вытягивания бабла домохозяек которая эффективна только после масштабного распространения вируса.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

31. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +1 +/
Сообщение от Ilya Indigo (ok) on 12-Фев-15, 23:00 
Тссс...
Сейчас же Лёня это услышит и займётся этим.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

33. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +1 +/
Сообщение от Andrey Mitrofanov on 13-Фев-15, 14:35 
>в ядро нужно встроить антивирус

Doh, http://lwn.net/Articles/318705/?

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

20. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –1 +/
Сообщение от Аноним (??) on 11-Фев-15, 16:46 
А ещё нужно отключаемость такой фишки при компиляции ядра
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

29. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –3 +/
Сообщение от Аноним (??) on 12-Фев-15, 18:43 
В ядре отключаемость будет, но системд будет обязательно требовать ядра с kpatch, так что все дистрибутивы будут поставляться со включенным. Ну так, чтобы АНБ всегда могло незаметно подсунуть что надо.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

36. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –1 +/
Сообщение от Аноним (??) on 13-Фев-15, 20:48 
> А ещё нужно отключаемость такой фишки при компиляции ядра

Она уже есть. Disable LKM, если я правильно помню название.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

35. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Аноним (??) on 13-Фев-15, 20:47 
> Можно будет внедрить в ядро бэкдор без перезагрузки!

Эта возможность существует уже четверть века. google://rootkit

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

42. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от AlexAT (ok) on 15-Фев-15, 21:02 
> Эта возможность существует уже четверть века. google://rootkit

С ядром есть маленькая проблема - руткит должен быть собран под конкретную версию и с конкретными опциями, и еще кто-то его под рутом должен запустить.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

22. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –1 +/
Сообщение от Аноним (??) on 11-Фев-15, 17:32 
определенно нужна функция перезагрузки без перезагрузки ядра
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Аноним (??) on 11-Фев-15, 20:27 
> определенно нужна функция перезагрузки без перезагрузки ядра

Рекурсивная? :))))))))

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

28. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  –1 +/
Сообщение от Капитан (??) on 12-Фев-15, 16:44 
JIT
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

37. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Аноним (??) on 13-Фев-15, 20:50 
> определенно нужна функция перезагрузки без перезагрузки ядра

systemctl isolate emergency && systemctl isolate default, не?

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

45. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Andrey Mitrofanov on 16-Фев-15, 10:33 
>> определенно нужна функция перезагрузки без перезагрузки ядра
> systemctl isolate emergency && systemctl isolate default, не?

Pid(1) перезапускает? А то ж динамически линкованные glibc, openssl, xorg и апач, да.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

48. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от AlexAT (ok) on 16-Фев-15, 22:41 
> Pid(1) перезапускает? А то ж динамически линкованные glibc, openssl, xorg и апач,
> да.

kexec - перезапускает всё :) И очень даже быстро, поскольку бут ядра и запуск сервисов systemd обычно копеечный, в итоге в ребуте сервака львиную долю времени занимает инициализация железа BIOS.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

49. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от Andrey Mitrofanov on 17-Фев-15, 09:46 
>> Pid(1) перезапускает? А то ж динамически линкованные glibc, openssl, xorg и апач, да.
> kexec - перезапускает всё :) И очень даже быстро, поскольку бут ядра

А без перезапуска сервисов!1? http:/opennews/art.shtml?num=41592

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

50. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от AlexAT (ok) on 17-Фев-15, 09:50 
> А без перезапуска сервисов!1?

Скомбинируйте с criu :)

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

47. "Разработчики Red Hat и SUSE занялись унификацией механизмов ..."  +/
Сообщение от AlexAT (ok) on 16-Фев-15, 22:36 
kexec?
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

39. "Red Hat и SUSE объединили усилия в продвижении механизмов об..."  –1 +/
Сообщение от Илья (??) on 15-Фев-15, 05:41 
Вот только не понимаю, зачем федоры запихнули "обновление при  перезагрузке в дистр"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

46. "Red Hat и SUSE объединили усилия в продвижении механизмов об..."  +1 +/
Сообщение от count0krsk (ok) on 16-Фев-15, 12:52 
Реквестирую отключение по-умолчанию данной "фичи" для не-серверных ядер. Ибо локалхост заведомо слабее защищен, чем "критический сервис", и это может привести к появлению нового ботнета.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру