RaceHound 1.0 - ещё раз о «гонках» в ядре

Материал из Rosalab Wiki
Перейти к: навигация, поиск
 
м
 
Строка 1: Строка 1:
 +
[[File:Race Condition Everywhere.jpg|right|256px]]
 +
 
Недавно вышла версия 1.0 системы [https://github.com/winnukem/racehound RaceHound] для поиска [https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B5_%D0%B3%D0%BE%D0%BD%D0%BA%D0%B8 «состояний гонки»] при обращениях к данным в ядре Linux.
 
Недавно вышла версия 1.0 системы [https://github.com/winnukem/racehound RaceHound] для поиска [https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B5_%D0%B3%D0%BE%D0%BD%D0%BA%D0%B8 «состояний гонки»] при обращениях к данным в ядре Linux.
  
Если говорить простым языком, такие «состояния гонки» — это когда к данной области памяти разные потоки выполнения в программе (или, скажем, в ядре) могут обращаться одновременно, причём хотя бы один из потоков выполнения меняет содержимое этой области памяти. Такие ситуации могут приводить к очень неприятным последствиям, но выявить их бывает очень непросто.
+
Если говорить простым языком, такие «состояния гонки» — это когда к данной области памяти разные потоки выполнения в программе (или, скажем, в ядре) могут обращаться одновременно, причём хотя бы один из потоков выполнения меняет содержимое этой области памяти. Такие ситуации могут приводить к очень неприятным последствиям, но выявить их бывает очень непросто.
  
 
В этом, например, может помочь инструмент [https://github.com/euspectre/kernel-strider/ KernelStrider]. Он находит много потенциальных «гонок», но у него могут быть и ложные срабатывания, то есть бывает, что он сообщает о «гонке», которой нет.
 
В этом, например, может помочь инструмент [https://github.com/euspectre/kernel-strider/ KernelStrider]. Он находит много потенциальных «гонок», но у него могут быть и ложные срабатывания, то есть бывает, что он сообщает о «гонке», которой нет.
  
RaceHound же, наоборот, может многое «не заметить», но если он выявил «гонку» — та, действительно, происходит. Кстати, эти инструменты хорошо работают в паре: KernelStrider выявляет потенциальные «гонки», а RaceHound проверяет, действительно ли эти «гонки» происходят.
+
RaceHound же, наоборот, может многое «не заметить», но если он выявил «гонку» — та, действительно, происходит. Кстати, эти инструменты хорошо работают в паре: KernelStrider выявляет потенциальные «гонки», а RaceHound проверяет, действительно ли эти «гонки» происходят.
  
 
В частности, таким образом удалось недавно выявить [https://lkml.org/lkml/2015/5/20/568 интересную «гонку»] в драйвере «uvcvideo» (работа с web-камерой) из ядра 4.1-rc5. Правда, разработчики этого драйвера уверяют, что ничего страшного из-за этой гонки произойти не может, но всё же.
 
В частности, таким образом удалось недавно выявить [https://lkml.org/lkml/2015/5/20/568 интересную «гонку»] в драйвере «uvcvideo» (работа с web-камерой) из ядра 4.1-rc5. Правда, разработчики этого драйвера уверяют, что ничего страшного из-за этой гонки произойти не может, но всё же.
Строка 14: Строка 16:
 
* Когда какая-то из ПТП срабатывает, выясняем, к каким данным в памяти соотв. инструкция собирается обратиться, то есть находим их адрес и размер.
 
* Когда какая-то из ПТП срабатывает, выясняем, к каким данным в памяти соотв. инструкция собирается обратиться, то есть находим их адрес и размер.
 
* Ставим аппаратные точки прерывания на эту область памяти.
 
* Ставим аппаратные точки прерывания на эту область памяти.
* Делаем небольшую задержку. Если в это время кто-то обратится к этой области памяти, аппаратные точки прерывания сработают — «гонка» выявлена.
+
* Делаем небольшую задержку. Если в это время кто-то обратится к этой области памяти, аппаратные точки прерывания сработают — «гонка» выявлена.
 
* Убираем аппаратные точки прерывания, затем даём возможность той инструкции, для которой выше сработала ПТП, выполняться дальше.
 
* Убираем аппаратные точки прерывания, затем даём возможность той инструкции, для которой выше сработала ПТП, выполняться дальше.
  
Разумеется, «дьявол — в деталях» и реализовать такой алгоритм на практике оказалось очень и очень непросто. Не зря работа над RaceHound ведётся с лета 2012 года.
+
Разумеется, «дьявол — в деталях» и реализовать такой алгоритм на практике оказалось очень и очень непросто. Не зря работа над RaceHound ведётся с лета 2012 года.
  
По сравнению с предыдущими версиями (0.x), в версии 1.0 наши специалисты существенно переработали основные компоненты RaceHound. Раньше можно было использовать его только для одного выбранного модуля ядра. Теперь же — для произвольного кода как в самом ядре, так и в модулях, для любого участка кода, куда можно поставить программную точку прерывания.
+
По сравнению с предыдущими версиями (0.x), в версии 1.0 наши специалисты существенно переработали основные компоненты RaceHound. Раньше можно было использовать его только для одного выбранного модуля ядра. Теперь же — для произвольного кода как в самом ядре, так и в модулях, для любого участка кода, куда можно поставить программную точку прерывания.
  
Кстати, при подготовке этой версии была [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd найдена и исправлена ошибка] в механизме работы с точками прерывания (точнее, с т. н. Kprobes) в самом ядре. Исправление должно войти в версию ядра 4.1.
+
Кстати, при подготовке этой версии была [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd найдена и исправлена ошибка] в механизме работы с точками прерывания (точнее, с т. н. Kprobes) в самом ядре. Исправление должно войти в версию ядра 4.1.
  
 
[[Category:ToROSAPoint]]
 
[[Category:ToROSAPoint]]
 
{{wl-publish: 2015-06-04 19:45:08 +0400 | Eugene.shatokhin }}
 
{{wl-publish: 2015-06-04 19:45:08 +0400 | Eugene.shatokhin }}

Текущая версия на 19:31, 8 июня 2015

Race Condition Everywhere.jpg

Недавно вышла версия 1.0 системы RaceHound для поиска «состояний гонки» при обращениях к данным в ядре Linux.

Если говорить простым языком, такие «состояния гонки» — это когда к данной области памяти разные потоки выполнения в программе (или, скажем, в ядре) могут обращаться одновременно, причём хотя бы один из потоков выполнения меняет содержимое этой области памяти. Такие ситуации могут приводить к очень неприятным последствиям, но выявить их бывает очень непросто.

В этом, например, может помочь инструмент KernelStrider. Он находит много потенциальных «гонок», но у него могут быть и ложные срабатывания, то есть бывает, что он сообщает о «гонке», которой нет.

RaceHound же, наоборот, может многое «не заметить», но если он выявил «гонку» — та, действительно, происходит. Кстати, эти инструменты хорошо работают в паре: KernelStrider выявляет потенциальные «гонки», а RaceHound проверяет, действительно ли эти «гонки» происходят.

В частности, таким образом удалось недавно выявить интересную «гонку» в драйвере «uvcvideo» (работа с web-камерой) из ядра 4.1-rc5. Правда, разработчики этого драйвера уверяют, что ничего страшного из-за этой гонки произойти не может, но всё же.

Принцип работы RaceHound очень прост.

  • Ставим программную точку прерывания, ПТП, (наподобие того, как это делают отладчики) на те инструкции в коде, которые могут участвовать в «гонке».
  • Когда какая-то из ПТП срабатывает, выясняем, к каким данным в памяти соотв. инструкция собирается обратиться, то есть находим их адрес и размер.
  • Ставим аппаратные точки прерывания на эту область памяти.
  • Делаем небольшую задержку. Если в это время кто-то обратится к этой области памяти, аппаратные точки прерывания сработают — «гонка» выявлена.
  • Убираем аппаратные точки прерывания, затем даём возможность той инструкции, для которой выше сработала ПТП, выполняться дальше.

Разумеется, «дьявол — в деталях» и реализовать такой алгоритм на практике оказалось очень и очень непросто. Не зря работа над RaceHound ведётся с лета 2012 года.

По сравнению с предыдущими версиями (0.x), в версии 1.0 наши специалисты существенно переработали основные компоненты RaceHound. Раньше можно было использовать его только для одного выбранного модуля ядра. Теперь же — для произвольного кода как в самом ядре, так и в модулях, для любого участка кода, куда можно поставить программную точку прерывания.

Кстати, при подготовке этой версии была найдена и исправлена ошибка в механизме работы с точками прерывания (точнее, с т. н. Kprobes) в самом ядре. Исправление должно войти в версию ядра 4.1.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.