Comments 32
UFO just landed and posted this here
Как-раз поиска по сигнатуре и хотелось избежать. Поиск по сигнатуре многократно описан, например здесь же рядом: Встраивание в ядро Linux: перехват системных вызовов (уж лучше так). Но зачем искать по сигнатуре, которая в любой момент может поменяться, если достаточно простого kallsyms_lookup_name( «sys_call_table» ). В вашем коде сигнатура сохраняется только для X86_64 (даже для I386 всё не так), а kallsyms_lookup_name() работает на любой платформе.
Для патча sys_call_table на стоковых x86_64 ядрах я написал вот такую функцию
На 64-бит архитектуре всё становится куда интереснее не в том, чтобы патчить sys_call_table (дело не хитрое), а в том, чтобы перехватить в своих целях все варианты выполнения системного вызова. что становится горомоздко из-за вариантов выполнения как 32-бит, так и 64-бит приложений.
Повторю схему, которую здесь уже рядом статье показывали:
UFO just landed and posted this here
Почему для перехвата системных вызовов не использовать ptrace?
UFO just landed and posted this here
в юзерспэйс?
Конечно.
Цель ведь не в том, чтобы выловить системные вызовы из одного конкретного процесса… да ещё запущенного каким-то особым образом, под трасировщиком. Цель в том, чтобы контролировать все системные вызовы от всех запускаемых процессов, а потом уже решать что с этим системным вызовом делать… или ничего не делать.
да ещё запущенного каким-то особым образом, под трасировщиком
В этом нет необходимости, к нужному процессу можно присоединиться после его запуска.
Цель в том, чтобы контролировать все системные вызовы от всех запускаемых процессов
И это можно сделать с помощью ptrace, так делает, например, strace -f.
В этом нет необходимости, к нужному процессу можно присоединиться после его запуска.
Это не важно, запущен особым образом, или к нему подключиться после запуска… речь о том, чтобы контролировать системные запросы от любого процесса (всех!), запущенного стандартным образом, командной строкой… или вообще от любого процесса, запущенного как угодно: демон, сервис… без разницы.
UFO just landed and posted this here
UFO just landed and posted this here
в листинге номер два есть одна хоть и незначительная, но все же проблема:
Нет такой проблемы ;-)
Во-первых, проблема эта известна, описана и ссылка показана в тексте: WP: Safe or Not?.
Во-вторых, проблема в SMP не возникнет из-за cli / sti, хотя можно её оградить и более сложным образом, испольуя макросы preempt_disable() и preempt_enable_no_resched(). Лучше ли это? Не знаю…
В-третьих, когда пишется текст, хотелось бы его упростить «до нельзя», не акцентируясь на детали: описывать схему — чтобы кто-то из читающих смог ним оспользоваться, а не показывать насколько пишущий умён ;-)
Так делать нельзя, короче, если вам нужно модифицировать read only страницу памяти — то для этого следует выставлять атрибуты доступа в PTE описывающей эту страницу
В-четвёртых, этот способ хорошо известен, показан, например, вот здесь: Кошерный способ модификации защищённых от записи областей ядра Linux (в комментариях). Там же (в статье) предложен ещё один способ… лучший, наверное, по сравнению… и с вашим и с нашим ;-). Способов много. Какой из них лучше трудно судить.
UFO just landed and posted this here
Дык если речь не про руткиты, а про свою машину, то делать с ней можно что угодно.
И если «выяснить, что происходит» — не основная задача, то специализированный язык намного быстрее доведёт до результата — полно готовых примеров на все случаи жизни. А код надо писать как серьёзный проект уже.
Ну это всё, если не руткиты :-D
И если «выяснить, что происходит» — не основная задача, то специализированный язык намного быстрее доведёт до результата — полно готовых примеров на все случаи жизни. А код надо писать как серьёзный проект уже.
Ну это всё, если не руткиты :-D
UFO just landed and posted this here
и такое пишем. Да, там не все современные средства отладки бывают доступны, да :-)
Сам не так давно свои боевые исходники ядра, внедрённого в эксплуатацию, потерял :-) Спасло то, что когда-то догадался поставить галочку на конфиге ядра в /proc/config.gz. Получилось всё восстановить. Ну и поскольку 3.8, все SystemTap при желании доступны. OProfile ещё когда-то пробовал, но не очень понравилось.
Сам не так давно свои боевые исходники ядра, внедрённого в эксплуатацию, потерял :-) Спасло то, что когда-то догадался поставить галочку на конфиге ядра в /proc/config.gz. Получилось всё восстановить. Ну и поскольку 3.8, все SystemTap при желании доступны. OProfile ещё когда-то пробовал, но не очень понравилось.
Не всегда есть возможность пересобрать ядро из сорцов
Поставщик такого ядра не предоставляющий его исходники нарушает условия лицензии ядра.
Интрересно, что лицензия не предусматривает сроки, в которые поставщик обязан предоставить исходники. Возможна ситуация — запрос исходников, ответ — ждите, делаем. И тишина.
На практике я сталкивался с этим у компании HTC, поддержка которой на вопросы по исходникам отвечает «мониторьте портал для разработчиков, там скоро выложат». Задержка от выхода устройства на рынок до появления исходников может быть и полгода, и год.
На практике я сталкивался с этим у компании HTC, поддержка которой на вопросы по исходникам отвечает «мониторьте портал для разработчиков, там скоро выложат». Задержка от выхода устройства на рынок до появления исходников может быть и полгода, и год.
А можно вместо глобального отключения страничной защиты найти pte страницы где лежаж векторы и поправить там флаги?
Просто выше верно подметили про smp и стремность такого отлкючения.
Для SMP (а это общий на сегодня случай) нужно обеспечить, чтобы выполнение на критическом фрагменте не было перенесено на другой процессор.
Пожалуй, этот вопрос заслуживает отдельного рассмотрения.
Sign up to leave a comment.
Модификация системного вызова. Часть 2