Представлен (https://lkml.org/lkml/2013/7/30/869) второй выпуск проекта ktap (https://github.com/ktap/ktap), в рамках которого развивается новая система динамической трассировки работы ядра Linux, предоставляющая собственный скриптовый язык для создания сценариев. Сценарии могут быть использованы как для автоматизации выявления узких мест, так и для изменения параметров работы ядра. В том числе, скрипты ktap могут использоваться для изменения поведения систем ядра и даже для реализации дополнительной функциональности. Код проекта распространяется (https://github.com/ktap/ktap) под лицензией GPL и оформлен в виде модуля для ядра Linux (поддерживаются ядра начиная с ветки 3.1), не требующего применения дополнительный патчей.
От существующих систем, таких как SystemTap и DTrace, ktap отличается иной архитектурой и другими принципами организации выполнения скриптов трассировки. Скрипты преобразуются (https://github.com/ktap/ktap/blob/master/doc/design.txt) в байткод, загружаемый и выполняемый уже работающим центральным модулем ktap, что не требует сборки и загрузки отдельных модулей ядра из расчёта отдельный модуль для каждого из сценариев трассировки. Байткод выполняется внутри специальной регистровой виртуальной машины ktapvm (подобный подход близок к DTrace и отличается от SystemTap, в котором используется транслятор). Байткод является универсальным и может быть использован без пересборки в ядрах на системах с различной архитектурой, т.е. скрипт может быть собран и проверен на ПК разработчика и потом выполнен на встраиваемом устройстве на базе другой процессорной архитектуры.Синтаксис (https://github.com/ktap/ktap/blob/master/doc/syntax.txt) языка сценариев напоминает язык Си и отличается в основном методом объявления переменных (в ktap используются динамические переменные, без явного объявления), поддержкой вместо массивов табличных структур (хэши ключ/значение, позволяющие указывать t["key"] = 10), отсутствием необходимости завершения строки знаком ';'. Замедление работы ядра при активации ktap не превышает 10%, после интеграции JIT в виртуальную машину ktapvm паразитную нагрузку планируется свести к 3-5%.
В новой версии расширены возможности скриптового языка, добавлен новый синтаксис для определения блоков трассировки (ключевые слова trace и trace_end), задания фильтров трассировки, трассировки функций и использования uprobe/uretprobe. В утилиту ktap добавлны средства для написания однострочников, например, "ktap -e 'trace "syscalls:*" function (e) { print(e) }'". Унифицирован интерфейс для взаимодействия с подсистемой ядра perf. Проведена оптимизация производительности. В дополнение к ранее поддерживаемым 32- и 64-разрядным системам x86, в новом выпуске появилась поддержка архитектур ARM и PowerPC, а также обеспечена возможность работы совместно с ядром preempt-rt.
Из возможностей также отмечается поддержка установки точек трассировки (tracepoints), анализ работы системных вызовов, использование контрольных проверок kprobes, uprobe и kretprobes, отслеживание вызова обработчиков событий от таймера, оценка состояния стека. Для использования в скриптах поставляется встроенная библиотека функций (https://github.com/ktap/ktap/blob/master/doc/library.txt) для упрощения работы с различными низкоуровневыми механизмами трассировки.URL: https://lkml.org/lkml/2013/7/30/869
Новость: http://www.opennet.me/opennews/art.shtml?num=37563
Какое-то жалкое подобие DTrace.
Так оно и есть, плюсую
А почему "жалкое"?
Нищебродское подделие наперсточников
Нигде почему-то не упомянуто, что байткод выполняется в виртуальной машине, 1-в-1 повторяющей виртуальную машину Lua. Сравните https://github.com/lua/lua/blob/master/src/lvm.c и https://github.com/ktap/ktap/blob/master/interpreter/vm.c
Смотреть функции static void ktap_execute(ktap_state *ks) и void luaV_execute (lua_State *L).
> Нигде почему-то не упомянуто, что байткод выполняется в виртуальной машине, 1-в-1
> повторяющей виртуальную машину LuaНу почему же нигде. На сайте в README.md: "simple but powerful script language(forked by lua, proven to be fast)"
Да, не заметил :(
Офигеть, куда Lua пролез...
(пошел менять работу, с Haskell на Lua!)
понятно теперь на чем вирусы для линукса будут писать.
Вирусы для линукса исторически пишутся на сях.
Но, к сожалению, не работают. И это проблема вызвана не ЯП, а юниксовым механизмом разграничения доступа.
> Вирусы для линукса исторически пишутся на сях.
> Но, к сожалению, не работают. И это проблема вызвана не ЯП, а
> юниксовым механизмом разграничения доступа.работают с привилегиями пользователя
> работают с привилегиями пользователяа что, пользователям до сих пор дом и /tmp монтируют без noexec? ну, ССЗБ.
Зачем дом монтировать в noexec?
> Зачем дом монтировать в noexec?а зачем «обычному юзеру» права на исполнение чего-либо в доме? «обычный юзер» даже скрипты не пишет, у него от одного вида терминала начинается синдром «немоугнеумеюнезнаюнехочудайтекнопачку!»
Ограничение доступа?
Где в этом смысл? Мне, как пользователю важно не потерять свои файлы, а не файлы рута/системы.
> Ограничение доступа?
> Где в этом смысл? Мне, как пользователю важно не потерять свои файлы,
> а не файлы рута/системы.но при этом ты таки скачал непонятный бинарь из непонятного источника и запустил? сам виноват. система выживет. а неосторожный пользователь… его проблемы. сколько раз говорили же: не тяни в рот что попало!
http://nginx.org/en/docs/nginx_dtrace_pid_provider.html#see_...