RaceHound 1.0 - ещё раз о «гонках» в ядре
м |
|||
Строка 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 же, наоборот, может многое «не заметить», но если он выявил | + | 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 года. |
− | По сравнению с предыдущими версиями (0.x), в версии 1.0 наши специалисты существенно переработали основные компоненты RaceHound. Раньше можно было использовать его только для одного выбранного модуля ядра. Теперь | + | По сравнению с предыдущими версиями (0.x), в версии 1.0 наши специалисты существенно переработали основные компоненты RaceHound. Раньше можно было использовать его только для одного выбранного модуля ядра. Теперь же — для произвольного кода как в самом ядре, так и в модулях, для любого участка кода, куда можно поставить программную точку прерывания. |
− | Кстати, при подготовке этой версии была [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd найдена и исправлена ошибка] в механизме работы с точками прерывания (точнее, с т. | + | Кстати, при подготовке этой версии была [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
Недавно вышла версия 1.0 системы RaceHound для поиска «состояний гонки» при обращениях к данным в ядре Linux.
Если говорить простым языком, такие «состояния гонки» — это когда к данной области памяти разные потоки выполнения в программе (или, скажем, в ядре) могут обращаться одновременно, причём хотя бы один из потоков выполнения меняет содержимое этой области памяти. Такие ситуации могут приводить к очень неприятным последствиям, но выявить их бывает очень непросто.
В этом, например, может помочь инструмент KernelStrider. Он находит много потенциальных «гонок», но у него могут быть и ложные срабатывания, то есть бывает, что он сообщает о «гонке», которой нет.
RaceHound же, наоборот, может многое «не заметить», но если он выявил «гонку» — та, действительно, происходит. Кстати, эти инструменты хорошо работают в паре: KernelStrider выявляет потенциальные «гонки», а RaceHound проверяет, действительно ли эти «гонки» происходят.
В частности, таким образом удалось недавно выявить интересную «гонку» в драйвере «uvcvideo» (работа с web-камерой) из ядра 4.1-rc5. Правда, разработчики этого драйвера уверяют, что ничего страшного из-за этой гонки произойти не может, но всё же.
Принцип работы RaceHound очень прост.
- Ставим программную точку прерывания, ПТП, (наподобие того, как это делают отладчики) на те инструкции в коде, которые могут участвовать в «гонке».
- Когда какая-то из ПТП срабатывает, выясняем, к каким данным в памяти соотв. инструкция собирается обратиться, то есть находим их адрес и размер.
- Ставим аппаратные точки прерывания на эту область памяти.
- Делаем небольшую задержку. Если в это время кто-то обратится к этой области памяти, аппаратные точки прерывания сработают — «гонка» выявлена.
- Убираем аппаратные точки прерывания, затем даём возможность той инструкции, для которой выше сработала ПТП, выполняться дальше.
Разумеется, «дьявол — в деталях» и реализовать такой алгоритм на практике оказалось очень и очень непросто. Не зря работа над RaceHound ведётся с лета 2012 года.
По сравнению с предыдущими версиями (0.x), в версии 1.0 наши специалисты существенно переработали основные компоненты RaceHound. Раньше можно было использовать его только для одного выбранного модуля ядра. Теперь же — для произвольного кода как в самом ядре, так и в модулях, для любого участка кода, куда можно поставить программную точку прерывания.
Кстати, при подготовке этой версии была найдена и исправлена ошибка в механизме работы с точками прерывания (точнее, с т. н. Kprobes) в самом ядре. Исправление должно войти в версию ядра 4.1.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.