не требует быть системным вызовом для работы (т.е. не требует ядерных привилегий)
Но тогда, насколько я понял, (стабильный?) интерфейс программа-ядро начнёт состоять не только из "вызовов функций", но и из read-only страниц памяти. vDSO, случайно, не лежит внутри конкретного скомпилированного ядра? У меня сложилось ощущение, что это такой способ не выдумывать стабильного интерфейса на содержимое этих страниц (о совместимости которого потом придётся задумываться), а выдать более понятные "геттеры" с интерфейсом обычной функции, которые хоть формально и не требуют ядерных привилегий, но жутко implementation-specific.
Как говорится, "Жесть, читать до конца". Цинизм прохождения первого уровня насмешил. А на пятом вспомнился анекдот про "За использование неопределённого поведения в особо крупных размерах приговаривается к 40 годам обратной совместимости", ещё подумалось: "А как же в исходниках JVM поковыряться?" — и тут уровень 6...
Недавно пытался кросскомпилировать библиотеку APR с помощью MinGW, но завяз где-то в системных хедерах. Решил погуглить по запросу apache portable runtime mingw. Вторая ссылка в гугле ведёт на tomdeman <dot> com/apache-portable/apache-portable-runtime-mingw.html — шикарную по своей наглости и наивности страницу...
Когда читаю про то, что Ext4 хорошая ФС, но на Винде нужны хитрые сторонние драйверы, вспоминается проект Linux kernel library. Фактически, люди портировали ядро на архитектуру "процесс POSIX/Win32". Сейчас вот попытался по-быстрому набросать статейку про использование родных ФС Linux kernel на Винде, но с ходу кросс-компилировать не удалось: liblkl.dll собрать получилось, а вот cptofs.c / cpfromfs.c зависят от argp.h и на Винде не собираются. Хотел скомпилировать lklftpd, но завяз на сборке Apache Portable Runtime с помощью MinGW. А вот на Маке, вполне возможно, ещё и lklfuse соберётся, и будет счастье. Disclaimer: я не знаю, насколько это качественный порт, и не разрушит ли он ФС с важными данными.
На случай, если кто-то задумается: "Блин, хочу такое же, но я на Линуксе". Оно есть (во всяком случае, похожее). Есть упоминания о reverse debug в GDB (там записывается каждая выполненная инструкция). Также есть эпичный проект от Mozilla: rr — он записывает только недетерминированное поведение (системные вызовы, rdtsc, ...) и имеет некоторые ограничения (в частности, работает, насколько я помню, только под Linux и на относительно свежих процессорах от Intel; недавно, вроде, пытались добавить поддержку AMD Ryzen, интересно, чем закончилось) — заявляется оверхед на запись чуть ли не x1.5 и меньше. В QEMU тоже, вроде, какой-то record-replay добавляли...
<sarcasm> Разработчики компилятора OCaml тоже так думали </sarcasm>
А если серьёзно, то наивно, конечно, ожидать, что вот только начал программировать, написал 20 строчек кода и словил глюк процессора. Но не удивлюсь, если новичок, напоровшийся на undefined behavior в C, будет уверен, что наткнулся на баг в компиляторе, который неправильно компилирует.
Сам я разработчиком под ядро не являюсь, поэтому оценивать не берусь, но натыкался на такую книгу (переводы и т.д. / читать здесь). Она не то, чтобы прицельно про разработку драйверов — насколько я понимаю, человек изучал кодинг под ядро, читал исходники и документацию и попутно писал. То есть это не истина в последней инстанции, но может пригодиться — в том числе для развлечения почитать — там много всего описано. :)
Насколько я понимаю, проблема в том, что статически все UB не отловить. Возможно, вы имеете в виду, что, например, разыменование указателя должно быть разыменованием (и падать на NULL), но что, если это обломает компилятору какую-нибудь хорошую оптимизацию. Но это — ладно — просто доопределим поведение. А если *((int*)rand()) — как здесь гарантированно упасть?
А если программе 10 лет и пишут ее 100500 программистов?
Можно попробовать Undefined Behavior Sanitizer в Clang или GCC. Но он отлавливает только то, что реально произошло в процессе работы, и не уверен, что весь UB можно отловить хотя бы в run-time.
На всякий случай, если вдруг понадобится: эту команду имеет смысл искать по содержимому пакетов — например, на Debian/Ubuntu она лежит в perf-tools-unstable (а на Ubuntu их, похоже, даже две версии).
Есть ещё интересная, но экспериментальная, команда execsnoop, которая через трассировку ядра (так что, теоретически, что-то может сломаться на низком уровне, но у меня не ломалось) показывает, кому эти PID принадлежат. У меня два из них, как и следовало ожидать — это lsof -ccrome ... и grep -i chrome, третий — с ходу не понял, четвёртого не было (ну или я команду не точно вбил).
Так нет, я никого и не принуждаю :) Просто чтобы людей простотой линуксовой командной строки не запугивать предложил ещё одну альтернативу. Ну, и если уж придираться, то в скрипте такое писать мне было бы страшновато, поскольку мало ли, как поменяется формат вывода ps. Или, например, на моей системе ps aux выводит ещё и командные строки программ — вдруг, там где-то упоминается chrome (более того, наверное, там упоминается grep -i chrome)… Я тоже не уверен, что killall всегда работает идеально. Но точек, где можно ошибиться, в случае killall, видимо, меньше.
Объясните, пожалуйста, для человека знакомого лишь с предпосылками, но не подробностями Rust: мне казалось, что основные идеи Rust — это "бесконтрольный доступ опасен, обложим всё compile-time проверками, максимально затруднив написание опасного кода". Не являются ли эти примеры попыткой выкосить все хорошие нововведения Раста, чтобы они не мешали писать код, как раньше. Я понимаю, что в низкоуровневых библиотеках будет что-то подобное, но, казалось бы, их должны один раз написать, очень тщательно проверить их интерфейсы на безопасность, а потом пользоваться этими интерфейсами (не реализуя их каждый раз у себя)?
Понятно. Значит, придётся кешировать :) Впрочем, в случае одного процесса и большого количества повторных запросов это в любом случае нужно делать. А вот для сбора информации обо всей системе — да, проблема...
Скажите, пожалуйста, жив ли ещё этот проект и поддерживает ли ядро на данный момент этот или какой-то другой механизм быстрого получения информации о процессах (например, аналогичной содержащейся в /proc/PID/maps)?
Не пропускать знаки препинания, ведь даже если забыл правила пунктуации, то можно подглядеть в первоисточник.
Если под первоисточником понимается "референсный" текст, а не учебник русского языка, то автор того же вопроса разумно уточнил, что если погуглил текст, а потом поставил пароль, то с точки зрения паранойи уже не всё так хорошо. Впрочем, я бы в большей степени опасался возможности социальной инженерии. Эта байка с башорга кажется мне вполне логичной. Но, да, подстановки, на первый взгляд, делают угадывание сложнее.
Но тогда, насколько я понял, (стабильный?) интерфейс программа-ядро начнёт состоять не только из "вызовов функций", но и из read-only страниц памяти. vDSO, случайно, не лежит внутри конкретного скомпилированного ядра? У меня сложилось ощущение, что это такой способ не выдумывать стабильного интерфейса на содержимое этих страниц (о совместимости которого потом придётся задумываться), а выдать более понятные "геттеры" с интерфейсом обычной функции, которые хоть формально и не требуют ядерных привилегий, но жутко implementation-specific.
Как говорится, "Жесть, читать до конца". Цинизм прохождения первого уровня насмешил. А на пятом вспомнился анекдот про "За использование неопределённого поведения в особо крупных размерах приговаривается к 40 годам обратной совместимости", ещё подумалось: "А как же в исходниках JVM поковыряться?" — и тут уровень 6...
Недавно пытался кросскомпилировать библиотеку APR с помощью MinGW, но завяз где-то в системных хедерах. Решил погуглить по запросу apache portable runtime mingw. Вторая ссылка в гугле ведёт на tomdeman <dot> com/apache-portable/apache-portable-runtime-mingw.html — шикарную по своей наглости и наивности страницу...
По основательности напомнило Копирайт на команду /bin/true
Когда читаю про то, что Ext4 хорошая ФС, но на Винде нужны хитрые сторонние драйверы, вспоминается проект Linux kernel library. Фактически, люди портировали ядро на архитектуру "процесс POSIX/Win32". Сейчас вот попытался по-быстрому набросать статейку про использование родных ФС Linux kernel на Винде, но с ходу кросс-компилировать не удалось:
liblkl.dllсобрать получилось, а вотcptofs.c/cpfromfs.cзависят отargp.hи на Винде не собираются. Хотел скомпилировать lklftpd, но завяз на сборке Apache Portable Runtime с помощью MinGW. А вот на Маке, вполне возможно, ещё иlklfuseсоберётся, и будет счастье. Disclaimer: я не знаю, насколько это качественный порт, и не разрушит ли он ФС с важными данными.На случай, если кто-то задумается: "Блин, хочу такое же, но я на Линуксе". Оно есть (во всяком случае, похожее). Есть упоминания о reverse debug в GDB (там записывается каждая выполненная инструкция). Также есть эпичный проект от Mozilla: rr — он записывает только недетерминированное поведение (системные вызовы,
rdtsc, ...) и имеет некоторые ограничения (в частности, работает, насколько я помню, только под Linux и на относительно свежих процессорах от Intel; недавно, вроде, пытались добавить поддержку AMD Ryzen, интересно, чем закончилось) — заявляется оверхед на запись чуть ли не x1.5 и меньше. В QEMU тоже, вроде, какой-то record-replay добавляли...Если кто не видел эту чудесную историю. Но тут уж и близко не новичок, конечно.
<sarcasm> Разработчики компилятора OCaml тоже так думали </sarcasm>
А если серьёзно, то наивно, конечно, ожидать, что вот только начал программировать, написал 20 строчек кода и словил глюк процессора. Но не удивлюсь, если новичок, напоровшийся на undefined behavior в C, будет уверен, что наткнулся на баг в компиляторе, который неправильно компилирует.
Сам я разработчиком под ядро не являюсь, поэтому оценивать не берусь, но натыкался на такую книгу (переводы и т.д. / читать здесь). Она не то, чтобы прицельно про разработку драйверов — насколько я понимаю, человек изучал кодинг под ядро, читал исходники и документацию и попутно писал. То есть это не истина в последней инстанции, но может пригодиться — в том числе для развлечения почитать — там много всего описано. :)
Насколько я понимаю, проблема в том, что статически все UB не отловить. Возможно, вы имеете в виду, что, например, разыменование указателя должно быть разыменованием (и падать на NULL), но что, если это обломает компилятору какую-нибудь хорошую оптимизацию. Но это — ладно — просто доопределим поведение. А если
*((int*)rand())— как здесь гарантированно упасть?Можно попробовать Undefined Behavior Sanitizer в Clang или GCC. Но он отлавливает только то, что реально произошло в процессе работы, и не уверен, что весь UB можно отловить хотя бы в run-time.
На всякий случай, если вдруг понадобится: эту команду имеет смысл искать по содержимому пакетов — например, на Debian/Ubuntu она лежит в
perf-tools-unstable(а на Ubuntu их, похоже, даже две версии).Есть ещё интересная, но экспериментальная, команда
execsnoop, которая через трассировку ядра (так что, теоретически, что-то может сломаться на низком уровне, но у меня не ломалось) показывает, кому эти PID принадлежат. У меня два из них, как и следовало ожидать — этоlsof -ccrome ...иgrep -i chrome, третий — с ходу не понял, четвёртого не было (ну или я команду не точно вбил).Кстати, в качестве более безопасной, чем парсинг
ps aux, альтернативы, видимо, можно использовать lsof с ключом-t. Сам, впрочем, не пользовался.Так нет, я никого и не принуждаю :) Просто чтобы людей простотой линуксовой командной строки не запугивать предложил ещё одну альтернативу. Ну, и если уж придираться, то в скрипте такое писать мне было бы страшновато, поскольку мало ли, как поменяется формат вывода
ps. Или, например, на моей системеps auxвыводит ещё и командные строки программ — вдруг, там где-то упоминается chrome (более того, наверное, там упоминаетсяgrep -i chrome)… Я тоже не уверен, чтоkillallвсегда работает идеально. Но точек, где можно ошибиться, в случаеkillall, видимо, меньше.А если
killall -KILL program_name? Или речь о том, что не находит все PID? Кстати, вman killallговорится даже о поиске по регулярному выражению.Объясните, пожалуйста, для человека знакомого лишь с предпосылками, но не подробностями Rust: мне казалось, что основные идеи Rust — это "бесконтрольный доступ опасен, обложим всё compile-time проверками, максимально затруднив написание опасного кода". Не являются ли эти примеры попыткой выкосить все хорошие нововведения Раста, чтобы они не мешали писать код, как раньше. Я понимаю, что в низкоуровневых библиотеках будет что-то подобное, но, казалось бы, их должны один раз написать, очень тщательно проверить их интерфейсы на безопасность, а потом пользоваться этими интерфейсами (не реализуя их каждый раз у себя)?
Понятно. Значит, придётся кешировать :) Впрочем, в случае одного процесса и большого количества повторных запросов это в любом случае нужно делать. А вот для сбора информации обо всей системе — да, проблема...
del
Скажите, пожалуйста, жив ли ещё этот проект и поддерживает ли ядро на данный момент этот или какой-то другой механизм быстрого получения информации о процессах (например, аналогичной содержащейся в
/proc/PID/maps)?Если под первоисточником понимается "референсный" текст, а не учебник русского языка, то автор того же вопроса разумно уточнил, что если погуглил текст, а потом поставил пароль, то с точки зрения паранойи уже не всё так хорошо. Впрочем, я бы в большей степени опасался возможности социальной инженерии. Эта байка с башорга кажется мне вполне логичной. Но, да, подстановки, на первый взгляд, делают угадывание сложнее.