Безопасно ли анализировать файл / proc /?

Хотя файлы в /proc отображаются как обычные файлы в пользовательском пространстве, они не являются файлами, а объектами, которые поддерживают стандартные файловые операции из пользовательского пространства (open, read, close). Обратите внимание, что это совсем не так, как обычный файл на диске, который изменяется ядром.

Все ядро ​​выполняет печать своего внутреннего состояния в свою собственную память с помощью функции sprintf -like, и эта память копируется в пользовательское пространство всякий раз, когда вы вызываете системный вызов read(2).

Ядро обрабатывает эти вызовы совершенно по-другому, чем обычные файлы, что может означать, что весь моментальный снимок данных, которые вы будете читать, может быть готов в то время, когда вы его open(2), а ядро ​​удостоверяется, что параллельные звонки являются последовательными и атомными. Я не читал это нигде, но на самом деле не имеет смысла быть иначе.

Мой совет - взглянуть на реализацию файла proc в вашем конкретном вкусе Unix. Это действительно проблема реализации (как и формат и содержимое вывода), которые не соответствуют стандарту.

Простейшим примером может быть реализация файла uptime proc в Linux. Обратите внимание на то, как весь буфер создается в функции обратного вызова, переданной в single_open.

/proc - это виртуальная файловая система: на самом деле она просто дает удобный обзор внутренних элементов ядра. Это определенно безопасно читать (вот почему это здесь), но это рискованно в долгосрочной перспективе, так как внутренние эти виртуальные файлы могут развиваться с более новой версией ядра.

ИЗМЕНИТЬ

Дополнительная информация доступна в proc документации в документе Linux kernel doc, глава 1.4. Сеть Я не могу найти информацию о том, как информация эволюционирует с течением времени. Я думал, что он заморожен на открытом воздухе, но не может дать определенного ответа.

EDIT2

Согласно Sco doc (не linux, но я уверен, что все вкусы * nix ведут себя так)

Хотя состояние процесса и следовательно, содержание /proc файлы могут меняться от момента до мгновенное, одно чтение (2) of/proc файл гарантированно вернет "разумное" представление состояния, которое есть, чтение будет атомарным моментальный снимок состояния процесса. Никакая такая гарантия не распространяется на последовательные чтения применяются к /proc файл для текущего процесса. В добавление, атомарность конкретно не гарантируется для любого ввода-вывода, применяемого к файл as (address-space); содержимое любого адреса процесса пространство может быть одновременно изменено LWP этого процесса или любой другой процесса в системе.

API-интерфейс procfs в ядре Linux обеспечивает интерфейс, обеспечивающий считывание возвращаемых согласованных данных. Прочитайте комментарии в __proc_file_read. Пункт 1) в блоке больших комментариев объясняет этот интерфейс.

При этом, конечно, для реализации конкретного файла proc необходимо правильно использовать этот интерфейс, чтобы убедиться, что его возвращенные данные согласованы. Поэтому, чтобы ответить на ваш вопрос: нет, ядро ​​не гарантирует согласованность файлов proc во время чтения, но предоставляет средства для реализации этих файлов для обеспечения согласованности.

У меня есть источник для Linux 2.6.27.8, так как я сейчас разрабатываю драйверы на встроенной цели ARM.

Файл... linux-2.6.27.8-lpc32xx/net/ipv4/raw.c в строке 934 содержит, например,

    seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
            " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d\n",
            i, src, srcp, dest, destp, sp->sk_state,
            atomic_read(&sp->sk_wmem_alloc),
            atomic_read(&sp->sk_rmem_alloc),
            0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
            atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));

который выводит

[wally@zenetfedora ~]$ cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 15160 1 f552de00 299
   1: 00000000:C775 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 13237 1 f552ca00 299
...

в функции raw_sock_seq_show(), которая является частью иерархии функций обработки procfs. Текст не генерируется до тех пор, пока запрос read() не будет сделан из файла /proc/net/tcp, разумный механизм, поскольку чтение procfs, безусловно, намного реже, чем обновление информации.

Некоторые драйверы (например, мои) реализуют функцию proc_read с помощью одного sprintf(). Дополнительным осложнением в реализации основных драйверов является обработка потенциально очень длинного вывода, который может не соответствовать промежуточному буферу пространства ядра во время одного чтения.

Я тестировал это с помощью программы, использующей 64-килобайтный буфер чтения, но в моей системе создается буфер пространства ядра 3072 байта для proc_read для возврата данных. Для получения большего количества возвращаемого текста требуется несколько вызовов с продвигающимися указателями. Я не знаю, какой правильный способ сделать возвращенные данные согласованными, когда требуется более одного ввода-вывода. Конечно, каждая запись в /proc/net/tcp является самосогласованной. Существует вероятность того, что линии бок о бок являются моментальными снимками в разное время.

За исключением неизвестных ошибок, в /proc нет условий гонки, что приведет к чтению поврежденных данных или сочетанию старых и новых данных. В этом смысле это безопасно. Однако по-прежнему сохраняется состояние гонки, что большая часть данных, которые вы читаете из /proc, потенциально устарела, как только она сгенерирована, и даже более того, к тому времени, когда вы доберетесь до ее чтения/обработки. Например, процессы могут умереть в любое время, и новому процессу может быть назначен один и тот же pid; единственные идентификаторы процесса, которые вы можете использовать без условий гонки, - это ваши собственные дочерние процессы ". То же самое касается сетевой информации (открытые порты и т.д.) И действительно большая часть информации в /proc. Я считаю плохую и опасную практику полагаться на то, что любые данные в /proc являются точными, за исключением данных о вашем собственном процессе и, возможно, его дочерних процессах. Конечно, может быть полезно представить другую информацию от /proc пользователю/администратору для информативного/ведения журнала /etc. целей.

Когда вы читаете файл /proc, ядро ​​вызывает функцию, которая была заранее зарегистрирована, чтобы быть функцией чтения для этого файла proc. См. Функцию __proc_file_read в файле fs/proc/generic.c.

Следовательно, безопасность чтения proc только настолько же безопасна, как функция, которую ядро ​​вызывает для удовлетворения запроса на чтение. Если эта функция должным образом блокирует все данные, которые она затрагивает и возвращает вам в буфер, то ее можно безопасно читать с использованием этой функции. Поскольку файлы proc, подобные тем, которые используются для удовлетворения запросов на чтение /proc/net/tcp, уже давно существуют и прошли тщательный обзор, они настолько безопасны, насколько вы могли бы попросить. На самом деле многие распространенные утилиты Linux полагаются на чтение из файловой системы proc и форматирование вывода по-другому. (Сверху моей головы я думаю, что "ps" и "netstat" делают это).

Как всегда, вам не нужно об этом говорить; вы можете посмотреть на источник, чтобы успокоить свои страхи. Следующая документация из proc_net_tcp.txt сообщает вам, где "читать" функции для /proc/net/tcp live, поэтому вы можете посмотреть фактический код, который запускается при чтении из этого файла proc и убедиться, что нет блокирующие опасности.

В этом документе описаны интерфейсы /proc/net/tcp и /proc/net/tcp 6.
Обратите внимание, что эти интерфейсы устарел в пользу tcp_diag.        Эти интерфейсы /proc предоставляют информацию о текущем активном TCP соединений, и tcp4_seq_show() в net/ipv4/tcp_ipv4.c и tcp6_seq_show() в net/ipv6/tcp_ipv6.c, соответственно.