<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<title type="html"><![CDATA[Linux Forum &mdash; Red Hat и SUSE занялись унификацией механизмов обновления ядра]]></title>
	<link rel="self" href="https://linuxforum.ru/extern.php?action=feed&amp;tid=37656&amp;type=atom" />
	<updated>2015-02-11T13:24:08Z</updated>
	<generator>PunBB</generator>
	<id>https://linuxforum.ru/viewtopic.php?id=37656</id>
		<entry>
			<title type="html"><![CDATA[Re: Red Hat и SUSE занялись унификацией механизмов обновления ядра]]></title>
			<link rel="alternate" href="https://linuxforum.ru/viewtopic.php?pid=445200#p445200" />
			<content type="html"><![CDATA[<p>Отличный пример сотрудничества вместо бессмысленных форков и оскорблений.</p>]]></content>
			<author>
				<name><![CDATA[Vascom]]></name>
				<uri>https://linuxforum.ru/profile.php?id=5339</uri>
			</author>
			<updated>2015-02-11T13:24:08Z</updated>
			<id>https://linuxforum.ru/viewtopic.php?pid=445200#p445200</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Red Hat и SUSE занялись унификацией механизмов обновления ядра]]></title>
			<link rel="alternate" href="https://linuxforum.ru/viewtopic.php?pid=445193#p445193" />
			<content type="html"><![CDATA[<p><strong>Разработчики Red Hat и SUSE занялись унификацией механизмов обновления ядра без перезагрузки. </strong></p><p>Разработчики из компаний Red Hat и SUSE <a href="https://lkml.org/lkml/2015/2/9/534">объединили</a> свои усилия по продвижению в ядро Linux технологии динамического применения к работающему ядру патчей, которая позволяет на лету устранять уязвимости и некоторые типы ошибок без перезагрузки и без остановки работы приложений. Изначально обстоятельства сложились так, что Red Hat и SUSE практически одновременно предложили сообществу конкурирующие между собой технологии обновления ядра без перезагрузки - <a href="http://www.opennet.ru/opennews/art.shtml?num=39235">kPatch</a> и <a href="http://www.opennet.ru/opennews/art.shtml?num=39424">kGraft</a>, которые очень близки по своим возможностям и характеристикам, и отличаются лишь в деталях реализации.</p><p>Подобная ситуация поставила разработчиков ядра в замешательство из-за невозможности отдать предпочтение одной из этих технологий. К счастью, восторжествовал здравый смысл и разработчики kPatch и kGraft встали на путь сотрудничества. Для включения в ядро 3.20 <a href="https://lkml.org/lkml/2015/2/9/534">подготовлена</a> базовая инфраструктура, предоставляющая универсальный API для горячего наложения патчей на ядро, который не привязан к конкретным реализациям. После включения патча в состав ядра разработчики SUSE и Red Hat согласились задействовать данный API в своих продуктах вместо специфичного для kPatch и kGraft кода на уровне ядра.</p><p>Ключевые отличия kPatch и kGraft заключаются в способах подготовки патчей и средствах обеспечения целостности системы при их применении к ядру. В kGraft патч может формироваться непосредственно на основе исходных текстов, без манипуляций c объектным кодом. В kPatch патч генерируется на основе сравнения двух бинарных сборок ядра. В обеих системах патчи оформляются в форме модуля ядра, осуществляющего необходимую подстановку кода функций. Для замены функций в ядре и перенаправления на новую функцию применяется штатная подсистема ядра ftrace.</p><p>При этом в kPatch и kGraft используются разные механизмы для защиты от вызова подменяемого кода в пограничные моменты (задача может быть переключена на исправленную функцию только в момент, когда она не использует данную функцию). В kPatch для обеспечения непротиворечивости обращения к заменяемой функции из разных потоков применяется вызов stop_machine() с последующим анализом стека на предмет влияния подмены функции на выполняемые в текущий момент процессы. В kGraft применяется модель оценки непротиворечивости каждой отдельной нити, путём перебора всех процессов ядра и переноса нитей от старого варианта функции к исправленному варианту в безопасные для подмены моменты.</p><p>Предлагаемый для ядра 3.20 базовый API не касается методов обеспечения непротиворечивости, но для ядра 3.21 уже <a href="https://lkml.org/lkml/2015/2/9/475">предложена</a> реализация гибридной модели, комбинирующей метод отслеживания непротиворечивости через анализ стека (kPatch) с механизмом оценки отдельных задач (kGraft). По сравнению с kPatch гибридная модель позволяет избежать задержек во время наложения патча, может применяться в ситуациях выполнения подменяемой функции и предоставляет более предсказуемый прогноз успешности выполнения операции. По сравнению с kGraft гибридный метод более прост в реализации и оказывает меньшее влияние на процессы (не требует отправки сигнала спящим задачам). Из недостатков гибридной модели по сравнению с kPatch отмечаются более высокие требования к оформлению модуля ядра с патчем.</p><p>Дополнение: Линус Торвальдс <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d9c5d79e6e4385aea6f69c23ba543717434ed70">принял</a> в ядро 3.20 базовый API для обновления ядра без перезагрузки.</p><br /><p>Источник: <a href="http://www.opennet.ru/opennews/art.shtml?num=41651">http://www.opennet.ru/opennews/art.shtml?num=41651</a></p>]]></content>
			<author>
				<name><![CDATA[verg]]></name>
				<uri>https://linuxforum.ru/profile.php?id=10709</uri>
			</author>
			<updated>2015-02-11T12:54:10Z</updated>
			<id>https://linuxforum.ru/viewtopic.php?pid=445193#p445193</id>
		</entry>
</feed>
