форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Разработчики 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 (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 | Индекс форумов | Темы | Пред. тема | След. тема