Когда читаю про то, что 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)?
Не пропускать знаки препинания, ведь даже если забыл правила пунктуации, то можно подглядеть в первоисточник.
Если под первоисточником понимается "референсный" текст, а не учебник русского языка, то автор того же вопроса разумно уточнил, что если погуглил текст, а потом поставил пароль, то с точки зрения паранойи уже не всё так хорошо. Впрочем, я бы в большей степени опасался возможности социальной инженерии. Эта байка с башорга кажется мне вполне логичной. Но, да, подстановки, на первый взгляд, делают угадывание сложнее.
Вот тут как раз обсуждается вопрос про строчки из песен. В частности, указывается неочевидная на первый взгляд, но вполне очевидная на второй вещь, что если выбирать N слов подряд, то увеличение N почти никак не влияет на количество возможных паролей, даже чуть уменьшает (хотя, конечно "3, 4 или 5 слов" — это больше вариантов чем "всегда 3"). Но ведь тут есть та же опасность, что и с секретными вопросами — эту информацию можно случайно раскрыть в обычной беседе и даже не заметить.
Так я тоже умею, но почему-то от этой идеи отказался — то ли даже переключение терминалов тормозило, то ли SysRq привычнее, то ли ещё что — надо при случае попробовать. Но есть ещё проблема: чтобы зайти в систему в текстовой консоли, нужно, чтобы запустился bash, а у меня он ещё и bash-completions подгружает, а это уже не так быстро...
… а вот когда приложения начнут активно свопиться, и система перестанет реагировать на пользовательские команды (или это только я такой невезучий?), вместо кнопки Reset поможет сочетание Alt-SysRq(PrtScr)-F (запустить OOM-Killer). По умолчанию оно отключено по соображениям безопасности, поскольку может убить что угодно — lock screen, например. Соответственно, если для вас это не проблема, но вы не хотите мучиться из-за ухода в своп, можно разрешить все (или некоторые) комбинации в /etc/sysctl.d/10-magic-sysrq.conf (там, на самом деле, полно разных Alt-SysRq-комбинаций — вплоть до принудительного kernel panic).
По основательности напомнило Копирайт на команду /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)?Если под первоисточником понимается "референсный" текст, а не учебник русского языка, то автор того же вопроса разумно уточнил, что если погуглил текст, а потом поставил пароль, то с точки зрения паранойи уже не всё так хорошо. Впрочем, я бы в большей степени опасался возможности социальной инженерии. Эта байка с башорга кажется мне вполне логичной. Но, да, подстановки, на первый взгляд, делают угадывание сложнее.
Вот тут как раз обсуждается вопрос про строчки из песен. В частности, указывается неочевидная на первый взгляд, но вполне очевидная на второй вещь, что если выбирать N слов подряд, то увеличение N почти никак не влияет на количество возможных паролей, даже чуть уменьшает (хотя, конечно "3, 4 или 5 слов" — это больше вариантов чем "всегда 3"). Но ведь тут есть та же опасность, что и с секретными вопросами — эту информацию можно случайно раскрыть в обычной беседе и даже не заметить.
Так я тоже умею, но почему-то от этой идеи отказался — то ли даже переключение терминалов тормозило, то ли SysRq привычнее, то ли ещё что — надо при случае попробовать. Но есть ещё проблема: чтобы зайти в систему в текстовой консоли, нужно, чтобы запустился bash, а у меня он ещё и bash-completions подгружает, а это уже не так быстро...
… а вот когда приложения начнут активно свопиться, и система перестанет реагировать на пользовательские команды (или это только я такой невезучий?), вместо кнопки Reset поможет сочетание
Alt-SysRq(PrtScr)-F(запустить OOM-Killer). По умолчанию оно отключено по соображениям безопасности, поскольку может убить что угодно — lock screen, например. Соответственно, если для вас это не проблема, но вы не хотите мучиться из-за ухода в своп, можно разрешить все (или некоторые) комбинации в/etc/sysctl.d/10-magic-sysrq.conf(там, на самом деле, полно разныхAlt-SysRq-комбинаций — вплоть до принудительного kernel panic).