Но вот внизу, канал по прежнему останется двунаправленным.
Мне понятно что вы здесь показываете, но непонятно зачем. Зачем вам принципиально однонаправленный канал?
Дело даже не в том «есть исходники» или «нет исходников».
А в том, может ли вы предоставлять свой проект потребителю в виде модуля, который динамически подгрузится к любому ядру и внесёт свои изменения… или вы должны будете предоставлять заказчику «своё самое лучшее» пересобранное ядро, или убеждать его наложить на ядро ваши патчи и пересобрать ядро.
Отгадайте с 3-х раз в какое место вас пошлёт заказчик? ;-)
В этом нет необходимости, к нужному процессу можно присоединиться после его запуска.
Это не важно, запущен особым образом, или к нему подключиться после запуска… речь о том, чтобы контролировать системные запросы от любого процесса (всех!), запущенного стандартным образом, командной строкой… или вообще от любого процесса, запущенного как угодно: демон, сервис… без разницы.
Цель ведь не в том, чтобы выловить системные вызовы из одного конкретного процесса… да ещё запущенного каким-то особым образом, под трасировщиком. Цель в том, чтобы контролировать все системные вызовы от всех запускаемых процессов, а потом уже решать что с этим системным вызовом делать… или ничего не делать.
Для патча sys_call_table на стоковых x86_64 ядрах я написал вот такую функцию
На 64-бит архитектуре всё становится куда интереснее не в том, чтобы патчить sys_call_table (дело не хитрое), а в том, чтобы перехватить в своих целях все варианты выполнения системного вызова. что становится горомоздко из-за вариантов выполнения как 32-бит, так и 64-бит приложений.
Повторю схему, которую здесь уже рядом статье показывали:
в листинге номер два есть одна хоть и незначительная, но все же проблема:
Нет такой проблемы ;-)
Во-первых, проблема эта известна, описана и ссылка показана в тексте: WP: Safe or Not?.
Во-вторых, проблема в SMP не возникнет из-за cli / sti, хотя можно её оградить и более сложным образом, испольуя макросы preempt_disable() и preempt_enable_no_resched(). Лучше ли это? Не знаю…
В-третьих, когда пишется текст, хотелось бы его упростить «до нельзя», не акцентируясь на детали: описывать схему — чтобы кто-то из читающих смог ним оспользоваться, а не показывать насколько пишущий умён ;-)
Так делать нельзя, короче, если вам нужно модифицировать read only страницу памяти — то для этого следует выставлять атрибуты доступа в PTE описывающей эту страницу
В-четвёртых, этот способ хорошо известен, показан, например, вот здесь: Кошерный способ модификации защищённых от записи областей ядра Linux (в комментариях). Там же (в статье) предложен ещё один способ… лучший, наверное, по сравнению… и с вашим и с нашим ;-). Способов много. Какой из них лучше трудно судить.
Как-раз поиска по сигнатуре и хотелось избежать. Поиск по сигнатуре многократно описан, например здесь же рядом: Встраивание в ядро Linux: перехват системных вызовов (уж лучше так). Но зачем искать по сигнатуре, которая в любой момент может поменяться, если достаточно простого kallsyms_lookup_name( «sys_call_table» ). В вашем коде сигнатура сохраняется только для X86_64 (даже для I386 всё не так), а kallsyms_lookup_name() работает на любой платформе.
Одна из интереснейших серий статей… на общем фоне довольно посредственных.
И наехали, затюкали автора — о чём попало, только не о том, о чём написана статья.
Вполне может быть и так…
Но уже много лет существует отчётливая тенденция уносить всё что возможно унести — из драйвера в юзерспейс: это и libusb, и файловая система FUSE.
Описываемое устройство не быстрое, переключения контекста там не страшны, а вот возможности завалить систему из-за программной ошибки в модуле ядра нет.
Отличный комментарий!
Именно комментарий (разбор) текста статьи, а не раздувание срача Windows vs Linux.
Хоть одному комментатору не лень было потерять время и показать, что публикация по аргументированности своей — дерьмо.
Мне понятно что вы здесь показываете, но непонятно зачем. Зачем вам принципиально однонаправленный канал?
Дело даже не в том «есть исходники» или «нет исходников».
А в том, может ли вы предоставлять свой проект потребителю в виде модуля, который динамически подгрузится к любому ядру и внесёт свои изменения… или вы должны будете предоставлять заказчику «своё самое лучшее» пересобранное ядро, или убеждать его наложить на ядро ваши патчи и пересобрать ядро.
Отгадайте с 3-х раз в какое место вас пошлёт заказчик? ;-)
Это не важно, запущен особым образом, или к нему подключиться после запуска… речь о том, чтобы контролировать системные запросы от любого процесса (всех!), запущенного стандартным образом, командной строкой… или вообще от любого процесса, запущенного как угодно: демон, сервис… без разницы.
На 64-бит архитектуре всё становится куда интереснее не в том, чтобы патчить sys_call_table (дело не хитрое), а в том, чтобы перехватить в своих целях все варианты выполнения системного вызова. что становится горомоздко из-за вариантов выполнения как 32-бит, так и 64-бит приложений.
Повторю схему, которую здесь уже рядом статье показывали:
Нет такой проблемы ;-)
Во-первых, проблема эта известна, описана и ссылка показана в тексте: WP: Safe or Not?.
Во-вторых, проблема в SMP не возникнет из-за cli / sti, хотя можно её оградить и более сложным образом, испольуя макросы preempt_disable() и preempt_enable_no_resched(). Лучше ли это? Не знаю…
В-третьих, когда пишется текст, хотелось бы его упростить «до нельзя», не акцентируясь на детали: описывать схему — чтобы кто-то из читающих смог ним оспользоваться, а не показывать насколько пишущий умён ;-)
В-четвёртых, этот способ хорошо известен, показан, например, вот здесь: Кошерный способ модификации защищённых от записи областей ядра Linux (в комментариях). Там же (в статье) предложен ещё один способ… лучший, наверное, по сравнению… и с вашим и с нашим ;-). Способов много. Какой из них лучше трудно судить.
И наехали, затюкали автора — о чём попало, только не о том, о чём написана статья.
Просто какой-то паноптикум дегенератов!
Но комментарии — это какой-то кураж… долбоёпов!
Вполне может быть и так…
Но уже много лет существует отчётливая тенденция уносить всё что возможно унести — из драйвера в юзерспейс: это и libusb, и файловая система FUSE.
Описываемое устройство не быстрое, переключения контекста там не страшны, а вот возможности завалить систему из-за программной ошибки в модуле ядра нет.
Это, конечно, ста-а-а-а-аж ...;-)
Более чем достаточный, чтобы сметь поучать других.
А здесь автор попросту безбожно врёт, рассказывает сказки и не краснеет.
Именно комментарий (разбор) текста статьи, а не раздувание срача Windows vs Linux.
Хоть одному комментатору не лень было потерять время и показать, что публикация по аргументированности своей — дерьмо.
OS Windows ;-)
Что за модель? Желательно, если можно, с какими-то URL на страницы устройства и/или производителя.
Все мы и так знаем, что Windows во много-много раз круче ;-)
Или статья и написана вашим учеником (подчинённым?… нужное подчеркнуть) для того, чтобы холивар поднять с новой силой?
P.S. тем более, что обсуждается здесь статья, позиционирующаяся, вроде как, как Open Source и как его правильно понимать ;-)